The problem you're referencing is really a problem of securing/protecting your backups once you've made them.
The standard approach to this problem is to use some form of removable media that's taken off site on a regular basis.
- Typically, with LTO-tape media, you'll have all your backup tapes rotated off site on a regular schedule, such that the only backup tapes that you have on site are the ones actively in the tape library to record backup data.
- I've also seen this done with USB flash drives and removable drives, occasionally. This approach protects your backups from both malicious action, and physical disasters.
- A slightly different take on this approach is to use write-once media, so that backups can't be deleted once they're made.
- CDs/DVDs or WORM LTO media, generally. Usually this approach is somewhat more limited in scope, because it can get expensive and effort-intensive pretty quickly.
- For an example, in a high security environment I worked in, we had scripts to copy our server logs over to a backup server on a continual basis, and then burn them to a DVD every night, as a mechanism to preserve the information in them. In the event that something went wrong or we got hacked, wiping out the logs on the server in question wouldn't do much good.
With the proliferation of disk-to-disk backup systems these days, neither option is always available or feasible, but there are many ways to achieve the same thing. They basically fall into two categories.
- One category, as mentioned in the comments, is the use of public key cryptography to separate read and write permissions at a cryptographic level.
- One such service is tarsnap. Since different keys are used to read and write data, you can store each key in a different place, so that an attacker who compromises your backups cannot read them.
- Tarsnap is far from the only provider of such a service, and you could even roll your own solution with widely available public key cryptographic tools. Presumably, however, they'd still be able to "mess with" the backups (destroy or corrupt them).
- This is most useful in compliance situations, or situations where data privacy is important, and the worry is about an attacker being able to get at the information (read your backups), but does not protect against an attacker destroying or corruption those backups.
- The other category, is to actually segment the permissions, so that your backup server does not have the permissions needed to alter or overwrite data.
- The obvious way to do this is by only giving your backup server/service read and write permissions at a filesystem level, but not modify or delete permissions.
- You can achieve the same thing by separating the backup server from the server that houses the backups, so that compromising the actual backups involves more than just compromising the server that's use to create your backups.
- This is the approach I'm using now, for $[corporate_overlord]. Backups are replicated offsite (disk-to-disk system), but the primary backup node, and the off-site node are accessed using different accounts, so compromising one node does not allow the other to be compromised. Each node can read the other's data, but each node can only modify/delete its own data.
- The two approaches can even be combined, for the truly paranoid/best of both worlds.
Finally, even if you're using a disk-to-disk scenario, there's no reason you can't implement a solution that effectively takes your backups offline. You could set up a system to automatically take the server/disk that houses your backups offline after the backups complete, and brings it back online only when the next backups are scheduled to occur, or less drastically, remount the volume storing your backups as read-only. Seems like more work than setting up permissions as above, but is possible.