| 1 |
On Tue, July 2, 2013 10:08, Neil Bothwick wrote: |
| 2 |
> |
| 3 |
> You're welcome. A pull system does rely on the server being secure, which |
| 4 |
> is why I don't use it for offsite backups to the cloud :-O |
| 5 |
|
| 6 |
Wouldn't a push/pull combination be a good compromise? |
| 7 |
|
| 8 |
The remote servers push their backups to their own location on a staging |
| 9 |
server. |
| 10 |
The backup-storage server then pulls the backups from there. |
| 11 |
|
| 12 |
The staging can then be a VM with the real backups being moved onto |
| 13 |
host-storage where the VM has no access to. |
| 14 |
|
| 15 |
This way, when the staging is compromised, only the latest backup can be |
| 16 |
accessed. |
| 17 |
When the remote server is compromised, only the latest backup can |
| 18 |
potentially be overwritten. |
| 19 |
But, the actual backups can not be accessed as the host will not have any |
| 20 |
outgoing connectivity and when the backups are being pulled, the VM will |
| 21 |
be stopped to allow access to the disk containing the backups. |
| 22 |
|
| 23 |
Following would be the steps: |
| 24 |
1) remote server(s) push backup to the VM |
| 25 |
2) host shuts down VM |
| 26 |
3) host mounts backup-store of VM locally |
| 27 |
4) host takes a backup of the "backup-store" |
| 28 |
5) host starts VM |
| 29 |
|
| 30 |
By using LVM snapshots, the downtime of the VM can be significantly reduced. |
| 31 |
Additionally, the VM OS and software can be restored from a known-good |
| 32 |
copy prior to each restart and the VM can be configured to only be running |
| 33 |
during the backup-window of the remote systems. This would then |
| 34 |
significantly reduce the window of opportunity for any security breach |
| 35 |
attempts. |
| 36 |
|
| 37 |
-- |
| 38 |
Joost |
Archives