Preserving the volhist file for a db restore

[dkmartin]

In our environment we do a full db backup on a daily basis. If we ever needed to restore the TSM database we would need the volume that the db backup was written to as well as the volhist file that contains the db backup volume information, correct?

My question....Is there a way that you can backup the volhist file after the db backup has run?

 

[RecoveryOne]

You need volhist and devconf files.
I have a script on my AIX box to capture those files and move them to to my NIM server. It also emails myself internally. Email servers and NIM server is in a different datacenter than the main TSM server. The same script that moves them to the NIM server, also executes a find with a ctime argument that matches my database retention so I don't have hundreds of files sitting about.

If you use the DRM aspect of TSM, copy your plan files as well.

How paranoid you want to be with those files is up to you. I'm fairly paranoid so they get plastered to a few more places not mentioned above

 

[dkmartin]

That's exactly what I would like to do is make a copy of all the external files needed for a DB recovery but I'm just unsure of when I should make the copy, as soon as the DB backup is complete? Or run a drm prepare and then do the copy?
So how do you run your script for the copy? I'm assuming it's a scheduled job, but how do you time it so that the files are copied after the db backup completes?
I was thinking about calling in a script from the

 

[dkmartin]

That's exactly what I would like to do is make a copy of all the external files needed for a DB recovery but I'm just unsure of when I should make the copy, as soon as the DB backup is complete? Or run a drm prepare and then do the copy?
So how do you run your script for the copy? I'm assuming it's a scheduled job, but how do you time it so that the files are copied after the db backup completes?
I was thinking about calling in a script from the admin schedule within TSM

 

[LED888]

Is there a way that you can backup the volhist file after the db backup has run?

Once the backup db process complete, there should be an admin schedule that issue backup volhist .
Following the backup volhist, should also run backup devconfig

In the dsmserver.opt file there are two paramerters: DEVCONFIG and VOLUMEHISTORY
These will point to where the devconfig.dat and volhist.dat are located.
NOTE (Someone correct me if I am wrong): Can have up to three lines of where the volhist.dat and devconfig.dat are located.

ie:

VOLUMEHISTORY volhist.out
VOLUMEHISTORY /path1/volhist2.out
VOLUMEHISTORY /path2/volhist3.out

When the backup volhist process run, the out put will be written at three places.

When there is change in the dsmserv.opt file, the sever need to be stop and restarted so that the new updates can be read.
There is a command called SETOPT where you can change some parameter on the fly.
Not all parameters can be set via the SETOPT.

should make the copy, as soon as the DB backup is complete?

Yes.


Good Luck,
Sias

 

[dkmartin]

Once the backup db process complete, there should be an admin schedule that issue backup volhist .
Following the backup volhist, should also run backup devconfig

In the dsmserver.opt file there are two paramerters: DEVCONFIG and VOLUMEHISTORY
These will point to where the devconfig.dat and volhist.dat are located.
NOTE (Someone correct me if I am wrong): Can have up to three lines of where the volhist.dat and devconfig.dat are located.

ie:

VOLUMEHISTORY volhist.out
VOLUMEHISTORY /path1/volhist2.out
VOLUMEHISTORY /path2/volhist3.out

When the backup volhist process run, the out put will be written at three places.

When there is change in the dsmserv.opt file, the sever need to be stop and restarted so that the new updates can be read.
There is a command called SETOPT where you can change some parameter on the fly.
Not all parameters can be set via the SETOPT.



Yes.


Good Luck,
Sias

Thank you for the information. It's very helpful and I will definitely implement the changes to have the files backed up to multiple locations.

Here is my next question. What happens to the volhist file(s) when an unscheduled db backup runs? For example a db backup will kick off automatically if your log file space is getting full, correct? This would overwrite the current volhist file and you would not have the other 2 copies because the backup volhist command did not run, correct? And I would also not have a current plan file because a DRM prepare was not executed either?

 

[LED888]

What happens to the volhist file(s) when an unscheduled db backup runs?

If we did not issue the backup volhist, no data is written to the volhist.out file(s).

This would overwrite the current volhist file and you would not have the other 2 copies because the backup volhist command did not run, correct?

No. The information is never overwritten. The information is appended to the volhist.out .
When we issue backup volhist, the information is going to be written to ALL locations that are configured in the dsmserv.opt file.
Unless we specify where the volhist is to be located and named -
backup volhist filenames=/path/volhist.dat

NOTE: Over time the volhist.out file will grow. To prune the volhist.out and to keep so many backup db ...
delete volhist todate=today-60
I use 60 as an example. This will keep the database backup for 60 days, anything older than 60 days will be removed from the volhist. You don't need a database backup that was done 365 days ago.
Also, you can not delete the most recent backup db.

