How to move a dataset from one ZFS pool to another ZFS pool

[Mr. Slumber]

Ok, here's what I want to do:

I have one ZFS pool (let's just call it) "pool A" (3 HDDs, raidZ1) with one dataset (let's just call it) "dataset A". Also on this machine I have another ZFS "pool B" (3HDDs, raidZ1).

I want to move "dataset A" from "pool A" completely over to "pool B". (Read some postings about this here on the forum, but I'm searching for an quiet "easy" way like: open "mc" in terminal, goto to "dataset A", press F6 and move it to "pool B")

Thank you in advance :)

 

[SweetAndLow]

Everything on the same system? Just create the dateset on the second pool and cp/mv the data. Use screen or tmux if you want to make sure the job doesn't die from network hiccup. That's the fastest method. Rsync is another option if there is the chance you will need to stop and start the transferred.

 

[Mr. Slumber]

Everything on the same system?

Yes.

Just create the dateset on the second pool

ok, will do :)

Use screen or tmux

Sorry , could you explain in more detail? Thanks :)

 

[Mr. Slumber]

Rsync is another option

Sorry, not really good at command line... So I need to enable rsync under "services" and then enter what rsync commando exactly... Thanks :)

 

[danb35]

cp/mv the data.

...or ZFS replicate:

Code:

zfs snapshot poolA/dataset@migrate
zfs send -v poolA/dataset@migrate | zfs recv poolB/dataset

 

[SweetAndLow]

...or ZFS replicate:

Code:

zfs snapshot poolA/dataset@migrate
zfs send -v poolA/dataset@migrate | zfs recv poolB/dataset

For local operations mv or cp are going to be significantly faster. And also easier for the op.

 

[seltz]

If using cp, remember to use cp -a (archive mode) so file dates get preserved and symlinks don't get traversed.

 

[Mr. Slumber]

If using cp, remember to use cp -a (archive mode) so file dates get preserved and symlinks don't get traversed.

Didn't know that. Thank you!

 

[petur]

When using ZFS replicate, do consider using the "-p" argument.
From the man page:

-p, --props
Include the dataset's properties in the stream. This flag is implicit when -R is specified. The receiv‐
ing system must also support this feature. Sends of encrypted datasets must use -w when using this flag.

 

[elkmaster]

That means

zfs snapshot poolA/dataset@migrate
zfs send -vR poolA/dataset@migrate | zfs recv poolB/dataset

would be the best to get most data and properties and so one transfered

I do need to move an dataset from a older pool to a newer one

 

[Scharbag]

Any way to copy the snapshot history from the old pool too?

Probably possible with a quick script... Likely not something I really need...

Anyway, any help would be very awesome.

 

[Arwen]

@Scharbag - Do you mean that you want to copy all the other snapshots too?

My pool cloning script does that. Meaning if I start with this;

rpool/root/20220801
rpool/root/20220904@1
rpool/root/20220904

Then create a recursive snap of "@copy" and perform the ZFS send & receive. After clearing out the temporary snap "@copy", the result is this;

usbpool/root/20220801
usbpool/root/20220904@1
usbpool/root/20220904

 

[Scharbag]

@Scharbag - Do you mean that you want to copy all the other snapshots too?

My pool cloning script does that. Meaning if I start with this;

rpool/root/20220801
rpool/root/20220904@1
rpool/root/20220904

Then create a recursive snap of "@copy" and perform the ZFS send & receive. After clearing out the temporary snap "@copy", the result is this;

usbpool/root/20220801
usbpool/root/20220904@1
usbpool/root/20220904

Hmm, where is this magical script?

 

[Arwen]

It's not magic:

Code:

#
# Create the destination pool
#
zpool create \
  -o ashift=12 \
  -o comment="${MY_DEST_POOL} pool created $( date +%Y/%m/%d )" \
  -O atime=off \
  -O mountpoint=legacy \
  -O compression=lz4 \
  -O aclinherit=passthrough \
  -O acltype=posixacl \
  -f ${MY_DEST_POOL} ${MY_POOL_DEVICE}
#
# Snapshot the source pool
#
zfs snapshot -r ${MY_SRC_POOL}@${MY_SNAP}
#
# Copy pool
#
zfs send  -Rpv  ${MY_SRC_POOL}@${MY_SNAP} | \
  zfs receive -dFu ${MY_DEST_POOL}
#
# Clean up source pool
#
zfs destroy -rv ${MY_SRC_POOL}@${MY_SNAP}
#
# Clean up destination pool
#
zfs destroy -rv ${MY_DEST_POOL}@${MY_SNAP}

If desired, I can attach the entire script, which creates log file and also can copy "/boot", "/boot/efi" and update swap.

But, the script is really for me, to copy my Linux OS on ZFS to a recovery media. On my miniature desktop, that's a bootable USB drive. On my miniature media server, it's a bootable MicroSDXC card. The script makes assumptions on boot pool and grub configuration that may not hold true for some one else's install.

 

[arthurnn]

what is the zfs destroy doing at the end?

so, when using zfs send | zfs receive it would keep the snapshots created in the source?

 

[Arwen]

what is the zfs destroy doing at the end?

so, when using zfs send | zfs receive it would keep the snapshots created in the source?

In my case, I am cloning the OS pool. Thus, I don't need the snapshot that references the cloning process. So I destroy them in both the source and destination.

The other snapshots in the root OS pool remain exactly as they were copied. Both, in source and destination. That was the point of the example.

 

[arthurnn]

@Arwen , got it. make sense to me.
I am in a process of coping a 1TB data pool to a new z2 3TB pool. Using `send | receive` so I will not loose the snapshot history.

 

[leeroy]

I need to do essentially the same thing, but I'm going from and encrypted pool to another encrypted pool and want to keep all my snapshots. I wasn't sure how to do this in the terminal.

Code:

zfs snapshot poolA/dataset@migrate
zfs send -Rvw poolA/dataset@migrate | zfs recv -d poolB

I then couldn't seem to load a key and change it to inherit from the new pool. However in TrueNAS I could unlock, then force the inheritance, which is fine, but not sure how to do this through the terminal. It was odd that I also couldn't directly load my key, I had to use the HASH in the dialog when you unselect use key.