I’ve never, ever made a backup and afterwards thought that was a waste of time. Either they save the day or they do no harm. Whenever I make a significant, radical, or wildly inappropriate mod to one of my Raspberry Pi computers, I’ll typically make a quick backup. Here’s how I do it.
This will be short and to the point, but there are a few important call-outs.
- Before you commit to a backup strategy, know the restoration plan.
- If possible, test the restoration plan before backing up something mission critical.
- Minimize use of the system being backed up during the backup process. If possible, don’t touch it!
This quick backup is not compressed (although that’s easy to do, compressing while backing up is painfully slow in my setup) and it’s pulled over the network to a RAIDed drive connected to a Mac Mini. That drive is backed up to Backblaze, however these are quick backups so they’re really only for fairly temporary use. For production backups, I’d encourage the use of compression.
Lo and behold, the quick backup.
The following command should be run from the destination computer, not from the system you are backing up. Replace x.x.x.x with the IP address of the Raspberry Pi you’d like to back up.
$ ssh [email protected] "sudo dd if=/dev/mmcblk0 bs=1M" | dd of=~/backup.img
Since compression is not in use, it won’t bog down the Raspberry Pi, but it will use space equivalent to the size of the micro SD card in the Pi.
One adjustment I recommend is to use Pipe Viewer, which will display a handy progress meter during the backup. It’s simple to install (install it to the machine performing the backup, not the one being backed up) and takes the guess work out of the question when is this backup going to finish? If you’re using Pipe viewer, the updated syntax will look like this:
$ ssh [email protected] "sudo dd if=/dev/mmcblk0 bs=1M" | pv | dd of=~/backup.img
Finally, ensure the backup file was created on the destination and that no errors were displayed during the backup process.
