Here's some additional info. On 07/16/07 08:34, Andrew Ferguson wrote: > Kingsley G. Morse Jr. wrote: > > On 07/15/07 23:34, Andrew Ferguson wrote: > > [...] > >> Please read the section "USERS AND GROUPS" in the manpage. > >> > >> http://www.nongnu.org/rdiff-backup/rdiff-backup.1.html#USERS%20AND%20GROUPS > >> > >> There are several references to it if you search for uid or gid in the > >> manpage. > > > > Hi Andrew, > > > > Thank you for elaborating. > > > > I wish I didn't feel the need to mention this, but > > I arrived at a different conclusion after reading > > that part of the man page. > > > > The relevant synopsis of numbers "1." and "2." in > > the "USERS AND GROUPS" part of rdiff-backup's man > > page is: > > > > "If the --preserve-numerical-ids option is > > given [...] Otherwise [...] This may result in > > files having different uids and gids across > > systems." > > > > Does that make sense? > > Kingsley, > > This is correct, and it is the best any program can do under Unix > semantics. Let me give you the following example: > > Let's say System A (source) has two users: > > Matthew:UID 100 > Mark: UID 200 > > and System B (target) has two users: > > Luke: UID 100 > Matthew: UID 101 > > if I use rdiff-backup to backup a directory on System A -- and I am root > on both systems, otherwise this isn't how this works -- then here's what > will happen: > > WITHOUT --preserve-numerical-ids, rdiff-backup will take files owned by > Matthew/100 on System A and make them owned by Matthew/101 on System B > (here we have the 'may result in different uid across systems' case). > For files owned by Mark/200, they will be owned by ???/200 on System B > (since System B has neither a UID 200 nor a user Mark). > > WITH --preserve-numerical-ids, rdiff-backup will take files owned by > Matthew/100 on System A and make them owned by Luke/100 on System B > (thus preserving the _numerical_ id). Files owned by Mark/200 on System > A will again by owned by ???/200 on System B. > > In BOTH cases (and in the case where the user on the target system is > not root, so all cases) rdiff-backup records the correct username AND > userid of each file in what's known as the "mirror_metadata" file. That > file, and several others, are kept in the "rdiff-backup-data" directory > on the target system. When you do a restore from target to source using > rdiff-backup, rdiff-backup reads the mirror_metadata file to ensure that > all usernames and userids are restored to the correct values. This is > what I meant by "If you use rdiff-backup to restore the data, it will > restore the correct uid's/gid's from its internal data store." > > The choice of using --preserve-numerical-ids or not is thus dependent on > how your personal setup is configured and how you intend to use > rdiff-backup. You'll note that in the WITH --preserve-numerical-ids > case, Luke on System B, is able to edit files that "should be" Matthew's > since their UID's are the same. > > The internal data store that rdiff-backup keeps is what enables it to be > such a good backup program. I regularly backup my Mac OS X system, which > has entirely different usernames/userids, system metadata (resource > forks, BSD file flags, etc.) to my Linux server, which is obviously an > entirely different system. rdiff-backup preserves as much as possible in > the mirrored copy, but makes extensive use of the mirror_metadata system > to correctly backup all metadata. When I do an `rdiff-backup -r now ...` > all of my files are restored perfectly. And rdiff-backup always trusts > the mirror_metadata file over the metadata that it attached to the > mirrored files. > > Take a look at the mirror_metadata file. The '.snapshot.gz' ones are > simply a gzip'd flat text file, so zless is very useful for looking at it. > > I'm sure once you see the contents of that file, you'll understand why > rdiff-backup is clearly anything other than 'corruption by default'. > > Best, > Andrew > > -- > Andrew Ferguson - [EMAIL PROTECTED] >
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
