Here's an intro to using rsync
for back-up on the Pi. Once the initial back-up is created, keeping it up to date this way is much much faster than constantly ripping the entire image. You can do this to a local hard drive or over a network.
You actually do not want a complete copy of a running system as a back-up, since some of the stuff ostensibly in the filesystem exists only at runtime. Including that in a backup and then using it to recreate an image later may create problems for you.
There are some other exceptions too. rsync
can accept a list of (glob) patterns to exclude, and those can be read from a file, so let's first go thru what should be in such a file. Note that the entries are of the form /directory/*
and not /directory
. This is because we want them to exist, but we don't want to copy anything in them.
/proc/*
/sys/*
These do not really exist on disk. They're an interface to the kernel, which creates and maintains them in memory. If you copy these and then copy them back into a system and boot it, it will be (at best) meaningless, since the kernel uses those as mount points for the interfaces [If you want to see what happens when you mount a filesystem partition on a directory with data in it, try. It works and won't do any harm, but the stuff that was in the directory is now inaccessible.]
Note that it is critical that the /sys
and /proc
mount points exist. But they should not contain anything. Next:
/dev/*
The dev
directory is not quite the same thing as proc
and sys
but for our purposes it is. If you believe that you should save this so you can have the same device nodes in your backup or something, you're wrong. Don't bother. Do not copy dev
. Once upon a long time ago Linux did work that way, but it doesn't anymore.
/boot/*
This is sort of a special case with the most (perhaps all) of the Pi specific distros such as Raspbian. It's actually
a mount point for the first, vfat, partition. We are going to deal with that separately. Whatever you do, don't bother including it here, because again, it's a mount point.
/tmp/*
/run/*
/run
is generally not on disk either, it's in memory. Perhaps /tmp
could be too (this would save a bit of SD card action), but in any case, as the names imply, these are not places for storing persistent data. Applications which use them expect that they may be deleted at each boot.
/mnt/*
/media/*
These are important particularly if you are planning to back up to a hard drive or USB stick and the device is in /mnt
or /media
(automounting tends to use the latter), because if you don't exclude the location of those devices in the filesystem you will create a loop backing up the content of the drive to itself, until it runs out of space. I think rsync
might be smart enough to spot something that dumb but try to avoid testing the premise.
On to the actual backing up: Create a directory to back up to on the locally mounted harddrive, USB thing, etc. -- e.g. "pi_backup". You can alternately backup to a remote location via ssh
(see below) or using a network mounted filesystem, but this will probably take a while the first time.
If the file containing the list to exclude is /rsync-exclude.txt
1 and your drive is /mnt/usbhd
, to do the actual backup:
rsync -aHlAXNv --delete --exclude-from=/rsync-exclude.txt / /mnt/usbhd/pi_backup/
Notice that there is a trailing slash on pi_backup/
. You may want to have a look at what all the switches mean in man rsync
.
This will take a while and produce a lot of output (if you want to examine that in a log instead, append > rsync.log
). --delete
is meaningless the first time, but for keeping the backup updated use it. This ensures that stuff you've later deleted on the Pi also gets removed from your backup. The a
sets recursion into directories and makes sure all the file attributes match. -H
is to preserve hard links2, v
is for verbose which is why you get some output (otherwise rsync
is quiet). See man rsync
for more.
There is a shortcut whereby you can skip the --exclude-from
file. If you are sure that all of the things you don't want to copy (/tmp
etc.) are on separate filesystems, you can just use:
rsync -axHlAXNv --delete-during / /mnt/usbhd/pi_backup/
-x
has been inserted. This is the short form of --one-file-system
, which tells rsync
not to cross filesystem boundaries. Personally I prefer the --exclude-from
, but on e.g., default Raspbian, --one-file-system
will work fine. You can use both if you want to be -x
tra careful :D
That's not quite a complete backup. It's enough if you haven't put anything in boot
and you are fine with using the back up to just restore the system by sticking the card in a computer and running:
rsync -av --delete-during /mnt/usbhd/pi_backup/ /mnt/sdcard_partition2/
You could also do this with a card with a new image on it (presuming it's the same as your base image) although that's a little inefficient if you have to create the image (because you're then going to overwrite most of it). You could also connect another SD card via a USB adapter with such an image on it, and use the above method to maintain a duplicate card.
If you've put stuff in /boot
(e.g., a custom kernel), including /boot/config.txt
, you'll want to back that up too (pretty simple -- there's not much to it). Just do it separately, and when you restore, that stuff goes in the first partition.
See here if you want to create a blank Raspbian style image which you could then backup into. You can use a similar methodology to create an empty Raspbian style card -- just rather than dealing with an .img
file, you'd be dealing with a real device (e.g. /dev/sdb
), meaning all you have to do is create the partition table with fdisk
and then format /dev/sdb1
and sdb2
(or whatever) with mkfs
.
But copying the whole image is easier! Why bother with this?
It's not that hard; I restored to a blank card (formatted as per that last link) in 10 minutes. Yes, just using dd
on the whole thing is simpler (if you find stuff like words confusing...), BUT then it takes quite a while every time you want to update your backup because you must do 100% of it every time. Using rsync
, once a backup exists, updating it is much much faster, so you can set this up to happen painlessly everyday via cron. Over a network even. Every six hours. The more often you do it, the less time it will take.
rsync
via ssh
Here's an example:
rsync [options] --rsh="ssh [ssh options]" root@[the pi ip]:/ /backup/rpi/
"Options" would be, eg, -av --delete --exclude-from=/rsync-exclude.txt
and "ssh options" is whatever you normally use (if anything). You must have root access via ssh
to do this for the purposes of a system backup (set PermitRootLogin=yes
in /etc/ssh/sshd_config
and restart the server).
1 You should keep this file. You can put comments in it on lines beginning with #
or ;
. This could include the actual rsync
command, which can be copy pasted later so you don't have to remember it each time.
2 Thanks to Kris for pointing out rsync
doesn't do this automatically.
dd
, look intorsync
.dd
copy with an appropriate block size will probably be fastest for a "new" copy. Doing a file-by-file copy to flash/SD media is probably a bad idea.