System backup: Difference between revisions
link fix |
Undo revision 842543 by Euzao (talk) - don't make AUR packages with just simple configuration files copy-pasted from the wiki Tag: Undo |
||
| (14 intermediate revisions by 6 users not shown) | |||
| Line 14: | Line 14: | ||
A system backup is <q>the process of backing up the operating system, files and system-specific useful/essential data. [It] primarily ensures that not only the user data in a system is saved, but also the system's state or operational condition. This helps in restoring the system to the last-saved state along with all the selected backup data.</q>[https://www.techopedia.com/definition/29387/system-backup] | A system backup is <q>the process of backing up the operating system, files and system-specific useful/essential data. [It] primarily ensures that not only the user data in a system is saved, but also the system's state or operational condition. This helps in restoring the system to the last-saved state along with all the selected backup data.</q>[https://www.techopedia.com/definition/29387/system-backup] | ||
One common and generally effective method is to follow the 3-2-1 strategy: | |||
* Maintain three copies of your data, | |||
* Use two different types of storage media, | |||
* Store one copy offsite. | |||
== Using Btrfs snapshots == | == Using Btrfs snapshots == | ||
| Line 39: | Line 45: | ||
== Bootable backup == | == Bootable backup == | ||
Having a bootable backup can be useful in case the filesystem becomes corrupt or if an update breaks the system. The backup can also be used as a test bed for updates, with the ''testing'' repo enabled, etc. If you transferred the system to a different partition or drive and you want to boot it, the process is as simple as updating the backup's {{ic|/etc/fstab}} and your | Having a bootable backup can be useful in case the filesystem becomes corrupt or if an update breaks the system. The backup can also be used as a test bed for updates, with the ''testing'' repo enabled, etc. If you transferred the system to a different partition or drive and you want to boot it, the process is as simple as updating the backup's {{ic|/etc/fstab}} and your boot loader's configuration file. | ||
This section assumes that you backed up the system to another drive or partition, that your current | This section assumes that you backed up the system to another drive or partition, that your current boot loader is working fine, and that you want to boot from the backup as well. | ||
=== Update the fstab === | === Update the fstab === | ||
| Line 51: | Line 57: | ||
Remember to use the proper device name and filesystem type. | Remember to use the proper device name and filesystem type. | ||
=== Update the | === Update the boot loader's configuration file === | ||
For [[Syslinux]], all you need to do is duplicate the current entry, except pointing to a different drive or partition. | For [[Syslinux]], all you need to do is duplicate the current entry, except pointing to a different drive or partition. | ||
| Line 69: | Line 75: | ||
=== First boot === | === First boot === | ||
Reboot the computer and select the right entry in the | Reboot the computer and select the right entry in the boot loader. This will load the system for the first time. All peripherals should be detected and the empty folders in {{ic|/}} will be populated. | ||
Now you can re-edit {{ic|/etc/fstab}} to add the previously removed partitions and mount points. | Now you can re-edit {{ic|/etc/fstab}} to add the previously removed partitions and mount points. | ||
| Line 79: | Line 85: | ||
You can copy the boot partition automatically on a kernel update to your {{ic|root}} partition with a [[pacman hook]] (make sure the hook file is owned by root): | You can copy the boot partition automatically on a kernel update to your {{ic|root}} partition with a [[pacman hook]] (make sure the hook file is owned by root): | ||
{{hc|/etc/pacman.d/hooks/95- | {{hc|/etc/pacman.d/hooks/55-bootbackup_pre.hook|2= | ||
[Trigger] | |||
Operation = Upgrade | |||
Operation = Install | |||
Operation = Remove | |||
Type = Path | |||
Target = usr/lib/modules/*/vmlinuz | |||
[Action] | |||
Depends = rsync | |||
Description = Backing up pre /boot... | |||
When = PreTransaction | |||
Exec = /usr/bin/bash -c 'rsync -a --mkpath --delete /boot/ "/.bootbackup/$(date +%Y_%m_%d_%H.%M.%S)_pre"/' | |||
}} | |||
{{hc|/etc/pacman.d/hooks/95-bootbackup_post.hook|2= | |||
[Trigger] | [Trigger] | ||
Operation = Upgrade | Operation = Upgrade | ||
| Line 89: | Line 110: | ||
[Action] | [Action] | ||
Depends = rsync | Depends = rsync | ||
Description = Backing up /boot... | Description = Backing up post /boot... | ||
When = PostTransaction | When = PostTransaction | ||
Exec = /usr/bin/rsync -a --delete /boot /.bootbackup | Exec = /usr/bin/bash -c 'rsync -a --mkpath --delete /boot/ "/.bootbackup/$(date +%Y_%m_%d_%H.%M.%S)_post"/' | ||
}} | |||
== Automation == | |||
Backups that are only manually created are rarely up to date when they are needed. Therefore it is recommended to setup an automated process to ensure backup processes are executed regularly. The most common solutions are provided by [[systemd/Timers]] and [[Cron]]. | |||
For a local system wide backup that requires read access to all files the following systemd timer and service may be useful as a template for automated backup processes. | |||
To use a ''timer'' unit [[enable]] and [[start]] it like any other unit. | |||
{{hc|/etc/systemd/system/backup.timer|2= | |||
[Unit] | |||
Description=Timer for backups | |||
[Timer] | |||
OnCalendar=weekly | |||
Persistent=true | |||
Unit=backup.service | |||
[Install] | |||
WantedBy=timers.target | |||
}} | |||
The following example is configured to run with minimal required permissions while preventing modifications from normal users for increased security. | |||
Note that this example will block the shutdown process when it is initiated while the backup is running. This ensures that the backup is not interrupted, but can lead to a delay during shutdown/reboot if many new files need to be saved. | |||
{{hc|/etc/systemd/system/backup.service|2= | |||
[Unit] | |||
Description=Backup system | |||
[Service] | |||
Type=simple | |||
User=''backupuser'' | |||
AmbientCapabilities=CAP_DAC_READ_SEARCH | |||
CapabilityBoundingSet=CAP_DAC_READ_SEARCH | |||
DevicePolicy=closed | |||
LockPersonality=yes | |||
MemoryDenyWriteExecute=yes | |||
NoNewPrivileges=yes | |||
PrivateDevices=yes | |||
PrivateTmp=yes | |||
ProtectClock=yes | |||
ProtectControlGroups=yes | |||
ProtectHome=read-only | |||
ProtectHostname=yes | |||
ProtectKernelLogs=yes | |||
ProtectKernelModules=yes | |||
ProtectKernelTunables=yes | |||
ProtectProc=invisible | |||
ProtectSystem=full | |||
RemoveIPC=yes | |||
RestrictAddressFamilies=AF_UNIX | |||
RestrictNamespaces=yes | |||
RestrictRealtime=yes | |||
RestrictSUIDSGID=yes | |||
SystemCallFilter=@system-service | |||
UMask=7007 | |||
ExecStart=/usr/local/bin/backup.sh | |||
ExecStop=bash -c 'if [ -n "$MAINPID" ]; then tail --pid="$MAINPID" -f /dev/null; fi' | |||
}} | }} | ||
{{ic|CAP_DAC_READ_SEARCH}} sets the capability that allows bypassing file read permission checks in the file system; thus all files in the file system will be accessible without requiring root permissions. | |||
For remote backups allow the use of network protocols: | |||
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6 | |||
Latest revision as of 06:30, 8 August 2025
A system backup is the process of backing up the operating system, files and system-specific useful/essential data. [It] primarily ensures that not only the user data in a system is saved, but also the system's state or operational condition. This helps in restoring the system to the last-saved state along with all the selected backup data.
[1]
One common and generally effective method is to follow the 3-2-1 strategy:
- Maintain three copies of your data,
- Use two different types of storage media,
- Store one copy offsite.
Using Btrfs snapshots
See Btrfs#Snapshots, #Snapshots and /boot partition, and Snapper.
Using LVM snapshots
See LVM#Snapshots, Create root filesystem snapshots with LVM, and #Snapshots and /boot partition.
Using rsync
See rsync#As a backup utility.
Using tar
See Full system backup with tar.
Using SquashFS
See Full system backup with SquashFS.
Bootable backup
Having a bootable backup can be useful in case the filesystem becomes corrupt or if an update breaks the system. The backup can also be used as a test bed for updates, with the testing repo enabled, etc. If you transferred the system to a different partition or drive and you want to boot it, the process is as simple as updating the backup's /etc/fstab and your boot loader's configuration file.
This section assumes that you backed up the system to another drive or partition, that your current boot loader is working fine, and that you want to boot from the backup as well.
Update the fstab
Without rebooting, edit the backup's fstab by commenting out or removing any existing entries. Add one entry for the partition containing the backup like the example here:
/dev/sdaX / ext4 defaults 0 1
Remember to use the proper device name and filesystem type.
Update the boot loader's configuration file
For Syslinux, all you need to do is duplicate the current entry, except pointing to a different drive or partition.
syslinux.cfg, you can also temporarily edit the menu during boot. When the menu shows up, press the Tab key and change the relevant entries. Partitions are counted from one, drives are counted from zero.For GRUB, it is recommended that you automatically re-generate the main configuration file. If you want to freshly install all GRUB files to somewhere other than /boot, such as /mnt/newroot/boot, use the --boot-directory flag.
Also verify the new menu entry in /boot/grub/grub.cfg. Make sure the UUID is matching the new partition, otherwise it could still boot the old system. Find the UUID of a partition with lsblk:
$ lsblk -no NAME,UUID /dev/sdXY
where /dev/sdXY is the desired partition (e.g. /dev/sdb3). To list the UUIDs of partitions GRUB thinks it can boot, use grep:
# grep UUID= /boot/grub/grub.cfg
First boot
Reboot the computer and select the right entry in the boot loader. This will load the system for the first time. All peripherals should be detected and the empty folders in / will be populated.
Now you can re-edit /etc/fstab to add the previously removed partitions and mount points.
Snapshots and /boot partition
If your file system supports snapshots (e.g., LVM or Btrfs), these will most likely exclude the /boot partition or ESP.
You can copy the boot partition automatically on a kernel update to your root partition with a pacman hook (make sure the hook file is owned by root):
/etc/pacman.d/hooks/55-bootbackup_pre.hook
[Trigger] Operation = Upgrade Operation = Install Operation = Remove Type = Path Target = usr/lib/modules/*/vmlinuz [Action] Depends = rsync Description = Backing up pre /boot... When = PreTransaction Exec = /usr/bin/bash -c 'rsync -a --mkpath --delete /boot/ "/.bootbackup/$(date +%Y_%m_%d_%H.%M.%S)_pre"/'
/etc/pacman.d/hooks/95-bootbackup_post.hook
[Trigger] Operation = Upgrade Operation = Install Operation = Remove Type = Path Target = usr/lib/modules/*/vmlinuz [Action] Depends = rsync Description = Backing up post /boot... When = PostTransaction Exec = /usr/bin/bash -c 'rsync -a --mkpath --delete /boot/ "/.bootbackup/$(date +%Y_%m_%d_%H.%M.%S)_post"/'
Automation
Backups that are only manually created are rarely up to date when they are needed. Therefore it is recommended to setup an automated process to ensure backup processes are executed regularly. The most common solutions are provided by systemd/Timers and Cron.
For a local system wide backup that requires read access to all files the following systemd timer and service may be useful as a template for automated backup processes.
To use a timer unit enable and start it like any other unit.
/etc/systemd/system/backup.timer
[Unit] Description=Timer for backups [Timer] OnCalendar=weekly Persistent=true Unit=backup.service [Install] WantedBy=timers.target
The following example is configured to run with minimal required permissions while preventing modifications from normal users for increased security.
Note that this example will block the shutdown process when it is initiated while the backup is running. This ensures that the backup is not interrupted, but can lead to a delay during shutdown/reboot if many new files need to be saved.
/etc/systemd/system/backup.service
[Unit] Description=Backup system [Service] Type=simple User=backupuser AmbientCapabilities=CAP_DAC_READ_SEARCH CapabilityBoundingSet=CAP_DAC_READ_SEARCH DevicePolicy=closed LockPersonality=yes MemoryDenyWriteExecute=yes NoNewPrivileges=yes PrivateDevices=yes PrivateTmp=yes ProtectClock=yes ProtectControlGroups=yes ProtectHome=read-only ProtectHostname=yes ProtectKernelLogs=yes ProtectKernelModules=yes ProtectKernelTunables=yes ProtectProc=invisible ProtectSystem=full RemoveIPC=yes RestrictAddressFamilies=AF_UNIX RestrictNamespaces=yes RestrictRealtime=yes RestrictSUIDSGID=yes SystemCallFilter=@system-service UMask=7007 ExecStart=/usr/local/bin/backup.sh ExecStop=bash -c 'if [ -n "$MAINPID" ]; then tail --pid="$MAINPID" -f /dev/null; fi'
CAP_DAC_READ_SEARCH sets the capability that allows bypassing file read permission checks in the file system; thus all files in the file system will be accessible without requiring root permissions.
For remote backups allow the use of network protocols:
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6