Re: ontape vs onbar

Colin Bull wrote: >> Ontape is quick and easy, but does not guarantee consistent >> restores if databse is active when backed up. Sorry, but Wrong! I hope someone else refuted this statement. ontape puts in a lot of effort to ensure a consistent point-in-time backup of an active database. This is not an issue. Using tar or dd against the dbspaces - THAT would be inconsistent... > Onbar works with logs to give reliable restore when database is > active, and is therefore more demanding to use. ontape interacts with logical log tapes when restoring, so this is not an issue either. Onbar is capable of higher performance (parallelism) and higher functionality (point in time restores, dbspace restores, etc) and that is why it's available as an alternative. However it requires some setup and understanding.

"Andrew Hamm" <ahamm@mail.com> wrote in message news:<c5i2cd$1ta65$1@ID-79573.news.uni-berlin.de>... > Colin Bull wrote: > >> Ontape is quick and easy, but does not guarantee consistent > >> restores if databse is active when backed up. > > Sorry, but Wrong! I hope someone else refuted this statement. OK, I'll refute it: the entire post showed a fundamental misunderstanding of what ontape and onbar do and of the differences between them. Refuting enough for you? For the record, BOTH products guarantee consistent restores, BOTH synchronise with any available logical logs and BOTH have the same other fundamental features such as online and incremental backups. onbar just adds a whole universe more media management facilities - and the encumbent headaches of setting it all up - plus some nifty extra facilities like point-in-time restores and backing up logs to temporary files if the tape fills up. The main reasons I tend to be nervous of onbar are, (a) anyone with a crib sheet and a brain can do an ontape backup / restore, and (b) onbar can be incredibly fickle, and require manual cleaning up / kludging if you foul it up the first time. Andy