How to send incremental snapshots to a clone?

[Binarus]

Hello everybody,

how can I send incremental snapshots to a clone?

Scenario (simplified), one pool with name rpool:

zfs create rpool/data
zfs snapshot rpool/data@1
zfs snapshot rpool/data@2
zfs snapshot rpool/data@3
zfs send -R rpool/data@3 | zfs receive -F rpool/backup
zfs destroy rpool/backup@2
zfs clone rpool/backup@1 rpool/clone

This works so far and gives the expected results. However, when I now do

zfs send -I rpool/data@1 rpool/data@3 | zfs receive rpool/clone

I get the error message

cannot receive incremental stream: most recent snapshot of rpool/clone does not match incremental source

How do I get around this problem?

The goal here is to restore the deleted snapshot rpool/backup@2. Since we can't send old snapshots to a dataset retroactively, the idea is to clone the first snapshot of the dataset in question (rpool/backup), to add all later snapshots to the clone based on that, and finally to promote the clone.

Coming back to the example, I know that I could could leave out the part with the clone and instead delete rpool/backup@3 and incrementally send rpool/data@2 and rpool/data@3 to rpool/backup. However, my situation is more complicated; put short, I don't want to destroy further snapshots in rpool/backup.

So why does sending the incremental snapshot to the clone not work? What I am doing wrong? rpool/backup was a literal copy of rpool/data, and rpool/clone is a literal clone of rpool/backup@1, so the incremental sources should match.

Thanks in advance for any help!

[whoschek]

The 'from' snapshot in the -I syntax should specify a common snapshot, but rpool/data@2 doesn't look like a common snapshot (whereas rpool/data@1 does). If you adjust it like this I guess it would work: zfs send -I rpool/data@1 rpool/data@3 | zfs receive rpool/clone

[Binarus]

Thank you very much for your reply, and +1.

But of course, I knew that there must be a common snapshot. But I had made a mistake in my problem report (due to copy-and-paste and simplification):

Actually, the command that I had used already was

zfs send -I rpool/data@1 rpool/data@3 | zfs receive rpool/clone

instead of

zfs send -I rpool/data@2 rpool/data@3 | zfs receive rpool/clone

Both commands produce the same error message. As you correctly have stated, the second command is expected to do that, but I actually have used the first (correct) command and nevertheless got that error message.

I am very sorry for the confusion. In the meantime, I have edited my question and have corrected the typo in the interest of people who come across it later.

[IvanVolosyuk]

The problem is the origin snapshot belongs to the original dataset. You can create a send stream on the original dataset from the original dataset from "origin" snapshot, save it, promote the clone temporarily (it will move the origin snapshot to the clone). Then you can receive the steam on clone and after that promote the original dataset to make the clone a clone again. You will have to do that only once, after that both clone and dataset will have common snapshots to deal with.

[Binarus]

Thank you very much, accepted and +1.

This answer is very interesting and has put me on the right track. I originally didn't understand your first sentence, so I'd like to reword it for my own reference and for later visitors:

Consider the following sequence of commands and their output:

zfs create rpool/backup
zfs snapshot rpool/backup@1
zfs snapshot rpool/backup@2
zfs clone rpool/backup@1 rpool/clone
zfs list -rt all rpool/clone
NAME          USED  AVAIL  REFER  MOUNTPOINT
rpool/clone     0B  7.60T    96K  none

In the output the problem is clearly visible: rpool/clone does not have any snapshots. Since incremental sending and receiving depends on snapshots, sending to rpool/clone must fail. A dataset as such is never equivalent to a snapshot, not even if that snapshot is the dataset's origin, and not even immediately after creation.

My second mistake was that I assumed that a clone always would contain all later snapshots of its origin dataset. After thinking about it, it's quite logical that it does not (because a key feature of a clone is that can become different from its origin at any time).

Your solution works, but can be simplified a bit. It seems that we can go without explicitly saving the send stream and reading it back, which can save space and time. For reference, here is what I did (complete example) (line numbers added):

01 zfs create rpool/data
02 zfs snapshot rpool/data@1
03 zfs snapshot rpool/data@2
04 zfs snapshot rpool/data@3
05 zfs send -R rpool/data@3 | zfs receive -F rpool/backup
06 zfs destroy rpool/backup@2
07 zfs clone rpool/backup@1 rpool/clone
08 zfs promote rpool/clone
09 zfs send -R -I rpool/data@1 rpool/data@3 | zfs receive -F rpool/clone
10 zfs promote rpool/backup
11 zfs snapshot rpool/data@4
12 zfs send -I rpool/data@3 rpool/data@4 | zfs receive -F rpool/clone
13 zfs promote rpool/clone
14 zfs destroy -r rpool/backup
15 zfs rename rpool/clone rpool/backup

A few notes:

• The key point with this solution is that rpool/clone does not have snapshots after its creation in line 07, but does have snapshot @1 after the promotion in line 08 (rpool/backup has lost snapshot @1 thereby).
• We can use line 09 instead of explicitly saving and loading the send stream. Sending and receiving the stream now works because rpool/data and rpool/clone now have the common snapshot @1.
• After line 12, rpool/backup contains snapshots @1 and @3, while rpool/clone contains snapshots @2, @3 and @4.
• After the example has run completely, rpool/clone has been deleted, and rpool/backup contains snapshots @1, @2, @3 and @4 as desired.
• In line 12, I'd like to add -R at the left side of the pipe (just for fun and testing), but this leads to a crash on my system. I'll open a bug report for that.