Backups
It is a very good idea to maintain backups of your critical hosts. It is quite important to keep backups of any functioning raspberry pi sdcards in order to make re-building after a disaster relatively painless [note 1].
It is also a good idea to run your critical Linux sdcard based systems with overlayfs to minimise sdcard access to prevent corruption of sdcard filesystems and to prevent the cards wearing out. [note 2]
The latest raspi-config has a Performance menu that offers running overlayfs for the rootfs See Overlay rootfs for background. and for the /boot partition. [note 3]
image backups
Image backups to preserve a working copy are convenient on machines such as:
The advantages are its a verbatim copy of the machine media, but the disadvantages are it is slow and archives can take up more room, unless compressed (which is why I have used compression such as lz4). Follow the backup instructions in Backup and Restore for LVM systems that use Volume Groups and Logical Volumes.
It is a simple matter to live boot the host with a USB device, or in the case of removable media, plugin that media to another host to perform the backups.
It is a simple matter to copy the media verbatim, not worrying about the partition layout. However, you can also use fdisk -L to obtain partition information and backup individual partitions, which is usually slightly faster - but more finicky. If you have plenty of archive storage and great numbers of machine it is less brain power to backup the whole media. Don;t forget some hosts put a swap partition on the media and it is a waste to back that up unless you want to restore resumable machine state. I usually convert my hosts to swapfile, or in many of the raspberry pi SBC I turn swap off.
You can even use these images to make Virtual machines if you are clever enough :-).
lz4
Here are the basic disk imaging instructions using lz4 compression
- take not of the disk layout and devices using lsblk
lsblk
- Use forensice dc3dd e.g.
sudo dc3dd if=/dev/sdx | lz4 > /media/user/<some-usb-drive>/sdx.img.lz4
- (or) you can use regular dd if you do not want to install dc3dd
dd if=/dev/sdx bs=10M status=progress | lz4 > /media/user/<some-usb-drive>/sdx.img.lz4
- restore
cd /media/user/<some-usb-drive> lz4 -d sdx.lz4 | pv [-s <nG>] | dd bs=10M of=/dev/sdx oflag=sync
- take care to chose correct sdx as dd overwrites!
- or just via dd with status=progress (a relatively new option)
lz4 -d sdx.lz4 | dd bs=10M of=/dev/sdx status=progress oflag=sync
- take care to chose correct sdx as dd overwrites!
- Don't forget the bs=<buffer> size if you use dd else you will be waiting a while for it to read and write to the target volume, dc3dd is able to default to a more reasonable buffer size if you use dc3dd instead.
xz
xz compression results in smaller files than lz4 files, but compression is much slower, though decompression is not so bad.
- backup and compress
dd if=/dev/sdx bs=10M status=progress | xz -c9 > sdx.img.xz
- decompress and restore
xz -dk sdx.img.xz | dd bs=10M status=progress oflag=sync of=/dev/sdx #
- take care to chose correct sdx as dd overwrites!
source backups
Source backups are an alternative means of copying Linux, bearing in mind that things will be changing while you do this backup. SO critical things like database journals might be in a historic state. You can always turn such services off while the source backup is performed.
- with tar on a live system
tar --exclude var/swap --exclude var/log --exclude mnt -c bin boot etc home initrd.img lib lib32 lib64 libx32 opt root sbin srv usr var vmlinuz | xz -z > /mnt/some-backup-file.tar.xz
- or you can use ssh to remote copy to another system (which is left as a research exercise. I know how it is done and I use it for backing up remote systems :-) )
There are also other recommended what of doing a live copy and can be documented later.
I live backup all my remote raspberry pi's across the internet using ssh and a privileged backup program using tar and xz over a tunnel to a file on my backup host. A source backup is do-able on a live system without shutting down remote services. Linux is pretty resiliant.
useful stuff
iostat 60 locate (updatedb)
- Debian and Kali package names
apt install dc3dd lz4 sysstat mlocate rsync sysstats
notes
- ↑ The more systems you maintain, and particularly if you look after remote systems, then the better it is to have a bullet-proof backup and restore scheme. I use backups across the wire for the remote machines I maintain - even though they run overlayfs.
- ↑ Using an overlayfs in a raspberry pi means you can just turn the power off without worrying about a corrupted filesystem.
- ↑ Note I do not run with /boot being replaced with an overlayfs, and instead prefer to be able to edit /boot configuration files and then reboot.
- ↑ When family members purchase a new Window's machine - if they bring it to my house for archive before they fill it with junk - I can use dd to backup a fresh smallest possible set of images for archive in my Network Addressable Storage - which runs effectively Raid 6.
- ↑ When I purchase an OEM laptop and I can't buy it without a Windows licence, I archive the Windows image and details before overwriting it with Linux :-) . I even turn some of these otherwise undesireable operating systems into Virtual Machine images that I can run in my KVM hypervisor gaming machine that I use for software development and testing.
- ↑ I got so tired of some software that would not run on Wine and very tired of lugging around two laptops, that I use one of these Windows VMs to update sdcards for embeded applicances - such as GPS in aeroplanes - when the OEM manufacturer refuses to recognize that Linux is best.
- ↑ I carry thumb-drives around with live-boot such as lubuntu (because it is good for legacy systems) and a large external disk drive to save pulling hosts apart while they are under warranty.