Arch linux backup system

System backup

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]

Using Btrfs snapshots

Using LVM snapshots

Using rsync

Using tar

Using 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.

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 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/95-bootbackup.hook

[Trigger] Operation = Upgrade Operation = Install Operation = Remove Type = Path Target = usr/lib/modules/*/vmlinuz [Action] Depends = rsync Description = Backing up /boot. When = PostTransaction Exec = /usr/bin/rsync -a --delete /boot /.bootbackup

Источник

Full system backup with tar

Reason: Uses a half-baked script instead of explaining basic options and referring to the manual, duplication with articles such as Help:Reading, numerous Help:Style issues (Discuss in Talk:Full system backup with tar)

This article will show you how to do a full system backup with tar.

Backing up with tar has the advantages of using compression that can help save disk space, and simplicity. The process only requires several steps, they are:

1. Boot from a LiveCD
2. Change root to the Linux install
3. Mount additional (if any) partitions/drives
4. Add exclusions
5. Use the backup script to backup

To minimize downtime the backup can alternatively be performed on a running system using LVM snapshots, if all filesystems reside on LVM volumes.

Boot with LiveCD

Many Linux bootable CDs, USBs. have the ability to let you change root to your install. While changing root is not necessary to do a backup, it provides the ability to just run the script without need to transfer it to a temporary drive or having to locate it on the filesystem. The Live medium must be of the same architecture that your Linux install currently is (i.e. i686 or x86_64).

Changing root

First you should have a scripting environment set up on your current Linux install. If you do not know what that is, it means that you are able to execute any scripts that you may have as if they are regular programs. If you do not, see this article on how to do that. What you will need to do next is change root, to learn more about what changing root is, read this. When you change root, you do not need to mount any temporary file systems ( /proc , /sys , and /dev ). These temporary file systems get populated on boot and you actually do not want to backup them up because they can interfere with the normal (and necessary) population process which can change on any upgrade. To change root, you will need to mount your current Linux installs root partition. For example:

# mkdir /mnt/arch # mount /dev/your-partition-or-drive 

Use fdisk -l to discover you partitions and drives. Now chroot:

# cd /mnt/arch # chroot . /bin/bash

Warning: Do not use arch-chroot to chroot into the target system — the backup process will fail as it will try to back up temporary file systems, all system memory and other interesting things. Use plain chroot instead.

This example obviously uses bash but you can use other shells if available. Now you will be in your scripted environment (this is provided that you have your ~/.bashrc sourced on entry):

# If using bash, source the local .bashrc source ~/.bashrc

Mount other partitions

Other partitions that you use (if any) will need to be mounted in their proper places (e.g. if you have a separate /home partition).

Exclude file

tar has the ability to ignore specified files and directories. The syntax is one definition per line. tar also has the capability to understand regular expressions (regexps). For example:

# Not old backups /opt/backup/arch-full* # Not temporary files /tmp/* # Not the cache for pacman /var/cache/pacman/pkg/ .

Backup script

Backing up with bsdtar is straight-forward process. Here is a basic script that can do it and provides a couple checks. You will need to modify this script to define your backup location, and exclude file (if you have one), and then just run this command after you have chroot ed and mounted all your partitions. Note that GNU tar with —xattrs will not preserve extended attributes.

#!/bin/bash # full system backup # Backup destination backdest=/opt/backup # Labels for backup name #PC=$ pc=pavilion distro=arch type=full date=$(date "+%F") backupfile="$backdest/$distro-$type-$date.tar.gz" # Exclude file location prog=$ # Program name from filename excdir="/home//.bin/root/backup" exclude_file="$excdir/$prog-exc.txt" # Check if chrooted prompt. echo -n "First chroot from a LiveCD. Are you ready to backup? (y/n): " read executeback # Check if exclude file exists if [ ! -f $exclude_file ]; then echo -n "No exclude file exists, continue? (y/n): " read continue if [ $continue == "n" ]; then exit; fi fi if [ $executeback = "y" ]; then # -p, --acls and --xattrs store all permissions, ACLs and extended attributes. # Without both of these, many programs will stop working! # It is safe to remove the verbose (-v) flag. If you are using a # slow terminal, this can greatly speed up the backup process. # Use bsdtar because GNU tar will not preserve extended attributes. bsdtar --exclude-from=$exclude_file --acls --xattrs -cpvzf $backupfile / fi

Restoring

To restore from a previous backup, mount all relevant partitions, change the current working directory to the root directory, and execute

$ bsdtar --acls --xattrs -xpzf backupfile 

replacing backupfile with the backup archive. Removing all files that had been added since the backup was made must be done manually. Recreating the filesystem(s) is an easy way to do this.

Backup with parallel compression

To back up using parallel compression (SMP), use pbzip2 (Parallel bzip2):

# bsdtar -cvf /path/to/chosen/directory/etc-backup.tar.bz2 -I pbzip2 /etc

Store etc-backup.tar.bz2 on one or more offline media, such as a USB stick, external hard drive, or CD-R. Occasionally verify the integrity of the backup process by comparing original files and directories with their backups. Possibly maintain a list of hashes of the backed up files to make the comparison quicker.

Restore corrupted /etc files by extracting the etc-backup.tar.bz2 file in a temporary working directory, and copying over individual files and directories as needed. To restore the entire /etc directory with all its contents execute the following command as root:

# bsdtar -xvf etc-backup.tar.bz2 -C /

Источник

Full system backup with SquashFS

Reason: Too specifically geared towards one specific sort of backup (using an entire device as the destination), reads like a blog post, content organization is unclear. (Discuss in Talk:Full system backup with SquashFS)

Compressed backup archives of whole filesystems can be made in the SquashFS format. Backup and retrieval takes relatively less time with its random access capability, but any kind of modification other than appending is not yet possible.

Device File	Description
/dev/sdB	Backup Drive
/dev/sdL	Live Medium
/dev/sdSRC	Drive to Be Backed Up

Pros and cons

• No partitioning, no guessing how much size is required
• SquashFS should be supported by most rescue disks
• Random access [citation needed] , with a plain mount
• Duplicate files are removed by default (unless -no-duplicates flag is on)

• Access Control Listsare not yet supported, and therefore not backed up
• Not accessible from Windows 1
• Appendable but impossible to remove things from it
• To use the disk for some other purposes, you have to destroy the backup 2

1. squashfs-tools-ng may support SquashFS image files but Windows itself does not support partitionless drives at all.
2. Do not grab the lifebuoy when you need a swim ring. File sharing and backup should be in separate disks. Please buy adequate backup hardware.

Prepare the backup drive

• All data on the backup drive will be lost.
• All data on machine may be lost if an incorrect device file is specified.

1. Wipe out all partitions /dev/sdBN , then the partition table /dev/sdB , with wipefs.
2. Synchronize all write caches # sync
3. Inform the OS of partition table changes # partprobe
4. Check for bad blocks:
   • If the backup drive is an SSD, use S.M.A.R.T..
   • If the backup drive is an HDD, use badblocks.

Prepare a live medium

Note: Creating SquashFS filesystem requires squashfs-tools , which is included in the official Arch Linux installation image.

Back up

1. Boot the live medium
2. When the boot loader menu appears, press ‘e’
3. Append copytoram to kernel parameters
4. # udisksctl power-off -b /dev/sdL (requires archiso releng with udisks2 in packages.x86_64)
5. Make sure the live medium stops spinning and disconnect it

Mount filesystems you would like to backup. (e.g. /dev/sdSRC to /mnt)

# fsck /dev/sdSRC # mount -o ro /dev/sdSRC /mnt

• All data on the backup drive will be lost.
• All data on machine may be lost if an incorrect device file is specified.

# mksquashfs /mnt /dev/sdB \ -not-reproducible \ -xattrs \ -wildcards \ -noappend \ -progress \ -mem 5G \ -e \ var/cache/pacman/pkg \ var/lib/pacman/sync \ var/log/journal \ efi \ boot/grub \ boot/initramfs-linux"*".img \ boot/vmlinuz-linux

-not-reproducible Slightly increase backup speed -noappend Overwrite -mem RAM granted to mksquashfs -e List of exclude dirs/files

(Optional) Test backup in QEMU

$ sudo chown $USER:$USER /dev/sdB

$ qemu-system-x86_64 \ -kernel /boot/vmlinuz-linux \ -append "root=/dev/sdB ro loglevel=3 init=/usr/lib/systemd/systemd" \ -initrd /boot/initramfs-linux-fallback.img \ -drive file=/dev/sdB,index=0,media=disk,format=raw \ -m virtual_machine_ram_in_MiB \ --enable-kvm \ -cpu host

(Optional) Inspect backup

# date --date=@"$(unsquashfs -mkfs-time /dev/sdB)"

More superblock information

The factual accuracy of this article or section is disputed.

Reason: unsquashfs -stat and df gives different sizes (Discuss in Talk:Full system backup with SquashFS)

# COUNT="$(unsquashfs -stat /dev/sdB | grep -F 'Filesystem size' | cut -d' ' -f3)" # echo "$COUNT Byte" # numfmt --to=iec-i "$COUNT" # head -c "$COUNT" /dev/sdB | sha1sum | tee -a sha1sum.txt

Retrieve file from backup

# mount /dev/sdB /mnt # cp /mnt/path/to/file /path/to/destination 

Restore backup

This article or section needs expansion.

To make system bootable after restore:

Источник