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?
If you want to go the old way of creating a clone of the existing drive on a new drive with at least the same capacity (which could be swapped in case the existing one fails), you can boot a Fedora Workstation Live ISO, and clone the entire disk from the CLI:
sudo dd if=/dev/<your-existing-drive> of=/dev/<your-backup-drive> bs=64K conv=noerror,sync status=progress
As always, remember that when used incorrectly, dd can destroy data irreversibly.
For creating disk or partition image files via GUI, from the same live ISO you can use GNOME Disks.
Hi,
As dd for example would clone the partition byte for byte, partclone.btrfs would only clone the files, not the empty space. It’s therefore faster. Naturally if your filesystem is almost full, don’t bother and go for dd or pv as in pv < /dev/source_drive > /dev/dest_drive
That part of things is definitely not obvious from a quick read of the man page. But it is a big advantage over ddrescue. I’ve installed it, and I may give that a test run for my next backup.
Thanks again!
I’ve had bad luck with dd in the past. It failed to reproduce things like partition flags consistently for me.
I’ve had bulletproof luck with ddrescue, though, so I’ve got zero motivation to change. Other than the efficiency aspect of partclone also mentioned elsewhere in this thread.
When you point dd (or ddrescue) at a partition (e.g. /dev/sda1), it will only copy the contents of the partition, not the partition metadata (its flags, label, UUID, etc.) which is stored outside of the partition. The partition headers/metadata are stored in the first few sectors of the disk. dd/ddrescue will copy those if and only if you copy the whole disk (e.g. /dev/sda).
Just FYI.
Thanks for that additional info. It makes perfect sense.
The instances I was referring to occurred for full disk “clones”, which were done before I learned about ddrescue.
The latter has been awesome for me, if a bit inefficient.
Good luck. Here’s my complete script. I’ve been using it for over 1 year. It’s tailored for MBR disks and LUKS encrypted Fedora partition. Adjust for your own needs.
#!/bin/bash
destdisk="sdf"
sourcedisk="sda"
mkdir /mnt/${destdisk}2
mkdir /mnt/${sourcedisk}2
mount /dev/${destdisk}2 /mnt/${destdisk}2
mount /dev/${sourcedisk}2 /mnt/${sourcedisk}2
cryptsetup luksOpen /dev/${destdisk}3 cryptdest
cryptsetup luksOpen /dev/${sourcedisk}3 cryptsource
#btrfs check -p --readonly /dev/mapper/cryptsource
#btrfs check -p --repair /dev/mapper/cryptsource
# backup boot sector
dd if=/dev/${sourcedisk} of=/dev/${destdisk} bs=512 count=1
dd if=/dev/${sourcedisk}1 of=/dev/${destdisk}1
# backup boot partition
rsync -aAXv --delete --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} /mnt/${sourcedisk}2/ /mnt/${destdisk}2/
sync
umount /mnt/${sourcedisk}2
umount /mnt/${destdisk}2
# backup fedora partition
partclone.btrfs -b -s /dev/mapper/cryptsource -o /dev/mapper/cryptdest
sync
cryptsetup luksClose cryptsource
cryptsetup luksClose cryptdest
Fsarchiver has been my partition archiving tool of choice for longer than I can remember.
It features compression, encryption and preserves associated flags.
There was a change to the ext4 filesystem in the Spring of 2023 which caused fsarchiver to fail but an update has fixed the incompatibility problems. FYI, the non-updated version of fsarchiver is the only version available via Fedora repos.
For those using btrfs, fsarchiver documentation indicates support for archiving btrfs partitions.
Thanks! This part of the discussion has been educational, for sure. It’s also now clear why you needed to decrypt your LUKS partition. 
My only remaining question is how whether partclone handle a bitlocker partition.
It won’t.
You can either turn bitlocker off first, then use partclone.ntfs and turn bitlocker back on.
Or use dd or pv on that specific partition.
Or Using Dislocker: On Linux, you can use a tool like Dislocker to unlock the BitLocker partition with the recovery key or password, creating a virtual decrypted partition. Partclone could then theoretically back up this decrypted virtual partition, but this process is complex and not officially supported by Partclone. You will need to reencrypt the destination partition afterwards. Here’s the complete procedure, untested:
sudo mkdir /mnt/bitlocker /mnt/decrypted
sudo dislocker -r -V /dev/sda4 -uRECOVERY_KEY -- /mnt/bitlocker
sudo mount -o loop /mnt/bitlocker/dislocker-file /mnt/decrypted
ls /mnt/decrypted
You should see the contents of the NTFS file system. If not, verify the Dislocker command and key.
sudo mkfs.ntfs -f /dev/sdb4
Warning: This wipes /dev/sdb4. Ensure it contains no important data.
sudo partclone.ntfs -c -s /mnt/decrypted -o /dev/sdb4
sudo partclone.ntfs -c -s /mnt/decrypted -o /path/to/backup.img
Then restore to /dev/sdb4:
sudo partclone.ntfs -r -s /path/to/backup.img -o /dev/sdb4
sudo mkdir /mnt/cloned
sudo mount /dev/sdb4 /mnt/cloned
ls /mnt/cloned
Ensure the files match those in /mnt/decrypted.
sudo umount /mnt/decrypted
sudo umount /mnt/cloned
sudo rm -rf /mnt/bitlocker /mnt/decrypted /mnt/cloned