Write-only remote backup solutions to prevent backup deletion by hackers
Solution 1:
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.
Solution 2:
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.
Solution 3:
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.
Solution 4:
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.
Solution 5:
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.