Date: Mon, 16 Aug 1999 16:57:32 -0700 (PDT) From: David Wolfskill <dhw@whistle.com> To: freebsd-hardware@freebsd.org Subject: Recommendations sought for backup server hardware Message-ID: <199908162357.QAA54173@pau-amma.whistle.com>
next in thread | raw e-mail | index | archive | help
We've been running amanda as our backup software for just about a year
now. I've been fairly pleased with it, despite the learning curve
involved in switching to letting amanda handle the scheduling.
However, the machine that had been our backup server is also heavily
used for other things. As a consequence, making signifcant changes to
its configuration can be excessively disruptive -- and unnecessary
disruption is something that I try very hard to avoid. (It comes pretty
close to violating my Prime Directive, you might say.)
Therefore, I am proposing to set up a completely separate backup server
(and move the autoloader to the new backup server).
Now, amanda is capable of imposing a fairly heavy load on the I/O subsystem
of a box, especially when it's writing multipple dump images to a disk,
while readaing one of these, and writing to tape. I am assuming -- but
would be happy to be demonstrated wrong -- that SCSI is the only
reasonable way to go for this. (The autoloader is wide SCSI alreaday;
that's a given. Whether or not that controller gets shared isn't a
given... yet.)
What I'm wondering, and asking help for, is what sort of components
would be appropriate for such a box: it doesn't need to be a
particularly fast CPU, as far as that goes, but it needs to push I/O
very well... and *very* reliably.
Now, amanda's primary load will be as mentioned above: sucking dump
images over the (100Base-TX) wire and placing them on the ("holding")
disk. As images are completed, they are placed in the "taper" queue;
the oldest entry in that queue is in the process of having the dump
image in question read (from disk) and written (to tape) by a pair of
processes.
In addition, amanda will be logging some information, but this data flow
is essentially negligible in the grand scheme of things.
So, for example, it would seem to me to be feasible to just use a
comparatively inexpensive IDE disk as the boot drive, and set up a /var
filesystem where amanda can keep her logs & control files. The machine
should -- during the backup operation, at least -- need to do very
little else, so I'm not too concerned about the usual desktop
applications, Web servers, & the like.
In order to provide greater bandwidth & decreased latency for the
holding disk, I'm tempted to suggest using Gerg Lehey's vinum package --
more spindles generally means faster access. (My current "holding disk"
is only 4 GB, and there are definitely times that additional space --
for atotal of at least 6 GB -- would be quite helpful in eliminating a
bottleneck. Currently, it's also on a single spindle, which is probably
keeping that disk rather busy... especially when the filesystem that
occupies the rest of that drive is being backed up.)
Another nice thing about (completely) separating the holding disk from
everything else is that the space is entirely transient: except during
the backup process, it's an empty filesystem, and could then be replaced
without disrupting any significant processes. And there's nothing to
restore -- (vinum config stuff first and) newfs , and away we go....
For reference, the SCSI controller that I was planning on moving from
the existing box to the new one, and which is currently handling (only)
the autoloader & DLT drive is:
ahc2 <Adaptec 2940 Ultra SCSI host adapter> rev 1 int a irq 11 on pci0:12:0
ahc2: aic7880 Wide Channel, SCSI Id=7, 16 SCBs
As I've mentioned in other notes, I'm pretty much a novice to PC
hardware, but I think I have a reasonable understanding of computer
system architecture in general, and the nature of this application's
load in particular.
I would be expecting to run FreeBSD-3.2, either -RELEASE or -STABLE --
at least with this box, I'd have the relative luxury of being able to
rebuild the world upon occasion, and re-boot it as long as backups
weren't in progress at the time. If I were to choose -STABLE, I expect
I'd tend to hang back a couple of weeks from the most recent, in an
attempt to be make it more challenging for the box to surprise me. :-}
Naturally, I'd prefer to avoid wasting resources; to that end, I'm
certain I would not need a CD (or DVD) drive, or a sound-anything (the
box will be in the server room, which I visit as seldom as possible).
Although I've run Suns from serial ports often enough, I've not had the
pleasure of doing this with FreeBSD boxen... but even if there is a
video card, it certainly doesn't need anything fancy.
I realize it's the custom in the freebsd- lists to respond to the list,
but I'm also willing to summarize, if there would be interest in that.
(Yeah, I've been around long enough to recall when that was the
expectation, if not the norm....)
Thanks (in advance),
david
--
David Wolfskill dhw@whistle.com UNIX System Administrator
voice: (650) 577-7158 pager: (888) 347-0197 FAX: (650) 372-5915
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hardware" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908162357.QAA54173>