zfs discuss - Apr 2007 - Poor man''s backup by attaching/detaching mirror drives on a _striped_ pool?

Hi,

one quick&dirty way of backing up a pool that is a mirror of two devices is
to
zpool attach a third one, wait for the resilvering to finish, then zpool detach
it again.

The third device then can be used as a poor man''s simple backup.

Has anybody tried it yet with a striped mirror? What if the pool is
composed out of two mirrors? Can I attach devices to both mirrors, let them
resilver, then detach them and import the pool from those?

Best regards,
  Constantin

-- 
Constantin Gonzalez                            Sun Microsystems GmbH, Germany
Platform Technology Group, Global Systems Engineering      http://www.sun.de/
Tel.: +49 89/4 60 08-25 91                   http://blogs.sun.com/constantin/

Sitz d. Ges.: Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Marcel Schneider, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering

On Tue, 10 Apr 2007, Constantin Gonzalez wrote:
> Has anybody tried it yet with a striped mirror? What if the pool is
> composed out of two mirrors? Can I attach devices to both mirrors, let
> them resilver, then detach them and import the pool from those?
You''d want to export them, not detach them.  Detaching will overwrite
the
vdev labels and make it un-importable.

Off the top of my head (i.e. untested):

 - zpool create tank mirror <dev1> <dev2> <dev3>
 - zpool export tank
 - {physically move <dev3> to new box}
 - zpool import tank
 - zpool detach tank <dev3>

On the new box:
 - zpool import tank
 - zpool detach tank <dev1>
 - zpool detach tank <dev2>



Regards,
markm

> one quick&dirty way of backing up a pool that is a mirror of two
> devices is to zpool attach a third one, wait for the resilvering to
> finish, then zpool detach it again.
>
> The third device then can be used as a poor man''s simple backup.
How would you access the data on that device?

-- 
Darren Dunham                                           ddunham at taos.com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

> You''d want to export them, not detach them.
But you can''t export just one branch of the mirror, can you?
> Off the top of my head (i.e. untested):
> 
>  - zpool create tank mirror <dev1> <dev2> <dev3>
> - zpool export tank
But this will unmount all the file systems, right?

-- Anton
 
 
This message posted from opensolaris.org

> How would you access the data on that device?
Presumably, zpool import.

This is basically what everyone does today with mirrors, isn''t it? :-)

Anton
 
 
This message posted from opensolaris.org

Hi Mark,

Mark J Musante wrote:
> On Tue, 10 Apr 2007, Constantin Gonzalez wrote:
> 
>> Has anybody tried it yet with a striped mirror? What if the pool is
>> composed out of two mirrors? Can I attach devices to both mirrors, let
>> them resilver, then detach them and import the pool from those?
> 
> You''d want to export them, not detach them.  Detaching will
overwrite the
> vdev labels and make it un-importable.
thank you for the export/import idea, it does sound cleaner from a ZFS
perspective, but comes at the expense of temporarily unmounting the filesystems.

So, instead of detaching, would unplugging, then detaching work?

I''m thinking something like this:

 - zpool create tank mirror <dev1> <dev2> <dev3>
 - {physically move <dev3> to new box}
 - zpool detach tank <dev3>

On the new box:
 - zpool import tank
 - zpool detach tank <dev1>
 - zpool detach tank <dev2>

This should work for one disk, and I assume this would also work for multiple
disks?

Thinking along similar lines, would it be a useful RFE to allow asynchronous
mirroring like this:

- <dev1>, <dev2> are both 250GB, <dev3> is 500GB
- zpool create tank mirror <dev1>,<dev2> <dev3>

This means that half of dev3 would mirror dev1, the other half would mirror dev2
and dev1,dev2 is a regular stripe.

The utility of this would be for cases where customer have set up mirrors, then
need to replace disks or upgrade the mirror after a long time, when bigger disks
are easier to get than smaller ones and while reusing older disks.

Best regards,
   Constantin

-- 
Constantin Gonzalez                            Sun Microsystems GmbH, Germany
Platform Technology Group, Global Systems Engineering      http://www.sun.de/
Tel.: +49 89/4 60 08-25 91                   http://blogs.sun.com/constantin/

Sitz d. Ges.: Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Marcel Schneider, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering

Hi,
>> How would you access the data on that device?
> 
> Presumably, zpool import.
yes.
> This is basically what everyone does today with mirrors, isn''t it?
:-)
sure. This may not be pretty, but it''s what customers are doing all the
time
with regular mirrors, ''cause it''s quick, easy and reliable.

Cheers,
   Constantin

-- 
Constantin Gonzalez                            Sun Microsystems GmbH, Germany
Platform Technology Group, Global Systems Engineering      http://www.sun.de/
Tel.: +49 89/4 60 08-25 91                   http://blogs.sun.com/constantin/

Sitz d. Ges.: Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Marcel Schneider, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering

