DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.

DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
...
While this feature will be compatible with disk-only VM snapshots, if a VM snapshot is reverted while there is an active backup chain, the next backup may have to be a full backup. When reverting a backup, if the VM has any VM snapshots, those will need to be removed before reverting the backup. Otherwise, we would have to create a new tree for the VM's volumes, and keep many trees would add complexity to the implementation. This limitation might be addressed in the future if a significant use case is presented.
We propose to add native backup offerings as the way to configure the KNIB backup offerings natively. Three new APIs will be created: createNativeBackupOffering, deleteNativeBackupOffering, listNativeBackupOfferings; these APIs will allow the creation, removal, and listing of native backup offerings. These offerings will be imported into the standard backup framework flow for use.
The createNativeBackupOffering API will have the following parameters:
...
Currently, the only way to create new offerings is to import them, using an external ID listed by the backup provider. Since we are proposing a solution where ACS is the provider, we will not have an external ID to inform on the importBackupOffering. Thus, a new API called createBackupOffering will be created, which will define a new backup offering from scratch, this API will have the necessary parameters to configure the behavior of KNIB backups.
The createBackupOffering API will have the following parameters:
| Parameter | Description | Default Value | Required |
|---|---|---|---|
name | Specifies the name of the offering | - | Yes |
description | The description of the backup offering | - | Yes |
compress | Specifies whether the offering supports backup compression | false | No |
validate | Specifies whether the offering supports backup validation | false | No |
validationSteps | A comma-separated list of which validation steps should be performed. |
| No |
validationInterval | Specifies the interval (in hours) between two validations of the same backup | false | No |
allowQuickRestore | Specifies whether the offering supports quick restore | false | No |
allowExtractFile | Specifies whether the offering supports file extraction from backups | false | No |
compressionlibrary | Compression library, for offerings that support compression. Accepted values are zstd and zlib. If the image only supports zlib, it will be used regardless of this parameter. | zstd | No |
backupchainsize | Backup chain size for backups created with this offering. | - | No |
zoneId | The zone ID for the offering | - | Yes |
userDrivenBackups | Whether users are allowed to create adhoc backups and backup schedules | - | Yes |
domainIds | the ID of the containing domain(s), null for public offerings | - | No |
The deleteNativeBackupOffering API will have the following parameter:
| Parameter | Description | Required |
|---|---|---|
id | Identifier of the native backup offering. | Yes |
A native backup offering will only be removed if it is not currently imported.
The listNativeBackupOfferings API will have the following parameters:
| Parameter | Description | Required |
|---|---|---|
id | Identifier of the offering. | No |
compress | Lists only offerings that support backup compression. | No |
validate | Lists only offerings that support backup validation. | No |
allowQuickRestore | Lists only offerings that support quick restore. | No |
allowExtractFile | Lists only offerings that support file extraction from backups. | No |
showRemoved | Lists also offerings that have already been removed. | No |
name | Backup offering name. | No |
...
We will create three new DB tables and a new view, native_backup_pool_ref, native_backup_store_ref, backup_details and native_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.
...