Re: [gentoo-user] {OT} backups... still backups....

[Grant]

>> 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