On April 11, 2007 11:54:38 AM +0200 Constantin Gonzalez Schmitz 
<Constantin.Gonzalez at Sun.COM> wrote:
> Hi Mark,
>
> Mark J Musante wrote:
>> On Tue, 10 Apr 2007, Constantin Gonzalez wrote:
>>
>>> Has anybody tried it yet with a striped mirror? What if the pool is
>>> composed out of two mirrors? Can I attach devices to both mirrors,
let
>>> them resilver, then detach them and import the pool from those?
>>
>> You''d want to export them, not detach them.  Detaching will
overwrite the
>> vdev labels and make it un-importable.
>
> thank you for the export/import idea, it does sound cleaner from a ZFS
> perspective, but comes at the expense of temporarily unmounting the
> filesystems.
>
> So, instead of detaching, would unplugging, then detaching work?
>
> I''m thinking something like this:
>
>  - zpool create tank mirror <dev1> <dev2> <dev3>
>  - {physically move <dev3> to new box}
>  - zpool detach tank <dev3>
If we''re talking about a 3rd device, added in order to migrate the
data,
why not just zfs send | zfs recv?

-frank

> > How would you access the data on that device?
> 
> Presumably, zpool import.
> 
> This is basically what everyone does today with mirrors, isn''t it?
:-)
But that''s not possible here because we can''t deport (or
import) a
subset of a pool, correct?

So I could detach a disk, but that disk is no longer part of a pool and
can''t be imported.... unless I''m missing something.

-- 
Darren Dunham                                           ddunham at taos.com
Senior Technical Consultant         TAOS            http://www.taos.com/
Got some Dr Pepper?                           San Francisco, CA bay area
         < This line left intentionally blank to confuse you. >

Hello Darren,

Wednesday, April 11, 2007, 7:39:18 PM, you wrote:
>> > How would you access the data on that device?
>> 
>> Presumably, zpool import.
>> 
>> This is basically what everyone does today with mirrors, isn''t
it? :-)
DD> But that''s not possible here because we can''t deport
(or import) a
DD> subset of a pool, correct?

DD> So I could detach a disk, but that disk is no longer part of a pool and
DD> can''t be imported.... unless I''m missing something.

You''re correct about current state.
However it should be possible to atomically detach all submirrors at
the same time without destroyng their label (actually with relabelling
them) and import them as separate pool. User data would be consistent
in the same way as you would detach svm submirror.

IIRC there''s RFE for it.


-- 
Best regards,
 Robert                            mailto:rmilkowski at task.gda.pl
                                       http://milek.blogspot.com

Frank Cusack wrote:
> On April 11, 2007 11:54:38 AM +0200 Constantin Gonzalez Schmitz 
> <Constantin.Gonzalez at Sun.COM> wrote:
>> Hi Mark,
>>
>> Mark J Musante wrote:
>>> On Tue, 10 Apr 2007, Constantin Gonzalez wrote:
>>>
>>>> Has anybody tried it yet with a striped mirror? What if the
pool is
>>>> composed out of two mirrors? Can I attach devices to both
mirrors, let
>>>> them resilver, then detach them and import the pool from those?
>>>
>>> You''d want to export them, not detach them.  Detaching
will
>>> overwrite the
>>> vdev labels and make it un-importable.
>>
>> thank you for the export/import idea, it does sound cleaner from a ZFS
>> perspective, but comes at the expense of temporarily unmounting the
>> filesystems.
>>
>> So, instead of detaching, would unplugging, then detaching work?
>>
>> I''m thinking something like this:
>>
>>  - zpool create tank mirror <dev1> <dev2> <dev3>
>>  - {physically move <dev3> to new box}
>>  - zpool detach tank <dev3>
>
> If we''re talking about a 3rd device, added in order to migrate the
data,
> why not just zfs send | zfs recv?
Time? The reason people go the split mirror route, at least in block 
land, is because once you split the volume you can export it someplace 
else and start using it. Same goes for constant replication where you 
suspend the replication, take a copy, go start working on it, restart 
the replication. (Lots of ways people do that one.)

I think the requirement could be voiced as, "I want an independent copy 
of my data on a secondary system in a quick fashion. I want to avoid 
using resources from the primary system." The fun part is that people 
will think in terms of current technologies so you''ll see "split 
mirror", or "volume copy" or "Truecopy" mixed in for
flavor.

Hi,

here''s a quick summary of the answers I''ve seen so far:

- Splitting mirrors is a current practice with traditional volume
  management. The goal is to quickly and effortlessly create a clone of a
  storage volume/pool.

- Splitting mirrors with ZFS can be done, but it has to be done the
  hard way by resilvering, then unplugging the disk, then trying to
  import it somewhere else. zpool detach would render the detached disk
  unimportable.

- Another, cleaner way of splitting a mirror would be to export the
  pool, then disconnect one drive, then re-import again. After that,
  the disconnected drive needs to be zpool detach''ed from the mother,
  while the clone can then be imported and its missing mirrors
  detached as well. But this involves unmounting the pool so it can''t
  be done without downtime.

- The supported alternative would be zfs snapshot, then zfs send/receive,
  but this introduces the complexity of snapshot management which
  makes it less simple, thus less appealing to the clone-addicted admin.

