Dbbackupexpiredays

[bonobos]

Hi,

I am doing daily backups of my primary storage pools to copypool (per script) and in the same script I perform a DB snapshot. Now I have over 10 tapes with dbbackups, but I set the DBBACKUPEXPIREDAYS to 3 day in the DRM Manager.

Do I have to set administrative schedules (something like "del volhist type=dbs todate=today-2) to set the dbs tapes back to scratch? Shouldn't the DBBACKUPEXPIREDAYS parameter do that for me?

That's just something I didn't get in my mind so far ...

 

[spidermila]

We are using the del volhist command and it does the job. I think that the DBBACKUPEXPIREDAYS parameter works only when you have DRM configured and are using it.

 

[bonobos]

ok, but I have DRM configured. What if I delete the db snapshots via "del volhist ..." - will they show up as vault-retrieve tapes in my DRM or will they just be deleted from every list (and be forgotten in the vault)

 

[BBB]

Do not use del volhist if using DRM. There's a 100 posts on here saying the same thing.

You probably haven't set drm up properly. You need to make sure you are doing move drm's to move the snapshots offsite. What state does "q drm" show the snapshots as being in?

 

[noodles]

Hi,

I had similar problems.
I was wondering when DRM would expire DBBackups.
It seems that this is done when you use "move drmedia".

IBM says that one should not use "delete volhist" when using DRM.
One thing that is not clear to me is how should I expire DBBackps when I use DRM with virtual volumes and backup the DB to a different TSM.
I do not want to remove tapes in this environment so "move drmedia" would not be the right solution for me, right?

Regards
/noodles

 

[heada]

Expire inventory expires DBBackups and then those volumes are moved back onsite via "move drmedia fromstate=vaultr tostate=onsiter"

If you delete the volume from volhist, the move drmedia command can't move it back onsite and it becomes lost.

-Aaron

 

[BBB]

**Edit: Ignore this post its wrong

Noodles in your particular situation the advice is different.

Keep using DRM as per usual for your normal tapes.

But to "expire" the DB backups on virtual volumes, do this:

[B]delete volhist type=dbbackup[I][COLOR=Green](or dbsnapshot etc)[/COLOR][/I] devclass=<devclass_for_your_virtual_volumes> todate=today-XXXX days
[/B]

The key is the devclass bit. This makes sure you just hit the virtual volumes.

 

[noodles]

Hi,

I again have the same problem:
"Dbbackupexpiredays" is set to 7 days but DBBackups are not expired when I run "expire inventory"...

The actlog says that 0 dbbackups have been expired although there are Volumes which are older than 20 days.
'q volhist' and "q drmedia' both show all these tapes.

I use DRM but I do not checkout volumes, we backup the DB to virtual volumes and to LTO tapes in a local attached library.

Now I have found following in the help of the Admin_Center (yes... I know) for the "Dbbackupexpiredays" option:

"A backup series is eligible for expiration if all of the following conditions are true:
The age of the last volume of the series exceeds the expiration value you specify.
For volumes that are not virtual volumes, the volume states are all VAULT.
It is not the most recent database backup series. The most recent backup series, snapshot or full plus incremental, is never deleted. "

In my case the state of all volumes is "mountable" - does that mean that my dbbackups are not expired because of that?
If this is the case do I have to use "delete volhist" instead?

Thanks in advance for helping me seeing things clearer!

/noodles

 

[heada]

Use "move drmedia" to move those DBB offsite (without checkout) and then use "move drmedia" again to bring them back onsite as scratch. The "move drmedia" process is the process that will actually expire the DBB tapes.

-Aaron

 

[gernthefish]

In our case, we create DBBs on disk and on tape each day. My understanding is that we have to run 'delete volhist' or we'll eventually run out of disk space. Is this the case? If so, maybe we should stop sending the DBB to disk and just use tape.

 

[heada]

Volhist is just the volume history file. It tracks volumes as they are used(scratch, used, deleted, etc). It does not free up disk space if you're writing to disk so I'm not sure why you'd use that to keep a filesystem from filling up. Do NOT delete from the volhist file if you are using DRM unless you know exactly how DRM and the volhist file work together. It is an easy way for tapes to get lost and never recalled from offsite.

-Aaron

 

[gernthefish]

Well, maybe dbbackupexpiredays is what deletes our old disk DBBs. Pardon my ignorance. We have the following settings:

dbbackupexpiredays 5
delete volhistory todate=today-5 type=dbbackup (runs every day)
reusedelay 6 (copy pool)

Should I no longer run 'delete volhist'?

 

[heada]

If I were you, I would track your DBBackup tapes to make sure that they're all being recalled from the vault. Since you are doing both, one of them is not needed and I would keep the DBBackupexpiredays setting and no longer delete the volhist data.

-Aaron

 

[jdresang]

We have full DB backups going to 3 predefined device type file volumes on local SAN storage and then send dbsnapshots on tape offsite. We want to keep the dbsnapshots offsite for 7 days, but because we only have disk space available for 3 volumes, we have to run the del volhist on just dbbackups. We let the db backup expire days control the offsite tapes. This would be the only exception to using the del vol hist, otherwise I'd agree to never use it.

 

[gernthefish]

Great info! Thanks for everyone's help.