Hi Craig, Darn, that's right. The things I loved about rsync were how very thorough and very fast it was. Using dd would be a =real= time muncher. The cadence of "UUIDs are not the problem you imagine them to be" (however true) reminds me of the scene where Obi Wan convinces the stormtrooper that "these are not the droids we're looking for". Yeah, my style of "restoring" isn't that common an occurrence, so editing the relevant files on the rare occasion would be OK. And including the editing of boot up scripts in the backup script would be even better. (Thanks for the sample code, as I'd be at a loss to begin to remember how.) Cheers, Carl On 23/04/14 16:13, Craig Sanders wrote:
On Wed, Apr 23, 2014 at 11:31:52AM +1000, Carl Turney wrote:
Hi Trent,
I had a 50/50 feeling that label would be metadata, providing no solution to my original different-UUIDs-at-boot-up problem.
So an alternative to my current rsync approach could be dd'ing. Hmm.
no. dd is not an alternative to your current rsync approach (well, pedantically it is but it's a damn stupid alternative to rsync for a job like this).
dd would perform an exact byte-by-byte duplicate of the *entire* disk *every* single time you performed the backup. rsync only backs up the files that have changed since the last backup.
But if dd'ing is so thorough, wouldn't the kernel (?) go into an exception routine, the next time I do a backup, when it tries to mount two hard disks with the exact =same= UUID and/or label?
forget about dd, you're making this far more complicated than it needs to be. UUIDs are not the problem you imagine them to be.
if your main drive has died and you need to use the backup, then just take a few minutes with a boot CD or USB and modify the /etc/fstab and /boot/grub/grub.cfg so that it has the new filesystems UUIDs. i've done this dozens of times without problem when replacing the boot+os drive on a system with a new larger or faster drive.
better yet, modify your backup script so that the last thing it does is to modify the UUIDs in /etc/fstab and in /boot/grub/grub.cfg on the backup disk - a trivial 2 or 3 line 'perl -pi' script will do the job. for example:
#! /usr/bin/perl -p -i.bak s/OLDUUID1/NEWUUID1/g s/OLDUUID2/NEWUUID2/g
with one 's/old/new/g' line for each fileystem / uuid.
BTW: Can one dd from a filesystem whilst running on that same filesystem?
yes, but you'll have the same potential for corruption on the destination drive as you would if the system was rebooted or powered down with the partitions still mounted (i.e. any unflushed data)
in any case, dd is not the answer to your problem.
craig