Write-only remote backup solutions to prevent backup deletion by hackers [closed]

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!


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.


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.


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.


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.