duplicating an entire zpool to a larger disk as a one-off operation

[Dave Cottlehuber]

Hi,

I want to duplicate my entire zpool from oldMac to newMac, which has
6x the capacity (woot). And then to split off newMac and in future
keep filesystems in sync via zfs send only. What's the best way to do
this one-off?

The reason for this approach is to preserve the snapshots and cloned
dependencies within the existing zpool, I don't think the clone links
will come across with zfs send/recv only.

Is this even possible? I can't use *BSD or illumos forks as the only
connectivity I have is thunderbolt (or ethernet, shudder).

I'm still waiting for somebody to recommend an external thunderbolt
JBOD enclosure that allows me to use my own disks!

A+
Dave

[Fastmail Jason]

ZFS send/receive as described in the wiki should sort you quick.


--
Jason Belec
Sent from my iPad

> --
>
>
>

[Dave Cottlehuber]

On 11 January 2013 13:18, Fastmail Jason <jason...@belecmartin.com> wrote:
> ZFS send/receive as described in the wiki should sort you quick.

I'm well aware of send/recv, but that's for a filesystem, not a pool.
And it will require uncompressing and recompressing all filesystems
along the way, for example, and I am not sure if it can retain the
clone/parent linkages for each filesystem. I have quite a few in this
state.

Can this be done at a pool level, without needing to loop across each
fs and snapshot via script?

A+
Dave

[Simon Casady]

senr recv will do it all in one command, well two actually. However
in duplicating a pool I found a problem I didn't no how to resolve.
The top level file system has the same name as the pool and I couldn't
figure out how to restore it. I always ended up with a second one. ie
pool/pool instead of just pool. Maybe an expert here knows how to do
it.

> --
>
>
>

[Jason]

Just use the rename parameter. And you are correct about send/receive.

Jason
Sent from my iPhone

> --
>
>
>

[Dave Cottlehuber]

On 11 January 2013 14:35, Simon Casady <capc...@gmail.com> wrote:
> senr recv will do it all in one command, well two actually. However
> in duplicating a pool I found a problem I didn't no how to resolve.
> The top level file system has the same name as the pool and I couldn't
> figure out how to restore it. I always ended up with a second one. ie
> pool/pool instead of just pool. Maybe an expert here knows how to do
> it.
>
> On Fri, Jan 11, 2013 at 7:22 AM, Dave Cottlehuber <d...@jsonified.com> wrote:
>> On 11 January 2013 13:18, Fastmail Jason <jason...@belecmartin.com> wrote:
>>> ZFS send/receive as described in the wiki should sort you quick.

Perhaps I should mention that I have 197 filesystems within this pool,
with clones/parents, varying levels of compression and copies, and
snapshots. So this is why I'm not convinced that a recursive zfs
send/recv is the best way to transfer this information to the larger
pool without mucking up the current clever arrangement.

Is there a way to transfer this at the *zpool* level?

A+
Dave

[Fastmail Jason]

You can try rsync if you don't want to use the built in tools.

--
Jason Belec
Sent from my iPad

> --
>
>
>

[Daniel Becker]

On Jan 11, 2013, at 1:25 AM, Dave Cottlehuber <d...@jsonified.com> wrote:

And then to split off newMac and in future
keep filesystems in sync via zfs send only.

What do you mean by "keep in sync"? ZFS send/recv do not support merging of any kind, so they can't be used to to bidirectionally sync changes between two machines.

[Fastmail Jason]

Copy from A to B. Sync A to B, really the same deal in this context. 

That said, once you replicate system A to system B, why can't you send files back? Many of us have done this, it's how we restore corrupt or lost data. Thus technically bi-directional.

--

Jason Belec

Sent from my iPad

[Daniel Becker]

To me, "keep A and B in sync" implies propagating changes both ways (similar to what dropbox, live sync, etc. do). ZFS send/recv let you either propagate changes from A to B or from B to A; however, if A and B both have changes, those on the receiving end will be lost. So a send/recv operation can do unidirectional sync only, but in either direction. This is obviously fine if one of the two filesystems is essentially read-only (other than receiving) to begin with, as in the case of backups, but probably not what you want if you plan to use both computers independently.

--
 
 
 

[Fastmail Jason]

Yes. However that can be overcome as well as several cloud based sites utilizing ZFS have done. It just gets creative with snapshots and clones.

--

Jason Belec

Sent from my iPad

[Dave Cottlehuber]

In the end I did a simple `zpool attach poolName oldDisk newDisk` and
achieved exactly what I wanted.

https://gist.github.com/3333118#adding-a-mirror-to-an-existing-pool

If there was a way to update the wiki, I'd add that there. But as
there isn't, it's in my gist.

Is there any risk of zfs assuming that these pools are related or
identical (e.g. some sort of UUID) if ever I connect again over
thunderbolt in target mode? I'm reluctant to try just in case things
break catastrophically.

A+
Dave

[Jason]

You can rename any pool. At anytime, on import, etc..

Jason
Sent from my iPhone

> --
>
>
>