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.
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
/proc mount points exist. But they should not contain anything. Next:
dev directory is not quite the same thing as
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.
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.
/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.
These are important particularly if you are planning to back up to a hard drive or USB stick and the device is in
/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.txt1 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
This will take a while and produce a lot of output (if you want to examine that in a log instead, append
--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
-xtra 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
sdb2 (or whatever) with
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.
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
/etc/ssh/sshd_config and restart the server).
1 You should keep this file. You can put comments in it on lines beginning with
;. 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 into
ddcopy 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.