I learned that tools such as clonezilla cannot omit free blocks when the disk is encrypted, which is a huge problem, since the backup drive always needs to have at least the same size as the source drive - even if the latter contains mostly free space! This is impractical and not how backups should work.

Let's assume a standard Linux installation with a partition structure such as this (encrypted, LUKS on LVM). How do you create a bootable, file-based backup?

Idea: Use cp -a to copy all files from the source to the backup drive.

=> How to reproduce the partition structure from the terminal? Are there Linux built-in tools for this job? And will cp copy files that are currently open/in use (hot transfer)?

The idea, obviously, is to create a slim & sleek Bash script that could be run, ideally, directly from any running source system:

- Creating backup -

1.) Mount empty USB flash drive to running source system
2.) Run Bash script (hot transfer of all files and partition structure)
3.) Bootable, file-based backup is created

- Restoring backup -

1.) Mount backup USB flash drive to empty host machine
2.) Boot the backup system
3.) Run Bash script (partitioning of host drive, hot-transfer of all files)

...finished! Reboot, remove backup USB flash drive, enjoy restored system.

Note: If I'm correct, the resulting backup will not be encrypted. But this seems to be a necessary trade-off in order to use cp from within the unlocked system and thereby avoid creating these gigantic bit-by-bit images/clones. Plus, an encryption can always be added afterwards.

  • Yes, you can copy each file or folder at a time. However, this is far slower than dd or other backup tools. Also, since each file takes up integral allocation units, it would take more room than a compressed backup image. You would also need to copy system files, including boot sectors, to have a safe image in case of disaster. – DrMoishe Pippik Jul 21 at 0:19
  • You can have the backup encrypted. You would need to have it use LUKs, then mount it, then copy the files. – davidgo Jul 21 at 4:56
  • Also, its better to encrypt then copy rather then try convert to encryption later - both because in the Interim you won't have protection, but also its possible some unencrypted data won't actually be encrypted when you convert it - especially on SSD's – davidgo Jul 21 at 4:58

It turns out that rsync is the perfect tool of choice. It supports the complete and hot transfer of an entire file system from within a running system:

rsync -avxHAX / /dev/[backup_drive]/

The encryption/decryption issue is solved by unlocking the encrypted disk beforehand:

cryptsetup luksOpen /dev/[source_drive] && rsync -avxHAX / /dev/[backup_drive]/

The remaining task is to reproduce everything outside the scope of rsync, i.e. outside the file system, meaning the boot sector (= first 512 Bytes on the drive) containing the bootloader and partition tables. For this, dd or ddrescue could be used:

cryptsetup luksOpen /dev/[source_drive] && rsync -avxHAX / /dev/[backup_disk]/ && dd if=/dev/[source_drive] of=/dev/[backup_drive] bs=446 count=1

Here, bs=446 is used instead of bs=512 in the assumption that the backup drive and partitions will have a different size, therefore omitting the partition table and signature bytes.

This should result in a complete, hot-transferred (from the running system), bootable, sparse (file-based) Linux disk backup done from the terminal.

To do: Encrypt the backup!

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.