Raspberry Pi Journal #6

Back Up Your SD Card part 2

On the last journal entry, I mentioned how everybody is satisfied with turning off their Raspi and pulling the card out, only to insert it to a Windows computer just to back up their SD card. Well, I'm not going to settle for that.

So, I keep digging, and finally found the program "part image". It's a partition backup program that takes a partition and save it to a file. Sounds familiar? Yes, that's exactly what "DD" Disk Dump do!

I ran into another problem. What's the name of the OS partition? Not documented anywhere, is it? After a few trial and error with fdisk, I came up with the name /dev/mmcblk0

There are 4 different partition, mmcblk0p1, mmcblk0p2, mmcblk0p3, mmcblk0p4. I'm sure one of those thing is the swap partition.

I'm backing up the first partition to my flash drive. mmcblk0p1 is fat32, 1.04 GB. Well, I think I just backed up NOOBS bootloader partition. Oh, well. It only takes about 20 minutes, anyway. Nice interface, too.

sudo -z1 -o -d save /dev/mmcblk0p1 /mnt/Lexar/raspi-p1.partimg.gz

So, that's it! Maneuver through the GUI and make some coffee!

Be careful about some of the options. There is a sync option at the end, that you want to keep, especially if you're doing live back-up. Mount devices are also iffy, and although you can override it, you definitely want to be extra careful on this one. I almost made the mistake of copying and writing to the same device, which would be bad.

I tried to do more back up:

The file system of [/dev/mmcblk02p2] is [-unknown-], and is not supported

As is partition 3 and 4.

So, the question is: Am I fully backed up or just the NOOBS?

I did

sudo dd if=/dev/mmcblk0p2 of=/media/Lexar/raspi-2.img

2+0 records in
2+0 records out
1024 bytes (1.0 kB) copied, 0.0992122 s, 10.3 kB/s

Well, obviously, my /home directory isn't in there. Let's do partition 3:

No such file or directory

Huh? It turns out they got shifted to 5 and 6. Oh, well. This is bad. I wonder if I'm destroying the file system! Better stop here for now.

In the end, I bit the bullet, and dump those anyway. Partition 5 is about 60 MB, so I'm guessing that's the swap partition. Partition 6 took such a long time, that I simply didn't wait.

sudo dd if=/dev/mmcblk0p6 | gzip -c >/media/Lexar/raspi-6.img.gz

It does about 2 MB per minute, and so I decided not to wait. Next time, I'll do it without compression, and if desired, do the compression separately. Also, I'll probably do it in the background so I can check the copying status

$ dd if=/dev/zero of=/dev/null& pid=$!
$ kill -USR1 $pid; sleep 1; kill $pid

Straight from the man page!

So, I finally did it, and what happens? Ran out of space! How can that be? And before you ask, nope, it doesn't work. Does not even boot.

Raspberry Pi Journal #5

SD Back Up Frustrations

So, I was going to back up my SD card. I think that there is a good chance that my SD card will go bust someday. I'd like to be protected. Considering that I install a lot of program, and it's not over yet, there is an excellent chance that the SD card will go out eventually. Especially since omxplayer is still messing up my system. The last time I used it, the screen actually got shifted in the middle. That is, all four corners of the desktop are centered on the screen. Sigh.

So, having the need to back up my SD card, how do I do it? A lot of instructions on the Internet says to use Win32 Disk Imager. I suppose it works fine, but come on, Debian is a very powerful OS. Are you saying I have to use Windows just to back up a Linux OS? That's silly.

So, I dig deeper. It turns out that I have to dig quite deep to uncover DD. DiskDump (or Disk Destroyer) seems to work fine. This is how you use it:

dd if=/dev/sdb of=/path/to/backupfile.img
if=input file or sd card
of=output file

And this is where I stop. The method obviously works if you're copying an SD card to another place, such as a flash drive. But, how will this back up my current system? I have to take it out of the machine and back it up manually? That's not how back up supposed to work, does it?

I understand that the output is not compressed, but I don't see it as a drawback. You can simply output to sdout and pipe it to gzip. There you go, compressed on the fly!

I also understand that if I specify the wrong SD card, I can mess things up. I read very carefully the text I have, but there is no specific mention how the SD card will be destroyed. I'm assuming that the destruction will happen on the output side, not the input side. But if so, isn't that natural?

All I can tell you is that the process will not backup the current running OS. Also, there is no instruction on how to restore the data. The only hint is that if "of" is given drive, it will try to "rewrite the whole disk". I'm wondering if that means the whole partition is intact. If indeed we're copying two SD cards, mirroring one another, I think that's a desirable outcome since that way, we get to skip a step. If one card is busted, well, no need to reflash the SD. Just use the back up SD right away!

Researching this method of back up is very frustrating and time consuming. Mirroring SD card is not what I'm looking for! I want to back up the OS, and I want to know how to do it, live.

I'm thinking to partition /boot and /home separately. I think I can just tar /home like this:

tar -cvzf tarball.tar /home/ 

and that's that. Extract the files by

tar -xvzf tarball.tar /home/

That should do nicely. I also wonder if the command

tar -xvf tarball.tar

all by itself is enough. I checked it. Sure enough, it works! Apparently, there is a check in there if the archive is compressed, it will automatically decompress. I checked out the output and there seems to be 4 bytes difference. I wonder why that is. There's no other differences that I can see.


There are two commands that you can use: "tar --help" and "tar --usage". Both screens are simultaneously overkill and not enough sample usage for everyday use. Hmmmph.

In any case, I still don't know how to back up my system, without shutting it down and take it out to another computer. Very frustrating!

Do you people are actually satisfied with the back up instruction that requires you to shutdown your Raspberry Pi, remove the SD card to Windows machine, and run a disk imager? I know that Linux has a live-back up system. How about doing instruction for that? I have an SD card in Raspi, and another one via USB. I want to backup the system to that USB+SD card. It's okay if I have to get a bigger card, but please don't tell me I need to shut the system down! That's just so inconvenient, and isn't the idea of getting a computer is convenience?

There are many, many web pages that tells you to use Windows to back up your SD card. Hello? Do you not see why that is not desirable? Worse, the instructions just mirror one another. I get repetitive instructions that is useless, and really, just a bunch of noise. I ran out of time trying to dig out the proper instruction. And before you ask, yes, I searched for "live backup". The few forum pages that I've seen, skirted the issue and did not answer at all.

I'm pretty sure there is a proper instruction in there somewhere, because I'm having trouble believing that people are willing to put up with shutting down the device every time you want to make a back up. It's just that the bad instructions are everywhere, and not enough people putting out good instruction to counter it. I have yet to check this, but I'm getting very frustrated. I wonder if the "back up your Pi with Windows" instructions are even in TheMagPi magazine? Because, IMHO, that's the boneheaded way to do it. Learning computers are fragile, and what good would it do to send cheap computers if you need an expensive one just to back up your data?

Of course, next thing I know, lots of people will be criticizing me for unwilling to pull the SD card out of the Raspi to make a daily back up. Uh-huh. And they wonder why people don't back up their SD cards.


BTW, I finally did an "rsync -r --progress * /media/5185-5397" where the number is the SD card on my USB. Works fine ... for a directory.