There are many ways to backup a Linux system. A few years ago, I settled on file level backup using rsync because it's robust and flexible (can be adapted for almost any scenario, including virtual machines). When I started, though, I discovered there aren't many articles on the subject, especially the critical aspect of how to restore. I ended up working out the details by trial-and-error. Here is what I'm using currently. You'll probably want to adapt for your own circumstances and preferences. Note: rsync is command line only. If you're not comfortable with terminal, this strategy isn't going to work for you.
Preparation. The foundation of my backup plan is a plain text file with ready-to-run command strings. To use, I copy-and-paste into Terminal. Personally, I find bash scripts more trouble than they're worth, but if you prefer to work that way, go for it. I have a copy of the file in my regular Linux notes, of course, and also copy it to the target backup drive. If not already, label system partition (makes command strings easier to write). Organize folders at target, especially important if backing up more than one system. For reference, copy output of lsblk -f and cat /etc/fstab to backup file. I also copy a screenshot of the system drive as shown by GParted.
Backup. I run backup with the system shut down. It's cleaner and easier. I do system backup once per month, which is good interval for rebooting anyway. I run the commands from a full install flash drive (a 'sidecar'); a live session also works. I like to have three snapshots, the current one plus the prior two. Each snapshot is independent, no links or updates.
Mount partitions, both source and target. I use Disks (in repo, installed by default in Gnome and Cinnamon). File Manager also can be used. Both methods use udisks, which mounts the partitions as folders in /media/$USER. The regular mount command can be used, but you'll have to set up mount points manually and modify command strings to match. Delete oldest snapshot, using Command Line or File Manager as Root (I use the latter).
The general form of rsync command is [sudo] rsync -flags --options /path/to/source/ /path/to/target. For system backup, I use something in this form:Notice slash after source; it's essential. The reference to Bookworm at source is the label of the system partition; the reference to Debian at target is a folder on a partition called System-Backups; snapshot folder will be created when command is run. To unpack the flags, per the rsync man page, -a = archive (implies -rlptgoD, i.e., recursive (include sub-directories); copy symlinks; preserve permissions, timestamps, groups, owner, devices and specials); -x = one file system (don’t cross filesystem boundaries); -H = preserve hardlinks (symlinks covered by -a); -A = preserve Access Control Lists; -X = preserve extended attributes.
If the dry run looks okay, up-arrow to retrieve command string, backspace to remove -n flag, and hit Enter. The dry run will have reported aggregate size of the transfer (that's what --info=progress2 does), so it's easy to gauge progress as the command runs. Once returned to prompt, run sync so will know when buffers have cleared (i.e., transfer is actually complete).
Exclusions. I've set up my main system so it's simple to back up, with separate data and swap partitions. Other cases can be a little more complicated. For example, if using a single large partition, you want to backup /home separately. Exclude it from system backup by adding --exclude=home after the flags, i.e., before --info. Notice, no slash, i.e., home not /home. If you use Timeshift, exclude its snapshot archive from backup, --exclude=timeshift. And, imho, there's no point to backing up a swapfile (create a new one after restore, if it comes to that), --exclude=swapfile. You can have multiple exclusions.
Config files. Meaning, the hidden "dot" files and folders in Home. With a data partition (my case), /home is on the system partition, contains nothing but config files, and is included in system backup. If using a home partition (automatically excluded by the above form of command) or a single large partition (excluded as described in the preceding paragraph), it's important to make sure config files are backed up one way or another. Either backup all of home at the same time or have two backups, one for data files and another for config files. It doesn't matter how many boxes you use for backup, so long as you have backups of everything somewhere.
Linked snapshots. One can save space at target by linking snapshots, the practical effect of which is that data blocks for files appearing in multiple snapshots are shared. The rsync parameter to achieve this is --link-dest=/path/to/prior/snapshot. FWIW, I used that procedure for about a year, then decided it wasn't worth the trouble. Although it reduces the amount of copying, comparing file lists takes time. Also, it takes longer to delete snapshots with hard links, as inodes need to be modified. Meanwhile, the space savings is scarcely worth talking about in the context of backing up 12 GB of system files (for example) to a 2 TB USB hard drive. The option might make sense in other cases, though, which is why I mention it.
Update while booted. It's possible to update a backup with the system running. Be aware, the system must be shut down for the initial backup, so its file system will be complete. Then, (a) if updating a backup (rather than creating a new one), you want a --delete parameter; and (b) if updating while booted, various directories should be excluded (to avoid loops and temporary files). The rsync parameter is --exclude={/dev,/media,/mnt,/proc,/run,/sys,/tmp} (notice, no spaces) (but yes to slashes); also, the source will be simply / (root), rather than /media/etc. When I did backup this way, I had two snapshots (called Purple and Green), alternated which was updated each month, and kept track of which had been updated last with a note in the backup notes file.
Revert In Place. Meaning, restore the system to its state as of some prior snapshot, e.g., because of an apt update error or an app installation which has gone sideways. Similar to what Timeshift does, only manually and without the bells-and-whistles. For what it's worth, revert-in-place is the main reason I bother with system backup. Hard drive failure is sufficiently rare that I would rely on reinstall (for which I have very detailed notes) rather than invest time in system backups. Some sort of oopsie is more common. Knowing I can revert (pretty easily) to a recent known-good configuration makes me less anxious about installing apps and running updates.
Once you've gotten this far, revert-in-place is pretty simple. Boot sidecar or live session. Mount system and backup partitions. Command in this form:If looks good, remove -n flag and run again. When finished, unmount partitions and shut down sidecar or live session. Boot installed system. Oopsie, what oopsie? Generally will want to run updates, to pick up changes since the snapshot. Update with care, if that's what caused the need to revert in the first place.
Full Restore. So far (knock wood), I've never had to restore from rsync backup, but I have used the procedure I'm about to describe to transfer a system from one computer to another. Also to transfer virtual machines at file level, or to bare metal or vice versa. The core step, file transfer, is the same as already discussed. A few other steps are needed, though, for a complete system.
Partition table. The partition table must be created manually because file level backup knows nothing about partitions. I use GParted. Refer to the screenshot saved previously for details. With file level backup, the new table doesn't need to match the old one exactly, provided each partition is large enough for the files being restored there. Give the partitions labels.
Conform UUIDs. Several files (including fstab but not only) reference partitions by UUID. For a clean restore, we want to reproduce the old UUIDs on the new partition table. The command which does this is tune2fs (mkswap for a swap partition); requires a file system check before it will modify the UUID. So, first something like sudo e2fsck -f /dev/sda1, then sudo tune2fs -U <copy-from-fstab> /dev/sda1. Repeat for all partitions. An EFI partition can't be conformed (tune2fs doesn't work on Windows file systems), so edit fstab to reflect the new EFI partition's UUID; while you're at it, add nofail to the mount parameters (which should be the default anyway, imho).
File transfer. This is a mirror of the backup command. For example:Note: If you excluded folders from backup, e.g., /home, you may need to recreate that folder manually (albeit empty) during restore. If you're using rsync for data file backup (as I do), now would be a good time to restore that backup. Restore other data file backups as appropriate for the tool used to create them (e.g., after booting the restored system, if appropriate).
Install Grub. Assuming a modern computer using UEFI, usually something like:Note: If using a live session to restore, you'll need to install the appropriate Grub package (grub-pc for BIOS or grub-efi-amd64 for UEFI).
Trial Run. Until it has been tested, a backup plan isn't worth the (virtual) paper it's printed on. If you're comfortable with virtualization (KVM/QEMU, VirtualBox, etc.), that's an easy and risk-free way to test these procedures. If not, I recommend doing full install to a USB flash drive (3.0, not 2.0, at least 32 GB), then practice backup-and-restore of that; as it's just a trial, you can save the backup on the main system drive, then delete when done.
Preparation. The foundation of my backup plan is a plain text file with ready-to-run command strings. To use, I copy-and-paste into Terminal. Personally, I find bash scripts more trouble than they're worth, but if you prefer to work that way, go for it. I have a copy of the file in my regular Linux notes, of course, and also copy it to the target backup drive. If not already, label system partition (makes command strings easier to write). Organize folders at target, especially important if backing up more than one system. For reference, copy output of lsblk -f and cat /etc/fstab to backup file. I also copy a screenshot of the system drive as shown by GParted.
Backup. I run backup with the system shut down. It's cleaner and easier. I do system backup once per month, which is good interval for rebooting anyway. I run the commands from a full install flash drive (a 'sidecar'); a live session also works. I like to have three snapshots, the current one plus the prior two. Each snapshot is independent, no links or updates.
Mount partitions, both source and target. I use Disks (in repo, installed by default in Gnome and Cinnamon). File Manager also can be used. Both methods use udisks, which mounts the partitions as folders in /media/$USER. The regular mount command can be used, but you'll have to set up mount points manually and modify command strings to match. Delete oldest snapshot, using Command Line or File Manager as Root (I use the latter).
The general form of rsync command is [sudo] rsync -flags --options /path/to/source/ /path/to/target. For system backup, I use something in this form:
Code:
sudo rsync -axHAXh --info=progress2 /media/$USER/Bookworm/ /media/$USER/System-Backups/Debian/Snapshot-YY.MM.DD -nIf the dry run looks okay, up-arrow to retrieve command string, backspace to remove -n flag, and hit Enter. The dry run will have reported aggregate size of the transfer (that's what --info=progress2 does), so it's easy to gauge progress as the command runs. Once returned to prompt, run sync so will know when buffers have cleared (i.e., transfer is actually complete).
Exclusions. I've set up my main system so it's simple to back up, with separate data and swap partitions. Other cases can be a little more complicated. For example, if using a single large partition, you want to backup /home separately. Exclude it from system backup by adding --exclude=home after the flags, i.e., before --info. Notice, no slash, i.e., home not /home. If you use Timeshift, exclude its snapshot archive from backup, --exclude=timeshift. And, imho, there's no point to backing up a swapfile (create a new one after restore, if it comes to that), --exclude=swapfile. You can have multiple exclusions.
Config files. Meaning, the hidden "dot" files and folders in Home. With a data partition (my case), /home is on the system partition, contains nothing but config files, and is included in system backup. If using a home partition (automatically excluded by the above form of command) or a single large partition (excluded as described in the preceding paragraph), it's important to make sure config files are backed up one way or another. Either backup all of home at the same time or have two backups, one for data files and another for config files. It doesn't matter how many boxes you use for backup, so long as you have backups of everything somewhere.
Linked snapshots. One can save space at target by linking snapshots, the practical effect of which is that data blocks for files appearing in multiple snapshots are shared. The rsync parameter to achieve this is --link-dest=/path/to/prior/snapshot. FWIW, I used that procedure for about a year, then decided it wasn't worth the trouble. Although it reduces the amount of copying, comparing file lists takes time. Also, it takes longer to delete snapshots with hard links, as inodes need to be modified. Meanwhile, the space savings is scarcely worth talking about in the context of backing up 12 GB of system files (for example) to a 2 TB USB hard drive. The option might make sense in other cases, though, which is why I mention it.
Update while booted. It's possible to update a backup with the system running. Be aware, the system must be shut down for the initial backup, so its file system will be complete. Then, (a) if updating a backup (rather than creating a new one), you want a --delete parameter; and (b) if updating while booted, various directories should be excluded (to avoid loops and temporary files). The rsync parameter is --exclude={/dev,/media,/mnt,/proc,/run,/sys,/tmp} (notice, no spaces) (but yes to slashes); also, the source will be simply / (root), rather than /media/etc. When I did backup this way, I had two snapshots (called Purple and Green), alternated which was updated each month, and kept track of which had been updated last with a note in the backup notes file.
Revert In Place. Meaning, restore the system to its state as of some prior snapshot, e.g., because of an apt update error or an app installation which has gone sideways. Similar to what Timeshift does, only manually and without the bells-and-whistles. For what it's worth, revert-in-place is the main reason I bother with system backup. Hard drive failure is sufficiently rare that I would rely on reinstall (for which I have very detailed notes) rather than invest time in system backups. Some sort of oopsie is more common. Knowing I can revert (pretty easily) to a recent known-good configuration makes me less anxious about installing apps and running updates.
Once you've gotten this far, revert-in-place is pretty simple. Boot sidecar or live session. Mount system and backup partitions. Command in this form:
Code:
sudo rsync -axHAXh --delete --info=progress2 /media/$USER/System-Backups/Debian/Snapshot-YY.MM.DD/ /media/$USER/Bookworm -nFull Restore. So far (knock wood), I've never had to restore from rsync backup, but I have used the procedure I'm about to describe to transfer a system from one computer to another. Also to transfer virtual machines at file level, or to bare metal or vice versa. The core step, file transfer, is the same as already discussed. A few other steps are needed, though, for a complete system.
Partition table. The partition table must be created manually because file level backup knows nothing about partitions. I use GParted. Refer to the screenshot saved previously for details. With file level backup, the new table doesn't need to match the old one exactly, provided each partition is large enough for the files being restored there. Give the partitions labels.
Conform UUIDs. Several files (including fstab but not only) reference partitions by UUID. For a clean restore, we want to reproduce the old UUIDs on the new partition table. The command which does this is tune2fs (mkswap for a swap partition); requires a file system check before it will modify the UUID. So, first something like sudo e2fsck -f /dev/sda1, then sudo tune2fs -U <copy-from-fstab> /dev/sda1. Repeat for all partitions. An EFI partition can't be conformed (tune2fs doesn't work on Windows file systems), so edit fstab to reflect the new EFI partition's UUID; while you're at it, add nofail to the mount parameters (which should be the default anyway, imho).
File transfer. This is a mirror of the backup command. For example:
Code:
sudo rsync -axHAXh --info=progress2 /media/$USER/System-Backups/Debian/Snapshot-YY.MM.DD/ /media/$USER/Bookworm -nInstall Grub. Assuming a modern computer using UEFI, usually something like:
Code:
sudo mount /dev/sda2 /mntsudo mount /dev/sda1 /mnt/boot/efi sudo grub-install /dev/sda --boot-directory=/mnt/boot --uefi-secure-bootTrial Run. Until it has been tested, a backup plan isn't worth the (virtual) paper it's printed on. If you're comfortable with virtualization (KVM/QEMU, VirtualBox, etc.), that's an easy and risk-free way to test these procedures. If not, I recommend doing full install to a USB flash drive (3.0, not 2.0, at least 32 GB), then practice backup-and-restore of that; as it's just a trial, you can save the backup on the main system drive, then delete when done.
Statistics: Posted by pbear — 2024-07-05 01:59 — Replies 1 — Views 42