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
--
craig sanders <[email protected]>
BOFH excuse #402:
Secretary sent chain letter to all 5000 employees.
_______________________________________________
luv-main mailing list
[email protected]
http://lists.luv.asn.au/listinfo/luv-main
