Previously, I have been using Clonezilla on a CLI Debian USB drive to perform system backups. However, I now have a portable SSD with a full Fedora Workstation install that I wish to use as a dedicated rescue disk. However, I can’t find Clonezilla anywhere but 3rd party repos (which I try to avoid).
What approach would you use to perform a ‘native Fedora’ system backup?
FWIW, I use zfs send, but ZFS isn’t “native Fedora”. Fedora Linux uses Btrfs by default and it has a similar send command. If I were using a more standard Fedora Linux installation, I would probably try to script a btrfs send ... command of some sort to backup my filesystem(s).
There are some examples of using btrfs send toward the end of the following article.
Perhaps I scanned this too quickly, but I gather this technique is used for data backup, rather than system backup (viz. disk image). I don’t see how the system partition could be made a subvolume…
IIUC, the OS filesystem is a subvolume. If you are using Btrfs and you run cat /proc/cmdline to check what parameters were passed to the kernel, you should see the name of the Btrfs subvolume that contains your OS listed. Btrfs doesn’t actually mount the top-level volume by default. You should be able to snapshot and send or receive the OS subvolume just like any other. (Well, almost. You’ll have to reboot and change that subvolume parameter to actually use a restored “root” subvolume.)
More examples of working with the root subvolume can be found here:
OK, got some homework to do here. Just to be sure of the big picture. I want to save the system backup to a different drive, in case the system drive fails. Using this method, would I still need to boot from my rescue SSD. AFAIK, it’s not possible to image a mounted drive.
FOLLOW UP:
Since / is a separate subvolume, would it possible to simply copy it to another drive as a backup. Then to restore, simply copy it back, overwriting the original?
It should be possible to keep a “rescue” OS in a parallel subvolume on your main SSD. You would also need to take care to keep the necessary “boot” files (the kernel+initramfs for the rescue system and the config file under loader/entries on the boot partition that would contain the Grub boot menu option).
Actually though, you could pass rd.break=mount when booting one of the kernels which would drop you to a mini rescue environment from which you should be able to perform recovery operations (btrfs snapshot/rollback/clone/send/receive etc.). Just make sure you have a (known) root password set before you generate your initramfses so that you will be able to sign-in to the recovery environment.
Yes. You could do that as long as it isn’t in use. You could do it from the dracut rescue shell, for example (i.e. rd.break=mount).
I once demo’d doing something similar here (step 6):
Note that using btrfs send would be much more efficient than using cp. Also, Btrfs should allow you to do “incremental” backups (you wouldn’t have to copy the whole filesystem every time – you could just copy the new data and “add to” an existing backup).
I use ddrescue to clone my entire resident SSD drive to an external SSD. It’s worked great so far. But, I don’t do this more than twice a month.
I have a Bitlocker’d Windows partition that only very rarely boot, so I usually only clone my EFI, /boot, and (encrypted) btrfs partitions once I’ve cloned the entire drive the first time.
Also, I don’t have any idea on whether I’m wearing out my SSDs doing this.
I have another HDD same capacity as my SSD for full backup.
Setup is MBR, Luks encryption. So I rsync the boot partition and partclone the btrfs partition. Can handle LUKS. I can post the complete script if need be but basically it does:
mkdir /mnt/sdd2
mkdir /mnt/sda2
mount /dev/sdd2 /mnt/sdd2
mount /dev/sda2 /mnt/sda2
rsync -aAXv --delete --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} /mnt/sda2/ /mnt/sdd2/
umount /mnt/sda2
umount /mnt/sdd2
partclone.btrfs -b -s /dev/sda3 -o /dev/sdd3
Here’s an example output using LUKS this time:
# sending incremental file list
# deleting vmlinuz-6.6.4-100.fc38.x86_64
# deleting symvers-6.6.4-100.fc38.x86_64.xz
# deleting initramfs-6.6.4-100.fc38.x86_64.img
# deleting config-6.6.4-100.fc38.x86_64
# deleting System.map-6.6.4-100.fc38.x86_64
# deleting .vmlinuz-6.6.4-100.fc38.x86_64.hmac
# ./
# deleting loader/entries/c9b852c1fd8c44b8aaa12d3e5c7a3992-6.6.4-100.fc38.x86_64.conf
# grub2/
# grub2/grubenv
# loader/entries/
#
# sent 12,112 bytes received 356 bytes 24,936.00 bytes/sec
# total size is 268,426,865 speedup is 21,529.26
# Enter passphrase for /dev/sdd3:
# Enter passphrase for /dev/sda3:
# Partclone v0.3.25 http://partclone.org
# Starting to back up device (/dev/mapper/cryptsource) to device (/dev/mapper/cryptdest)
# Calculating bitmap... Please wait... done!
# File system: BTRFS
# Device size: 499.0 GB = 30457472 Blocks
# Space in use: 165.1 GB = 10078402 Blocks
# Free Space: 333.9 GB = 20379070 Blocks
# Block size: 16384 Byte
# Elapsed: 00:23:14, Remaining: 00:00:00, Completed: 100.00%, Rate: 8.08GB/min,
# Current block: 30436705, Total block: 30457472, Complete: 100.00%
# Total Time: 00:23:14, Ave. Rate: 8.08GB/min, 100.00% completed!
# Syncing... OK!
# Partclone successfully cloned the device (/dev/mapper/crypsource) to the device (/dev/mapper/cryptdest)
# Cloned successfully.
It’s s lot faster than clonezilla, dd or pv.
I’ve never read about partclone until you posted this. So, thanks!
I admit, though, that I’m a little bit confused about why you’d need to decrypt your LUKS partition. Does this not clone the entire partition?