diff --git a/content/product/cluster_configuration/backup_system/overview.md b/content/product/cluster_configuration/backup_system/overview.md index 5f68db619..8b867171a 100644 --- a/content/product/cluster_configuration/backup_system/overview.md +++ b/content/product/cluster_configuration/backup_system/overview.md @@ -51,6 +51,6 @@ Performing a VM backup requires support from the hypervisor and the disk image f \* Any datastore based on files with the given format, i.e. NFS/SAN or Local. -† Ceph full and incremental backups are currently stored in a different way, see [backup types]({{% relref "product/virtual_machines_operation/virtual_machine_backups/operations#backup-types" %}}) for more details. +† See [Ceph Backup Format and Retention]({{% relref "product/cluster_configuration/storage_system/ceph_ds#backup-format-and-retention" %}}). ‡ Only supported in [thin mode]({{% relref "product/cluster_configuration/lvm/filemode#lvm-thin" %}}). diff --git a/content/product/cluster_configuration/storage_system/ceph_ds.md b/content/product/cluster_configuration/storage_system/ceph_ds.md index e24fa596a..32ba4a6c6 100644 --- a/content/product/cluster_configuration/storage_system/ceph_ds.md +++ b/content/product/cluster_configuration/storage_system/ceph_ds.md @@ -273,6 +273,16 @@ When creating a VM Template you can choose to deploy the disks using the default When using Sunstone, the deployment mode needs to be set in the Storage tab. +## Backup Format and Retention + +For backup configuration and operations, see [VM Backup Operations]({{% relref "product/virtual_machines_operation/virtual_machine_backups/operations" %}}). + +Ceph full backups use qcow2 files. Incremental chains created or reset on **OpenNebula 7.0.1 or later** also use qcow2, with increments generated from RBD snapshot differences. Both are registered with `FORMAT=raw`, despite storing qcow2 files. + +With Restic and Rsync, `KEEP_LAST` consolidates the oldest required backups into a base and removes superseded restore points, retaining the last N backups without periodic chain resets. This involves processing backup data; Restic retrieves the required backups and uploads the consolidated base. + +Legacy chains with `FORMAT=rbd` use native Ceph exports and do not support `KEEP_LAST`. Upgrades do not convert them automatically: use the backup operation's `--reset` option after upgrading to start a qcow2-based chain. Older backup images remain until removed separately. + ## Datastore Internals Images are stored in a Ceph pool, named after its OpenNebula ID `one-`. Virtual Machine disks are stored by default in the same pool (Ceph Mode). You can also choose to export the Image rbd to the hypervisor local storage using the SSH Mode. diff --git a/content/product/virtual_machines_operation/virtual_machine_backups/operations.md b/content/product/virtual_machines_operation/virtual_machine_backups/operations.md index 3afd1737e..5ee7346d2 100644 --- a/content/product/virtual_machines_operation/virtual_machine_backups/operations.md +++ b/content/product/virtual_machines_operation/virtual_machine_backups/operations.md @@ -34,11 +34,6 @@ Incremental backups of **qcow2** disks can use two different modes via the `INCR - **CBT** (Changed Block Tracking). For each increment OpenNebula creates a block bitmap in the disk image to track which blocks have changed since the last backup. - **SNAPSHOT**. OpenNebula tracks changes by creating a separate disk snapshot. This snapshot stores all disk changes since the last backup. -Also, for **RBD** disks (Ceph), FULL and INCREMENT backups are currently stored in a different way, although the difference should be transparent to the user: - -- **Full** backups (`FORMAT=raw`) store the RBD export converted to a qcow2 file. The restore process involves converting it to a RAW file and importing it to the Ceph pool. -- **Incremental** backups (`FORMAT=rbd`) store the initial RBD export, as well as zero or more increment files, in the native format of Ceph exports (rbd export –export-format 2 / rbd export-diff). The restore process involves importing the initial export and applying the diff files in the same order, one by one. - {{< alert title="Note" type="info" >}} The `INTERACTIVE` backup workflow is reserved for supported third-party integrations, such as the [OpenNebula-Veeam® Backup Integration]({{% relref "../../../product/cluster_configuration/backup_system/veeam.md#vm-backups-veeam" %}}). It is not a standalone backup backend for users to configure directly. In this workflow, OpenNebula exposes the backup data through OneBEX and the external backup system pulls the data from the hypervisor. @@ -67,7 +62,7 @@ In order to save space in the backup system, RAW disk backups are converted and - Live backups are only supported for KVM - Attaching a disk to a VM that had an incremental backup previously made will yield an error. The –reset option for the backup operation is required to recreate a new incremental chain - Incremental backups on VMs with disk or system snapshots is not supported -- `KEEP_LAST` option is not supported for Incremental backups of Ceph disks +- For Ceph retention requirements, see [Backup Format and Retention]({{% relref "product/cluster_configuration/storage_system/ceph_ds#backup-format-and-retention" %}}). - Interactive backups only support datastores using the `local`, `shared` and `lvm*` TM drivers. ## Preparing VMs for Backups