My original question:
We have a bunch of systems running Solaris 2.5. Currently, we use Solstice
Backup to backup our systems to a 4mm Dat drive. We realise that if our
backup server were to have an internal disk crash or something, it would
take us a very long time before we get the system up and running the way it
was because, we would first have to install the OS, then Solstice backup,
install the license and then using the bootstrap information restore the
root file system and whatever else. If any of our servers crash, we are
usually in a real cruch to have the system up and running in as short a
time as possible. Given this, we feel that it will be best to also do a
ufsdump of all our systems on a regular basis say once a month or so (this
is in addition to our regular backups using Solstice Backup). This way if
our server were to crash, we could use ufsrestore and bring the system up
in a short time frame.
What do you all think? Is this the right strategy? Are there better ways
to achieve the same goal? Is there any software that is compatable with
ufsdump and ufsrestore? Should we be using a different software and a
totally different approach to having a good backup? I'm aware of SMArch.
Is it really worth the money?
If we have to do ufsdump and also backups using Solstice backup, then we
probably need a Juke box with mutiltiple drives. Any recommendations - of
jukeboxes and vendors? What should we look out for?
-----------------
Responses:
Those who responded agreed that an alternate backup strategy is required to
Solstice Backup (Networker; Legato).
Some suggested Mirroring. My comment: We are already mirroring the
internals on our very important servers. But once our backup server got
crippled to the point where it could not recognize its own ethernet
interface and at that time even the mirror did help.
David Davisson suggested installing a second internal drive that is identical
to the boot drive and then doing regular ufsdumps (not daily) or even dd
one disk to the other to keep an exact duplicate hard disk in the machine.
He does not mean Mirror, but a backup of the internal which is a previous
version of the hard disk.
Caleb Warner said "we have rejected Soltice Backup or Legato
because of the reasons you stated. We use BudTool from PDC (www.pdc.com).
It backs up all of our systems (SunOS, Solaris, HPUX, DG/UX, DIGITAL UNIX)
using normal commands like dump, tar or cpio (your choice)."
Michael Maciolek pointed out that if you want ot run a jukebox, it will
cost extra for the jukebox driver enabler license.
My thank to :
Danny Johnson
Kevin Sheehan
Andrew
David Davisson
Caleb Warner
Stuart Lawson
Steve Turgeon
Michael Maciolek
I'll paste below all the detailed responses:
*****************
djohnson@nbserv2.dseg.ti.com (Danny Johnson)
your plan sounds doable, although it might be quicker to maintain
a ready-to-go set of simple restore or install tapes that let you
build a ready-to-run system (including Solstice) without all the
rest of your user files. this way you don't have to do a full
(long-running) ufsrestore only to overwrite it with a same-sized
Solstice restore.
also be careful of restoring the root, usr, and var partitions/
directories on a running system, no matter what method you use.
the quickest possible method would be to keep a spare ready-to-run
extra disk that you pop in/hook up only at restore time, use that
as the temporary system disk, newfs the regular disks, restore your
Solstice backups onto the regular disks, then put the configuration
back like it was. (remember to install the bootblock before trying
to boot the regular disks.)
*************
Michael Maciolek <mikem@centerline.com>
Hi, Vasantha
I've been using solstice backup (actually Legato Networker, but it's the
same product, just re-marketed by Sun under the 'solstice' name) and I've
been pretty satisfied with it...but I certainly agree that you should keep
a UFS backup of the root filesystem and any other 'networker' filesystem(s)
as well; that's what I do. However, I *only* back up the filesystems that
are needed to run 'networker'. That way, if I do have a total system crash,
I can use 'ufsrestore' to recreate a system that lets me run 'networker',
but I can still use 'networker' to recover everything else.
There's no need to run ufsdumps of anything that's not directly used by
networker (like user's home directories, shared workspace, whatever). Non-
networker filesystems can be recovered from the 'networker' archives, once
you have networker running again. Unless your networker index files are
*huge*, you ought to be able to fit everything you need on a single 4mm
tape.
As for jukeboxes, I don't have any up-to-date recommendations. I use an
Exabyte 10i jukebox for 8mm tapes, and it's plug-n-play with 'Networker',
but it's several years old now. I hear you can get those drives, used,
at fairly low cost these days, but I'd guess you would probably prefer to
stick with a 4mm system, since that's what you're using now.
Is your Solstice Backup license a single-host license, or a multi-client
license? Single-host only lets you use one backup device, unless they've
changed that policy. Multi-client lets you use several backup drives, but
even then, only single-tape drives. If you want to run a jukebox, it'll
cost you extra for the jukebox driver enabler license (unless that policy
has been changed.) You might be able to get an auto-stacker to work as a
single drive and you might not need a separate license, but you wouldn't
get any of the fancy jukebox functionality. (By "auto-stacker", I mean a
kind of tape drive that holds a stack of tapes; whenever it gets an 'eject'
signal, it ejects the current tape and automatically loads the next tape
in the stack. You don't get special functionality like being able to tell
it to 'back up' or load a particular tape from the middle of the stack.
I don't think I'd buy a jukebox *solely* because I wanted to implement a
UFS backup scheme alongside my existing 'networker' backup scheme, but if
you're already using a lot of tapes and you really need to automate the
whole backup process, a jukebox might be worthwhile for you.
One bit of caution - always do your UFS dumps in single-user mode. If you
are going to the trouble of keeping a UFS dump on hand, you really want to
make sure it's good. You don't want to risk the UFS dump being corrupted
if the filesystem was busy while you were doing the dump. It's always best
to drop down to single-user mode first. (there are ways to automate the
process too; usually a 'cron' job touches a file like /do_the_backup, then
does a reboot...and a shell script in rcS.d (or rc.boot, if you're still
using SunOS 4.x) checks for that file, runs the backup, removes the file
and resumes the boot to multi-user mode. Of course, this has its risks; if
there's a problem during the reboot, like an fsck error on root, then your
system will stall there and never make it back to multi-user mode.)
One other thing - keep a printout of how all your disks are partitioned.
If a disk crashes, you'll really want to know how everything was laid out
so you can reconstruct it from scratch.
- Mike
**************
> was because, we would first have to install the OS, then Solstice backup,
> install the license and then using the bootstrap information restore the
> root file system and whatever else. If any of our servers crash, we are
Make a duplicate boot partition, so if the primary one fails, you can
boot off that. Once you've make that, you should be able to install
a second copy of the license there - you'll never be booted off both!
It's certainly worth the time and disk space - that or mirroring so
you don't lose it on one disk failure.
***********
ACF <acf@nabaus.com.au>
We use a product "Budtool". Backups use native UNIX tools (tar, cpio,
dump etc) so you can restore data without having to install the backup
s/w first.
HTH,
Andrew
******************
cwarner@slpma8.ed.ray.com (Caleb Warner)
At our site we backup approximately 150 machines and our level 0 dumps are
about 300 GB. I think this makes us slightly different then your site.
However, I know that at our site we have rejected Soltice Backup or Legato
because of the reasons you stated. We use BudTool from PDC (www.pdc.com).
It backs up all of our systems (SunOS, Solaris, HPUX, DG/UX, DIGITAL UNIX)
using normal commands like dump, tar or cpio (your choice). I know that
as long as you keep track of where files are stored you can restore from
tapes with out the tool. Using the Tool makes it easier of course, but even
if I loose all of my backup history database, I can still retrieve from
the dump media.
As far as what kind of hardware to buy, we currently are using a 8mm jukebox,
a 27 tape DLT jukebox and 2 10 tape DLT jukeboxes. I really prefer the DLT
tapes because of the size and speed.
******************
"Stuart Lawson"<Stuart_Lawson@ivax.com>
Your backup strategy seems sensible, although you may want to consider
increasing the frequency of your full ufsdumps - every system I've worked
on has a full backup done once a week.
As to jukeboxes, I've used Hewlett-Packard in the past, which were pretty
reliable. If you suffer from a power outage, though, you can be in real
trouble if a disk was in the middle of being transported from shelf to
drive. You also have to ensure that the disks and drives are kept clean,
which can mean downtime to clean the drives at least. Also, I've had
problems in the past with magneto-optical (re-writable) optical disks. If
you use WORM, it can get quite expensive, as each disk costs around $60.
Anyway, if you've lost your complete operating system, you're going to have
to install something to drive the jukebox before you can reinstate your
backups. Bit of a Catch-22.
*****************
Steve_Turgeon_at_CCPOUNIX@ppc-191.putnaminv.com
Stay far away from 8mm. Spend the extra bucks and get a DLT changer - we have
had excellent results with the Sun model ( and horrible results with 8mm)
Steve
****************
Why don't you try installing a second internal drive that is identical to the
boot drive and do regular ufsdumps or even dd one disk to the other to keep an
exact duplicate hard disk in the machine.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:56 CDT