Backup SSD to HDD

Discussions in English on using Fedora
#1

I have a 1T SSD that I want to reformat.
So I am doing a full backup to my HDD

It is like
sda1 600MB efi
sda2 100MB MSreserved
sda3 67GB ntfs
sda4 1GB ext4 /boot
sda5 900GB btrfs

Please let me know how to do it in a better way:

  1. For each subvol in btrfs volume, using btrfs send/receive to the HDD’s btrfs volume
  2. remove sda5 using fdisk
  3. use qemu-img to dump the remaing data into a qcow2 file
    qemu-img -f ram -O qcow2 /dev/sdb my1Tssd-sda1234.qcow2

My problem is:
The qcow2 file is way larger than 100GB now and still in progress.

What is the correct method to avoid copying those 900GB space not belonging to any partitions?

#2

Have you heard of the rsync command?

2 Likes
#3

Yes.

For for Linux filesystem, I mainly use btrfs, so they are covered by btrfs send/receive for my case.

But for the EFI, MSReserved and ntfs WindowsOS partitions, I want to keep them “bootable” state.

I know how to rebuild /boot partition, so leave it out is OK for me also.

If rsync can allow me to restore the drive in a bootable state, then I will be eager to learn about it.

#4

The “rsync” command syncs two different folders/devices/drives/locations. Every system admin knows this command; theoretically. Imaging is a different animal… You can easy mount a EFI partition, copy the UEFI Windows boot files to a new EFI partition, and clone the NTFS partition moving the OS to a new drive. The extra Microsoft and OEM partitions are not so easily cloned without hardware cloning.

1 Like
#5

To my knowledge and abilities… The UUID has to match the partition.

2 Likes
#6

Yes, UUID, needs extra care.

That’s why I started with qemu-img convert for the “whole” disk. If qemu-img can skip those 900G space that is not belonging to any partitions, it will be great.

#7

You can actually online move the entire Btrfs file system preserving UUIDs:
Split Fedora 33 BTRFS in two disks - #4 by chrismurphy

2 Likes
#8

My personally need is to preserve data - as in Linux / Fedora it is easy to fix boot loader problems (I never tried secure boot anyway) interactively. So changing UUID, rebuild /boot from scratch is relatively use to do inactively.

But for Windows boot, my confidence is not as high as for Linux boot.

#9

It is a healthy fear, you have to preserve the Windows NTFS UUID for the boot loader to load the OS or use terminal commands to rebuild the EFI boot for the new UUID.

#10 
sudo -i
cd /
tar -acf bootefi.tar boot/
mount /dev/sda5 /mnt/ssd
mount /dev/sdb1 /mnt/backup
cd /mnt/ssd
btrfs sub snap -r root root.20210127
btrfs send root.20210127 | btrfs receive /mnt/backup

This way boot and ESP are backed up and in the snapshot that you send/receive. If sdb1 (HDD) isn’t Btrfs then you can use send -f option instead of receive.

sda3 is not backed up with this method so you’ll need a Windows specific backup for that; or maybe you could use guestfish to mount it and turn it into a sparse qcow2 image if you prefer. But such block copies aren’t exactly backups, they’re clones - bit unwieldy and aren’t easy to keep up to date.

1 Like