backup stgpool issue
I've got something strange going on here. If I run a backup storage pool command from my primary pool to one of my offsite copy pool everything is fine. It will finish whenever it is done. Same when I do a backup to my onsite copy pool. As long as let them finish everything is ok. However, if for some reason I do a cancel on the process things get interesting. I do the cancel on the process and wait for it to finish. I do some q proc's to check to see if it's finished yet. Once it finishes I then go back and start another backup stgpool. I get an error saying that a backup is already in progress. The q proc is coming back with nothing and I do a q mount just for the heck of it and it comes back with nothing mounted. It's like a hidden process that I have no control over and can't monitor. I end up having to halt and restart TSM to get control again. I'm running TSM 5.4.1 on a Windows 2003 box. Any ideas? David Tyree Interface Analyst South Georgia Medical Center 229.333.1155 Confidential Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
Re: backup stgpool issue
I suspect that some sort of timeout is involved. Storage pool backups use a lot of CPU, and a lot of db reads to generate a list of files that need to be backed up. I suspect that it may take some time to ditch that queued list of files before you can start another stg backup session involving the same pair of storage pools (primary and copy). -- Mark Stapleton ([EMAIL PROTECTED]) CDW Berbee System engineer 7145 Boone Avenue North, Suite 140 Brooklyn Park MN 55428-1511 763-592-5963 www.berbee.com -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Tyree, David Sent: Wednesday, November 12, 2008 11:26 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] backup stgpool issue I've got something strange going on here. If I run a backup storage pool command from my primary pool to one of my offsite copy pool everything is fine. It will finish whenever it is done. Same when I do a backup to my onsite copy pool. As long as let them finish everything is ok. However, if for some reason I do a cancel on the process things get interesting. I do the cancel on the process and wait for it to finish. I do some q proc's to check to see if it's finished yet. Once it finishes I then go back and start another backup stgpool. I get an error saying that a backup is already in progress. The q proc is coming back with nothing and I do a q mount just for the heck of it and it comes back with nothing mounted. It's like a hidden process that I have no control over and can't monitor. I end up having to halt and restart TSM to get control again. I'm running TSM 5.4.1 on a Windows 2003 box. Any ideas? David Tyree Interface Analyst South Georgia Medical Center 229.333.1155 Confidential Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
Re: backup stgpool issue
This is a known bug, fixed in 5.4.2 http://www-01.ibm.com/support/docview.wss?uid=swg1IC54096 Michael DeGasperis EDS - Centralized Backup and Restore MS 3-o 1075 West Entrance Drive Auburn Hills, MI 48326 ( Phone:+1-248-853-3726(8-365) + [EMAIL PROTECTED] pager: 248-272-0157 -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Mark Stapleton Sent: Wednesday, November 12, 2008 12:12 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] backup stgpool issue I suspect that some sort of timeout is involved. Storage pool backups use a lot of CPU, and a lot of db reads to generate a list of files that need to be backed up. I suspect that it may take some time to ditch that queued list of files before you can start another stg backup session involving the same pair of storage pools (primary and copy). -- Mark Stapleton ([EMAIL PROTECTED]) CDW Berbee System engineer 7145 Boone Avenue North, Suite 140 Brooklyn Park MN 55428-1511 763-592-5963 www.berbee.com -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Tyree, David Sent: Wednesday, November 12, 2008 11:26 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] backup stgpool issue I've got something strange going on here. If I run a backup storage pool command from my primary pool to one of my offsite copy pool everything is fine. It will finish whenever it is done. Same when I do a backup to my onsite copy pool. As long as let them finish everything is ok. However, if for some reason I do a cancel on the process things get interesting. I do the cancel on the process and wait for it to finish. I do some q proc's to check to see if it's finished yet. Once it finishes I then go back and start another backup stgpool. I get an error saying that a backup is already in progress. The q proc is coming back with nothing and I do a q mount just for the heck of it and it comes back with nothing mounted. It's like a hidden process that I have no control over and can't monitor. I end up having to halt and restart TSM to get control again. I'm running TSM 5.4.1 on a Windows 2003 box. Any ideas? David Tyree Interface Analyst South Georgia Medical Center 229.333.1155 Confidential Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
Re: Backup StgPool Issue Discovered
Paul,
That is a feature that we rely upon.
Our year-end close-out files go to a separate data path through our system.
Once I have the first copy from the server, I back up to Copypool for a
second copy, then pull both copies for offline storage. I flag both tapes
as unavailable and that exempts them from normal TSM reclamation, etc.
So three years from now, for example, I *still* know which tapes hold which
year-end files and their locations have not changed.
Tab Trepagnier
TSM Administrator
Laitram Corporation
Seay, Paul [EMAIL PROTECTED]@VM.MARIST.EDU on 03/19/2002 03:04:04
PM
Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED]
Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: Re: Backup StgPool Issue Discovered
The question I have: Does anyone consider this a problem or are you OK
with
it working like this?
-Original Message-
From: Remeta, Mark [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 19, 2002 10:33 AM
To: [EMAIL PROTECTED]
Subject: Re: Backup StgPool Issue Discovered
You could also do a
q vol * access=unavailable (or whatever you want to check).
-Original Message-
From: Seay, Paul [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 18, 2002 11:18 PM
To: [EMAIL PROTECTED]
Subject: Backup StgPool Issue Discovered
I found out today it appears that a BACKUP STGpool command will just skip
tapes that are in an UNAVAILABLE, DESTROYED, or DAMAGED status and put out
a
little warning message and give you a SUCCESS. DESTROYED is not a problem
because I took the overt action to say it was destroyed, but skipping
UNAVAILABLE or DAMAGED is not good. I would bet there are hundreds of
customers not aware of this. The exposure is your copypool (disaster
recovery set) may not include all of the data and not a valid restore
point.
Unfortunately, a tape can get in the UNAVAILABLE status just because the
tape library had a problem dismounting the tape.
I have developed a workaround:
select volume_name, access from volumes where access not in
('OFFSITE','READONLY','READWRITE','DESTROYED') and stgpool_name LIKE
'TAPE_%' ANR2034E SELECT: No match found using this criteria. ANS8001I
Return code 11.
This generates a return code 11 if everything is OK, zero is not good.
I am developing a script to do my backup commands and capture if there are
pools with errors.
Everyone may want to at least run this against your primary pools to see if
you have any. All my primary pools begin with TAPE_. Remember % is
splat
and _ is placeholder.
Paul D. Seay, Jr.
Technical Specialist
Naptheon, INC
757-688-8180
Confidentiality Note: The information transmitted is intended only for the
person or entity to whom or which it is addressed and may contain
confidential and/or privileged material. Any review, retransmission,
dissemination or other use of this information by persons or entities other
than the intended recipient is prohibited. If you receive this in error,
please delete this material immediately.
Re: Backup StgPool Issue Discovered
It would be better if perhaps in this case the Backup STGPOOL would end with
a RC=4, informing of a minor error.
We have error monitoring that tells us whenever a tape is unavailable,
damaged, or destroyed so we would catch this.
What other things are getting by though because Backup STGPOOL reports
success when there were problems??
-Original Message-
From: Seay, Paul [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 19, 2002 3:04 PM
To: [EMAIL PROTECTED]
Subject: Re: Backup StgPool Issue Discovered
The question I have: Does anyone consider this a problem or are you OK with
it working like this?
-Original Message-
From: Remeta, Mark [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 19, 2002 10:33 AM
To: [EMAIL PROTECTED]
Subject: Re: Backup StgPool Issue Discovered
You could also do a
q vol * access=unavailable (or whatever you want to check).
-Original Message-
From: Seay, Paul [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 18, 2002 11:18 PM
To: [EMAIL PROTECTED]
Subject: Backup StgPool Issue Discovered
I found out today it appears that a BACKUP STGpool command will just skip
tapes that are in an UNAVAILABLE, DESTROYED, or DAMAGED status and put out a
little warning message and give you a SUCCESS. DESTROYED is not a problem
because I took the overt action to say it was destroyed, but skipping
UNAVAILABLE or DAMAGED is not good. I would bet there are hundreds of
customers not aware of this. The exposure is your copypool (disaster
recovery set) may not include all of the data and not a valid restore point.
Unfortunately, a tape can get in the UNAVAILABLE status just because the
tape library had a problem dismounting the tape.
I have developed a workaround:
select volume_name, access from volumes where access not in
('OFFSITE','READONLY','READWRITE','DESTROYED') and stgpool_name LIKE
'TAPE_%' ANR2034E SELECT: No match found using this criteria. ANS8001I
Return code 11.
This generates a return code 11 if everything is OK, zero is not good.
I am developing a script to do my backup commands and capture if there are
pools with errors.
Everyone may want to at least run this against your primary pools to see if
you have any. All my primary pools begin with TAPE_. Remember % is splat
and _ is placeholder.
Paul D. Seay, Jr.
Technical Specialist
Naptheon, INC
757-688-8180
Confidentiality Note: The information transmitted is intended only for the
person or entity to whom or which it is addressed and may contain
confidential and/or privileged material. Any review, retransmission,
dissemination or other use of this information by persons or entities other
than the intended recipient is prohibited. If you receive this in error,
please delete this material immediately.
Re: Backup StgPool Issue Discovered
I would say it is a problem. If the backup can't get to some of the data then it is an error. - Kai Date:Tue, 19 Mar 2002 16:04:04 -0500 From:Seay, Paul [EMAIL PROTECTED] Subject: Re: Backup StgPool Issue Discovered The question I have: Does anyone consider this a problem or are you OK with it working like this? I found out today it appears that a BACKUP STGpool command will just skip tapes that are in an UNAVAILABLE, DESTROYED, or DAMAGED status and put out a little warning message and give you a SUCCESS. DESTROYED is not a problem because I took the overt action to say it was destroyed, but skipping UNAVAILABLE or DAMAGED is not good. I would bet there are hundreds of customers not aware of this. The exposure is your copypool (disaster recovery set) may not include all of the data and not a valid restore point. Unfortunately, a tape can get in the UNAVAILABLE status just because the tape library had a problem dismounting the tape.
Re: Backup StgPool Issue Discovered
Paul,
I'm pretty new to TSM and trying bl**d* hard to get a grip on it. We're
experiencing some trouble with TSM in a Windows 2000 environment - issues
we'll most likely have solved by the end of this week, probably earlier -
this is just to give you *some* background to my question.
When TSM does a space reclamation, I sometimes do see a FAILURE, while a q
ev * t=a tells me all ended as succesfull. Is this the problem you are
referring to?
Second, when I run the SQL-query you post, I get a list of 8 tapes. Is this
good or bad? One tape is DESTROYED - which it was, the others are READWRITE.
I guess you'll appreciate my little intro now you've read the 2nd
question...
Let me (and the rest of us) know what you think. Anyone else have some input
on this?
Kind regards,
Rick Harderwijk
Systems Administrator
Factotum Media BV
[EMAIL PROTECTED]
-Oorspronkelijk bericht-
Van: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]Namens Seay,
Paul
Verzonden: 19 maart 2002 5:18
Aan: [EMAIL PROTECTED]
Onderwerp: Backup StgPool Issue Discovered
I found out today it appears that a BACKUP STGpool command will just skip
tapes that are in an UNAVAILABLE, DESTROYED, or DAMAGED status and put out a
little warning message and give you a SUCCESS. DESTROYED is not a problem
because I took the overt action to say it was destroyed, but skipping
UNAVAILABLE or DAMAGED is not good. I would bet there are hundreds of
customers not aware of this. The exposure is your copypool (disaster
recovery set) may not include all of the data and not a valid restore point.
Unfortunately, a tape can get in the UNAVAILABLE status just because the
tape library had a problem dismounting the tape.
I have developed a workaround:
select volume_name, access from volumes where access not in
('OFFSITE','READONLY','READWRITE','DESTROYED') and stgpool_name LIKE
'TAPE_%'
ANR2034E SELECT: No match found using this criteria.
ANS8001I Return code 11.
This generates a return code 11 if everything is OK, zero is not good.
I am developing a script to do my backup commands and capture if there are
pools with errors.
Everyone may want to at least run this against your primary pools to see if
you have any. All my primary pools begin with TAPE_. Remember % is splat
and _ is placeholder.
Paul D. Seay, Jr.
Technical Specialist
Naptheon, INC
757-688-8180
Re: Backup StgPool Issue Discovered
You could also do a
q vol * access=unavailable (or whatever you want to check).
-Original Message-
From: Seay, Paul [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 18, 2002 11:18 PM
To: [EMAIL PROTECTED]
Subject: Backup StgPool Issue Discovered
I found out today it appears that a BACKUP STGpool command will just skip
tapes that are in an UNAVAILABLE, DESTROYED, or DAMAGED status and put out a
little warning message and give you a SUCCESS. DESTROYED is not a problem
because I took the overt action to say it was destroyed, but skipping
UNAVAILABLE or DAMAGED is not good. I would bet there are hundreds of
customers not aware of this. The exposure is your copypool (disaster
recovery set) may not include all of the data and not a valid restore point.
Unfortunately, a tape can get in the UNAVAILABLE status just because the
tape library had a problem dismounting the tape.
I have developed a workaround:
select volume_name, access from volumes where access not in
('OFFSITE','READONLY','READWRITE','DESTROYED') and stgpool_name LIKE
'TAPE_%'
ANR2034E SELECT: No match found using this criteria.
ANS8001I Return code 11.
This generates a return code 11 if everything is OK, zero is not good.
I am developing a script to do my backup commands and capture if there are
pools with errors.
Everyone may want to at least run this against your primary pools to see if
you have any. All my primary pools begin with TAPE_. Remember % is splat
and _ is placeholder.
Paul D. Seay, Jr.
Technical Specialist
Naptheon, INC
757-688-8180
Confidentiality Note: The information transmitted is intended only for the
person or entity to whom or which it is addressed and may contain
confidential and/or privileged material. Any review, retransmission,
dissemination or other use of this information by persons or entities other
than the intended recipient is prohibited. If you receive this in error,
please delete this material immediately.
Re: Backup StgPool Issue Discovered
I do a lot of checking due to various operator problems we have
had an some H/W problems. Even our operators check occasionally
for tapes in Unavailable state, so we generally catch this stuff
in a maximum of one day. If it was near time for offsite processing
in the morning, we couldn't fix it in time to gauarantee full copies
of offsite data anyhow.
I have seen a number of problems you can encounter with
tapes/libraries.
Just one of the thnigs we monitor daily, like if a drive fails.
David Longo
[EMAIL PROTECTED] 03/19/02 04:04PM
The question I have: Does anyone consider this a problem or are you OK with
it working like this?
-Original Message-
From: Remeta, Mark [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 19, 2002 10:33 AM
To: [EMAIL PROTECTED]
Subject: Re: Backup StgPool Issue Discovered
You could also do a
q vol * access=unavailable (or whatever you want to check).
-Original Message-
From: Seay, Paul [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 18, 2002 11:18 PM
To: [EMAIL PROTECTED]
Subject: Backup StgPool Issue Discovered
I found out today it appears that a BACKUP STGpool command will just skip
tapes that are in an UNAVAILABLE, DESTROYED, or DAMAGED status and put out a
little warning message and give you a SUCCESS. DESTROYED is not a problem
because I took the overt action to say it was destroyed, but skipping
UNAVAILABLE or DAMAGED is not good. I would bet there are hundreds of
customers not aware of this. The exposure is your copypool (disaster
recovery set) may not include all of the data and not a valid restore point.
Unfortunately, a tape can get in the UNAVAILABLE status just because the
tape library had a problem dismounting the tape.
I have developed a workaround:
select volume_name, access from volumes where access not in
('OFFSITE','READONLY','READWRITE','DESTROYED') and stgpool_name LIKE
'TAPE_%' ANR2034E SELECT: No match found using this criteria. ANS8001I
Return code 11.
This generates a return code 11 if everything is OK, zero is not good.
I am developing a script to do my backup commands and capture if there are
pools with errors.
Everyone may want to at least run this against your primary pools to see if
you have any. All my primary pools begin with TAPE_. Remember % is splat
and _ is placeholder.
Paul D. Seay, Jr.
Technical Specialist
Naptheon, INC
757-688-8180
Confidentiality Note: The information transmitted is intended only for the
person or entity to whom or which it is addressed and may contain
confidential and/or privileged material. Any review, retransmission,
dissemination or other use of this information by persons or entities other
than the intended recipient is prohibited. If you receive this in error,
please delete this material immediately.
MMS health-first.org made the following
annotations on 03/19/02 20:45:49
--
This message is for the named person's use only. It may contain confidential,
proprietary, or legally privileged information. No confidentiality or privilege is
waived or lost by any mistransmission. If you receive this message in error, please
immediately delete it and all copies of it from your system, destroy any hard copies
of it, and notify the sender. You must not, directly or indirectly, use, disclose,
distribute, print, or copy any part of this message if you are not the intended
recipient. Health First reserves the right to monitor all e-mail communications
through its networks. Any views or opinions expressed in this message are solely
those of the individual sender, except (1) where the message states such views or
opinions are on behalf of a particular entity; and (2) the sender is authorized by
the entity to give such views or opinions.
==
Backup StgPool Issue Discovered
I found out today it appears that a BACKUP STGpool command will just skip
tapes that are in an UNAVAILABLE, DESTROYED, or DAMAGED status and put out a
little warning message and give you a SUCCESS. DESTROYED is not a problem
because I took the overt action to say it was destroyed, but skipping
UNAVAILABLE or DAMAGED is not good. I would bet there are hundreds of
customers not aware of this. The exposure is your copypool (disaster
recovery set) may not include all of the data and not a valid restore point.
Unfortunately, a tape can get in the UNAVAILABLE status just because the
tape library had a problem dismounting the tape.
I have developed a workaround:
select volume_name, access from volumes where access not in
('OFFSITE','READONLY','READWRITE','DESTROYED') and stgpool_name LIKE
'TAPE_%'
ANR2034E SELECT: No match found using this criteria.
ANS8001I Return code 11.
This generates a return code 11 if everything is OK, zero is not good.
I am developing a script to do my backup commands and capture if there are
pools with errors.
Everyone may want to at least run this against your primary pools to see if
you have any. All my primary pools begin with TAPE_. Remember % is splat
and _ is placeholder.
Paul D. Seay, Jr.
Technical Specialist
Naptheon, INC
757-688-8180
