Difference between revisions of "Backup/Restore procedure"

From ScarletDME
Jump to navigation Jump to search
(New page: == Current Strategy == Currently running a backup script at 06:00 UTC == Problems with current strategy == #Only one physical backup copy overwritten daily so no possibility to go b...)
 
 
(11 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
== Current Strategy ==
 
== Current Strategy ==
  
Currently running a [[backup script]] at 06:00 UTC
+
=== Backup ===
 +
Currently running a [[backup script]] at 02:00 UTC
  
== Problems with current strategy ==
+
The VMWare virtual machine is snapshotted and then its file system is rsync'd while the VM is running.
  
#Only one physical backup copy overwritten daily so no possibility to go back more than one day if a corrupt system is backed up
+
===Restore to original host===
#No regular verification if the backup copy is usable
+
 
#Backup procedure could fail silently if there is anything wrong in the scripts
+
Copy the rsync copy back to its original location
#Only [[User:SteveB|SteveB]] has overview responsible means a single point of failure
+
 
 +
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.
 +
 
 +
== <font color=red>Problems with current strategy</font> ==
 +
 
 +
#Only [[User:SteveB|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

Latest revision as of 13:19, 10 December 2008

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

  1. Only SteveB has overview and responsibility. This is a single point of failure.
  2. Only one physical backup copy - overwritten daily - so no possibility to go back more than one day if a corrupt system is backed up
  3. 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
  4. VMSnapshot/Rsync is not totally proven method but results in minimal downtime whereas VMSuspend/Rsync will result in maybe 30 mins downtime