Push Button Recovery

The replication component of Dagda ensures that an up-to-date and logically consistent copy of every server's system state (o/s, applications and data) exists at a different location(s). However, it is not a trivial task to rebuild a server and make that data accessible again. Dagda automates the complexity of this process with its 'push button recovery' facility.

The push button recovery facility, 'inoculates' the disk image taken from the source server with the 'boot drivers' needed to make the operating system function with the differing hardware of the target server. It is able to do this whether the target server is a physical machine or a virtual machine (VM).

For example, in the case where the target server is a VM, the following summarises the steps taken automatically by the recovery process:

• Freezing the replication of each source volume;
• Applying a signature to each target volume to make them NTFS;
• Inoculation of the target operating system volumes with appropriate drivers;
• Updating the registry as appropriate for the operating system volumes;
• Removal of the replication session;
• Creation of a new VM profile;
• Logical transfer of the vmdk from the target server to the new VM;
• The vmdk is registered with VMware;
• The target server is stopped and restarted to release each vmdk.

In the diagram below, the push button recovery facility is illustrated with 3 different source machine scenarios (A, B & C) designed to represent small, medium and large source machine installations.

• Copy and recover. This option copies the affected target volumes after the freeze step. Although this increases the recovery time, it permits replication of the source volumes to be resumed after the recovery is complete.
• Backup and recover. This option takes backups of the affected volumes after the freeze step and subsequently recovers them to the newly created VM. The end result is similar to the above, but is substantially quicker.

Recovery from Archive

In some situations, it may be necessary to recover a server from one of the backup generations held in the archive. This may be required, for example, to produce a server for testing purposes, or possibly to recover a server that has been completely disabled by a malware infection. Dagda enables this process to be achieved quickly and easily. Upon initiation, the following steps are taken automatically; again this assumes recovery to a VM:

• Each new vmdk is created and registered with VMware;
• The target server is stopped and restarted to obtain each new vmdk;
• Upon restart the target server initialises each new vmdk;
• The required partitions are created and formatted;
• The Master Boot Record of each boot partition is created and activated;
• Each vmdk is recovered from the TIB file for the applicable backup generation;
• The operating system volumes are inoculated with the appropriate drivers;
• For each vmdk, a new VM is created and registered with VMware;
• Each vmdk is removed from the target server and attached to it's VM;
• The target server is stopped and restarted to release each vmdk.

The recovered server may then be started up. This step is deliberately left as a manual process in order to resolve any conflicts that may arise with the existing server, such as duplicate names or IP addresses.

In the case that a server has been recovered to an earlier date due to a malware infection, then once it is running, it is quite possible to restore individual files or folders from future backups (i.e. backups taken after the one that has been recovered). Thus important data can easily be brought back to the latest known good state.