Changes

This page describes how the VMs and VM-Templates are backed-up and restored inside the [http://www.stoney-cloud.org stoney cloud].

The main idea to backup a VM or a VM-Template is, to divide the task into three subtasks:

* Snapshot: Save the machines state (CPU, Memory and Disk)

Furthermore there is an control instance, which can independently call these three sub-processes for a given machine. Like that, the stoney cloud is able to handle different cases:

The procedure for backing up a single machine is very simple. Just call the three sub-processes (snapshot, merge and retain) one after the other. So the control instance would do some very basic stuff:

<source lang="c">

</source>

When backing up multiple machines at the same time, we need to make sure that the downtime for the machines are as close together as possible. Therefore the control instance should call first the snapshot process for all machines. After every machine has been snapshotted, the control instance can call the merge and retain process for every machine. The most important part here is, that the control instance somehow remembers, if the snapshot for a given machine was successful or not. Because if the snapshot failed, it must not call the merge and retain process. So the control instance needs a little bit more logic:

</source>

# Create a snapshot with state:

#* If the VM <code>vm-001</code> is running:

See also: [[stoney_conductor:_prov_backup_kvm#Snapshot | Snapshot workflow ]]

# Check if the VM <code>vm-001</code> is running

#* If not, start the VM in paused state: <syntaxhighlight lang="bash">virsh start --paused vm-001</syntaxhighlight>

See also: [[stoney_conductor:_prov_backup_kvm#Merge | Merge workflow]]

# Move the all the files in from the retain directory (<code>/path/to/retain/</code>) to the backup directory (<code>/path/to/backup/</code>)

## Move the VMs state file to the backup directory

See also [[stoney_conductor:_prov_backup_kvm#Retain | Retain workflow]]

Since the stoney cloud is (as the name says already) a cloud solution, it makes sense to have a backend (in our case openLDAP) involved in the whole process. Like that it is possible to run the backup jobs decentralized on every vm-node. The control instance can then modify the backend, and theses changes are seen by the diffenrent backup daemons on the vm-nodes. So the communication could look like shown in the following picture (Figure 1):

[[File:Daemon-communication.png|500px|thumbnail|none|Figure 1: Communication between the control instance and the prov-backup-kvm daemon through the LDAP backend]]

The step numbers correspond with the graphical overview from above.

<pre>

# The following backup configuration says, that the backup should be done daily, at 03:00 hours (localtime).

</pre>

The sub tree ''' ou=20121002T010000Z,ou=backup,sstVirtualMachine=kvm-005,ou=virtual machines,ou=virtualization,ou=services,o=stepping-stone,c=ch''' reflects the time, when the backup is planned (in the form of [YYYY][MM][DD]T[hh][mm][ss]Z ([http://en.wikipedia.org/wiki/ISO_8601 ISO 8601]) and it should be written at the time, when the backup is planned and should be executed. The section '''20121002T010000Z''' means the following:

* Year: 2012

</pre>

<pre>

# The attribute sstProvisioningState is updated with current time by the fc-brokerd, when sstProvisioningMode is modified.

</pre>

With the setting of the '''sstProvisioningMode''' to '''snapshot''', the actual backup process is kicked off by the Control instance daemon.

<pre>

</pre>

As soon as the Provisioning-Backup-KVM daemon receives the snapshot command, it sets the '''sstProvisioningMode''' to '''snapshotting''' to tell the Control instance daemon and other interested parties, that it is snapshotting the virtual machine or virtual machine template.

<pre>

</pre>

As soon as the Provisioning-Backup-KVM daemon has executed the snapshot command, it sets the '''sstProvisioningMode''' to '''snapshotted''', the '''sstProvisioningState''' to the current timestamp (UTC) and '''sstProvisioningReturnValue''' to zero to tell the Control instance daemon and other interested parties, that the snapshot of the virtual machine or virtual machine template is finished.

<pre>

</pre>

With the setting of the '''sstProvisioningMode''' to '''merge''', the Control instance daemon tells the Provisioning-Backup-KVM daemon to merge the backing file disk image back into the current disk image.

<pre>

</pre>

As soon as the Provisioning-Backup-KVM daemon receives the merge command, it sets the '''sstProvisioningMode''' to '''merging''' to tell the Control instance daemon and other interested parties, that it is merging the virtual machine or virtual machine template.

<pre>

</pre>

As soon as the Provisioning-Backup-KVM daemon has executed the merge command, it sets the '''sstProvisioningMode''' to '''merged''', the '''sstProvisioningState''' to the current timestamp (UTC) and '''sstProvisioningReturnValue''' to zero to tell the Control instance daemon and other interested parties, that the merging of the virtual machine or virtual machine template is finished.

<pre>

</pre>

With the setting of the '''sstProvisioningMode''' to '''retain''', the Control instance daemon tells the Provisioning-Backup-KVM daemon to retain (copy and then delete) all the necessary files to the configured backup location.

<pre>

</pre>

As soon as the Provisioning-Backup-KVM daemon receives the retain command, it sets the '''sstProvisioningMode''' to '''retaining''' to tell the Control instance daemon and other interested parties, that it is retaining the necessary files to the configured backup location.

<pre>

</pre>

As soon as the Provisioning-Backup-KVM daemon has executed the retain command, it sets the '''sstProvisioningMode''' to '''retained''', the '''sstProvisioningState''' to the current timestamp (UTC) and '''sstProvisioningReturnValue''' to zero to tell the Control instance daemon and other interested parties, that the retaining of all the necessary files to the configured backup location is finished.

<pre>

</pre>

As soon as the Control instance daemon notices, that the attribute '''sstProvisioningMode''' ist set to '''retained''', it sets the '''sstProvisioningMode''' to '''finished''' and the '''sstProvisioningState''' to the current timestamp (UTC). All interested parties now know, that the backup process is finished, there for a new backup process could be started.

<pre>