You can use both if you want to be -xtra careful :D Personally I prefer the -exclude-from, but on e.g., default Raspbian, -one-file-system will work fine. This is the short form of -one-file-system, which tells rsync not to cross filesystem boundaries. 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 -axHv -delete-during / /mnt/usbhd/pi_backup/ There is a shortcut whereby you can skip the -exclude-from file. H is to preserve hard links 2, v is for verbose which is why you get some output (otherwise rsync is quiet). The a sets recursion into directories and makes sure all the file attributes match. This ensures that stuff you've later deleted on the Pi also gets removed from your backup. delete is meaningless the first time, but for keeping the backup updated use it. This will take a while and produce a lot of output (if you want to examine that in a log instead, append > rsync.log). Notice that there is a trailing slash on pi_backup/. 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 -aHv -delete -exclude-from=/rsync-exclude.txt / /mnt/usbhd/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. On to the actual backing up: Create a directory to back up to on the locally mounted harddrive, USB thing, etc. I think rsync might be smart enough to spot something that dumb but try to avoid testing the premise. 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. Applications which use them expect that they may be deleted at each boot. 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. run is generally not on disk either, it's in memory. Whatever you do, don't bother including it here, because again, it's a mount point. We are going to deal with that separately. It's actuallyĪ mount point for the first, vfat, partition. This is sort of a special case with the most (perhaps all) of the Pi specific distros such as Raspbian. Once upon a long time ago Linux did work that way, but it doesn't anymore. If you believe that you should save this so you can have the same device nodes in your backup or something, you're wrong.
The dev directory is not quite the same thing as proc and sys but for our purposes it is. Note that it is critical that the /sys and /proc mount points exist. 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 They're an interface to the kernel, which creates and maintains them in memory. This is because we want them to exist, but we don't want to copy anything in them. Note that the entries are of the form /directory/* and not /directory. 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. Including that in a backup and then using it to recreate an image later may create problems for you. 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. You can do this to a local hard drive or over a network. Once the initial back-up is created, keeping it up to date this way is much much faster than constantly ripping the entire image. Here's an intro to using rsync for back-up on the Pi.