- There''s an RFE for supporting splitting mirrors: 5097228
  http://bugs.opensolaris.org/view_bug.do?bug_id=5097228

IMHO, we should investigate if something like zpool clone would be useful.
It could be implemented as a script that recursively snapshots the source
pool, then zfs send/receives it to the destination pool, then copies all
properties, but the actual reason why people do mirror splitting in the
first place is because of its simplicity.

A zpool clone or a zpool send/receive command would be even simpler and less
error-prone than the tradition of splitting mirrors, plus it could be
implemented more efficiently and more reliably than a script, thus bringing
real additional value to administrators.

Maybe zpool clone or zpool send/receive would be the better way of implementing
5097228 in the first place?

Best regards,
   Constantin

-- 
Constantin Gonzalez                            Sun Microsystems GmbH, Germany
Platform Technology Group, Global Systems Engineering      http://www.sun.de/
Tel.: +49 89/4 60 08-25 91                   http://blogs.sun.com/constantin/

Sitz d. Ges.: Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Marcel Schneider, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering

On Wed, 11 Apr 2007, Constantin Gonzalez Schmitz wrote:
> So, instead of detaching, would unplugging, then detaching work?
I don''t see why that couldn''t work.  The original question of
striped
mirrors would be similar:

 - zpool create tank mirror <dev1> <dev2> mirror <dev3>
<dev4>
 - {physically move <dev2> and <dev4> to new box}
 - zpool detach <dev2>
 - zpool detach <dev4>

On the new box:
 - zpool import tank
 - zpool detach <dev1>
 - zpool detach <dev3>

> Thinking along similar lines, would it be a useful RFE to allow
> asynchronous mirroring like this:
>
> - <dev1>, <dev2> are both 250GB, <dev3> is 500GB
> - zpool create tank mirror <dev1>,<dev2> <dev3>
That''s an interesting idea.  Of course, you could do that today by
splitting <dev3> into two 250gb partitions.  An RFE to make it easier to
do these kind of ''sneakernet'' backups might worth filing.



Regards,
markm

I lost track if this rfe was posted yet:

	5097228 provide ''zpool split'' to create new pool...
	http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=5097228

-r

Mark J Musante writes:
 > On Wed, 11 Apr 2007, Constantin Gonzalez Schmitz wrote:
 > 
 > > So, instead of detaching, would unplugging, then detaching work?
 > 
 > I don''t see why that couldn''t work.  The original
question of striped
 > mirrors would be similar:
 > 
 >  - zpool create tank mirror <dev1> <dev2> mirror <dev3>
<dev4>
 >  - {physically move <dev2> and <dev4> to new box}
 >  - zpool detach <dev2>
 >  - zpool detach <dev4>
 > 
 > On the new box:
 >  - zpool import tank
 >  - zpool detach <dev1>
 >  - zpool detach <dev3>
 > 
 > 
 > > Thinking along similar lines, would it be a useful RFE to allow
 > > asynchronous mirroring like this:
 > >
 > > - <dev1>, <dev2> are both 250GB, <dev3> is 500GB
 > > - zpool create tank mirror <dev1>,<dev2> <dev3>
 > 
 > That''s an interesting idea.  Of course, you could do that today
by
 > splitting <dev3> into two 250gb partitions.  An RFE to make it
easier to
 > do these kind of ''sneakernet'' backups might worth
filing.
 > 
 > 
 > 
 > Regards,
 > markm
 > _______________________________________________
 > zfs-discuss mailing list
 > zfs-discuss at opensolaris.org
 > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Mark J Musante wrote:
> On Wed, 11 Apr 2007, Constantin Gonzalez Schmitz wrote:
> 
>> So, instead of detaching, would unplugging, then detaching work?
> 
> I don''t see why that couldn''t work.  The original
question of striped
> mirrors would be similar:
> 
>  - zpool create tank mirror <dev1> <dev2> mirror <dev3>
<dev4>
>  - {physically move <dev2> and <dev4> to new box}
>  - zpool detach <dev2>
>  - zpool detach <dev4>
The detach must be an atomic operation. In other words, we need work
to be done to implement this, you can''t (safely) fake it with a script.
  -- richard

Constantin Gonzalez wrote:
> - The supported alternative would be zfs snapshot, then zfs send/receive,
>   but this introduces the complexity of snapshot management which
>   makes it less simple, thus less appealing to the clone-addicted admin.
...
> IMHO, we should investigate if something like zpool clone would be useful.
> It could be implemented as a script that recursively snapshots the source
> pool, then zfs send/receives it to the destination pool, then copies all
> properties, but the actual reason why people do mirror splitting in the
> first place is because of its simplicity.
> 
> A zpool clone or a zpool send/receive command would be even simpler and
less
> error-prone than the tradition of splitting mirrors, plus it could be
> implemented more efficiently and more reliably than a script, thus bringing
> real additional value to administrators.
I agree that this is the best solution.  I am working on "zfs send -r"
(RFE filed but id not handy), which will provide the features you 
describe above.

--matt