Transfer contents of one dataset into another, with snapshots?

[Glorious1]

Objective: Transitioning from deprecated AFP to SMB file sharing. This is not well documented, but I understand there are legacy issues if you just change the shares and a few dataset properties. I've seen it recommended to make a new clean dataset with SMB share type, and move your data into it. That's what I want to do. The trouble I'm having is moving the data completely, ideally with snapshots so the transition is seamless.

What I've tried: I had some misfires with cp. The other recommendations bandied about more frequently are rsync and zfs send/receive. But there are details that don't get bandied about as much. I would appreciate insight and suggestions for the ZFS propeller-heads.

ZFS Replication (full): The problem here, it seems, is that I can't do a full replication to an existing dataset. And of course the Catch 22 is that simply replicating the dataset will give me my old dataset and defeat the purpose. Here's what happens.

Code:

Tabernacle:~$ sudo zfs send -R Ark/Jim@auto_2023-01-13_0000-2w | sudo zfs recv Ark/Jim2
cannot receive new filesystem stream: destination 'Ark/Jim2' exists
must specify -F to overwrite it
warning: cannot send 'Ark/Jim@auto_2022-08-01_0000-6m': signal received
warning: cannot send 'Ark/Jim@auto_2022-09-01_0000-6m': Broken pipe
warning: cannot send 'Ark/Jim@auto_2022-10-01_0000-6m': Broken pipe  [ . . . ]
Tabernacle:~$

ZFS Replication (incremental): Here the problem seems to be that a snapshot of some sort is required on the destination. I could make one, but I would be flying blind and doubt it would work. Here's the attempt, trying to increment between the oldest and newest snapshots on the source:

Code:

Tabernacle:~$ sudo zfs send -R -i @auto_2022-08-01_0000-6m Ark/Jim@auto_2023-01-13_0000-2w | sudo zfs recv Ark/Jim2
cannot receive incremental stream: most recent snapshot of Ark/Jim2 does not
match incremental source
warning: cannot send 'Ark/Jim@auto_2023-01-13_0000-2w': signal received
Tabernacle:~$

rsync: rsync seems to work mostly, but the new and old datasets are very different size. I assume, but am by no means sure, that is because the snapshots fail to send (this is after a previous rsync sent most of the dataset):

Code:

Tabernacle:~$ rsync -aUv --delete /mnt/Ark/Jim/ /mnt/Ark/Jim2/
sending incremental file list
rsync: [sender] readdir("/mnt/Ark/Jim/.zfs"): Invalid argument (22)
rsync: [generator] failed to set times on "/mnt/Ark/Jim2/.zfs": Operation not supported (45)
rsync: [generator] failed to modify permissions on "/mnt/Ark/Jim2/.zfs": Operation not supported (45)
rsync: [generator] failed to set times on "/mnt/Ark/Jim2/.zfs/snapshot": Operation not supported (45)
rsync: [generator] failed to modify permissions on "/mnt/Ark/Jim2/.zfs/snapshot": Operation not supported (45)
rsync: [generator] recv_generator: mkdir "/mnt/Ark/Jim2/.zfs/snapshot/auto_2022-08-01_0000-6m" failed: Operation not supported (45)
*** Skipping any contents from this failed directory ***
IO error encountered -- skipping file deletion
.zfs/
.zfs/snapshot/
.zfs/snapshot/auto_2022-08-01_0000-6m/
rsync: [generator] recv_generator: mkdir "/mnt/Ark/Jim2/.zfs/snapshot/auto_2022-09-01_0000-6m" failed: Operation not supported (45)
*** Skipping any contents from this failed directory ***
.zfs/snapshot/auto_2022-09-01_0000-6m/
rsync: [generator] recv_generator: mkdir "/mnt/Ark/Jim2/.zfs/snapshot/auto_2022-10-01_0000-6m" failed: Operation not supported (45)
*** Skipping any contents from this failed directory ***
.zfs/snapshot/auto_2022-10-01_0000-6m/
[ . . . same with all snapshots]

 

[anodos]

You can't rsync the ZFS ctldir (".zfs"). Do note that if you upgrade to SCALE, the AFP shares are auto-migrated to SMB.

 

[Glorious1]

You can't rsync the ZFS ctldir (".zfs"). Do note that if you upgrade to SCALE, the AFP shares are auto-migrated to SMB.

That's a nice touch, though making new shares is relatively trivial.

 

[anodos]

That's a nice touch, though making new shares is relatively trivial.

Right. It's about having xattr settings with a particular configuration to make it so that there is no truncation when reading xattrs written via netatalk. We have checkbox for this in SCALE (Legacy AFP) that's not present in Core.

 

[Glorious1]

I think one of the Horsemen of the Apocalypse was carrying ACLs and another brought extended attributes. I don't see a need for them and avoid them as much as possible. I'm setting up the new datasets with ACLs stripped and ACLs disabled in the SMB shares. Seems to work so far.

 

[Glorious1]

I went ahead and set up the new dataset with rsynced data (without the snapshots). The next problem is, after starting automatic snapshots in it, they won't replicate to the backup. There has to be a better way to do this that won't require destroying and recreating the backup with all new snapshots.

Code:

Replication "Ark/Attic -> ArkBak/Attic" failed:
No incremental base on dataset 'Ark/Attic'
and replication from scratch is not allowed.

 

[Glorious1]

Now I'm having a problem with snapshots and replication of the new datasets to the backup pool. I already discovered that I can't start replicating a new dataset to an existing backup dataset. Okay fine, this is apparently the way of ZFS.

In the first dataset I did, I was fortunate to set up the new replication task before I deleted the old target dataset. So the sequence was

1. Set up new auto snapshot task
2. Wait for first auto snapshot
3. Set up new replication task, choosing the old target dataset as destination
4. Delete the old target
5. When replicating, the new target (of the same name as old) was created and all replicated into it. That's nice.

On my second dataset, I deleted the old target first, knowing it wouldn't be of use. However, then I found when creating the replication task, that I was unable to specify a target unless it already exists. This is getting super frustrating:

1. You can't replicate a new dataset to one that already exists with snapshots.
2. You can't set up a replication task in GUI that specifies a target that doesn't yet exist. (wrong, see below)

So I chose the backup pool as target, assuming it would make the dataset in it. No, it just plastered the new contents in the root dataset. Aaaah!!!

Edit: Duh, I didn't realize you could type into the upper part that shows the root of the path.