> 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
http://www.solarisinternals.com/wiki/index.php/ZFS_Troubleshooting_Guide#ZFS
_Root_Pool_Recovery
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
somewhere
that can be accessed from a CD boot environment, which does not include
ssh/scp.
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
etc.
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
/mnt/rpool_ROOT.zfssend.7z
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
properties:
echo "" > /mnt/zpool-properties.txt
for pool in `zpool list | grep -v '^NAME ' | sed 's/ .*//'` ; do
echo "-------------------------------------" | tee -a
/mnt/zpool-properties.txt
echo "zpool get all $pool" | tee -a /mnt/zpool-properties.txt
zpool get all $pool | tee -a /mnt/zpool-properties.txt
done
echo "" > /mnt/zfs-properties.txt
for fs in `zfs list | grep -v @ | grep -v '^NAME ' | sed 's/ .*//'` ; do
echo "-------------------------------------" | tee -a
/mnt/zfs-properties.txt
echo "zfs get all $fs" | tee -a /mnt/zfs-properties.txt
zfs get all $fs | tee -a /mnt/zfs-properties.txt
done
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 192.168.1.100/24 up
mount 192.168.1.105:/backupdir /mnt
Verify that you have access to the backup images. Now prepare your boot
disk as follows:
format -e
(Select the appropriate disk)
fdisk
(no fdisk table exists. Yes, create default)
partition
(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
rpool/ROOT/machinename_slash
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
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
