> There is also one other catch with dd, If a file was being written to the drive
>while dd was copying it's data the file may become corrupt! With me the only files
>that get changed on the root drive is /etc stuff and it's highly unlikely that anyone
>is going to edit those at 1AM:-) Even if they did it would only
> be corrupted for one night.
Actually, you're statement here about corruption is rather optimistic.
It's fairly possible that you will get very serious filesystem
corruption using the dd method. The reason for this is that your
corruption is at a filesystem level not the file level.
For example, (and this is not an accurate representation, just an
example) picture a btree stored on disk.
Lots of nodes storage on disk.
Start copy
dd continues in background
A node is added to the btree causing a branch to get recalculated, some
of which takes place
in areas on the disk that have already been copied.
copying still going in background, and finishes.
At this point, you have a serious problem because you've got corruption
in low level data structures... Picture this with the underlying inode
structure in the filesystem. Major yuck.
If I were going to take the approach of doing manual filesystem copying
and didn't want to risk serious filesystem corruption, I would do this:
umount /mirror
mke2fs /dev/sdb1
mount /dev/sdb1 /mirror
cd /
find . -print | cpio -pdm /mirror/
umount /mirror
Using that method, you only risk corruption at a file level. (Using
rsync would also work, and would eliminate the need to remake the
filesystem each time.)
-- Nathan
------------------------------------------------------------
Nathan Neulinger EMail: [EMAIL PROTECTED]
University of Missouri - Rolla Phone: (573) 341-4841
Computing Services Fax: (573) 341-4216
