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:
...
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