Backing up your Pi
Now, you have a fresh Pi. Backing up is not the first thing you should do because really, at this point, we have nothing to lose. Getting back to this point from restoring a back up would take as much time as flashing a fresh image. The reason why I put this section here is because I said everything after getting starting is optional, and before you jump too far ahead, I want the opportunity to go over this important topic.
As you install more applications and make configurations on these applications, you will have invested more and more time into your Pi. If anything goes wrong, without a back up, you will be back at zero. Even a stable Pi that was working perfectly one day, might have a corrupted microSD the next. That’s what happened to me. Thankfully, I also have the habit of backing up my data, and my Pi was up and running like it was in just 15 minutes.
So if on a fresh Pi, it is too soon to back up, then when should you back up? Well, I usually do my first back up after the basic configuration, which includes: changing my username, setting a password, expanding the file-system, and setting the locale and time zone. Those are boring and tedious but essential. I also like to make a back up after installing an application, and testing that all of the functions and features are working correctly.
If you only rely on your Pi to run applications, you only need a single back up when all of your desired applications are installed and configured. For example, I don’t make any changes to my Pi Zero after setting up Pi-Hole, Homebridge, and PiVPN. These programs just run.
My Pi 4, however, I host a website and it has new content/data daily. I do a scheduled back up every day.
There are two types of back ups. The first is backing up your chosen directories and files inside. The second is an image back up of your entire microSD card – creating a clone. If you create an image back up, you can flash that image on another microSD card of the same size or greater, and when you insert that microSD card into your Pi, it would boot up and run as if it went back in time to the moment you backed it up.
I suggest an image back up to restore all of your applications and configurations, and also regularly back up directories with lots of changes to the files, for example, the home directory. This is also on desktop Linux installations, the home directory is often on a separate partition. If you need to reinstall the operating system for whatever reason, most of your data will be kept and you would only have to reinstall in the applications – or you just restore an image back up on the operating system partition.
Directories and files
There are a number of ways to back up and schedule back ups specific directories and files. The most basic way, without downloading any software is copying and pasting. You can do this with a Secure Copy (SCP) client. From the terminal, you will do the following, after SSH-ing into your pi:
$ scp -r <path and directory you want to back up> <username to log in to the following host>@<hostname of the computer you want to backup to>:<path of where you want the backup to go> # Example: $ scp -r /home/pi/ cng@linuxdesktop:/home/cng/backups/
“scp” is the command for Secure Copy. “-r” is an option, which means recursive and that will mean to include all of the contents of the directory. The rest of the syntax is: from to. The recursive option is not necessary for individual files, so it would look like this:
$ scp /home/pi/file1 cng@linuxdesktop:/home/cng/backups/
Two more notes:
- If your file has spaces, use quotes to surround the entire file name, including the extension because,
- If you want to want to scp multiple files, you can included them with a space between each file. This is why you should avoid using spaces when naming in Linux.
$ scp /home/pi/file1 "/home/pi/file 2" cng@linuxdesktop:/home/cng/backups/
To schedule a back up would require more coding and writing a bash script, which is extending the scope of this tutorial a bit too much. There are easier ways, such as installing your own back up application, but that you have to Google and choose one that best suite your needs.
This is my favorite as I have a peace of mind knowing at any time, I can just restore the whole microSD card and be up and running as if I went in a time machine (probably the same feeling that inspired the guy at Apple who named their back up program). This code is entered without ssh-ing into your Pi:
$ ssh <username on your pi>@<hostname or IP of your pi> sudo dd if=/dev/mmcblk0 bs=1M | gzip – | dd of=<location of where you want your back up>.img.gz # Example: $ ssh pi@raspberrypi sudo dd if=/dev/mmcblk0 bs=1M | gzip – | dd of=~/pi_backup.img.gz
Some of you may be asking, why am I doing this before I ssh into the Pi. The microSD card is, in most cases, at “/dev/mmcblk0” if your computer doesn’t have more that one removable drive. This way, hopefully, everyone can learn from the same code. If your microSD card is not mounted at “/dev/mmcblk0” then you can replace it with the location after you type “lsblk” in the terminal.
Unfortunately, “dd” is not really an abbreviation of anything for you to conveniently remember it. It is just the command to copy. “if” is input file, or in this case, the entire drive. “bs” is blocksize, and that is the smallest block of memory we want to use – in this case, 1 MB. “|” is located above the “enter” key on your keyboard and it means to parse the output from the left of the “|” to the command on the right. The command on the right is “gzip”, gunzip, which is a compression utility, like zip. You have to sort of use your imagination here to visualize this. So the gunzip command works like this:
$ gzip <directory or file>
The code above does not actually output anything because it needs to know what to output as. A complete command looks like this:
$ gzip <directory or file> <output name>.gz
What our back up code gave us was that while we are copying from the entire drive, gunzip it, and the output from the gunzip (notice the second “|”) we will copy (notice the second “dd”) it to “of”, which is the output file. I will give you what a normal dd command look like:
dd if=<directory or file here> bs=<your choice> of=<directory or file here>
So we run one copy process, where we have a drive and the output is not saved but parsed into another command where the data is compressed, and then that data acts as the input for another copy process, where the output is an imaged that is compressed.
This is why coding is fun!