Omniback II (3.01) and OnBar
IDS 7.30.uc7 (soon to be 7.31.uc4+) HPUX 10.20 We're planning to implement Omniback to handle file system backups on our production system. A few questions for those of you who have implemented Omniback and OnBar . . . 1. Are there any gotchas? 2. Is it possible to restore to a different system using OnBar (assuming identical logical setups)? 3. Could you point me to any relevant reading material? I've already perused Informix's site and deja.com. Thanks in advance! -- John Carlson Informix DBA WHSmith USA #include std_disclaimer.h /* These are my opinions, not my company's opinion */
In article <388CB182.55D2601E@bellsouth.net>, "Carlson@WHSmith" <carlson1@bellsouth.net> wrote: > IDS 7.30.uc7 (soon to be 7.31.uc4+) > HPUX 10.20 > > We're planning to implement Omniback to handle file system backups on > our production system. A few questions for those of you who have > implemented Omniback and OnBar . . . > 1. Are there any gotchas? Gotcha's are plentiful, but mostly on the OmniBack side. There is a utility that you (as the DBA) must run to identify yourself to OmniBack called util_informix.exe. It configures the interface between OmniBack and Informix. Additionally, you'll either have to run your first archive from the OmniBack GUI, or insert into your sysutils.bar_versions table a record that defines the OmniBack version (if you run the archive from the OmniBack GUI, that insert is done for you). The other major one that we ran into is that if you allow Informix to "open up the floodgates" during a parallel archive, you will flood OmniBack with too much information, and it will crash. We've found that 4 streams per DLT tape device seems to work best for us. To guarantee that, set BAR_MAX_BACKUP to be 4 times the number of tape devices that you have. > 2. Is it possible to restore to a different system using OnBar > (assuming identical logical setups)? Absolutely, but here the procedure is pretty cryptic. I'm sure that there is something posted either in the newsgroup or on the IIUG site, but if not, let me know, and I'll send you the procedure that I wrote up for us. The big gotcha here is that you have to have your OS files (ixbar.<servernum> in particular) in sync with your database archives, or the restore won't happen. > 3. Could you point me to any relevant reading material? I've already > perused Informix's site and deja.com. > I've got a good general site for OnBar stuff, but I don't recall it having anything wonderful for OmniBack. Its URL is http://www.geocities.com/Heartland/Acres/4927/onbar.html Hope that gets you where you need to go. -- Dan Michaelis Database Administrator dan@kax.com Sent via Deja.com http://www.deja.com/ Before you buy.
"Dan Michaelis" <dan_michaelis@my-deja.com> wrote in message news:86ih6k$3ge$1@nnrp1.deja.com... > In article <388CB182.55D2601E@bellsouth.net>, > "Carlson@WHSmith" <carlson1@bellsouth.net> wrote: > > IDS 7.30.uc7 (soon to be 7.31.uc4+) > > HPUX 10.20 > > > > We're planning to implement Omniback to handle file system backups on > > our production system. A few questions for those of you who have > > implemented Omniback and OnBar . . . > > 1. Are there any gotchas? > > Gotcha's are plentiful, but mostly on the OmniBack side. There is a > utility that you (as the DBA) must run to identify yourself to OmniBack > called util_informix.exe. It configures the interface between OmniBack > and Informix. Additionally, you'll either have to run your first > archive from the OmniBack GUI, or insert into your sysutils.bar_versions > table a record that defines the OmniBack version (if you run the archive > from the OmniBack GUI, that insert is done for you). The other major > one that we ran into is that if you allow Informix to "open up the > floodgates" during a parallel archive, you will flood OmniBack with too > much information, and it will crash. We've found that 4 streams per DLT > tape device seems to work best for us. To guarantee that, set > BAR_MAX_BACKUP to be 4 times the number of tape devices that you have. > > > 2. Is it possible to restore to a different system using OnBar > > (assuming identical logical setups)? > > Absolutely, but here the procedure is pretty cryptic. I'm sure that > there is something posted either in the newsgroup or on the IIUG site, > but if not, let me know, and I'll send you the procedure that I wrote up > for us. The big gotcha here is that you have to have your OS files > (ixbar.<servernum> in particular) in sync with your database archives, > or the restore won't happen. > > > 3. Could you point me to any relevant reading material? I've already > > perused Informix's site and deja.com. > > > > I've got a good general site for OnBar stuff, but I don't recall it > having anything wonderful for OmniBack. Its URL is > http://www.geocities.com/Heartland/Acres/4927/onbar.html > > Hope that gets you where you need to go. > > -- > Dan Michaelis > Database Administrator > dan@kax.com > > > Sent via Deja.com http://www.deja.com/ > Before you buy. We're currently using OnBar/ADSM and are experimenting with OmniBack. OmniBack's ONLY plus, as far as I can tell, is the ability to use local (to the database server) tape drives in addition to being able to do network backups. Personally (and maybe it is because I've played with ADSM longer), OmniBack lacks some important items that don't affect database backup, but do affect log handling. 1) No automatic migration of backups from disk to tape as disk fills (I backup logs to disk for speed and migrate to tape as disk nears capacity) 2) No consolidation of backup tapes. I make a backup of all changes for the day, daily, and then combine the tapes once a week. I get reduced daily copy time and weekly release of tapes without loss of data. Just some of the items I've run across. If I'm wrong, I'd be GLAD to hear it. Doug Agnew