On 19 September 2017 at 17:58, steve-ALUG@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!