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

Consider this scenario: I have linux server which is automatically backed up daily to some remote location via rsync or something like this. Everything is fine until some bad guy gains access to server, finds my automated backup script and deletes everything form backup server too.

I am trying to find some remote backup utility which allow only adding backups remotely, but not removing them. I don't now how to make anything that uses ssh write-only, and I tried to find something that doesn't use ssh, but found only Box Backup.

I now it's possible, but I want to know if there is some canonical way to achieve this.

I've got lots of answers, thanks to everybody!

share|improve this question
up vote 5 down vote accepted

The simplest thing would probably be to go the other way with the backups, ie. pull from the backup server. That's how I run my backups with rdiff-backup.

share|improve this answer

If you're doing a naive backup (single copy, overwriting all data) then there's no way of achieving what you want -- an attacker can always "backup" a pile of empty files (or an empty file set) which will result in all your data going bye-bye. So, I'm assuming here that you're doing proper archival backups, and you're monitoring your backups well enough that any attempts to eradicate the backup by sending an empty backup set will be detected before any permanent damage is done.

If your rsync-over-(presumably)-SSH uses a forced command to run rsync on the destination, then you're about as secure from deletion as you can be. Since you only want to run a specific rsync command, you can hardcode all the arguments and then the only thing it can do is write new data. Archiving is simple enough by backing up to a new tree each time and associating unchanged files with the previous backup using hardlinks, which saves space and transfer time.

The other way to go is to use pull backups, where the backup server initiates and manages the rsync operation -- this means that the client machine doesn't even have the ability to run a restricted rsync command, which means the attacker has no power to delete files.

This all assumes that your backup server is secure. If the attacker can get access to it via another means, you're boned regardless of what you do.

share|improve this answer

This is one of the features I like about the Tarsnap backup service. It allows me to to create subkeys with read, write and/or delete capabilities.

On my servers I generally keep subkeys with read and write capabilities. At times when I need/want to prune old backup archives I do that using the master keys from my local desktop computer.

Note that Tarsnap is in itself a storage service. You can not use the Tarsnap software to create backups against your own storage servers.

share|improve this answer

ftp: for example vsftp has an option to disable deletions so you can only upload. Then on the other side you create a script that deletes backups older than x days. I use this option, on the main server backups are simple backups using tar+gz, they are uploaded to a nas server via sftp and then the nas server deletes backups older than 7 days.

rsync: rsync server has an option to disable deletions so that may also work for you, but you have to use rsync protocol/server. refuse options = delete

But then you would have to manually delete the 'delete' files once in a while.

share|improve this answer

Attempt to use a writeonly filesystem layer that will mask your actual destination.

I found an example here, using FUSE.

You can also use an encrypted filesystem that anyone can write into, but needs your key certificate to be altered (seems the most secure option, although it probably needs more planning during the implementation). If you go this way see check WOCFS (Write Only enCrypted FileSystem) and TrueCrypt

So, while the first solution will "mask" your filesystem, that is actually stored elsewhere within the machine and can be altered to the system users with permissions, in the second solution it can only be altered with the proper keys.

share|improve this answer

So, I learned that there are two basic strategies:

  1. Pull backups from server being backed up using something ssh-based
  2. Setup sshd on backup server to accept only safe commands

Quote from rdiff-backup manpage related to second strategy:

Although ssh itself may be secure, using rdiff-backup in the default way presents some security risks. For instance if the server is run as root, then an attacker who compromised the client could then use rdiff- backup to overwrite arbitrary server files by "backing up" over them. Such a setup can be made more secure by using the sshd configuration option command="rdiff-backup --server" possibly along with the --restrict* options to rdiff-backup. For more information, see the web page, the wiki, and the entries for the --restrict* options on this man page.

--restrict-update-only path
          ike --restrict, but only allow writes as part of an incremental
          backup.  Requests for  other  types  of  writes  (for  instance,
          deleting path) will be rejected.

Of course your backups must be incremental, and you should have some monitoring system in place, to prevent scenario when hacker backups junk data to eventualy "displace" real data from your incremental back up system.

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.