>> You're welcome. A pull system does rely on the server being secure, which >> is why I don't use it for offsite backups to the cloud :-O > > Wouldn't a push/pull combination be a good compromise? > > The remote servers push their backups to their own location on a staging > server. > The backup-storage server then pulls the backups from there. > > The staging can then be a VM with the real backups being moved onto > host-storage where the VM has no access to. > > This way, when the staging is compromised, only the latest backup can be > accessed. > When the remote server is compromised, only the latest backup can > potentially be overwritten. > But, the actual backups can not be accessed as the host will not have any > outgoing connectivity and when the backups are being pulled, the VM will > be stopped to allow access to the disk containing the backups. > > Following would be the steps: > 1) remote server(s) push backup to the VM > 2) host shuts down VM > 3) host mounts backup-store of VM locally > 4) host takes a backup of the "backup-store" > 5) host starts VM > > By using LVM snapshots, the downtime of the VM can be significantly reduced. > Additionally, the VM OS and software can be restored from a known-good > copy prior to each restart and the VM can be configured to only be running > during the backup-window of the remote systems. This would then > significantly reduce the window of opportunity for any security breach > attempts.
I think I follow. :) Do you think that would be better than having the clients push to the backup server via rsync, then having the backup server update an rdiff-backup repository that the clients have no access to, then having another system pull from the backup server's rsynced data and create its own rdiff-backup repository? To me that seems like it would have the right combination of security, redundancy, and simplicity. - Grant
