chill wrote:
> I've used tar occasionally, basically as a zip replacement, to bundle a
> selection of files. I had assumed that using such a tool, or any of the
> tools suggested by Roland0 earlier, to recover an SD card with more than
> one partition would require me to manually recreate the file system and
> partitions, and then recover the files into those partitions. I'm
> intrigued that the 'everything is a file' philosophy might mean that the
> file system and partition info can be included in the backup. dd is
> working for me, but I'm still interested in experimenting with these
> other tools.
I shall continue to follow this thread with interest to see where you
eventually end up. I have the impression that 'disk image manipulation'
tools have advanced greatly since I looked at it, and I suspect that the
issues I was addressing with my use of tar have probably evaporated by
now. My guess is that you wouldn't gain anything by switching to a tar
based approach.
I'll bet that someone has already written a tool that resizes the
individual partitions of a disk image and generates a smaller disk
image. It would need to be file system aware... It wouldn't be difficult
to roll your own, I think.
Some notes on my use of tar, should you ever wish to pursue:
Yes, one tar job for each partition, with the expectation that you
manually recreate the file system before untarring into it. I haven't
considered trying to provoke tar into saving partition info, and I'm
dubious about it.
Disk volume labels (and/or disk UUIDs) may need to be 'remembered and
restored'. If your system uses a label/UUID to identify a disk to be
mounted (e.g. a root volume id baked into Debian's default initial
ramdisk) then you could get some very puzzling failures. :)
Options set up with tune2fs need to be 'remembered and restored'.
The root file system that tar will see is 'polluted' by the existence
of bind mounts. You might think that ---one-file-system Do not cross
mount points- might be enough, but no, it's not. tar would still not
see, for example, the underlying contents of -/dev-. So I mount the
file system, read only, on a temporary mount point and tar from there.
-${SSH_ORIGINAL_COMMAND}- can be used to pass the 'command part' of
your ssh invocation to an underlying script, should you ever go with
ssh's "command=..." restriction in your -authorized_keys- file.
------------------------------------------------------------------------
mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299
View this thread: http://forums.slimdevices.com/showthread.php?t=110496
_______________________________________________
ripping mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/ripping
