Project

General

Profile

Actions

Subtask #3272

closed

Feature #4084: rbd: incremental backups

send/receive rbd snapshots

Added by Pavel Arbuzov over 11 years ago. Updated about 11 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 1 (0 open1 closed)

Copied to rbd - Feature #4444: send/receive rbd snapshotsResolvedSage Weil10/08/2012

Actions
Actions #1

Updated by Josh Durgin over 11 years ago

  • Subject changed from send/recieve rbd snapshots to send/receive rbd snapshots
Actions #2

Updated by Sage Weil over 11 years ago

  • Translation missing: en.field_position set to 7
Actions #3

Updated by Josh Durgin about 11 years ago

  • Parent task set to #4084
Actions #4

Updated by Ian Colle about 11 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

Actions #5

Updated by Ian Colle about 11 years ago

  • Status changed from New to Rejected
  • Translation missing: en.field_remaining_hours set to 0.00
Actions #6

Updated by Ian Colle about 11 years ago

  • Estimated time set to 0:00 h

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

Actions

Also available in: Atom PDF