Questions about stability of snapshots and vinum in 5.1

James Quick jq at quick.com
Tue Aug 12 17:49:13 PDT 2003


My goal is to have a box, with 2 drives, each of which is identically
configured.  Slice 1, and Slice 2, will be smallish FreeBSD partitions
4-8 GB each. 1 will be treated as a production environment.  The other
will be used for building and testing new environments.  The bulk
of the space will be used for data.  Each pair of production and test
slices will be periodically mirrored to it's twin to provide a measure
of fault tolerance.  The box currently has one of the two new large 
drives
installed, and 3 smaller aging (and ailing) drives.

I was hoping to use vinum for all the rest, as it would give me far more
flexibility. Based on recent posts it sounds like I should wait on 
that, and
will leave enough unconfigured space at the top so that I can migrate
from manually created partitions to vinum once I feel that geom+vinum
have stabilized a bit.

I am seeking feedback on the status of vinum, and whether the following
plan makes sense as an upgrade plan for a host with a light load but
whose downtime windows are short.  I am curious if my planned use
of snapshots is risky in 5.1, I have used them in under a much older
5.0 version with no problems, but a lot has changed.

I have not migrated my data onto the first of these drive since I need 
to
configure one, migrate from 2 old drives, then put in the second new
drive before continuing.  I also need to do as much of this work as
possible without interruption.  My plan is, to build out the first set 
of partitions,
then create a queue of jobs for each disk controller:
1. create a snapshot on the destination drive.
2. use dump+restore or tar at a decent nice value, to copy from source
to the new dest.
3. Then when I can shutdown production, and all the old data has 
completed
a full (though aged) copy, get rid of the old mirrors.  Use rsync to 
copy the
changes to the destination.
4. Create snapshots on the new system volumes, boot into the new 
environment
for testing.
5. If that goes well, swap out one of the old drives for the second new 
one,
build out the OS copies, and copies of critical user data.
6. I can then get rid of, or fool around with the old disks at my 
leisure.



More information about the freebsd-current mailing list