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>