not have a current plan file because a DRM prepare was not executed either?

The DRM prepare need to be current. Keep in mind that the DRM process are for someone else to restore the Spectrum Protect Server.

Good Luck,
Sias

 

[RecoveryOne]

I used to use what LED888 said and have it write to multiple paths. One path being a NFS mount of my NIM box. Now, I started to use the 'issue message' inside of my admin tasks, then a cron script to check the server messsages for my string. If string is matched, delete cron task and sftp files over to remote servers and send email.

I have it in the first line of my expire inv script.
So something like this in my database backup:
backup db devc=<library>t=f s=y nums=4 wait=yes
backup volhist
backup devconfig
delete schedule 3_ONSITE_DBB t=a
define schedule 4_EXPIRE_INV cmd='run 4_EXPIRE_INV' t=a active=yes startt=NOW+0:05

Then the first line of 4_expire_inv is:
ISSUE MESSAGE w "Backup of volhist and devconfig completed"

Cron checks +/- 2h from my 'normal' database backup finish time, and if it doesn't see that message, an if statement emails the team saying volhist and devconf not found during normal time. So there is a 'gap' and there are other ways to do it but way I chose.

Once the backup db process complete, there should be an admin schedule that issue backup volhist .
Following the backup volhist, should also run backup devconfig

The newer versions of Spectrum Protect, a dedicated backup volhist/devconfig isn't needed. But I agree, its good to have it in your scripts I've not seen what happens when an emergency database backup happens for devconfig/volhist. Thankfully those days of log space getting full are behind me, so I cannot say. But as of 8.1.9 I think (Don't quote me on that) its done automatically after a full database backup is ran.

Anyhow,
Its a bit convoluted but infosec was on my tail about nfs mounts... Long story, so I did what was needed to get them off my back

Oh and idealy you keep the volhist for the same number of days you keep your database backups, which is the same amount of time you have set for your reuse delay for scratch volumes.

 

[marclant]

One addition, the VOLHIST and DEVCONFIG files are automatically backed up at the end of the database backup as long at the VOLUMEHISTORY and DEVCONFIG options are defined in dsmserv.opt. And you can define those options more than once if you want them to be written to more than one location:

After the database backup is complete, the IBM Spectrum Protect server backs up information, depending on the options that are specified in the server options file. The following information is backed up:

• Sequential volume-history information is backed up to all files that the VOLUMEHISTORY option specifies
• Information about device configuration is backed up to all files that the DEVCONFIG option specifies
• The server's master encryption key

https://www.ibm.com/support/knowledgecenter/SSEQVQ_8.1.11/srv.reference/r_cmd_db_backup.html

There's no harm in backing those up again, but there's also no need to do it.

 

[marclant]

I did a manual one to show you, here's what was logged after the BACKUP DB, I didn't backup the volhist and devconfig, the server did:

03/22/2021 08:47:10      ANR0985I Process 68 for Database Backup running in the
                          FOREGROUND completed with completion state SUCCESS at
                          08:47:10. (SESSION: 88571, PROCESS: 68)
03/22/2021 08:47:10      ANR4500I Writing sequential volume history information to
                          defined files.
03/22/2021 08:47:10      ANR4501I Sequential volume history information
                          successfully written to volhist.dat.
03/22/2021 08:47:10      ANR2394I BACKUP DB: Server device configuration
                          information was written to all device configuration
                          files. (SESSION: 88571)

 

[RecoveryOne]

One addition, the VOLHIST and DEVCONFIG files are automatically backed up at the end of the database backup as long at the VOLUMEHISTORY and DEVCONFIG options are defined in dsmserv.opt

Yeah forgot to mention that. Just so second nature to have it defined in the dsmserv.opt.

 

[dkmartin]

Thank you everyone for the great information. I understand that the volhist/devconfig files are backed up once a db backup completes. We do have locations defined in the dsmserv file so that part is covered. What I would ultimately like to do is keep a copy of those files each time a db backup is run if that makes any sense.

We had a situation recently where we had to restore the db to a version older than the most recent backup. It just so happens that we do an sftp of the volhist, devconfig and plan files to a remote server as part of our DR plan so I was able to retrieve the versions I needed that corresponded to the db volume I was going to use for the restore. If I didn't have those versions of the files I would have been in trouble (at least I think I would have been). So now I too am paranoid about not having these files available if we a restore was needed.
Ultimately, I would like to make a copy of the volhist/devconfig/planfile each time the scheduled db backup runs and I'm just not sure the best way to go about it. My initial idea was to call in a shell script from within my admin sched job that would create the copies after the backup is complete?