Difference between revisions of "System backup"

From ArchWiki
Jump to navigation Jump to search
(update interlanguage links)
Tag: wiki-scripts
 
(253 intermediate revisions by 62 users not shown)
Line 1: Line 1:
[[Category:System recovery (English)]]
+
[[Category:Backup]]
[[Category:HOWTOs_(English)]]
+
[[cs:Full system backup with rsync]]
{{Template:Merge|Rsync}}
+
[[es:System backup]]
This [[rsync]] script allows creating a full backup copy across file-systems. It is setup so that the copy includes intact booting capabilities, optionally excluding selected files.
+
[[ja:Rsync によるフルシステムバックアップ]]
 +
[[pt:System backup]]
 +
[[zh-hans:System backup]]
 +
[[zh-hant:Full system backup with rsync]]
 +
{{Related articles start}}
 +
{{Related|Synchronization and backup programs}}
 +
{{Related|System maintenance#Backup}}
 +
{{Related|Disk cloning}}
 +
{{Related|Migrate installation to new hardware}}
 +
{{Related|File recovery}}
 +
{{Related articles end}}
  
The approach has benefits over omitting system files by just copying personal data; if the system becomes corrupted in the main partition, overcoming the problem means booting into the backup as opposed to identifying and reinstalling affected programs followed by copying back personal data.
+
It is important to regularly backup system and user data stored for example in {{ic|/etc}}, {{ic|/home}}, {{ic|/var}} and for server installations, also {{ic|/srv}}.
  
Instructions were converted from [http://bbs.archlinux.org/viewtopic.php?id=83071 this forum post].
+
== Using Btrfs snapshots ==
  
==Partitioning==
+
See [[Btrfs#Snapshots]] and [[Snapper]].
<!-- this section might be wrong. investigating on veracity/replacing scripts... -->
 
File-systems in the backup ''source'' and ''destination'' device need to be the same type. It could work with a mix of ext3 and ext4, but this hasn't been tested. For booting capabilities, the partitioning on the backup source does not matter, whereas the device the backup will be copied to (destination device) needs to have a single partition.
 
  
==Files==
+
== Using LVM snapshots ==
Two files are needed; the backup script and a file stating which files to include/exclude from the backup source.
 
  
===Backup script===
+
See [[LVM#Snapshots]] and [[Create root filesystem snapshots with LVM]].
This script is very simple. It rsyncs in archive mode, ensuring that symbolic links, devices, attributes, permissions and ownerships, among other file attributes are preserved, while excluding files that match the patterns from the include/exclude list.
 
  
Save it as {{filename|rbackup.sh}} and make it executable:
+
== Using rsync ==
{{file|name=rbackup.sh|content=
 
#!/bin/sh
 
# rsync backup script
 
  
sudo sh -c "
+
See [[rsync#As a backup utility]].
    rsync -av --delete-excluded --exclude-from=backup.lst / $1;
 
    touch $1/BACKUP
 
"
 
}}
 
  
;Backup source; {{codeline|/}}
+
== Using tar ==
:In this case it's performing a backup on the whole root.
 
  
;Backup destination; {{codeline|$}}1
+
See [[Full system backup with tar]].
:Passed as an argument to the script; e.g. {{filename|/media/mountpoint}}
 
  
;Include/exclude list; {{codeline|<nowiki>--exclude-from=backup.lst</nowiki>}}
+
== Using SquashFS ==
:This example uses {{filename|backup.lst}}.
 
  
===Include/exclude list===
+
See [[Full system backup with SquashFS]].
As deciding which files should populate this list can be difficult, here's a typical backup example that excludes common files that don't need to be backed up, such as the vast majority of {{filename|/dev}}. Note that specifying every desired file or directory in {{codeline|Include}} is not needed; this section only acts as a filter for statements in {{codeline|Exclude}}. This file is in the traditional include/exclude rsync format.
 
  
Save the following as {{filename|backup.lst}}:
+
== Bootable backup ==
{{file|name=backup.lst|content=
 
# Include
 
+ /dev/console
 
+ /dev/initctl
 
+ /dev/null
 
+ /dev/zero
 
  
# Exclude
+
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 bootloader's configuration file.
- /dev/*
 
- /proc/*
 
- /sys/*
 
- /tmp/*
 
}}
 
  
;Exclude: Content in system directories; {{filename|/dev}}, {{filename|/proc}}, {{filename|/sys}} and {{filename|/tmp}} are excluded because they are created by the system at runtime. Note that the directories themselves need to be preserved since they are ''not'' regenerated at boot.
+
This section assumes that you backed up the system to another drive or partition, that your current bootloader is working fine, and that you want to boot from the backup as well.
  
;Include: Even though {{filename|/dev}} is excluded, 4 files that are not dynamically created by [[udev]] need to be preserved. These are {{filename|console}}, {{filename|initctl}}, {{filename|null}} and {{filename|zero}}.
+
=== Update the fstab ===
  
==Backing up==
+
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:
Substitute {{filename|/dev/'''sdb1'''}} along with {{filename|/media/'''mountpoint'''}} as apropiate, and mount the destination device:
 
# mount /dev/sdb1 /media/mountpoint
 
  
Run the backup script:
+
  /dev/sda''X''    /             ''ext4''      defaults                0  1
  # ./rbackup.sh /media/mountpoint/
 
  
rsync will then backup to that destination.
+
Remember to use the proper device name and filesystem type.
  
==Boot setup==
+
=== Update the bootloader's configuration file ===
After the sync is finished, a boot loader needs to be installed on the backup destination and configuration in the destination's {{filename|/boot/grub/menu.lst}} needs to be amended to reflect the new location.
 
  
These instructions assume [[GRUB]] is the bootloader of choice.
+
For [[Syslinux]], all you need to do is duplicate the current entry, except pointing to a different drive or partition.
  
===Install bootloader===
+
{{Tip|Instead of editing {{ic|syslinux.cfg}}, you can also temporarily edit the menu during boot. When the menu shows up, press the {{ic|Tab}} key and change the relevant entries. Partitions are counted from one, drives are counted from zero.}}
Open the GRUB console:
 
# grub
 
  
Direct the install towards the destination device:
+
For [[GRUB]], it is recommended that you automatically [[GRUB#Generate_the_main_configuration_file|re-generate the main configuration file]].  If you want to freshly install all GRUB files to somewhere other than {{ic|/boot}}, such as {{ic|/mnt/newroot/boot}}, use the {{ic|--boot-directory}} flag.
root (hd'''1,0''')
 
setup (hd'''1''')
 
  
The '''{{codeline|root}}''' command should point to where the GRUB files are located--in this case, "{{codeline|hd 1}}" means the second storage device ({{filename|/dev/sdb}}) and "{{codeline|0}}" is the first partition ({{filename|/dev/sdb''1''}}).
+
Also verify the new menu entry in {{ic|/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]]:
  
Whereas the '''{{codeline|setup}}''' command should point to where the actual boot loader is to be installed. In this example it is installed to the [[MBR]] of the second storage device.
+
$ lsblk -no NAME,UUID /dev/sd''XY''
  
===Configure bootloader===
+
where {{ic|/dev/sd''XY''}} is the desired partition (e.g. {{ic|/dev/sdb3}}). To list the UUIDs of partitions GRUB thinks it can boot, use ''grep'':
The problem here is that even though the boot loader installs correctly, its menu entries are for the main system's partitions, not the backup system's.
 
  
It's possible to fix this by creating a custom {{filename|/boot/grub/menu.lst}} for the backup destination. In order to do so, modify {{filename|rbackup.sh}} so that it copies a custom {{filename|menu.lst}}:
+
# grep UUID= /boot/grub/grub.cfg
{{file|name=rbackup.sh|content=
 
#!/bin/sh
 
# rsync backup script
 
  
sudo sh -c "
+
=== First boot ===
    rsync -av --delete-excluded --exclude-from=backup.lst / $1;
 
    '''cp ~/custom.menu.lst $1/boot/grub/menu.lst;'''
 
    touch $1/BACKUP
 
"
 
}}
 
  
{{tip|instead of replacing {{filename|menu.lst}} with a custom version solely for the backup, add a new GRUB entry pointing to the backup device or simply edit GRUB's menu during boot time.}}
+
Reboot the computer and select the right entry in the bootloader. 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.

Latest revision as of 07:26, 19 August 2019

It is important to regularly backup system and user data stored for example in /etc, /home, /var and for server installations, also /srv.

Using Btrfs snapshots

See Btrfs#Snapshots and Snapper.

Using LVM snapshots

See LVM#Snapshots and Create root filesystem snapshots with LVM.

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 bootloader's configuration file.

This section assumes that you backed up the system to another drive or partition, that your current bootloader 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 bootloader's configuration file

For Syslinux, all you need to do is duplicate the current entry, except pointing to a different drive or partition.

Tip: Instead of editing 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 bootloader. 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.