DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
Page History
...
4.0. VM Backup Creation
We will create three two new DB tables and a new view, nativeinternal_backup_pool_ref, nativeinternal_backup_store_ref, backup_details and nativeinternal_backup_view. The first will store metadata about backup deltas, which are on the primary storage; the second will store metadata about the backups, which are on the secondary storage; the third table will be a generic details table, that may be used by any backup provider, for this provider, a some information will be stored in it: Whether the backup is current, if it is the end of its chain, what is its parent and which image store it is in. Regarding the view, it is used to facilitate some processes in the code. When a backup delta is created, all three tables will be updated.
The nativeinternal_backup_pool_ref table will contain the following columns:
| Name | Type | Description |
|---|---|---|
| id | bigint | Row ID |
| backup_id | bigint | The backup's ID. Foreign key that points to the backups table. |
| storage_pool_id | bigint | The storage's ID. Foreign key that points to the storage_pool table. |
| volume_id | bigint | The volume's ID. Foreign key that points to the volumes table. |
| backup_delta_path | varchar(255) | Path of the created delta |
| backup_parent_path | varchar(255) | Path of the created delta's parent |
The nativeinternal_backup_store_ref table will contain the following columns:
...
| Name | Type | Description |
|---|---|---|
id | bigint | Row ID |
backup_id | bigint | The backup's ID. Foreign key that points to the backups table. |
name | varchar(255) | The detail name |
value | varchar(1024) | The detail value |
display | tinyint(1) unsigned |
The nativeinternal_backup_view will contain the following columns:
...
BackingUp: When the backup process begins, the VM will transition from theReadyorStoppedto theBackingUpstate, this state cannot be reached otherwise. During the backup process, the backup job will be queued alongside the other VM jobs; therefore, we will not have to worry about the VM being stopped/started during the backup, as each job is processed sequentially for each given VM.BackupError: If an exception which cannot be automatically recovered from happens (if the MGMT/agent service goes down, for example) or the job times out, the VM will go from theBackingUpto theBackupErrorstate. While the VM is in this state, the VM may not be started, stopped, rebooted, migrated or snapshotted; its volumes cannot be attached, detached, migrated or snapshotted. An operator must read the logs and recover the VM manually from ThefinishBackupChainAPI may be called to try to fix this state.
The proposed VM backup creation workflow is summarized in the following diagram. Every step is repeated for all the volumes of the VM, except the virDomainSnapshotCreateXML step and the validation step, which are done for the VM as a whole.
...
To allow operators to pause the compression processes, the backup.compression.task.enabled account/domain/global setting will be created, when set to false in the global scope, no compression jobs will be executed, regardless of the value in other scopes. When true in the global scope, you may disable the compression task for certain domains or accounts by setting the value to false in the domain/account.
4.0.2 Ending the backup chain
The API finishBackupChain will be added to allow users to force a backup chain on a VM to end. This API may be called on VMs that are on the BackupError state and it will do a best-effort attempt at normalizing the VM and returning it to its original state, as well as finishing the backup chain on the VM. The API hast the following parameter:
| Parameter | Description |
|---|---|
vmId | ID of the VM to finish the chain. |
4.1. Backup Restoration
As with the backup creation, this process will be queued with the other VM jobs and serialized, so we will not have to worry about the VM starting during the restoration process. Furthermore, the current backup chain will be severed.
...
The backup validation process will consist of three steps: wait for the VM to boot; execute a user-defined command; take a screenshot of the console of the VM. The first two steps can only be performed if the VM has the QEMU guest agent installed and it is configured to start on system startup. The main idea of the backup validation process is to verify that the VM is able to boot using the backup being validated. The validation steps that will be executed are defined in the native backup offering through the validationSteps parameter, by default, only the screenshot step is executed.
...
Furthermore, operators will be able to configure periodic validation of already validated backups. At the end of the validation process, if the backup is deemed valid, a hash of the backup will be stored. The next validations of that backups will only take the hash and compare it to the original. Since the backup was already marked as valid, as long as the hash of the backup does not change, it should remain valid. To configure the periodic backup validation process, operators may use the validationInterval parameter of the native backup offerings. Furthermore, a new VM setting with the same name will be created that overrides the configuration set in the backup offering. By default, only operators will be able to see this VM setting, as it will be added to the user.vm.denied.details list of settings.
...
Overview
Content Tools