[geeks] Well, THAT was a setback

Phil Stracchino alaric at metrocast.net
Tue Jan 19 21:39:25 CST 2010


On 01/19/10 21:29, der Mouse wrote:
> Well, I suspect you don't actually mean all those "as XYZ as possible";
> they probably should be something more like "as XYZ as possible while
> spending less than $MONEY and taking less than HOURS of staff time".
> Otherwise, you'll end up with "solutions" like using a single shared
> SCSI bus for everything so the disks can send their data directly to
> the tape drive - it'll work, but so much hackery will be needed (to,
> for example, teach the hosts' OSes to coexist on a shared SCSI bus)
> that you'd actually be better off with something else.

Well, yeah.  "Within reason."  :)

> It is, however, a good point that if the drive streams 40MB/sec, you
> need more than 100Mb/sec incoming bandwidth to keep it busy.  Four
> 100Mb interfaces might do, if they're shared in sufficiently clever
> ways, but unless there's some reason to avoid a gigabit-capable switch,
> you'd probably be better off with gigabit.

Yup.  Only budget for the switch and NICs is keeping me from it.

> But that's not true unless you have to stream the data to the tape at
> the same time as you receive it from the network.  If you can buffer
> enough that you don't need to write to tape in parallel with network
> reception, there might be no need for new networking infrastructure at
> all.

Indeed.  And Bacula does support disk spooling.

> If your metric is "time from first dumper start to tape popping out of
> the drive", this sounds as though you can't do that.  But can you?  If
> it's really more like "length of nightly cronjob run", then you could
> perhaps buffer on disk for one night, so that while tonight's dumps are
> dumping to disk, last night's dumps are being copied from disk to tape.

The time varies.  Nightly incrementals run to disk on the server, and
run in minutes.  No problem there.  Weekly differentials, also to disk,
take a little longer; but they're all done inside about half an hour.
It's the monthly full backups that are the problem, because until I can
spare the money for a complete set of new disks for the server, I only
have enough disk space free on it to have a single full backup to disk
in existence at any one time.  This makes me very uncomfortable, which
is why I want to be able to pull the fulls off to tape.  (Ideally, I'd
like to make the full backups to disk, then migrate them to tape, but
while Bacula does support job migration, it doesn't - yet - support
migrating jobs between storage daemons on different hosts.  So until
that functionality is added, I have to make my Full backups direct to
tape in the first place.)

The problem there is that with the existing connections and the LTO-1
tapes I have at the moment (no budget for LTO-2 tapes yet), it ended up
taking about twenty hours to write five LTO-1 tapes, with tape changes
every four to five hours.  *That's* the part of the whole operation I'd
like to speed up enough to at least fit into the waking hours of a
single day.


-- 
  Phil Stracchino, CDK#2     DoD#299792458     ICBM: 43.5607, -71.355
  alaric at caerllewys.net   alaric at metrocast.net   phil at co.ordinate.org
         Renaissance Man, Unix ronin, Perl hacker, Free Stater
                 It's not the years, it's the mileage.



More information about the geeks mailing list