Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 27 Jan 2013 11:36:12 +0100
From:      Ulrich =?utf-8?B?U3DDtnJsZWlu?= <uqs@FreeBSD.org>
To:        current@FreeBSD.org, fs@FreeBSD.org
Subject:   Zpool surgery
Message-ID:  <20130127103612.GB38645@acme.spoerlein.net>

next in thread | raw e-mail | index | archive | help
Hey all,

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

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.

Any ideas?

Cheers,
Uli




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130127103612.GB38645>