zfs discuss - Aug 2008 - [Q] Am I misunderstanding snapshotting and zfs send/recv or is it really this complicated?

I''ve seen posted here snippets of regularly running zfs send/recv and 
here''s one below:
>So for example, each night you could do:
># zfs snapshot -r tank/data at today
># zfs send -R tank/data at today  | ssh <otherhost> zfs recv -d
backuptank
># zfs destroy -r tank/data at yesterday
># zfs rename -r tank/data at today tank/data at yesterday
But when I tried this myself, I found out fairly quickly that it 
doesn''t quite work.

The very first go around this will appear to work, but on the first 
subsequent runs, it breaks down. In my examples, I''m using a pool 
called zfs-pool and zfs-pool/home at current for the most recently 
created source snapshot.

First, the line zfs send -R zfs-pool/home at current | ssh targetssystem 
zfs recv -d zfs-pool complains with the error:

cannot receive new filesystem stream: destination
''zfs-pool/home'' exists
must specify -F to overwrite it

So then I tried zfs send -R zfs-pool/home at current | ssh targetssystem 
zfs recv -dF zfs-pool, and now it complains with the error:

cannot receive new filesystem stream: destination has snapshots (eg. 
zfs-pool/home at current) must destroy them to overwrite it.

But doing that causes the send/recv pair to write out the whole 
filesystem from scratch.

I then learned about incrementally updating the prior source 
snapshot, which I have will have renamed to 
zfs-pool/home at earliersnapshot.

zfs send -R -i zfs-pool/home at earliersnapshot zfs-pool/home at current | 
ssh targetssystem zfs recv -d zfs-pool

This command must be substituted for the command without the "-i" on 
that command''s second and subsequent runs.

However, each time it runs, it will create a cryptically named 
snapshot, such as @recv-3173-1, on the target system. What I learned 
is that this snapshot becomes the "current" snapshot of the target 
system and that trying to send another snapshot after deleting it 
outright results in the error:

cannot receive incremental stream: destination zfs-pool/home has been 
modified since most recent snapshot.

So to prevent a buildup of these snapshots, they can be renamed just 
as the current snapshot of the source system and then that renamed 
snapshot can be deleted after another snapshot from the source is 
sent over. Incidentally, the target system also gets copies of the 
two snapshots maintained on the source system.
-- 

Maurice Volaski, mvolaski at aecom.yu.edu
Computing Support, Rose F. Kennedy Center
Albert Einstein College of Medicine of Yeshiva University

I''ve been playing with this, and it seems what''s going on is
simply
poor documentation on how snapshotting and send/recv interact.

Here''s the snippet that''s been posted prior that will work
once and
then fail on subsequent runs
>>So for example, each night you could do:
>># zfs snapshot -r tank/data at today
>># zfs send -R tank/data at today  | ssh <otherhost> zfs recv -d
backuptank
>># zfs destroy -r tank/data at yesterday
>># zfs rename -r tank/data at today tank/data at yesterday
>
Basically, this fails on subsequent runs because it''s trying to send 
the same-named snapshot to the target and because it''s trying to send 
a whole snapshot instead of an increment. In addition, the source 
increment on both systems must match

Here''s a revised version:

On the first run:
zfs snapshot -r tank/data at yesterday
zfs send -R tank/data at yesterday  | ssh <otherhost> zfs recv -d
backuptank

On subsequent runs:
zfs snapshot -r tank/data at today
zfs send -R -i tank/data at yesterday  tank/data at today  | ssh 
<otherhost> zfs recv -d backuptank

zfs destroy -r tank/data at yesterday
ssh <otherhost> zfs destroy -r tank/data at yesterday
(in an actual script, "yesterday" must be substituted with a variable 
that specifies the prior snapshot)
-- 

Maurice Volaski, mvolaski at aecom.yu.edu
Computing Support, Rose F. Kennedy Center
Albert Einstein College of Medicine of Yeshiva University