Project

General

Profile

Subtask #3272

Feature #4084: rbd: incremental backups

send/receive rbd snapshots

Added by Pavel Arbuzov almost 8 years ago. Updated over 7 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Target version:
% Done:

0%

Source:
Tags:
Backport:
Reviewed:
Affected Versions:
Pull request ID:

Description

It would be great to be able to send and receive incremental RBD snapshots as is done in zfs.

zfs send -i snap1 ... snapN | ssh root@host "zfs recieve ..."

In this case only changes will be sent.
This is very useful for creating incremental backups of large volumes.


Related issues

Copied to rbd - Feature #4444: send/receive rbd snapshots Resolved 10/08/2012

History

#1 Updated by Josh Durgin almost 8 years ago

  • Subject changed from send/recieve rbd snapshots to send/receive rbd snapshots

#2 Updated by Sage Weil over 7 years ago

  • translation missing: en.field_position set to 7

#3 Updated by Josh Durgin over 7 years ago

  • Parent task set to #4084

#4 Updated by Ian Colle over 7 years ago

From Sage - "I think this breaks down into a few different pieces:

1) Decide what output format to use. We want to use something that is
resembles a portable, standard way of representing an incremental set of
changes to a block device (or large file). I'm not sure what is out
there, but we should look carefully before making up our own format.

2) Expose changes objects between rados snapshots. This is some generic
functionality we would bake into librbd that would probably work similarly
to how read_iterate() currently does (you specify a callback). We
probably also want to provide this information directly to a user, so that
they can get a dump of (offsets, length) pairs for integration with their
own tool. I expect this is just a core librbd method.

3) Write a dumper based on #2 that outputs in format from #1. The
callback would (instead of printing file offsets) write the data to the
output stream with appropriate metadata indicating which part of the image
it is. Ideally the output part would be modular, too, so that we can come
back later and implement support for new formats easily. The output data
stream should be able to be directed at stdout or a file.

4) Write an importer for #1. It would take as input an existing image,
assumed to be in the state of the reference snapshot, and write all the
changed bits. Take input from stdin or a file.

5) If necessary, extend the above so that image resize events are properly
handled."

Note this ticket covers 1, 3, and 4 - 2 is 3387.

Estimate 11 points

#5 Updated by Ian Colle over 7 years ago

  • Status changed from New to Rejected
  • translation missing: en.field_remaining_hours set to 0.00

#6 Updated by Ian Colle over 7 years ago

  • Estimated time set to 0.00 h

Moved to 4444 - to track as a feature, not a subtask

Also available in: Atom PDF