Re: Zpool surgery
--Sig_/FJX6_h0WkAB0cAJZ1ipHtOB
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Ulrich Sp=C3=B6rlein <uqs@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...
>=20
> 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.
>=20
> 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.
>=20
> I have:
> tank -> sending snapshots to archive
>=20
> I want:
> tank' -> sending snapshots to archive
>=20
> 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.
>=20
> 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.
>=20
> 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:
>=20
> 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
--Sig_/FJX6_h0WkAB0cAJZ1ipHtOB
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)
iEYEARECAAYFAlEFMfgACgkQBYqIVf93VJ11YQCgst43rQ0fEPedB1gaEUIocoQS
I/IAni9cEfESXBY5DZOO+mJ44csGHkYN
=nniE
-----END PGP SIGNATURE-----
--Sig_/FJX6_h0WkAB0cAJZ1ipHtOB--
討論串 (同標題文章)
完整討論串 (本文為第 8 之 16 篇)：