I am testing an rsnapshot backup system running for a customer. Users are not computer savvy but they can at least navigate a file manager to copy individual files for restoration. Large scale disaster recovery would be a phone call to me, but that is not important to this thread.

I would like to keep the users from inadvertently deleting files from the rsnapshot directory.

The rsnapshot directory is contained on a separate partition.

Initially I thought basic file and directory permissions might suffice, but the snapshots include /home, in which users would have full permissions to their backup files.

I thought about running rsnapshot in a wrapper script through cron rather than directly through cron. The backup partition would be mounted r-o in fstab but the wrapper script would remount r-w, backup/rotate, and then remount the partition r-o. I don't yet know what kind of sanity checks I would need to avoid problems.

Does that sound sane? Any better ideas?

Thanks.

P.S. This is not a full scale backup plan. This plan only covers basic "fat-finger" mistakes.

If you set the sticky bit on the back up directory and change the ownership of it to backup_admin:users_personal_group
chmod something like 1760? <--- 1740 for group read only: Edit
would that resolve this problem?

You should be able to use setfacl to set the access control list for the files in their copy of their home filesystem such that they can read them but cannot write them in that directory.

Just don't use "cp -p" to copy them out, since that will bring the ACL along.

So something like this?

$ setfacl -s user::r--,group::r-- /mnt/backups

I mount the backup partition in fstab to /mnt/backups. If I add the acl option in fstab and then manually run setfacl as above, all non-root users and groups have read access to /mnt/backups but also retain original permissions, such as accessing all /home/$USER files, read-only access to /etc, and so forth?

And rsnapshot, being run as root, has no problems performing backups?

Well, you could add the root user to specifically allow rw on the directories.

While Fedora-centric, this appears to be an OK guide.

Hmm. Like this?

setfacl -s user:root:rwx,user::r--,group:root:rwx,group::r-- /mnt/backups

I doubt it, since I can't seem to find "-s" as a valid option.

I think it's more along the lines of At least that appeared to work when I tested it.

Okay. Time to test and destroy the test box.

Any thoughts about wrapping rsnapshot in a script, mounting /mnt/backups r-o in fstab, and have the wrapper script toggle between r-o and r-w?

Well, it leaves a space of time where your users can delete/change something. Unless you've got a really, really fast backup mechanism, I'm pretty sure they will hit it. Even if you run the backup at 4am or something.

I think the ACL will work, but some of that depends upon how you are doing the backup.

1 members found this post helpful.

Chown the mount point to "BackUpAdmin" and change the rights before you unmount/remount the drive or better yet, do it after you pull it down before you mount it rw.
Your doing this on a file server, aren't you? They may be mapped to the partition, but the windows users haven't mounted it locally (by your description it doesn't seem likely you're working in a SAN here).
If the partition unmounts with windows users mapped to it, they'll get over it, it'll just go dead until they remap after your finished and you reset the ownership and rights on the mount point itself.
It's windows, if loosing drive mappings were a serious issue, they'd all be doorstops by now.

File server? No, this is the user's computer. A desktop computer. I don't know where the topic of Windows entered the discussion.

The rsnapshot backups are intended only to backup important system and user files. The rsnapshot rotation is not a full-fledged backup strategy. Just something to enable users to recover 99.5% of the files they might inadvertently delete. The rsnapshot rotations also provide me a way to restore system files in a disaster recovery effort.

The only backup files $USER can modify are /home/$USER. All other backup files are system files and require root privileges to modify because rsnapshot transfers all permissions the same as the source files.

I tested setfacl with no success. Users always still have full access to the rsnapshot copies of /home/$USER. At the moment I live with users being able to modify the backup files or use the wrapper script idea, although theoretically with the wrapper script users could access the backup copies during an rsnapshot rotation moment. The rotations are very fast after I manually create the initial backup. Thus the opportunity for modifying backup files is slim. I prefer to set some kind of ACL but at the moment a solution alludes me. I think the problem might have to do with masking but I am just guessing as I am nothing close to an ACL expert.

No, I think that I misunderstood the use cases where you'd use ACL.

It seems to be used to selectively allow other users to access your files with the permissions that you set.

So if your backup utility changed all the files to belong to, say, the user 'nobody' then you could use ACL to allow the real user read-only access to them while root could be set to access them read-write. I don't think that ACL is designed to prevent the file owner from manipulating the files any way he/she/it sees fit.

So I wasted your time so that I would learn something. Sorry about that.

That is my conclusion. During my efforts I kept thinking that ACLs are intended to enable users rather than limit. I ran across a how-to that implied what I wanted to do is possible, but I now can't find that page. Yet the difference in that example is setting read-only ACLs to files/directories that already exist. I am trying to change ACLs on files/directories that do not yet exist and because of the rsnapshot rotation mechanism, are changed every hour.

I fiddled some with sticky bits too.

Not a waste of time. I had to try something and ACLs seemed sensical. Perhaps ACLs remain a valid solution and I need to learn more. I also learned to appreciate the value of custom ACLs, which likely will come in handy one day.

The script wrapper idea is doable albeit clunky. These users do not make a lot of changes to their systems and each rsnapshot update will be quite fast, which should avoid real-time inadvertent changes. I have the partition mounted in fstab to /mnt/backups and the mount does not appear in file manager sidebars, which keeps the backup files out of sight and out of mind until needed. Thus I might not need the script wrapper. These users are the type who are afraid of computers and if I tell them not to touch the files except in emergencies, they are likely to do just that.

Don't know if you already saw this, but rsnapshot seems to suggest making the snapshot directory unreadable for users and then exporting read only via NFS for users to access

http://www.rsnapshot.org/howto/1.2/r...html#all_users


(You also might be able to bind mount read only elsewhere instead of exporting? Haven't tried that or even fully thought it through so take with a grain of salt, just something that occurred to me)

Interesting solution and makes sense --- when the backups are stored on a network. These backups are stored locally and the users don't have networks.

I don't know about the bind mount idea. Something to think about.

I did test chmod 700 to the backup directory. That prevents all access as non-root and alows rsnapshot to run. I haven't figured out how to provide the user with non-root access to restore files, which is the whole purpose of the backups. The user could elevate to root, but these are not savvy users and even they admit they don't want to do things like that. These folks don't do terminals either.

Thus far the wrapper script seems least intrusive as that way users always have read access to the backup files. I am not perturbed by that option --- just seems with all the usual power in a 'nix system there should be a more elegant solution. There probably is but is beyond me.