On Mon, 1 May 2006, Bill Moran wrote:
I backup ~20Tb to LTO2. The tapes run almost as fast as most of the
disk arrays (MSA 1000 and Nexsan Atabeast)
I guess I didn't make my point.
The tapes are several orders of magnitude slower than disk.
Then get faster tapes.
If things are that critical you can afford a LTO3 or SAIT2 changer.
The time it takes to get them back onsite alone is too slow for most
recovery scenerios.
Hence the necessity for job cloning - AND a decent data firesafe.
Sveral people have requested simultaneous backups for the same reason.
Asking for D-D-T just obscures what you really want.
Can you please define these terms, then. I'm fuzzy on what they mean:
1) simultaneous backups: ?
Job cloning - data is dumped to 2 sets of tape at the same time (or disk
and tape simultaneously)
2) D-D-T: ?
disk to disk to tape (which isn't done for the reasons you want it done)
Not at all, but 1Tb is a small amount of disk these days.
I suppose. We don't expect it to stay that small, and we've got a limited
amount of time to shake the bugs out of the system before our backup
needs balloon.
Then you DEFINITELY need faster tape.
In any case, the functionality you need can probably be achieved
using bcopy on the backup sets - and given the small dataset you have, it
wouldn't take long.
You mean the utterly undocumented bcopy? Or is there some other bcopy that
you're referring to?
That's the one.
I did do some experiments with bcopy, and wasn't happy with the results.
If I rememeber correctly, it required me to write a script that:
1) Knew which on-disk volume it needed to duplicate.
2) Was able to generate a label for the tape _prior_ to running bcopy.
While that's certainly possible, it's still far from "ready for general
consumption". Quite frankly, I'm in the dark on how to do #1 reliably,
and #2 requires btape. Starts to seem rather klunky.
It is, but it is an interim workaround.
Your other alternative is to backup twice, to 2 different pools.
Before the end of the year, we will require redundancy that can survive
major catastropies that are geographically localized. IOW: if Pittsburgh
were to get hit with a nuclear warhead, our customers would expect us
to fail over to a second site. Thus we need truely offsite backups.
No.
If you have that kind of demand then you need fully replicated
geographically dispersed filesystems. Bringing things online from backups
will take too long.
Very cool. However, it wouldn't suit our needs. As I mentioned, the unit
would _literally_ have to be nuclear warhead-proof. Since nobody makes
such a unit, our DRP must include geographically dispersed redundancy.
The internet was designed (originally(*)) to withstand nuclear attack and
route around the damage.
If you need that kind of durability then relying on a tape backup system
is at least an order of magnitude below your _true_ requirements and will
leave you caught short if things do go bang.(**)
AB
(*) There has been so much consolidation into major backbones that I
suspect the 'net would catastrophically fail in the event of even a minor
problem, witness the severe degradation which occurs with localalised
communications outages around major nexus points.
(**) there are far nastier things which can be done with fissile material
than to make it go bang.
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
