>> On Thu, 5 Jan 2006 09:54:34 -0500, "Kauffman, Tom" <[EMAIL PROTECTED]> 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
