[ALUG] RPi SD backup/restore
mark at more-solutions.co.uk
Wed Sep 20 12:53:45 BST 2017
On 19 September 2017 at 17:58, <steve-ALUG at hst.me.uk> wrote:
> Could you not just use the built-in sd-card backup/cloning utility?
Which one do you mean? I'm aware of one that clones a running Pi to an
SD card in a USB port connected to the Pi, but that doesn't really
lend itself to keeping backups off the Pi.
> If you don't want to back-up to a separate sd card or USB stick, you
> could use a mock drive (I think you create a fixed-size file, then
> format it, then mount it) and backup to that.
That would create a 4GB backup of a 4GB SD card though, which I'm
tying to avoid. (Yes it compresses, but not as well or as quickly as
using tar to backup just the files in the first place).
> Alternatively, grab the source for the new sd-card backup utility
> and bodge it to backup to where you want it to.
I did look at this (if it's the same tool) and took some inspiration
from it, but it was easier to write something from scratch in the end.
> Re your backup utility, can I ask a stupid question? If backing
> up a windows filesystem, in order to create a faithful bootable
> backup, certain files have to be in certain locations. Is the
> same true with a PI-backup.
I believe not. The Pi doesn't use a boot sector the way a PC does, and
certainly my own experiments so far have confirmed that creating the
partition and copying the files across works fine. However I do note
that a lot of tools seem to use DD to copy the partition table and the
first partition across so I'm not 100% sure I'm not missing something.
(So far I've done lots of runs without issue though.)
> If not, is there any point in backing up the sfdisk stuff?
> More fundamentally, if not, just back up the files with
> tar, gzip, zip or other.
Well I still need to create partitions on the new SD card (the FAT one
for /boot and the Ext4 one for /). sfdisk was one way to do that
although I'm looking to change that as a direct copy isn't appropriate
if restoring a 4GB backup to an 8GB card. Ideally I want the FAT
partition to be kept the right size, and the ext4 partition to be
whatever is left. And also I want to support more than 2 partitions,
as for my own use I want to have a read only / partition and a
read/write partition for /var, so that loss of power can't stop it
booting, and nor can runaway log files. So I want to support N
partitions (N>=2), and have the Nth partition take up whatever space
is left with the others copied faithfully.
> For what it's worth, I occasionally backup using DD to
> an image file, which I then zip to save space.
DD is fine for occasional use, but it's slow - especially when you
have maybe 1GB used on a 16GB card but DD has to copy the whole thing,
and empty space isn't necessarily zeroed so won't always compress
well. A dd backup also isn't easy to extract files from (not compared
with a .tar.gz file anyway). Tar also has the advantage of being able
to ignore files (so the backup can optionally skip log files, apt
archives, /tmp, etc). Basically: dd is designed to take an accurate
copy of the disk, warts and all, without any knowledge of the
filesystem(s), and it does that well. But having something that
understands the filesystem brings additional benefits.
> I also have a daily Backuppc backup. Backuppc
> is a pig to set up, but, when it works, it works well.
> It has the advantage (and possible pitfall), that it
> backs up only one copy of a file - so if you have 2
> Pis and 2 linux machines, and they all have the
> same version of a library file installed, only one
> copy will be saved. This saves tons of space. The
> disadvantage of course is that if that copy of the
> file gets corrupted, then all the copies will be corrupted.
I use backuppc for other things here in the office. However I wanted
something much smaller and simpler to work only with the Pi.
I do now have early but working versions of rpi-backup.sh and
rpi-restore.sh if anyone is interested (one day I'll try and get them
onto github if there's any interest but I need to stop playing with
this now it's working and do some real work!) With hindsight I should
have used python as it's more portable (eg to Windows, especially if
compiled) but hindsight is a wonderful thing!
Mark Rogers // More Solutions Ltd (Peterborough Office) // 0844 251 1450
Registered in England (0456 0902) 21 Drakes Mews, Milton Keynes, MK8 0ER
More information about the main