Backing up the root file system with rsync, a script!

[stormychel]

hi,

I'm a relatively new pi owner, but already did a lot of work on making it a NAS, media player, Time Machine backup server, AirPlay server, and print server. After realising I needed a way to backup my precious work, I started digging into this. Taking out the card and backing it up is ok, but not something I like to do on a regular basis, because it's a hassle... So I stumbled upon this article : https://wiki.archlinux.org/index.php/Fu ... with_rsync , it talks about how to backup your / via rsync to a backup location, and I think it works very well... and is very simple to use. I didn't try the restore instructions yet, but since it's a full copy, preserving all attributes, this should work, I guess... Any second thoughts on this by more experienced or smarter people than me?

[stormychel]

Also, would having a second SD, prepared for the pi with same image as the one in the pi itself, connected trough a card reader, be a good backup location? Should be bootable, no?

[rpdom]

Also, would having a second SD, prepared for the pi with same image as the one in the pi itself, connected trough a card reader, be a good backup location? Should be bootable, no?

Yes, this would work, as long as you have the same partition layout. Fortunately the Pi has no need for mucking about with boot loaders and flags and such, just the right files in /boot

If you need to restore, just swap the card over and throw the bad one away/reformat it and use for backup again.

Even better would be to have two (or more) spare cards and alternate between them. That way you could go back to a snapshot of your system on a prvious backup if the latest one got corrupted or the card failed.

[stormychel]

Cool will order a second SD and try this, and post my findings here!

[DBryant]

Rsync is very good but its strictly a tool for copying files, so backing up music or photos is fine.

But to backup an OS then one needs to do it when the OS is not running. File copy tools do not necessarily operate on open files and usual Unix sys admin approach would be to umount disks before copying them in rad-only mode. But then you can't do that on the OS partition.

The removeable SD comes into its own; remove it to another system and do a 'dd' (http://linux.die.net/man/1/dd) assuming another Unix box which does a byte by byte copy (as used to make the original SD if you recall). Care has to be taken should the backup media not be exactly the same capacity (smaller) but apart from that you have a true clone of the original. It will boot and run just as the original.

As a workflow once might do a dd clone once a week and use rsync on a daily basis for an incremental backup. The rsync might include OS files like /etc/hosts, /etc/smb/smb.conf i.e. configuration files that might be hacked on the fly besides user-based filesystems. You might use the cloned copy in the coming week, since that validates it as a viable functional backup and re-cycle the original for the next clone.

It its important to ensure the restore process does indeed work. Finding out it doesn't when things have got wrong is not a lot of use. So whatever backup process(es) you use, do get another disk and restore your backup and use it.

[stormychel]

Yep, there will be rsync backups after each successful change, and dd backups every week or so,,,