The Basics for Beginners (part 1) got rather lengthy so I decided to split it into
two three parts. In this second part it’s all about backup and accessing the Raspberry Pi via SSH.
At first I did not care about backing up the system. If something went wrong I just dumped a new and clean image onto my SD-card and started all over. With more and more bits and pieces coming together and (some of them) working out, I soon realized that it would be a good idea to regularly backup the things I had accomplished so far.
Remote access is another important thing. I am sure most of us have the Raspberry Pi running as a “headless” system, connecting to it via SSH from a shell. However, there is one drawback with SSH. It generates a key per IP address. Now I wanted to use just one IP for my Raspberry, no matter which SD-card was inserted. This usually goes not very well with SSH, as different systems (per SD-card) will result in different SSH-keys.
Backup and restore SD-card images
As mentioned before, I am going to describe the necessary steps to backup the SD-card from a Mac-OS perspective. For users of Windows there are tools out there that will do the backup. Backing up the Raspberry’s SD-card involves using the command line on Mac OS. The Mac OS usually comes with a program called “Terminal.app” (found under Applications/Utilities). I am using iTerm, just because I so often fiddle around with the command line on different computers and like to have more than one window/tab open.
First the SD-card needs to be inserted into a card reader that is connected to the Mac. Remember to properly shut down the Raspberry before taking the card out.
Then we need to find out which device our the card is. In the terminal type:
Usually this gives you some output like this:
/dev/disk0 #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *500.1 GB disk0 1: EFI 209.7 MB disk0s1 2: Apple_HFS name_of_disc 499.2 GB disk0s2 3: Apple_Boot Recovery HD 650.0 MB disk0s3 /dev/disk1 #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *1.0 TB disk1 1: EFI 209.7 MB disk1s1 2: Apple_HFS TimeMachine 999.9 GB disk1s2 /dev/disk2 #: TYPE NAME SIZE IDENTIFIER 0: FDisk_partition_scheme *4.0 GB disk2 1: Windows_FAT_32 boot 58.7 MB disk2s1 2: Linux 3.9 GB disk2s2
This means that currently three disks are mounted on my Mac. /dev/disk0 is the harddisk, /dev/disk2 is my TimeMachine volume and, finally, /dev/disk2 is the SD-card. I always check for the “SIZE” field and then have a quick look at the “TYPE NAME”. So /dev/disk2 is what we want.
Now for the fun part. Backing up via disk dump. In the terminal type
sudo dd if=/dev/rdisk2 of=/path/to/backup.img bs=1m
and then prepare to wait for some time…
What happens here?
- sudo gives the user administrative privileges needed to run the following command
- dd which does a disk dump of the given disk. The parameters are:
- if=/dev/rdisk2 specifies the path to the input file
- of=/path/to/backup.img specifies the path to the output file and
- bs=1m sets the block size to 1 Mbytes
So why using /dev/rdisk2 when diskutil explicitly states /dev/disk2
There is a short answer and a longer answer to this. In short: using /dev/rdisk is faster. You may happily skip the next few lines if this gets too technical.
Basically /dev/disk is buffered, meaning any I/O is done in 4kb chunks. This makes unaligned reads possible and is usually the type of reading/writing that suits normal operations best. On the other hand /dev/rdisk is just passing the read/write to the device. When backing up the SD-card with dd the whole card (or device) is read and written to a file, so there is no need for buffering. A more detailed explanation can be found on the Apple Mailing List.
Backing up a 4 GB card will result in a 4 GB file on your disk because we are just doing a dump. Luckily for us, Mac OS, basically being built on a Unix system, can do something called “piping”. This means that the output of one program is forwarded as the input for another program, hence “piped”. To save us some space we pipe the dd-output to gzip, the GNU compressor.
The syntax is slightly different as we do not need an output file parameter for dd. The output file is written by gzip:
sudo dd if=/dev/rdisk2 bs=1m | gzip > /path/to/backup.gz
Restoring is just as simple
Just make sure you do run the diskutil command again to identify the SD-card!
From an uncompressed image:
sudo dd if=/path/to/backup.img of=/dev/rdisk2 bs=1m
and from the compressed image:
gzip -dc /path/to/backup.gz | sudo dd of=/dev/rdisk2 bs=1m
As this part is, again, longer than expected, I split again. Part three will cover SSH.