Project

General

Profile

Actions

Feature #4444

closed

send/receive rbd snapshots

Added by Ian Colle about 11 years ago. Updated about 11 years ago.

Status:
Resolved
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 3 (0 open3 closed)

Related to rbd - Feature #4445: librbd: expose changed objects since a given snapshotResolvedSage Weil10/23/2012

Actions
Related to rbd - Feature #4084: rbd: incremental backupsResolvedSage Weil10/08/2012

Actions
Copied from rbd - Subtask #3272: send/receive rbd snapshotsRejected10/08/2012

Actions
Actions #1

Updated by Ian Colle about 11 years ago

  • Translation missing: en.field_story_points set to 11.00

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 #2

Updated by Ian Colle about 11 years ago

  • Target version set to v0.61 - Cuttlefish
Actions #3

Updated by Neil Levine about 11 years ago

  • Status changed from New to 12
Actions #4

Updated by Sage Weil about 11 years ago

  • Status changed from 12 to In Progress
Actions #5

Updated by Ian Colle about 11 years ago

  • Assignee set to Sage Weil
Actions #6

Updated by Sage Weil about 11 years ago

  • Status changed from In Progress to Resolved
Actions

Also available in: Atom PDF