ZFS Moving ZFS structure on small SSD to bigger SSD - how to

[hardworkingnewbie]

Hi,

I've got a 128 GB SSD in my little home router with ZFS, which is of course bootable and has several snapshots and sub volumes. Since most data on it is throwaway anyway, it's just a single disk system.

Soon I will have a 512 GB SSD ready to be reused somewhere. How can I move the data of the old SSD to the new one?

My idea is to attach the new SSD to the pool as mirror, let ZFS resilver it and then detach the old disk. After set setting autoexpand=on for the pool and let that do its magic.

Is this doable, and will it result in the new SSD being a bootable dropin replacement then of the old one, as intended?

 

[cracauer@]

Bootable or not depends on what you do with the partitions on there.

I would dd the small to the big disk, then write the partition table on the new one by just writing with gdisk with no adjustments, then do the mirror trick.

Overall it might be better to only dd the thing from a USB boot stick.

 

[Erichans]

[...] My idea is to attach the new SSD to the pool as mirror, let ZFS resilver it and then detach the old disk.

After getting a copy of the "disk structure" on the new SSD and having copied every non-ZFS data, I'd think that the mirror way would be the most comfortable; however it seems that zpool-split(8), instead of detach-ing after resilvering, is the appropriate way, (Michael Lucas, Advanced ZFS, Splitting Mirrors):

If you want to more literally clone a machine, or pull off a copy of a mirror to run a backup, or
perform some other sort of mad computer science, zpool split is your friend.

Have a look at thread Can I dd copy a ZFS disk.

Also, not very likely, but your new SSD just might need a different ashift than your current SSD has, but IIRC zpool-add(8) takes the existing ashift of the pool (=your lonely present SSD) and uses that for each new vdev addition to the pool.
EDIT: when using o.a. zpool-attach(8) you can specify an ashift value explicitly for the vdev to be attached. Normally different ashift values for vdev-s in a mirror would not be ideal, but in your case that doesn't matter because the mirror is temporary. (zpool create ignores specified ashift when creating mirror on mixed sector size drives shows that ZFS still seems to have some ashift issues; at least as reported there for ZFS on Debian.)

Moving ZFS data from pool to pool by means of replication (zfs send/receive) serialises all data and thereby bypasses this problem altogether (you still need to set the correct ashift but you do that separately you need verify/set (either automatically or manually) the ashift correctly; this may be not very important for a router where I presume there won't be a reliance on heavy disk IO performance (EDIT: however having an ashift value that is off, increases wear of flash-ware unnecessarily).

 

[bakul]

My idea is to attach the new SSD to the pool as mirror, let ZFS resilver it and then detach the old disk. After set setting autoexpand=on for the pool and let that do its magic.

I expanded my original 4x160GB mirrored disks to 4x300GB and then 4x1TB using this method. But this was a while ago (10+ years) and I don't recall if I had to set autoexpand=on or anything.

[Edit] When I set up a new server with larger disks, I moved my previous 4x1TB zfs pool to the new machine using incremental zfs send/receive over a period of weeks until I put it in service. Today zfs send/receive is what I too would recommend.

 

[dnb]

When I had this problem, I thought that of course I could just split zpool. But this is not the universal strategy, since in the future you may want to move the data from/to different types of pulls (raidz/pools on partitions or files/with boot areas for UEFI and/or bios/with different bootloaders). So I would use the following simple commands:

zpool create new
zfs snapshot -r old@4444
zfs send --replicate --verbose --raw old@4444 | zfs receive -uvF new

UPD: I would also like to note that it is useful to know how the installer does partitioning for various configurations, and repeat his actions exactly, but manually. Then it’s very easy to transfer pulls to new computers.

 

[mer]

It's been a while since I've done this, but if you partition the new device to match the old one except for the freebsd-zfs partition miroring should work fine.