Grsync (rsync) backup strategy question: Should you "preserve [the] owner?

[MX-16_fan]

@all:

I am currently doing some experiments with Grsync (a GUI for rsync, cf. https://en.wikipedia.org/wiki/Grsync).

Grsync has a checkbox for preserving files' and folders' owner (rysnc's "-o" option). The tooltip says "super-user only". I guess that means that you have to run Grsync in super-user mode in order to be able to use this option.

Now my question is: What is preserving the owner any good for? Meaning: Are there any technical reasons why you should preserve the owner in the first place, and if there are any, what would be a typical scenario in which you would like to preserve the owner?


Thanks in advance for any answer, Joe

[skidoo]

typical scenario when desirable to preserve ownership+permission during backup? nearly always.
Technical reasons? Copy my .config files to backup... later, when I restore them, if they are not owned by my user, my user account may not have permission to read 'em or apps that I'm running may not have permission to update 'em.

A couple "odd cases" when it is NOT desirable to preserve ownership:
Your config files are trashed, so you're restoring a known-good set of config files from another account.
You have migrated to another system and the "restore" job is pulling files owned by (might be same username but) different UID useraccount

[penguin]

Sorry . I am not sure what you are asking for, but is a tutorial of someone in internet that compare grsync with lucky backup. Find it and watch. If you are experimenting or want to find a right tool for backup, I will suggest qt4-fsarchiver. Is very simple, fast,compress backup image, can save MBR and works perfectly with one or 2 clicks without being pain in the ass utility. Simple and reliable utility that backup or restore partitions without so much bla bla bla options.

[MX-16_fan]

@skidoo:

typical scenario when desirable to preserve ownership+permission during backup? nearly always.
Technical reasons? Copy my .config files to backup... later, when I restore them, if they are not owned by my user, my user account may not have permission to read 'em or apps that I'm running may not have permission to update 'em.

A couple "odd cases" when it is NOT desirable to preserve ownership:
Your config files are trashed, so you're restoring a known-good set of config files from another account.
You have migrated to another system and the "restore" job is pulling files owned by (might be same username but) different UID useraccount

Thanks for the explanation.

Just to make sure that I've fully understood this: The owner (e.g. "skidoo") is defined by its name only, correct?

Meaning: Even if you set up a completely new system, your new system running under the "skidoo" user account would recognize as genuine your old files owned by "skidoo" - correct?

I'm asking this because I once got the impression that there's more to ownership than that mere "owner label".


Greetings, and thanks in advance for your answer, Joe

[skidoo]

flip it upside down.
account username is just a label, a string of characters.
account userid is what the system recognizes, and uses, when enforcing permissions.

One of the potential sticking points when copying "/home" from a different system is mismatched userids.