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. 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? BTW: Can one dd from a filesystem whilst running on that same filesystem? BTW BTW: In the current scheme, while I'm rsync'ing from a filesystem whilst running on that same filesystem... I've shut it down to runlevel 1. Never had a problem yet. Cheers, Carl On 23/04/14 10:40, Trent W. Buck wrote:
Carl Turney <carl@boms.com.au> writes:
(2) LABEL a possible bullet-in-the-foot:
As every single file and directory is copied in my backup system, it may COPY the master disk label on to the backup disk
UUID and label are filesystem metadata. File-level cp'ing files will not touch them; Block-level dd'ing the whole filesystem will. You can view them with blkid. You can set ext ones with tune2fs.
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main