Re: backup takes too long

Well, Billy, I'm just trying to help, so I'm not sure why you chose to immediately flame me. I am well aware that there are a number of people using onarchive without problems. I also know there are a number of people driving pintos around that haven't blown up. That is not the issue. In backup/recovery land, it's not the 100's or even 1000's of people that successfully use a product that determine its worthiness in the marketplace. It's that one person (or 100's of people) that discover all the things that it DOESN'T do! I AM indeed a principal consultant with Pencom Systems Administration, specializing in data protection and disaster recovery, and have specialized in it for over 4 years now. I have setup backup/recovery systems from the simple desktop to 100's of servers with terabytes of data. And, as my signature indicates, I am writing O'Reilly's first book on the subject. The only time in that four year career that something I setup potentially caused data loss was Onarchive. I understand the value of setting up a simple system. The problem is that's really hard to do with such a complex product. If you mean that you are not using any of its advanced features, then why use it at all? Why not use ontape, a proven, VERY simple utility whose only limitation is that you can't split up the backup of a very large database? If you have a very large database, and must split up your backup to multiple dbspacesets, then your backup is no longer simple, and you are in the same boat as I was. Believe me. We worked very hard on making the setup as simple as it could possibly be, given the size of the database. The best we could do was automatic continuous backups to disk, and split the instance up into 4 dbspacesets which would go to 4 drives simultaneously. This was the only way to get >100GB to tape in one night using DDS-2 drives. Informix was very happy with our setup, and used it as an example for two other large sites. Then we went to recover. With full support of the Informix team, we went to our disaster recovery site and tried to recover the whole instance to another system. No dice. The first time, it was said that we didn't have the right patches on the HP. The second time, we made sure the appropriate patches were there. No dice. After a third failure, we bought a bigger, faster, DLT drive and went back to ontape. There is no need for you to defend Onarchive just because you're using it. I am not insulting you or your setup. I am warning you that you may not know the whole story. Summary: I am not the only one to report problems with Onarchive. If you've been getting along just fine, great. I am warning you that the dangers are there. Ask yourself why Informix went and coded onbar in the first place? It's essentially a completely competing product. Why would they do that if Onarchive was working just fine? If you don't need its complexity, then don't use it. Ontape is MUCH easier to use and never failed me, even with hundreds of restores. If you need it's complexity, then buy a commercial backup product and use onbar. It's as simple as ontape, but more powerful than onarchive. If you want to keep driving the pinto, just because it hasn't blown up on YOU yet, that's fine with me. In article <5l8qui$6ja@cssun.mathcs.emory.edu>, From billy@west.co.za ("Billy Wheeler"), the following was written: >> On 12 May 97 at 15:12, Tim Schaefer wrote: > >> Curtis Preston wrote: >>> Bill, I've got to disagree with you big time. Onarchive is a > nightmare, >>> and should not be used for anything. Take the lead from Informix, >>> and dump it. (That's why they wrote onbar!) Your "this will >>> require some setup" is putting it mildly. I am a data protection >>> expert, and > worked >>> with Onarchive for many months. Short version: >>> >>> 1) read the manual 4 times >>> 2) went to the official class >>> 3) spent 4 months designing and testing a solution >>> 4) tried ~3~ times to do a recovery using the backups. >>> 5) After multiple failures, we gave up, bought a bigger/faster drive >>> and went back to ontape. > >> Are you suggesting the restore features of OnArchive do not work >> correctly, >> or are you talking about the product in general? > > Erm, I've done successful restores in a production environment. I am > definitely *not* a data protection expert, so I don't know what I > could have done wrong... :-) > > Perhaps I erred in making a fairly simple backup strategy. > > Having said that, however, I didn't find OnArchive to be a > particularly usable product... :-( > > -- > Ciao, > Billy