DB Backup Overwrite / Retention

DHall

ADSM.ORG Member
Joined
Nov 24, 2008
Messages
11
Reaction score
0
Points
0
Location
Miami, FL
PREDATAR Control23

First time post, so please be gentle. I'm fairly new to TSM and have gotten pretty proficient, but would consider myself a newb still by most standards. To my question:

We are trying to setup a 7 day DB Backup tape rotation. We have retained some LTO1 tapes exclusively for DB Backups. We do full backups every day straight to tape. Right now, I cannot put more then 3 scratch in our library for DB backups. On the fourth day, instead of taking the 4th scratch tape, it will overwrite the oldest DB tape. For example, today being the 24th, if I did not eject that tape by the 27th, it would overwrite that tape instead of using a scratch. I have set the TSM server to retain for 8 days before backups are available for expiration, but the problem persists.

When I do a q drm, it only shows the DB Backup tapes that are in the mountable state. When I move DB tapes out of the library, I use the command:

move drmedia (tape number) wherest=mountable tost=vault rem=untileeful

I would like if I could see both the mountable and vaulted DB Backup volumes when I do a q drm until they expire or even better have TSM move them to a vaultretreive state when they have expired.

Please let me know if anymore information is required. I would really like to figure this out. I've had to come in multiple weekends because of this... :)

Any help would be appreciated.
 
PREDATAR Control23

Are you using DRM? If you are not, you need to track the DB tapes manually to know when the retention goes past 7 days to allow you to retrieve the tapes as scratch.

On the other hand, since you mentioned MOVE DRM, then the system will track any DB tapes that goes past retention and be eligible for retrieval. Configure DB retention for seven days and the rotation will be automatic but eject tapes (move drm ...) daily after a full DB backup and checkin new scratch tapes for the next DB backup.
 
PREDATAR Control23

when you do a q drmstatus what is your dbbackup expiration set to?

I could be wrong but it thought it automatically tracked db volumes through whole drm process by default as long as configured correctly.

So maybe if your dbbackup expiration is set higher than 7 your dbbackup tapes are sitting in vault status longer than you would like.

Are you actually ejecting the dbbackup tapes? You said something about overwriting, if your are running move drm it should move db volumes as well and you shouldnt have any volumes in library.
 
PREDATAR Control23

Thanks for the reply.

We do have DRM running.

Is it not possible then to put in, say, five scratch at a time? Is it required to eject on a daily basis? We typically eject our DRM on a weekly basis. Our library is not in the same location as our office so I'm trying to get to the point where we could eject a weeks worth of DB backups tapes at a time and give the library a weeks worth of new scratch.

For what ever reason, this process works for three scratch, but does not work for more then that.
 
PREDATAR Control23

When I do a q drmstatus it shows that DB Series Expiration is set to 8 days, which is what I set it to.

I am ejecting every three days right now, because our system will overwrite DB tapes instead of taking scratch at that point, which is the root of my problem.

DRM does not appear to be tracking my DB tapes. When I do a q drm, it only shows the tapes that are mountable (in the library), anything that has been ejected no longer shows in this list.
 
PREDATAR Control23

It is a highly recommended practice to eject and send to offsite DB backup tapes on daily basis. Some installations that I know of create two DB backups daily, and sent offsite daily.
 
Last edited:
PREDATAR Control23

Ok, so let's not focus on the amount of tapes then.

I'm curious, even when I ejected on a daily basis, why DRM is not tracking the DB tapes. As soon as I moved them to the vault state (we go straight from mountable to vault because we have our own vault), they disappear from the q drm list. Any insight on this?
 
PREDATAR Control23

How do you send DB tapes to OFFSITE? What command do you use? Can you post it here?

If I do a "q drm" I see all of my DB tapes that I keep for 7 days saying it is all at VAULT.
 
PREDATAR Control23

How do you send DB tapes to OFFSITE? What command do you use? Can you post it here?

If I do a "q drm" I see all of my DB tapes that I keep for 7 days saying it is all at VAULT.


Thats what I thought as well. We actually write our DB backups to dev=file so its a bit different, but same concept. We do this so we dont send the key to our data with the data offsite. IBMs best practice recommend against this. So if applicable I would use a mount point on a remote server and write DB on that. I know this solution isnt for everyone but works extreamly well. Here is a example of one of our remote TSM boxes that write the DB backup here at our HQ for DR recovery. As you can see below it is tracking our *.dbb files like it would a tape.

tsm: FARTSM1P>q drm

