We think that this is a good solution, even if it isn't automated.
Pros:
* It backs up everything on the SD card, including the partitioning info
* Easy and quick. Well, quick is relative, I suppose - depending upon the size of your SD card, but the entire procedure should take less than an hour. Doesn't require any special configuration / setup of backup software.
* Fairly straightfoward method for identifying backup set (by date)
Cons:
* Can't be automated
It would be nice if you could restart the system by setting the next reboot from NAND rather than SD, on the NAND you have the script that start automatically the backup and at the end it restart the system setting the next reboot from SD.
But I think it is impossibile to do so far.
* Can be a little awkward to retrieve individual files from backup (decompress / mount / extract)
About this cons, if you want you can create the image uncompressed, or create a better script that for example first compress the old backup image in that folder, then create a new image, so you have the old one zipped and a new one uncompressed.
You can create a script that mount the image with a command like this:
# cd mnt/mountname/sheeva
# mount -o loop,offset=12615680 -t auto /mnt/mountname/sheeva/$(ls *.img) /mnt/rootfsbck
(this is the offset of the second partition on my SD)
Or you can create two separate images for the two partition on the SD card, so the mount is simpler.
In many cases the cons will be acceptable, and preferable to a solution that involves manually deciding which directories are to be backed up.
This is a backup of the whole system, like the backup that you can do on other system using software like Acronis True Image or Norton Ghost. It is not for data backup. If the SD card dies, you can restore the system very quickly on another SD. Moreover, I moved /var folder and /home folder on the attached SATA HD.
