Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for incremental backups in Ceph #6411

Closed
3 tasks
rsmontero opened this issue Nov 29, 2023 · 3 comments
Closed
3 tasks

Add support for incremental backups in Ceph #6411

rsmontero opened this issue Nov 29, 2023 · 3 comments

Comments

@rsmontero
Copy link
Member

Description
This feature is to implement incremental backups in Ceph. The overall process would be:

  • Create a snapshot to mark the start of the increment
  • Use rbd diff to get the blocks changed since the snapshot was created
  • Read blocks and write them to a qcow2 file
  • Store the qcow2 increment files in the backup server

Interface Changes
None

Progress Status

  • Code committed
  • Testing - QA
  • Documentation (Release notes - resolved issues, compatibility, known issues)
@nachowork90
Copy link

I was doing the same thing and I was thinking in create a driver for Backy or Benji, in order to build a more profesional tools, because the conversion to qcow2 have better portability than the raw image, but dealing with the raw images can speed up the process! Backy/benji simplifies the whole process because they use the xml that represent the rbd diff!

@1gramos 1gramos added this to the Release 7.0 milestone Jul 30, 2024
@1gramos 1gramos self-assigned this Jul 30, 2024
@rsmontero rsmontero modified the milestones: Release 7.0, Release 6.10.1 Oct 2, 2024
1gramos added a commit to OpenNebula/docs that referenced this issue Oct 3, 2024
@Franco-Sparrow
Copy link

Hi @rsmontero

I think that a better approach for Ceph Incremental Backups could be achieved using known projects like Backy2. Store the increments in qcow2 files will require to convert from raw to qcow2, so a backup uising Ceph will take more time. An rsync host could be prepared with backy2 and sharing its storage with the opennebula cloud. Backy2 driver should be prepared to create, delete, ls and some other actions required for a backup.

This is just my humble opinion, which is aligned with @nachowork90 proposal.

@rsmontero
Copy link
Member Author

Hi @Franco-Sparrow

Agree, in fact the final implementation in 6.10.1 does not stores deltas in qcow2 format but in native rbd diff format. Don't know the internals of other tools but directly implementing this incremental backups on top of the OpenNebula backup framework is aimed to provide the best experience for our user base.

Thanks for your comments

rsmontero added a commit that referenced this issue Oct 4, 2024
Implementation overview:

- Incremental points are saved as dedicated rbd snapshots under the
  "one_backup_<increment_id>" namespace. This snapshots are used to
  generate delta files in rbdiff format.

- The rbdiff formats are stored in the backup server to restore the rbd volumes.

- The restore process is performed directly on the Ceph cluster
  importing the base image (first full backup in the chain, rbd import)
  and then applying the increments (rbd import-diff) up to the target
  increment.

- Two new pseudo-protocols has been implemented to adopt the restore
  pattern above (restic+rbd, rsync+rbd). This protocols bundle of the
  rbdiff files in a tarball for transfer from the backup server. Note:
  reconstruct process uses the Ceph BRIDGE_LIST and not the backup
  server (as opposed to qcow2 backups)

Other bug fixes

- This commit also fixes #6741, resetting the backup chain after a
  restore

- The original ceph drivers do not receive the full action information,
  this now has been fixed by including VM information in the STDIN string sent
  to the driver.

Compatibility note.

- backup actions should return now the backup format used raw, rbd, ...
  If not provided oned (6.10.x) will use raw as a default to accommodate any
  third party driver implementation. It is recommended to include this
  third argument.

Signed-off-by: Guillermo Ramos <[email protected]>
Co-authored-by: Guillermo Ramos <[email protected]>
rsmontero pushed a commit to OpenNebula/docs that referenced this issue Oct 4, 2024
rsmontero pushed a commit to OpenNebula/docs that referenced this issue Oct 4, 2024
Signed-off-by: Guillermo Ramos <[email protected]>
(cherry picked from commit 860e3ff)
1gramos added a commit to OpenNebula/docs that referenced this issue Oct 8, 2024
1gramos added a commit to OpenNebula/docs that referenced this issue Oct 8, 2024
rsmontero pushed a commit to OpenNebula/docs that referenced this issue Oct 8, 2024
rsmontero pushed a commit to OpenNebula/docs that referenced this issue Oct 8, 2024
Signed-off-by: Guillermo Ramos <[email protected]>
(cherry picked from commit 80ff9a5)
rsmontero pushed a commit to OpenNebula/docs that referenced this issue Oct 8, 2024
rsmontero added a commit that referenced this issue Jan 13, 2025
Implementation overview:

- Incremental points are saved as dedicated rbd snapshots under the
  "one_backup_<increment_id>" namespace. This snapshots are used to
  generate delta files in rbdiff format.

- The rbdiff formats are stored in the backup server to restore the rbd volumes.

- The restore process is performed directly on the Ceph cluster
  importing the base image (first full backup in the chain, rbd import)
  and then applying the increments (rbd import-diff) up to the target
  increment.

- Two new pseudo-protocols has been implemented to adopt the restore
  pattern above (restic+rbd, rsync+rbd). This protocols bundle of the
  rbdiff files in a tarball for transfer from the backup server. Note:
  reconstruct process uses the Ceph BRIDGE_LIST and not the backup
  server (as opposed to qcow2 backups)

Other bug fixes

- This commit also fixes #6741, resetting the backup chain after a
  restore

- The original ceph drivers do not receive the full action information,
  this now has been fixed by including VM information in the STDIN string sent
  to the driver.

Compatibility note.

- backup actions should return now the backup format used raw, rbd, ...
  If not provided oned (6.10.x) will use raw as a default to accommodate any
  third party driver implementation. It is recommended to include this
  third argument.

Signed-off-by: Guillermo Ramos <[email protected]>
Co-authored-by: Guillermo Ramos <[email protected]>
(cherry picked from commit 5f7b370)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants