• Please help support our sponsors by considering their products and services.
    Our sponsors enable us to serve you with this high-speed Internet connection and fast webservers you are currently using at ADSM.ORG.
    They support this free flow of information and knowledge exchange service at no cost to you.

    Please welcome our latest sponsor Tectrade . We can show our appreciation by learning more about Tectrade Solutions
  • Community Tip: Please Give Thanks to Those Sharing Their Knowledge.

    If you receive helpful answer on this forum, please show thanks to the poster by clicking "LIKE" link for the answer that you found helpful.

  • Community Tip: Forum Rules (PLEASE CLICK HERE TO READ BEFORE POSTING)

    Click the link above to access ADSM.ORG Acceptable Use Policy and forum rules which should be observed when using this website. Violators may be banned from this website. This notice will disappear after you have made at least 3 posts.

DB Backup Overwrite / Retention

DHall

ADSM.ORG Member
#1
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.
 

moon-buddy

ADSM.ORG Moderator
#2
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.
 

djchopps0013

ADSM.ORG Senior Member
#3
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.
 

DHall

ADSM.ORG Member
#4
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.
 

DHall

ADSM.ORG Member
#5
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.
 

moon-buddy

ADSM.ORG Moderator
#6
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:

DHall

ADSM.ORG Member
#7
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?
 

moon-buddy

ADSM.ORG Moderator
#8
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.
 

djchopps0013

ADSM.ORG Senior Member
#9
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
 

DHall

ADSM.ORG Member
#12
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.
 

djchopps0013

ADSM.ORG Senior Member
#13
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?
 

moon-buddy

ADSM.ORG Moderator
#14
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.
 

djchopps0013

ADSM.ORG Senior Member
#15
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?
 

DHall

ADSM.ORG Member
#16
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.
 

moon-buddy

ADSM.ORG Moderator
#17
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.
 

DHall

ADSM.ORG Member
#18
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.
 

moon-buddy

ADSM.ORG Moderator
#19
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!
 
#20
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!
 

Advertise at ADSM.ORG

If you are reading this, so are your potential customer. Advertise at ADSM.ORG right now.

UpCloud high performance VPS at $5/month

Get started with $25 in credits on Cloud Servers. You must use link below to receive the credit. Use the promo to get upto 5 month of FREE Linux VPS.

The Spectrum Protect TLA (Three-Letter Acronym): ISP or something else?

  • Every product needs a TLA, Let's call it ISP (IBM Spectrum Protect).

    Votes: 8 23.5%
  • Keep using TSM for Spectrum Protect.

    Votes: 17 50.0%
  • Let's be formal and just say Spectrum Protect

    Votes: 5 14.7%
  • Other (please comement)

    Votes: 4 11.8%

Forum statistics

Threads
30,927
Messages
131,579
Members
21,207
Latest member
Nur03