Project

General

Profile

Actions

Feature #55152

open

rbd mirroring retention policy

Added by Jiayu Sun about 2 years ago. Updated almost 2 years ago.

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

0%

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

Description

Hi, I've read the docs from: https://docs.ceph.com/en/latest/rbd/rbd-mirroring/
I don't know if my understand is correct:
when I do one way snapshot based mirroring from cluster A to cluster B with a schedule like once a day. It will generate a new snapshot on cluster B every day and kept forever?

I also want to known if there's any capabilities that I can automatically remove old snapshot or if I can do a more complicated retention policy like: keeping full rbd snapshot for last week, last month and last year. and keep snapshot by diff for last 7 days?

Actions #1

Updated by Arthur Outhenin-Chalandre about 2 years ago

  • Tracker changed from Support to Feature
  • Project changed from Ceph to rbd

Jiayu Sun wrote:

Hi, I've read the docs from: https://docs.ceph.com/en/latest/rbd/rbd-mirroring/
I don't know if my understand is correct:
when I do one way snapshot based mirroring from cluster A to cluster B with a schedule like once a day. It will generate a new snapshot on cluster B every day and kept forever?

No it will generate mirror snapshots at the rate you want (BTW you can also manually or via your own automation do `rbd mirror image snapshot` to create a new mirror snapshot) and once it's replayed snapshots are automatically cleaned up.

I also want to known if there's any capabilities that I can automatically remove old snapshot or if I can do a more complicated retention policy like: keeping full rbd snapshot for last week, last month and last year. and keep snapshot by diff for last 7 days?

There is no retention policies on the mirror snapshots right now but I think that could be a nice feature to add. Note that this a not a backup tool (well it could become close to that if we have retention policy for mirror snapshots), for instance there is no mechanism to notify the application that a backup is running so you can't expect full application consistency (I think it's in the long term plan to have something to fsfreeze on rbd snapshots though).

Actions #2

Updated by Arthur Outhenin-Chalandre about 2 years ago

Actually thinking about this a second time, this could be something similar than the scheduled cephfs snapshot where you could do the same for rbd images. It would be simpler than adding extra complexity in rbd-mirror and also could be useful outside of rbd replication.

You could do also do your own automation today with a script that take normal red snapshots. Those would be replicated as well in your other ceph cluster with rbd replication (and not cleaned up like mirror snapshots). WDYT?

Actions #3

Updated by Jiayu Sun almost 2 years ago

Arthur Outhenin-Chalandre wrote:

Actually thinking about this a second time, this could be something similar than the scheduled cephfs snapshot where you could do the same for rbd images. It would be simpler than adding extra complexity in rbd-mirror and also could be useful outside of rbd replication.

You could do also do your own automation today with a script that take normal red snapshots. Those would be replicated as well in your other ceph cluster with rbd replication (and not cleaned up like mirror snapshots). WDYT?

Hi, I'm not quiet familiar with this. any docs for replicate a rbd snapshot to other cluster?

Actions #4

Updated by Arthur Outhenin-Chalandre almost 2 years ago

Jiayu Sun wrote:

Hi, I'm not quiet familiar with this. any docs for replicate a rbd snapshot to other cluster?

That's the default behavior of rbd replication, it replicates the rbd snapshots alongside the image.

Actions #5

Updated by Jiayu Sun almost 2 years ago

Arthur Outhenin-Chalandre wrote:

Jiayu Sun wrote:

Hi, I'm not quiet familiar with this. any docs for replicate a rbd snapshot to other cluster?

That's the default behavior of rbd replication, it replicates the rbd snapshots alongside the image.

do you mean that if I enable rbd-mirroring from cluster A to cluster B. and I take a snapshot on cluster A of some rbd-image. there's also another snapshot on cluster B generated for that rbd-image?

That sounds good! what if I'm running a script to generate a snapshot directly on B ?

which means that I don't need too much capacity on my high speed full SSD production environment and I can use cheaper HDD to store the snapshots.

Is it doable?

Actions #6

Updated by Arthur Outhenin-Chalandre almost 2 years ago

Jiayu Sun wrote:

Arthur Outhenin-Chalandre wrote:

Jiayu Sun wrote:

Hi, I'm not quiet familiar with this. any docs for replicate a rbd snapshot to other cluster?

That's the default behavior of rbd replication, it replicates the rbd snapshots alongside the image.

do you mean that if I enable rbd-mirroring from cluster A to cluster B. and I take a snapshot on cluster A of some rbd-image. there's also another snapshot on cluster B generated for that rbd-image?

Yes! It even works if you clone images from snapshots etc.

That sounds good! what if I'm running a script to generate a snapshot directly on B ?

You can only write/take snapshot from the cluster with the "active" image, so I believe that would be cluster A in your example.

which means that I don't need too much capacity on my high speed full SSD production environment and I can use cheaper HDD to store the snapshots.

Is it doable?

Not sure what you mean... But yeah the target cluster could be slower, in our case the "production" cluster is HDD replicas 3 and the cluster where we replicate data is HDD with EC.

Actions #7

Updated by Jiayu Sun almost 2 years ago

Not sure what you mean... But yeah the target cluster could be slower, in our case the "production" cluster is HDD replicas 3 and the cluster where we replicate data is HDD with EC.

I'm concerning capacity usage. Say that I have a production cluster consist of expensive SSD. And snapshot is only for some kind of backup usage. I just want my snapshot stored only on a HDD cluster with EC so that I can store many snapshots of a long history with little expense.

Actions #8

Updated by Arthur Outhenin-Chalandre almost 2 years ago

Jiayu Sun wrote:

Not sure what you mean... But yeah the target cluster could be slower, in our case the "production" cluster is HDD replicas 3 and the cluster where we replicate data is HDD with EC.

I'm concerning capacity usage. Say that I have a production cluster consist of expensive SSD. And snapshot is only for some kind of backup usage. I just want my snapshot stored only on a HDD cluster with EC so that I can store many snapshots of a long history with little expense.

That won't work AFAIK, the image is replicated as is with all its snapshots so you can't take snapshot on one cluster that won't be replicated on the other cluster.

Actions #9

Updated by Jiayu Sun almost 2 years ago

Arthur Outhenin-Chalandre wrote:

Jiayu Sun wrote:

Not sure what you mean... But yeah the target cluster could be slower, in our case the "production" cluster is HDD replicas 3 and the cluster where we replicate data is HDD with EC.

I'm concerning capacity usage. Say that I have a production cluster consist of expensive SSD. And snapshot is only for some kind of backup usage. I just want my snapshot stored only on a HDD cluster with EC so that I can store many snapshots of a long history with little expense.

That won't work AFAIK, the image is replicated as is with all its snapshots so you can't take snapshot on one cluster that won't be replicated on the other cluster.

Thanks! I'll setup mirroring and periodically snapshot. expensive backups is better than no backup

Actions

Also available in: Atom PDF