ontape -a and ontape -c

Hello, I run ontape -a on a weekly basis and backup up the database to disk device(\\ifmxbkup\\bkupmmdd). and run ontape -c during midweek. Will this help me in recovering any database if required Also, during other times I keep the ltapedev and tapedev parameters to NUL so as to avoid keeping track of the logs and their size. My concern here is whether, I am doing this correct or is there any other precautions I need to take. thanks for your suggestions Mitesh Shah DBA Princeton Softech mshah@princetonsoftech.com (609)-6885107

Mitesh Shah wrote: > > Hello, > > I run ontape -a on a weekly basis and backup up the database to disk > device(\\ifmxbkup\\bkupmmdd). and run ontape -c during midweek. Will this help > me in recovering any database if required > Also, during other times I keep the ltapedev and tapedev parameters to NUL > so as to avoid keeping track of the logs and their size. > > My concern here is whether, I am doing this correct or is there any other > precautions I need to take. No, you are doing this incorrectly, unless you are not explaining yourself well. If you are running with LTAPEDEV set to /dev/null your log files are all being dumped in to the bit bucket (ie discarded) upon completion so they are NEVER being backed up by either the ontape -a or ontape -c. Also BOTH these commands are for backing up the logical logfiles, which is fine, but you do not say that you EVER run ontape -s which is the backup command to save your databases! Without an ontape -s archive as a base for restoring the logs you are saving are completely useless and because you are discarding MOST of those logs even with an ontape -s archive it is unlikely that you will have the logfiles you will need to roll the restore forward to current time after a crash. PLEASE read the Archive and Backup Guide which describes the ontape tool. You should be taking an ontape -s -L0 (level zero base archive) AT LEAST weekly with ontape -s -L1 and ontape -s L2 alternating daily for the rest of the week OR ontape -s -L1 daily for the first half of the week and ontape -s -L2 for the balance of the week if level 1 archives take toolong after a few days. All this with the TAPEDEV set to a real file or tape device. In addition if you want to be able to restore to the point closest possible to before a crash you should be running ontape -c (continuous logical log backup) with LTAPEDEV set to a real tape device at ALL TIMES changing the tape at the beginning of each ontape -s -L0 so you can save the prior log tape with the prior Level 0, 1, & 2 archives so in case the new level 0 is unusable you can still restore the prior Level 0 through 2 and the saved logs to get to the same place. If you do not want to dedicate a tape drive, and terminal, to constantly backing up logs you can accomplish the same thing by setting the LTAPEDEV to a file and using the ALARMPROGRAM to back up each logical logfile as it fills up with ontape -a (automatic logical log backup, an unfortunate name for something that should have been called Manual logical log backup since that is what it accomplishes). See my submission to the IIUG Software Repository named utils3_ak for two examples of doing this using a shell script (modified version of log_full.sh) and an executable which can be used in ALARMPROGRAM to monitor engine panics and warnings and also perform the log file archiving to disk renaming the output file and creating a new empty one each time. Art S. Kagel