4 ms·

Is there any way to protect backups from being deleted? ServerA shouldn't be allowed to destroy ServerB's backups. And preferably it shouldn't be allowed to des

by e911 13y ago

Is there any way to protect backups from being deleted? ServerA shouldn't be allowed to destroy ServerB's backups. And preferably it shouldn't be allowed to destroy it's own backups (bad backup script or evil attacker trying to delete eevrything).

corobo 13y ago
(not rsync, just a happy customer!) It may be a tiny bit of a chore but you can get sub-accounts set up if it's a potential problem: http://www.rsync.net/resources/faq.html#7a http://www.rsync.net/resources/faq.html#7a
dspillett 13y ago
> ServerA shouldn't be allowed to destroy ServerB's backups. This seems's to be covered in the FAQ: Do you have multi-user access? Yes. You may configure additional users, at no cost, that can log in and share your account. You may control access and file permissions with standard Unix tools like 'chmod' and 'chgrp'. So you could give each content unit its own account and protect it from the others. > And preferably it shouldn't be allowed to destroy it's own backups That one is fun to arrange. Many services like rsync.net offer daily snapshots for a number of days so you can't easily kill everything in one huge cock-up, but if you don't notice a problem for weeks then all your daily snapshots prior to the problem may have expired and data therefore lost. The only real answer here is to have some form of regular checking (both automated and human powered in case the automated checking fails and fails to inform you) of your backups.
rsync 13y ago
Well, two things... First, our ZFS storage arrays have read-only snapshots (7 dailies by default, or any arbitrary day/week/month by request). No charge for them, or their space, unless you do a custom retention setup. Second, we support "pull" backups ... that is, instead of rsyncing (or wahtever) to us, we can set up a cron job on our end and pull from you, using an SSH key. That way an attacker on your system has no ability to log into your rsync.net account, nor do they even know it exists unless they watch all the network connections and put two and two together... So we'll make it work for you ...

by e911 13y ago

corobo 13y ago

(not rsync, just a happy customer!) It may be a tiny bit of a chore but you can get sub-accounts set up if it's a potential problem: http://www.rsync.net/resources/faq.html#7a http://www.rsync.net/resources/faq.html#7a

dspillett 13y ago

> ServerA shouldn't be allowed to destroy ServerB's backups. This seems's to be covered in the FAQ: Do you have multi-user access? Yes. You may configure additional users, at no cost, that can log in and share your account. You may control access and file permissions with standard Unix tools like 'chmod' and 'chgrp'. So you could give each content unit its own account and protect it from the others. > And preferably it shouldn't be allowed to destroy it's own backups That one is fun to arrange. Many services like rsync.net offer daily snapshots for a number of days so you can't easily kill everything in one huge cock-up, but if you don't notice a problem for weeks then all your daily snapshots prior to the problem may have expired and data therefore lost. The only real answer here is to have some form of regular checking (both automated and human powered in case the automated checking fails and fails to inform you) of your backups.

rsync 13y ago

Well, two things... First, our ZFS storage arrays have read-only snapshots (7 dailies by default, or any arbitrary day/week/month by request). No charge for them, or their space, unless you do a custom retention setup. Second, we support "pull" backups ... that is, instead of rsyncing (or wahtever) to us, we can set up a cron job on our end and pull from you, using an SSH key. That way an attacker on your system has no ability to log into your rsync.net account, nor do they even know it exists unless they watch all the network connections and put two and two together... So we'll make it work for you ...