Difference between revisions of "Backup/Restore procedure"
Jump to navigation
Jump to search
| (8 intermediate revisions by the same user not shown) | |||
| Line 2: | Line 2: | ||
=== Backup === | === Backup === | ||
| − | Currently running a [[backup script]] at | + | Currently running a [[backup script]] at 02:00 UTC |
| − | The VMWare virtual machine is snapshotted and then its file system is rsync'd. | + | The VMWare virtual machine is snapshotted and then its file system is rsync'd while the VM is running. |
===Restore to original host=== | ===Restore to original host=== | ||
Copy the rsync copy back to its original location | Copy the rsync copy back to its original location | ||
| + | |||
| + | Restart the VM after removing the snapshot | ||
=== Restore to another host === | === Restore to another host === | ||
| + | |||
| + | Similar to restoration to the original location plus: | ||
Needs VMWare Server 2.0 installed | Needs VMWare Server 2.0 installed | ||
| Line 16: | Line 20: | ||
gpl.openqm.com DNS to point to new server. | gpl.openqm.com DNS to point to new server. | ||
| − | == Problems with current strategy == | + | == <font color=red>Problems with current strategy</font> == |
| − | #Only one physical backup copy overwritten daily so no possibility to go back more than one day if a corrupt system is backed up | + | #Only [[User:SteveB|SteveB]] has overview and responsibility. This is a single point of failure. |
| − | #No regular verification | + | #Only one physical backup copy - overwritten daily - so no possibility to go back more than one day if a corrupt system is backed up |
| − | + | #No regular verification that the backup copy is usable - so the backup procedure could fail silently eg if there is anything wrong with the script logic | |
#VMSnapshot/Rsync is not totally proven method but results in minimal downtime whereas VMSuspend/Rsync will result in maybe 30 mins downtime | #VMSnapshot/Rsync is not totally proven method but results in minimal downtime whereas VMSuspend/Rsync will result in maybe 30 mins downtime | ||
Latest revision as of 13:19, 10 December 2008
Contents
Current Strategy
Backup
Currently running a backup script at 02:00 UTC
The VMWare virtual machine is snapshotted and then its file system is rsync'd while the VM is running.
Restore to original host
Copy the rsync copy back to its original location
Restart the VM after removing the snapshot
Restore to another host
Similar to restoration to the original location plus:
Needs VMWare Server 2.0 installed
gpl.openqm.com DNS to point to new server.
Problems with current strategy
- Only SteveB has overview and responsibility. This is a single point of failure.
- Only one physical backup copy - overwritten daily - so no possibility to go back more than one day if a corrupt system is backed up
- No regular verification that the backup copy is usable - so the backup procedure could fail silently eg if there is anything wrong with the script logic
- VMSnapshot/Rsync is not totally proven method but results in minimal downtime whereas VMSuspend/Rsync will result in maybe 30 mins downtime
