From owner-freebsd-hardware Mon Aug 16 16:57:24 1999 Delivered-To: freebsd-hardware@freebsd.org Received: from pau-amma.whistle.com (pau-amma.whistle.com [207.76.205.64]) by hub.freebsd.org (Postfix) with ESMTP id 6D36B152A7 for ; Mon, 16 Aug 1999 16:57:19 -0700 (PDT) (envelope-from dhw@whistle.com) Received: (from dhw@localhost) by pau-amma.whistle.com (8.9.2/8.9.2) id QAA54173 for freebsd-hardware@freebsd.org; Mon, 16 Aug 1999 16:57:32 -0700 (PDT) Date: Mon, 16 Aug 1999 16:57:32 -0700 (PDT) From: David Wolfskill Message-Id: <199908162357.QAA54173@pau-amma.whistle.com> To: freebsd-hardware@freebsd.org Subject: Recommendations sought for backup server hardware Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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 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