Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I unfortunately have no choice but to backup some files from a ext3 parition on a server to a filesystem which does not allow me to set and edit the normal file attributes (NFS, with all_squash set so chgrp/chown etc. even as root is forbidden). I'm planning on using rsnapshot for the actual backups, since I'm already familiar with this and it's worked well in other scenarios.

Clearly I would like permissions, ownership and other attributes to be retained in someway for these backups, even if it's not directly with the files themselves. As I see it that leaves three options:

  1. Create a loopback filesystem on the remote NFS space.
  2. Dump the other attributes separately.
  3. Use a FUSE filesystem as an overlay which fakes this, by writing to /backup/.permissions/ or some other extra file.

None of these are ideal:

  1. I wanted to make the use of the external filestore use automount, but automount does not allow recursive mounts like this (to the best of my knowledge).
  2. this doesn't seem terribly easy to do using shell scripts. Using find + stat would be somewhat wasteful, but more importantly restoring from that information would be fiddly. I could write a small tool (in C) to call stat, dump the struct to a file and restore the appropriate information from that struct, but this seems like a lot of work for something which ought to be trivial.
  3. I'm surprised nothing exists which already does this, but I can't seem to see anything appropriate on this list of FUSE filesystems, which I assumed to be quite authoritative.

Suggestions? I'm leaning towards solution #3, unless it already exists or #2 is more trivial that I thought. I want something simple and robust which doesn't require reinventing any wheels, however I am willing to write new wheels if they're genuinely useful.

share|improve this question
up vote 6 down vote accepted

You can dump the attributes of the files using getfacl -R * >perms.bak and recover them using setfacl --restore=perms.bak

share|improve this answer
That looks like exactly what I was looking for, for solution #2. The syntax, at least on my system seems to be setfacl --restore=perms.bak though. – Flexo Feb 25 '11 at 18:03
@Alan: Your syntax is correct I misread the man page – Iain Feb 25 '11 at 18:06

My first suggestion would be to set up a more traditional backup system -- Bacula, tar, or even boring old dump(8) & restore(8) -- and store those backups to the squashed NFS store. You can still use rsnapshot locally as a "quick recovery" kind of tool.
The big benefit here is a well-known, well-supported way of doing your backups that's easier to troubleshoot and doesn't really care what the underlying storage is (because as far as the tools I mentioned are concerned they're just using the NFS-available file as a container).

Barring that I think your next best option is to set up the loopback filesystem -- this gets back to the container metaphor above -- but this is far from ideal as you've already noted. It may be possible for you to hack something acceptable together with a shell script to handle the mounting/unmounting of the loopback FS's file-device (Automount may work here, but I don't think it will properly "chain" the mounting as you seem to need -- i.e. realize that you need /nfs/file, and /nfs is an automount mountpoint that needs to be mounted first)

share|improve this answer
The automount chaining was one of the big problem I had when I tried that out as a simple test. The other being it seemed to be far too easy to get into a state whereby fsck was required on the loopback volume despite nothing "bad" happening. I'm slightly surprised I'd not come across dump and restore before, they look quite interesting for this. – Flexo Feb 25 '11 at 17:35
dump and restore have fallen out of favor over the years -- they are the old-school traditional Unix tools for this job. They are far more mature on BSD systems and Commercial Unix than on Linux IMHO, but they should do the job. – voretaq7 Feb 25 '11 at 18:23

Why not just stick the files into some archive? You can just tar them up onto the NFS. I use bacula to encrypt, archive, and transfer my files to a backup server.

share|improve this answer
Usign an archive very quickly becomes wasteful if you want to hang on to a range of older versions - with rsnapshot (which uses rsync + hardlinks) you pay a much smaller storage penalty for having a historical archive too. – Flexo Feb 25 '11 at 17:29
Bacula also seems to be far more of a heavyweight solution than I was looking for. – Flexo Feb 25 '11 at 17:33
The advantage of Bacula is the incremental backups and the ability to schedule & report -- It is a more traditional enterprise-y backup system than you seem to be looking for, but if you can foresee needing that complexity (e.g. for dumping databases) it may be worth the initial investment now... – voretaq7 Feb 25 '11 at 18:24
You can actually do incremental backups using some of the add-on features of GNU tar. Bacula isn't too heavyweight except you need a database. The hardest part about bacula is learning how to configure it. – JOTN Feb 25 '11 at 23:34

Look at backuppc. It stores all the attributes in a separate file. It does de-duplication when you have multiple versions of the same file in your backups. If you use rsync as the protocol, then further backups are done at incremental speeds. Handles laptops and the like as well.

Once I got my first backups running adding additional systems was a breeze.

Bacula would be a good option to backup your backuppc repository to tape for offsite storage.

EDIT: Reread your post so it is likely you will be reading using rsync. I believe backuppc may fit your requirements better than rsnapshot, and should have similar capabilities.

share|improve this answer

Whilst searching through the rsync manpage today for a totally unrelated reason I stumbled upon the --fake-super option:

From the manpage:

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 includes the file’s owner and group...

Which is exactly what I was looking for when I originally asked this question although I didn't know what I was searching for before I posted. This neatly solves the problem without any loopback filesystem tricks, or external attribute dumping or FUSE hacking.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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