I would like to perform incremental backups (for the entire filesystem) from a machine. rsync does this quite will, however I would like to also preserve file ownership - meaning, make it possible to restore it.

Is this possible to do without running rsync as root on the target machine (storing the backups)?

Some ideas...

  • Is there a way to mount a filesystem (FUSE?) in such a way as to allow chown for a non-root user? (I guess it would probably need to be noexec to forbid elevation.)
  • Some way to store and restore the ownership in metadata files instead of the filesystem itself?
  • tar can store file ownership, though getting it to work with rsync or incremental backups would be a bit more involved. It would also be nice to be able to browse the backups like a regular filesystem.
  • Perhaps some kind of fake root environment? A virtual machine would work, but would be nice to avoid the associated maintenance and performance overhead.

As stated in the other answers, to directly preserve ownership information you need root access to the destination machine.

However, you had at least two workarounds to avoid root access while preserving ownership:

  1. use the --fake-super rsync option. From the man page:

When this option is enabled, rsync simulates super-user activities by saving/restoring the privileged attributes via special extended attributes that are attached to each file (as needed)

This means that ownership is not directly preserved in classical Unix style, rather ownership information is stored inside a special extended attribute (ie: a sort of "tag" attached to the file). When restoring, rsync can use this EA/tag to correctly reconstruct the original file owner.

  1. do not let rsync preserve ownership information, rather preserve them using the getfacl utility. For example, issuing getfacl -R MNTPOINT > acls.txt you effectively save ownership (and ACL) info in a text file which can be later used to restore such information using the setfacl --restore command.
| improve this answer | |
  • Wow, the --fake-super option is exactly what I needed. Thank you! – Vladimir Panteleev Feb 12 '16 at 17:04

If I were you, I would put the backups on a volume in a Docker container. This way, you can put good limits on it and avoid security risks but still run it as root so it does what it needs to do.

| improve this answer | |
  • I don't know why this was downvoted. But would this work, considering that - AIUI - containers require mapping a specific set of UIDs, and forbid operations on UIDs outside the mapped set? – Vladimir Panteleev Feb 12 '16 at 10:27

Rather than copying all your files one-by-one like rsync does, you should consider putting the files in some kind of "container" that lets you pack up all the files, transport them around, and never lose any metadata.

Have you considered "tar"? I know that tar is the antithesis of rsync: it isn't incremental, it doesn't transport the data anywhere, etc.

However it is really good at preserving ownership, permissions, ACLs, modification times, and such. You can make a tar file, copy it to a machine that doesn't even understand the Unix way of doing file permissions (i.e. Windows, TOPS-20, VAX/VMS), then copy it back to a Unix host, untar it, and you get all the permissions, etc. that it originally had.

There is a FUSE filesystem that will mount (read-only) tar files.

Of course, you lose the incremental copies and other features that make rsync such an excellent tool. However, the Unix world used tar for 20+ years before rsync was invented and it works really well for certain situations.

| improve this answer | |

Obviously to get the "root" files from the destination, you need root access. However, there are many ways to screw your system.

1) You could allow rsync to use sudo without password 2) You could use setuid to rsync so that it can access root files, while the backup orchestrator is a normal user rather than the root. 3) use rssh to limit the security risks of all the above

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.