On Tue, 2 May 2006 11:18:53 +0100 (BST) Alan Brown <[EMAIL PROTECTED]> wrote:
> 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. I appears as if I'm still not communicating. The actual speed of the tapes themselves is acceptable. The time it takes to get the tapes back on site is too long. Since we are _required_ to have offsite backups, and we also have a logical _need_ for onsite backups, we would benefit from what you are calling job cloning. > If things are that critical you can afford a LTO3 or SAIT2 changer. Already there. > > 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. What does a firesafe have to do with this? > >> 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) That's what we want. That fits our needs. > > 2) D-D-T: ? > > disk to disk to tape (which isn't done for the reasons you want it done) Huh? I'm not following either your explanation of the term, nor your assertion as to why I would want to use it. > >> 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. No. As previously described, the _tapes_ are fast enough, getting them back from the offsite storage facility is too slow. Our need for offsite storage is different than our on-disk backups. The offsite backups are for archival and legal requirements. Our on-disk backups are for handling 99% of the data-loss incidents. [snip] > > 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. Which is what we're doing now. > > 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. Yes. > If you have that kind of demand then you need fully replicated > geographically dispersed filesystems. Bringing things online from backups > will take too long. You are correct. But simply implementing geographically redundant filesystems would not meet all our needs. In some ways it would be overkill and prohibitively expensive. Additionally, redundancy _never_ replaces backup. I can have 1000 redundant systems dispersed across the entire galaxy, and if a user accidentally deletes an important record, I'll still need to go to backup to recover it, since the redundant systems will faithfully delete it from all mirrors. Here's the upshot: 1) We will have multiple locations that can fail over in near real time via database replication. 2) Each of these locations is redundant so that simple hardware failures are failed over transparently. 3) Each location keeps on-disk backups on a raid array for the purpose of restoring corrupt data. 4) One site will be used to generate backup tapes that will be taken offsite for legal and archival purposes. 5) Additionally, we have "supporting" systems used by staff, that are _not_ required to fail over like the product is. However, the data in these is still important, just the recovery can be slower. So: a) Some systems are locally redundant (such as DNS, LDAP) b) Data is backed up nightly to local RAID c) Data is backed up offsite weekly for legal/archival purposes. The upshot is that the product is expected to be reliable, period. It has to survive considerable man-made or natural disasters. Our DRP reflects that. The supporting stuff: email, financial records, and other "business" stuff needs to be reliable, backed up, and archived - but the requirements are less. We can afford _some_ data loss in this area (about a week) and we can afford some time to recover from a catastrophe. If we apply the business DRP to our product, the product will be unacceptable. If we apply the product DRP to the business data, we'll incur significant expenses that are unwarranted. Additionally, redundancy and backups serve two different purposes. Trying to use backup to solve redundancy problems will not work and vice versa. > > 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. Yeah, and the constitution of the US was supposed to protect individuals from unreasonable taxation, but look how that ended up. > 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.(**) Exactly. No pressure ... -- Bill Moran Collaborative Fusion Inc. **************************************************************** IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. **************************************************************** ------------------------------------------------------- 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
