IBM E16RMLL-I Implementation Guide - Page 410
Defining the volume history schedules
![]() |
View all IBM E16RMLL-I manuals
Add to My Manuals
Save this manual to your list of manuals |
Page 410 highlights
Once the script is defined to the server, you need to define a schedule that will run the script for you every day at 4 a.m. The macro, mac.schedules, which we provide to define recommended schedules in our book environment, is shown in "Define schedules" on page 735 and includes the schedule definition command in Example 12-5 on page 380. Example 12-5 Defining the REDBOOK_OFFSITE schedule tsm: LOCHNESS_SERVER1>define schedule redbook_offsite type=admin cmd="run redbook_offsite" desc="Backup all data for off site storage" starttime=04:00 active=yes ANR2577I Schedule REDBOOK_OFFSITE defined. tsm: LOCHNESS_SERVER1>q sched redbook* type=admin * Schedule Name Start Date/Time Duration Period Day REDBOOK_OFFSITE 02/20/2006 04:00:00 1 H 1 D Any 12.2.2 Defining the volume history schedules If you have licensed the Disaster Recovery Manager (DRM), we recommend that you run a schedule to back up the volume history on a daily basis. DRM will handle expiry of database backups. If you are not using DRM, we recommend that you run one schedule to delete the old database backup volume history, and also one schedule to back up the volume history, on a daily basis. Every volume that is used by Tivoli Storage Manager, including the volumes used for server database backups, is tracked in the server database. You can access this information while the server is up with the query volhistory command. The volume history information is very important because it tells you which volume holds your most recent database backup. If the server database is lost or corrupted, you need to know which is the latest backup in order to restore your database. However, if you cannot start the server, the database is not available, and you cannot retrieve the information. Therefore, a separate copy of the volume history information should be periodically saved to a text file. You can specify the file name with the VOLUMEHISTORY option in the server options file (dsmserv.opt). You can specify multiple VOLUMEHISTORY entries in the options file to specify more than one file. We recommend maintaining at least two copies of the volume history file, in case one becomes unusable. When you back up the database, the previous database backups become obsolete. However, it is wise to save the older backup for a short time before returning them to scratch volume status for reuse. DRM will take care of 380 IBM Tivoli Storage Manager Implementation Guide
![](/manual_guide/products/ibm-e16rmlli-implementation-guide-3588123/410.png)