How to 'snapshot' a Pi?

Hi,

I have not yet received my Pi (should be arriving in the next 3 weeks), but I have a question with regard to how to make an image of a Pi that I have previously configured, using only the filesystem and a network drive.

I wish to write a program (to be executed as root), that will dump the entire filesystem (across all partitions), to a network share. From the filesystem dump, I wish to create a new image file to be loaded on a new SD card from a non-Pi computer.

The reason for this is so that I can just create a simple backup to a known state at any point in time having invested potentially dozens of hours in configuration.

So, my questions are:

• How many partitions are there in the Debian Squeeze Raspberry Pi image?
• How can I translate one-per-partition .tar files into a new image file? (I would have to stream the tar across the network as I cannot use local storage for the cache)
• Gary, Jason or Howard?

PP

There's nothing about this task that should be too complicated (read: I'm sure you will have no trouble doing it), but, as always, the fun will be in the details (which only you are likely to really understand).

A simple solution is to just whip out your card and create an image on your main computer; the reverse of what you did to create the card in the first place. Not particularly elegant but it it is easy to do, as long as you are careful to get those dd instructions spot on!

• Gary, Jason or Howard?

Are you trying to groom us? Haribo works better!

There is a possibility of running 'dd' on a live system. But this could prove fraught with danger as having something change mid-write is highly likely. Also, limited memory devices, large file transfer, and Linux can be very painful if the system isn't set up correctly
Don't know how Pi-Debian's been set up, so don't know if it would suffer from that*.


Grumpy's suggestion above is certainly the best way forwards. Power down; whip it out; and have a quick flash....


* If anyone is having fun trying to copy very large files to very slow media (USB flash) and watching their whole Linux system go on holiday for a day or two, just shout BTW (this includes very slow write speeds despite Windows using the device correctly).

I wonder if perhaps rsync is what you might be looking for? It's designed for synchronizing files/folders in remote locations. You wouldn't necessarily need to tar/compress it into an .img file either because If you ever needed to restore, you could just rsync the files in the other direction, or mount the Debian .img and drop your config files into it before writing it to your card.

Maybe I'm missing the reason why this wouldn't work for you though, or misunderstanding the process of loading the SD card... If not, hope I helped.

I vote for rsync solution - just don't dump everything. You don't need swap contents or logs. But simpler way is to dump card on a PC.

[rurwin]

I've heard some good things about rsync, but it doesn't snapshot the entire machine the way the RaspPi is designed to be used and the OP wants.

You should not use tar and you do not need to do each partition separately. The best way is as GrumpyOldGit suggested, but if you find that you don't have another PC, then taking the RaspPi to single user mode (sudo init 1) should be sufficient. Then use dd to take an image of the entire SD device to a USB stick.

Of course going in the other direction -- restoring the image -- definitely needs to be done on another machine.

What about rsnapshot ?
http://rsnapshot.org/

Slightly at a tangent but if anyone who's wondering how to do this with a Windows PC, the Win32DiskImager has a super simple interface for Writing .img files to SD cards AND reading them back.
So creating backs and clones onto second and third cards is really easy using the 'Read' option
Currently restoring a saved 4Gb SD card image onto a second 4Gb card. (I'm getting reads at 16Mb/s and writes at 11Mb/s so 4Gb takes about 4 minutes to shove on and off my hard drive)
As well as time to read/write be aware that these things do gobble disk space up at a fair old rate - so those with 8gb, 16Gb and 32Gb SD cards might want to reconsider what they use as their boot SD

Slightly at a tangent but if anyone who's wondering how to do this with a Windows PC, the Win32DiskImager has a super simple interface for Writing .img files to SD cards AND reading them back.
So creating backs and clones onto second and third cards is really easy using the 'Read' option
Currently restoring a saved 4Gb SD card image onto a second 4Gb card. (I'm getting reads at 16Mb/s and writes at 11Mb/s so 4Gb takes about 4 minutes to shove on and off my hard drive)
As well as time to read/write be aware that these things do gobble disk space up at a fair old rate - so those with 8gb, 16Gb and 32Gb SD cards might want to reconsider what they use as their boot SD

Check this out in my video how to guide : http://www.youtube.com/watch?v=WEbfHbOVPvc

I'm looking to build a process a little bit like yours. I will use bup to build it, as I do not need to backup my SD card while my r-pi is using it. bup uses the git-core operations. It automatically detects duplicated data and only save one copy, so it generate small images. The first backup is usually the biggest, the others only contains the differences from the previous backup. You can read more on the bup web site:
https://github.com/apenwarr/bup

I still have to fully test it, but the process is like this:

# Prepare bup repository, one for each SD card
mkdir SDx
cd SDx
BUP_DIR=$PWD bup init

# To create a backup
cd SDx
du -hs # to see the space used before
dd if=/dev/sdb bs=4096 | BUP_DIR=$PWD bup split -vn master
du -hs # to see the space used after

# To restore
cd SDx
BUP_DIR=$PWD bup join master | dd of=/dev/sdb bs=4096

#----
Replace /dev/sdb with your device name.

I always define BUP_DIR because once a backup is made in a repository we cannot erase it: it is part of the repository. So I use a different repository for each thing I backup with bup.

I will try to replace dd with partclone in the future, as it would only copy the used sectors instead of copying every ones of them. So that may even result in smaller backups.

Hi slightly off topic but I wanted to find out if its possible to use a "snapshot" already taken off an 8GB card and stick it on a 32GB card?

Basically I'm currently using a class 4 8gb card and i want to get myself a 32gb class 10 and rather then setting and configuring the pi (as I now have it how I like) I want to just put the image I currently have onto the new card...what would happen with the extra space?

Hi slightly off topic but I wanted to find out if its possible to use a "snapshot" already taken off an 8GB card and stick it on a 32GB card?

Basically I'm currently using a class 4 8gb card and i want to get myself a 32gb class 10 and rather then setting and configuring the pi (as I now have it how I like) I want to just put the image I currently have onto the new card...what would happen with the extra space?

You can do that, then use a linux computer, live CD or flash drive or even a Parted live cd to enlarge the partitions afterwards. It's a piece of cake.

I've been doing this sort of thing and after many hours of looking at tutorials, installing GParted on the Pi (and trying a bootable CD version on a PC from ultimate BootCD, here's a simple solution).

1) Download the win32diskimager http://www.softpedia.com/get/CD-DVD-Too ... ager.shtml (you may have already used this to create your bootable Pi SD-Card if you're like me)

2) Put your Pi SD-Card back into your PC read.

3) Run Win32DiskImager and select your memory card and set your file name to store your card image in (use the little folder icon to bring up a file selection dialogue)

4) Select "Read file" - and leave for about 10 mins or more...

5) You now have a snapshot of your card!

6) If you are using the debian-wheezy image, then either open a terminal window, or SSH in from your PC and type

Code: Select all

sudo raspi-config

Then just select

expand_rootfs Expand root partition to fill SD card

and it does all that "clever stuff" that I could never get to work myself for you!

I hope this saves someone the hours that I spent on this!

Thanks to all forum users for their detailed and helpful posts - I never thought the world would end up being ruled by Raspberry Pi's!!