Re: Zpool surgery

Ulrich Spörlein <uqs_at_FreeBSD.org> wrote:

> I have a slight problem with transplanting a zpool, maybe this is not
> possible the way I like to do it, maybe I need to fuzz some
> identifiers...
> 
> I want to transplant my old zpool tank from a 1TB drive to a new 2TB
> drive, but *not* use dd(1) or any other cloning mechanism, as the pool
> was very full very often and is surely severely fragmented.
> 
> So, I have tank (the old one), the new one, let's call it tank' and
> then there's the archive pool where snapshots from tank are sent to, and
> these should now come from tank' in the future.
> 
> I have:
> tank -> sending snapshots to archive
> 
> I want:
> tank' -> sending snapshots to archive
> 
> Ideally I would want archive to not even know that tank and tank' are
> different, so as to not have to send a full snapshot again, but
> continue the incremental snapshots.
> 
> So I did zfs send -R tank | ssh otherhost "zfs recv -d tank" and that
> worked well, this contained a snapshot A that was also already on
> archive. Then I made a final snapshot B on tank, before turning down that
> pool and sent it to tank' as well.
> 
> Now I have snapshot A on tank, tank' and archive and they are virtually
> identical. I have snapshot B on tank and tank' and would like to send
> this from tank' to archive, but it complains:
> 
> cannot receive incremental stream: most recent snapshot of archive does
> not match incremental source

In general this should work, so I'd suggest that you double check
that you are indeed sending the correct incremental.

> Is there a way to tweak the identity of tank' to be *really* the same as
> tank, so that archive can accept that incremental stream? Or should I
> use dd(1) after all to transplant tank to tank'? My other option would
> be to turn on dedup on archive and send another full stream of tank',
> 99.9% of which would hopefully be deduped and not consume precious space
> on archive.

The pools don't have to be the same.

I wouldn't consider dedup as you'll have to recreate the pool if
it turns out the the dedup performance is pathetic. On a system
that hasn't been created with dedup in mind that seems rather
likely.

> Any ideas?

Your whole procedure seems a bit complicated to me.

Why don't you use "zpool replace"?

Fabian