>> On Thu, 5 Jan 2006 09:54:34 -0500, "Kauffman, Tom" <KauffmanT AT NIBCO DOT 
>> COM> said:


> Electronic off-siting isn't an option -- I've seen us cut 400 MB
> Oracle redo logs for our SAP/R3 database at the rate of one every
> 2.5 minutes for extended time periods (and this is explicitly the
> data that has to go off-site). I'd need multiple T1 lines to cover
> the traffic, and the cost of a single T1 is considered to be "too
> high".

I feel for you.  You might want to cost out the following things for
your physical-carry offsites. Once my chain saw the numbers laid out,
the case for the bandwidth and the remote site were compelling.


+ Courier trips

+ Inefficient use of tape
  [ what % full are your offsite vols?  This will get worse if you
    make trips more frequently ]

+ Risk of courier error/subversion.  NIBCO isn't medical, you might
  not care that much.  We had more than one tape request be greeted
  with a "You want -what-?" sort of shrug.  Shudder.

+ Need to keep extra copies.  I don't know if you have an onsite
  copypool, but we weren't comfortable with having the only recourse
  for fixing a media error be a 30+hour tape retrieval cycle,
  especially if your confidence in the courier is less than 100%.

+ Delay in getting data offsite, which you're already interested in.
  This has an additional note:  In the event of a serious, predictable
  disaster [hurricane bearing down] you're SOL if you want to get your
  courier in and out at the 11th hour.  You could keep bits moving up
  until the building falls in, if you're well connected.

+ Ostrich behavior re: failures; putting off the acquisition of the
  harware which will serve you in DR scenarios until you're in a
  disaster mostly means you're not exercising your DR.  I've been able
  to write by-god shell scripts that recover my TSM servers.  And test
  them.  For real.  (and that was fun!)


I've got a gigabit from Gainesville to Atlanta now, and I'm feeling
happy about it.  The remote site isn't production yet, but we're
getting close.



- Allen S. Rout