As already know there are many situations you can corrupt the file
system of the SD card which makes it hard and ruin all the hours of
work you have dedicated to your project. After you read this guide you
will stop re-installing everything over and over again.
It directly covers recovery from catastrophic failure or
corruption of the SD card. It could be argued that is the most
important backup recovery use case.
For selective recovery of files that were accidentally deleted or
overwritten, the backup SD card could be mounted via an SD-to-USB
adapter (or on a second Linux machine) and the file copied over.
For either use case, one could use several backup cards and
rotate them to facilitate several generations of recovery. Rob,
what else would you consider essential ingredients of a proper
Checking of file creation/modification time stamps and saving a copy of
the new version of the file (after checking it against the currently
saved version). For specified parts of the file hierarchy like /home
and /etc or for the whole file system excluding locations like /tmp
and /var and remote disks.
IOW, use rsync to do the job, running it from a script that:
1) mounts the backup card (or checks that its mounted)
2) runs rsync to backup the parts of the filing system yo want to save
3) unmounts the backup card
4) runs fsck against the card to check it for errors
I've been doing backups this way for several years. The main benefit is
speed because rsync does the minimum amount of work to make the backed up
set of files the same as the live set, i.e. the first backup to a new SD
card will be slow because everything is copied. After that things are a
lot faster because it only removes deleted files and copies new and
modified ones. It may take a little initial fiddling to get the script
doing exactly what you want but after that backups will be quick and easy.
martin@ | Martin Gregorie
gregorie. | Essex, UK