> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Jesus Cea
> Sorry if this list is inappropriate. Pointers welcomed.

Not at all.  This is the perfect forum for your question.

> So I am thinking about splitting my full two-disk zpool in two zpools,
> one for system and other for data. Both using both disks for
> mirroring. So I would have two slices per disk.

Please see the procedure below, which I wrote as notes for myself, to
perform disaster recovery backup/restore of rpool.  This is not DIRECTLY
applicable for you, but it includes all the necessary ingredients to make
your transition successful.  So please read, and modify as necessary for
your purposes.

Many good notes available:
    ZFS Troubleshooting Guide

Before you begin
    Because you will restore from a boot CD, there are only a few
    compression options available to you:  7z, bzip2, and gzip.
    The clear winner in general is 7z with compression level 1.  It's about
    as fast as gzip, with compression approx 2x stronger than bzip2

    Because you will restore from a boot CD, the media needs to be located
    that can be accessed from a CD boot environment, which does not include
    The obvious choice is NFS.  Be aware that solaris NFS client is often
not very
    compatible with linux NFS servers.

    I am assuming there is a solaris NFS server available because it makes
    my job easy while I'm writing this.  ;-)  Note:  You could just as 
    easily store the backup on removable disk in something like a zfs pool.
    Just make sure whatever way you store it, it's accessible from the 
    CD boot environment, which might not support a later version of zpool

Create NFS exports on some other solaris machine.
    share -F nfs -o rw=machine1:machine2,root=machine1:machine2 /backupdir
    Also edit hosts file to match, because forward/reverse dns must match
for the client.

Create a backup suitable for system recovery.
    mount someserver:/backupdir /mnt

    Create snapshots:
    zfs snapshot rpool@uniquebackupstring
    zfs snapshot rpool/ROOT@uniquebackupstring
    zfs snapshot rpool/ROOT/machinename_slash@uniquebackupstring

    Send snapshots:
    Notice: due to bugs, don't do this recursively.  Do it separately, as
outlined here.
    Notice:  In some version of zpool/zfs, these bugs were fixed so you can
safely do it recursively.  I don't know what rev is needed.
    zfs send rpool@uniquebackupstring | 7z a -mx=1 -si /mnt/rpool.zfssend.7z
    zfs send rpool/ROOT@uniquebackupstring | 7z a -mx=1 -si
    zfs send rpool/ROOT/machinename_slash@uniquebackupstring | 7z a -mx=1
-si /mnt/rpool_ROOT_machinename_slash.zfssend.7z

    It is also wise to capture a list of the "pristine" zpool and zfs
    echo "" > /mnt/zpool-properties.txt
    for pool in `zpool list | grep -v '^NAME ' | sed 's/ .*//'` ; do
        echo "-------------------------------------" | tee -a
        echo "zpool get all $pool" | tee -a /mnt/zpool-properties.txt
        zpool get all $pool | tee -a /mnt/zpool-properties.txt
    echo "" > /mnt/zfs-properties.txt
    for fs in `zfs list | grep -v @ | grep -v '^NAME ' | sed 's/ .*//'` ; do
        echo "-------------------------------------" | tee -a
        echo "zfs get all $fs" | tee -a /mnt/zfs-properties.txt
        zfs get all $fs | tee -a /mnt/zfs-properties.txt

    Notice:  The above will also capture info about dump & swap, which might
be important, 
    so you know what sizes & blocksizes they are.

Now suppose a disaster has happened.  You need to restore.
    Boot from the CD.
    Choose "Solaris"
    Choose "6.  Single User Shell"

    To bring up the network:
        ifconfig -a plumb
        ifconfig -a
        (Notice the name of the network adapter.  In my case, it's e1000g0)
        ifconfig e1000g0 up

    mount /mnt
    Verify that you have access to the backup images.  Now prepare your boot
disk as follows:

    format -e
    (Select the appropriate disk)
        (no fdisk table exists.  Yes, create default)
        (choose to "modify" a table based on "hog")
        (in my example, I'm using c1t0d0s0 for rpool)
    zpool create -f -o failmode=continue -R /a -m legacy rpool c1t0d0s0

    7z x /mnt/rpool.zfssend.7z -so | zfs receive -F rpool
    (notice: the first one requires -F because it already exists.  The
others don't need this.)

    7z x /mnt/rpool_ROOT.zfssend.7z -so | zfs receive rpool/ROOT
    7z x /mnt/rpool_ROOT_machinename_slash.zfssend.7z -so | zfs receive

    zfs set mountpoint=/rpool rpool
    zfs set mountpoint=legacy rpool/ROOT
    zfs set mountpoint=/      rpool/ROOT/machinename_slash

    zpool set bootfs=rpool/ROOT/machinename_slash rpool

    You did save the zpool-properties.txt and zfs-properties.txt didn't you?
;-)  If not, you'll just have to guess 
    about sizes and blocksizes.  The following 2G dump, 1G swap, and 4k
blocksize swap are pretty standard for a x86 
    ystem with 2G ram.
    zfs create -V 2G rpool/dump
    zfs create -V 1G -b 4k rpool/swap

    installgrub /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c1t0d0s0

    And finally, init 6

    After the system comes up "natural" once, it's probably a good idea to
capture a new "zpool-properties.txt" and "zfs-properties.txt" and 
    compare against the "pristine" ones, to see what (if anything) is
different.  Likely suspects are auto-snapshot properties and
    stuff like that.  Which you probably forgot you ever created, years ago
when you (or someone else) built your server and didn't save any 
    documentation about the process.

zfs-discuss mailing list

Reply via email to