[NBLUG/talk] dd for different size partitions?

[Eric Eisenhart]

On Tue, Aug 10, 2004 at 03:59:12PM -0700, sms at sonic.net wrote:
> > Otherwise find piped to cpio is your best bet. I use this method all the
> > time to migrate to newer or other hard drives, and ended up explaining it
> > so often I just wrote it down in my tips section:
> 
> Hm.  Is there some reason you prefer   find | cpio   over   dump   (and
> the mated   restore  )?  Basically, this is a "backup/restore" situation,
> and I'm inclined to use the native tools for the job, rather than cobble
> up a solution from other tools.  TIMTOWTDI & all that, but...

Personally, I prefer "tar -clpzvf /someplace/rootfs.tar.gz /" over cpio. 
(and one of those over cp -a; and any of those over dump)

Dump has 2 basic requirements:
1) a version specific to the fs you're using.
2) that the filesystem in question be mounted read-only or unmounted (a
"dirty snapshot" is sometimes okay if you have the capability of doing
something like that in your setup)

If you try to do a dump on a filesystem that's being written to, dump will
happily procede as if all is good, but there's high odds that the results
will be a broken image.  With ext3, things get worse; last I'd heard, there
was no available version of dump that knew how to handle ext3's journal. 
(meaning that dumping is even more unreliable)

dumping a filesystem that's mounted read-write is a lot like pulling the
plug on your computer in the middle of some writes (where fsck has to be
run, etc.), only orders of magnitude worse.  Since the state of the
filesystem is changing, it's entirely possible for it to think that multiple
files are pointing to the same blocks or various and sundry other terribly
strange and unfixable inconsistencies.

Just because "dump" and "restore" *sound* like the backup tools of choice,
doesn't mean that they're better than the more oddly named "tar" and "cpio"
tools.

tar and cpio have been used for backing up and restoring filesystems for a
long time now.  Because of their habit of going through the "virtual
filesystem" layer of the kernel, they're guaranteed to be reading a
consistent filesystem.  Though going through that stuff does mean they're
slower.  And, as an added bonus, they can back up any filesystem that Linux
can read.

All that said, if you've got a basic ext2 filesystem and you're leaving it
mounted read-only, dump is fine and will absolutely work with no problems. 
If you're using ext3 and journalling, you'll need to have the filesystem
mounted read-only (or unmounted) and you'll need to fsck the filesystem
before you dump it.  (e2fsck runs the journal on an ext3 fs)
-- 
Eric Eisenhart
NBLUG Co-Founder & Director-At-Large
The North Bay Linux Users Group
http://nblug.org/
eric at nblug.org, IRC: Freiheit at freenode, AIM: falschfreiheit, ICQ: 48217244