pyznap icon indicating copy to clipboard operation
pyznap copied to clipboard

dest_auto_create + raw_send = error

Open DragonQ opened this issue 2 years ago • 5 comments

What's the correct way to send an encrypted dataset to a remote pool with no existing dataset? I'm using these options:

[source/backups]
daily = 7
snap = yes
clean = yes
raw_send = yes
dest_auto_create=yes
dest = ssh:22:root@backup-nas:backups/backups
dest_keys = /home/user/.ssh/id_rsa

[ssh:22:root@backup-nas:backups/backups]
daily = 7
snap = no
clean = yes
key = /home/user/.ssh/id_rsa

When I run pyznap send, I get this error:

Feb 14 20:18:35 INFO: Destination root@backup-nas:backups/backups does not exist, will create it...
Feb 14 20:18:35 INFO: Successfully created root@backup-nas:backups/backups...
Feb 14 20:18:35 DEBUG: Sending source/backups to root@backup-nas:backups/backups...
Feb 14 20:18:35 INFO: No common snapshots on root@backup-nas:backups/backups, sending oldest snapshot source/backups@pyznap_2023-02-14_02:00:03_yearly (~216.3G)...
Feb 14 20:18:35 DEBUG: Using raw zfs send...
Feb 14 20:18:35 DEBUG: Using mbuffer on source: 'mbuffer -q -s 128K -m 256M'...
Feb 14 20:18:35 DEBUG: Using pv on source: 'pv -f -w 100 -s 315990178336 -D 60 -i 60'...
Feb 14 20:18:35 ERROR: Error while sending to root@backup-nas:backups/backups: cannot receive new filesystem stream: zfs receive -F cannot be used to destroy an encrypted filesystem or overwrite an unencrypted one with an encrypted one...

Is there a "proper" way to do this without manually creating a dataset on the destination pool?

DragonQ avatar Feb 14 '23 20:02 DragonQ

For anyone with the same issue, I was able to workaround this manually by finding the oldest snapshot (first shown when running zfs list -t snapshot source/backups), then running the following command:

sudo zfs send -p -w source/backups@pyznap_oldest_snapshot | pv | ssh backup-nas sudo zfs recv backups/backups

Pyznap then works as normal after removing the dest_auto_create option. It would be nice if this manual step wasn't necessary for encrypted datasets though.

DragonQ avatar Mar 08 '23 15:03 DragonQ

Sorry, I totally missed this question. I never used encrypted datasets, so I'm actually not too familiar with how they work with zfs send/recv. Would it also work if you just create the dataset and then use pyznap without the dest_auto_create? Or does there need to be a snapshot on the dataset before it works?

yboetz avatar Mar 08 '23 20:03 yboetz

I manually create a destination dataset, then do a sudo pyznap send -s source/test1 -d ssh:22:root@backup-nas:backups/test1 -w, I get the same error as above.

DragonQ avatar Mar 22 '23 14:03 DragonQ

Hm no idea what exactly is causing this. I never worked with encrypted datasets, so no experience there on how exactly they behave with zfs send/recv.

yboetz avatar Apr 02 '23 19:04 yboetz

I had the same problem so I submitted a PR for this specific case #101

With raw send you should not create the destination since it'll always complain that the dest doesn't match source.

ddemuro avatar Apr 03 '23 20:04 ddemuro