Volume Name State Last Update Automated
Date/Time LibName
---------------- ----------------- ------------------- ----------------
FAR001L2 Vault 10/14/2008 15:21:21
FAR006L2 Vault 11/13/2008 10:28:50
FAR008L2 Mountable 11/25/2008 11:36:55 LTOLIB
FAR021L2 Vault 10/13/2008 08:02:23
FAR023L2 Vault 09/11/2008 08:29:36
FAR024L2 Vault 10/27/2008 06:58:13
FAR029L2 Vault 09/17/2008 08:08:14
FAR044L2 Vault 09/11/2008 08:29:36
FAR045L2 Vault 07/28/2008 07:46:37
FAR056L2 Vault 10/15/2008 12:24:32
FAR070L2 Vault 11/24/2008 09:09:34
FAR073L2 Vault 10/30/2008 09:46:41
FAR081L2 Vault 11/17/2008 09:06:38
FAR086L2 Vault 09/23/2008 12:29:33
FAR090L2 Vault 10/13/2008 08:02:23
FAR095L2 Vault 11/24/2008 09:09:34
FAR098L2 Vault 09/25/2008 08:50:02
FAR102L2 Vault 10/17/2008 09:09:12
FAR107L2 Vault 10/20/2008 10:33:22
FAR111L2 Vault 11/24/2008 09:09:34
FAR113L2 Vault 11/06/2008 08:57:56
FAR117L2 Vault 11/19/2008 15:00:49
FAR123L2 Vault 10/13/2008 08:02:23
FAR131L2 Vault 11/20/2008 10:54:44
FAR133L2 Vault 11/13/2008 10:28:50
FAR141L2 Vault 11/04/2008 09:08:30
FAR143L2 Vault 11/06/2008 08:57:56
FAR154L2 Mountable 11/25/2008 11:04:26 LTOLIB
FAR155L2 Vault 10/27/2008 06:58:13
FAR159L2 Vault 11/10/2008 11:45:44
FAR174L2 Vault 11/07/2008 10:47:33
FAR178L2 Vault 10/30/2008 09:46:41
FAR180L2 Vault 11/10/2008 11:45:44
\\STLBKP\TSMDBF- Mountable 11/24/2008 07:14:50
AR$\27541057.D-
BB
\\STLBKP\TSMDBF- Mountable 11/24/2008 07:14:50
AR$\27539394.D-
BB
\\STLBKP\TSMDBF- Mountable 11/24/2008 07:14:50
AR$\27537704.D-
BB
\\STLBKP\TSMDBF- Mountable 11/24/2008 07:14:50
AR$\27535930.D-
BB
\\STLBKP\TSMDBF- Mountable 11/24/2008 07:14:50
AR$\27534256.D-
BB
\\STLBKP\TSMDBF- Vault 11/24/2008 09:09:34
AR$\27529339.D-
BB
\\STLBKP\TSMDBF- Vault 11/24/2008 09:09:34
AR$\27527675.D-
BB
\\STLBKP\TSMDBF- Vault 11/24/2008 09:09:34
AR$\27526012.D-
BB
\\STLBKP\TSMDBF- Vault 11/24/2008 09:09:34
AR$\27524245.D-
BB
\\STLBKP\TSMDBF- Vault 11/24/2008 09:09:34
 
PREDATAR Control23

The command I use is:

move drmedia (tape number) wherest=mountable tost=vault rem=untileeful

Is this the wrong command to use?
 
PREDATAR Control23

The command I use is:

move drmedia (tape number) wherest=mountable tost=vault rem=untileeful

Is this the wrong command to use?

Nothing is wrong with your command. I just just use a wildcard instead of the tape number.
 
PREDATAR Control23

Right, but because we only eject our DRM once a week, and I have to eject DB tapes every three days because of the problems explained below, I cannot use the wild card because I do not want to eject all of our DRM tapes.
 
PREDATAR Control23

Do you have I/O slots available? If so you could script it to run a eject script after the DB backup that was just made on a daily basis. Then they could sit in I/O slots until you send offsite.

Back to your original question you should see your DBB volumes when you go throught the DRM steps. Why your not I am not quite sure. I would contact IBM they can dig into your specific environment and come up with a solution. It seems to me TSM is seeing your dbb backups as being expired thats why its stomping back over them.

What command are you using to run DBB backups?
 
PREDATAR Control23

The command I use is:

move drmedia (tape number) wherest=mountable tost=vault rem=untileeful

Is this the wrong command to use?

Based on your DRM command, you are using a 3494 Library, correct?

Instead use this: move drmedia (tape number) wherest=mountable tost=vault rem=bulk

I would start off loading DB backups daily as a good practice. You will never know when you get hit by a disaster. I also hope you are sending to offsite all DR tapes daily - the copy pool tapes, that is.
 
PREDATAR Control23

I would start off loading DB backups daily as a good practice. You will never know when you get hit by a disaster. I also hope you are sending to offsite all DR tapes daily - the copy pool tapes, that is.


I totally agree. How is management or your business going to respond when you get hit by a disaster and the only data you can recover is a week old?
 
PREDATAR Control23

I thank you for your comments.

I understand that this is not best practice, but that was not my question. I will contact IBM for further support.
 
PREDATAR Control23

I thank you for your comments.

I understand that this is not best practice, but that was not my question. I will contact IBM for further support.

Going back to the issue of overwriting your DB tapes, have you defined a strict range of tapes that DB Backup can only use? In the past, we use to have only 7 tapes that we rotate but we eject daily.

But this is not the issue.

Do you run del volhist type=all? Daily or every two or three days? If you do, this is a no-no when using DRM.
 
PREDATAR Control23

Just moments before you posted, I discovered a very badly misnamed administrative script that is running this command:

delete volhistory todate=today-3 t=dbbackup

I assume, with fairly good reasoning, that this is undermining everything I am trying to accomplish.
 
PREDATAR Control23

Just moments before you posted, I discovered a very badly misnamed administrative script that is running this command:

delete volhistory todate=today-3 t=dbbackup

I assume, with fairly good reasoning, that this is undermining everything I am trying to accomplish.

Yeah! That will really throw off all that you wanted to do. Remove this script from your system!
 
PREDATAR Control23

I have a similar problem to yours. Can't keep track of our db tapes. Solution would be nice to hear about. If there was any..

Cheers!
 
Top