zfs discuss - Jul 2010 - disaster recovery process (replace disks)

I believe I know enough to figure this out on my own, but there''s
usually
some little "gotcha" that you don''t think of until you hit
it.  I''m just
betting that Cindy has already a procedure written for just this purpose.
;-)

 

In general, if you''ve been good about backing up your rpool via
"zfs send,"
and then you''re forced to restore onto bare metal, what would be the
process?

 

Also, precisely what should I be backing up via "zfs send" anyway?  I
see
three filesystems of interest:

NAME                                                    USED  AVAIL  REFER
MOUNTPOINT

rpool                                                  5.86G  13.7G  35.5K
/rpool

rpool/ROOT                                             4.33G  13.7G    18K
legacy

rpool/ROOT/s10x_u6wos_07b                              4.33G  13.7G  3.98G
/

 

In particular, I have a system with the OS on disks mirrored by hardware.  I
need to upgrade those disks to a larger size, which cannot be done in-place
because of the hardware mirroring.  I plan to put in the larger disks, and
use zfs software mirroring from now on.  So I''ve got to backup my OS,
and
restore onto blank disks.  And make it bootable.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20100717/28a6dd03/attachment.html>

Hi Ned,

One of the benefits of using a mirrored ZFS configuration is just replacing each
disk with a larger  disk, in place, online, and so on...

Its probably easiest to use zfs send -R (recursive) to do a recursive snapshot
of your root pool.
Check out the steps here:

http://www.solarisinternals.com/wiki/index.php/ZFS_Troubleshooting_Guide

ZFS Root Pool Recovery

Thanks,

Cindy
-- 
This message posted from opensolaris.org

> From: zfs-discuss-bounces at opensolaris.org [mailto:zfs-discuss-
> bounces at opensolaris.org] On Behalf Of Cindy Swearingen
> 
> Hi Ned,
> 
> One of the benefits of using a mirrored ZFS configuration is just
> replacing each disk with a larger  disk, in place, online, and so on...
Yes, the autoexpand property (or whatever it''s called).  Although
I''m not
sure if it would help me in this case (because my requirements require that
I keep the OS confined to 160G and partition the rest for other uses...)

Another big benefit of ZFS mirror over hardware mirror is that when you
scrub ... it will actually scrub both disks.  If you scrub a hardware
mirror, there''s no telling *what* you''re scrubbing.  A block
from the first
one, a block from the 2nd one, a whole swath of blocks from the first one,
alternating with just an occasional small chunk from the second one ...
Maybe you''re only hitting one disk the whole time, for all you know. 
The
one thing you can safely assume if scrubbing a hardware mirror is that
you''re only scrubbing half of your data.  At best.

> http://www.solarisinternals.com/wiki/index.php/ZFS_Troubleshooting_Guid
> e
> 
> ZFS Root Pool Recovery
Thanks for that.

What''s a good choice for a decently stable upgrade?  I''m
unable to run
backups because ZFS send/receive won''t do full-pool replication 
reliably, it hangs better than 2/3 of the time, and people here have 
told me later versions (later than 111b) fix this.  I was originally 
waiting for the "spring" release, but okay, I''ve kind of
given up on
that.  This is a home "production" server; it''s got all my
photos on it.
  And the backup isn''t as current as I''d like, and
I''m having trouble
getting a better backup.  (I''ll do *something* before I risk the 
upgrade; maybe brute force, rsync to an external drive, to at least give 
me a clean copy of the current state; I can live without ACLs.)

I find various blogs with instructions for how to do such an upgrade, 
and they don''t agree, and each one has posts from people for whom it 
didn''t work, too.  Is there any kind of consensus on what the best way 
to do this is?

-- 
David Dyer-Bennet, dd-b at dd-b.net; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

On Sun, Aug 1, 2010 at 2:57 PM, David Dyer-Bennet <dd-b at dd-b.net>
wrote:
> What''s a good choice for a decently stable upgrade? ?I''m
unable to run
> backups because ZFS send/receive won''t do full-pool replication
reliably, it
> hangs better than 2/3 of the time, and people here have told me later
> versions (later than 111b) fix this. ?I was originally waiting for the
> "spring" release, but okay, I''ve kind of given up on
that. ?This is a home
> "production" server; it''s got all my photos on it. ?And
the backup isn''t as
> current as I''d like, and I''m having trouble getting a
better backup. ?(I''ll
> do *something* before I risk the upgrade; maybe brute force, rsync to an
> external drive, to at least give me a clean copy of the current state; I
can
> live without ACLs.)
>
> I find various blogs with instructions for how to do such an upgrade, and
> they don''t agree, and each one has posts from people for whom it
didn''t
> work, too. ?Is there any kind of consensus on what the best way to do this
> is?
You''ve got to point pkg to pkg.opensolaris.org/dev and then choose one
of the development builds.

If you run a `pkg image-update` right away, the latest bits you''ll get
are from build 134 which people have reported works OK.

If you want to try something in between b111 and b134, see the
following instructions:

http://blogs.sun.com/observatory/entry/updating_to_a_specific_build

-- 
Giovanni Tirloni
gtirloni at sysdroid.com

On 1-8-2010 19:57, David Dyer-Bennet wrote:
>  I''ve kind of given up on that.  This is a home
"production" server;
> it''s got all my photos on it.
The uncertainty around OpenSolaris made me drop it. I''m very sorry to 
say, because I loved the system. I do not want to worry all the time 
though, so I changed (back) to FreeBSD/amd64 with ZFS. I must say it 
runs very well and maintenance is very easy/clear. Not much help for 
you. I do hope there will be another OpenSolaris release, but I have my 
doubts.