Actually, I think there may be a minor problem with this approach -- well, a couple actually:
When I first added my SDcard, I copied the NAND root FS onto it essentially the same way. (Actually, I used something like "find / -mount | cpio -pdm /mnt/sdcard".) However, I found after I did this, I couldn't boot from the SDcard. The problem turned out to be that the kernel really does need a couple of the entries in /dev, like /dev/ttyS0, early-on in the boot process. These must exist in the /dev on the root FS, even though /dev is later overlayed by the pseudo-fs
udev that the kernel uses to create its device hierarchy. Thus, I'd advocate just including the entire /dev to your backup: You'll get more than you need, but it really doesn't take up much room.
The other problem I see with this approach is that it only works for fs's that are less than about 50% full. For those that are greater than that, you'll run your root fs out of space doing the backup. One workaround is to use nc. On the remote backup site -- let's call it "mydesktop" run:
nc -lp 2345 >MyPlug.backup.cpio
then on your Plug run (as root):
cd / && find . dev -mount | cpio -oc | nc mydesktop 2345
It takes about a minute to backup my Plug over my local LAN using this method, and the backup is "offsite" to boot!
If you'd rather create a complete hierarchical subdirectory on the backup site -- or, say, replicate one Plug's fs on another's -- instead of the initial "nc" above, you could use something like:
cd /mountpoint && nc -lp 2345 | cpio -idm
(You can no doubt translate the above
cpios into
tar commands, too. I use
cpio, since that is the backup tool I was raised with.)
YMMV
