Re: To Collate or Not to Collate? - UPDATE
select distinct(volume_name) from volumeusage where node_name='YOUR-NODENAME-GOES-HERE' David E Ehresman [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] 01/15/03 12:40 PM Please respond to ADSM: Dist Stor Manager To: [EMAIL PROTECTED] cc: Subject:Re: To Collate or Not to Collate? - UPDATE Since then I've been able to put an SQL query together to get that info but it takes quite a while to execute. Can you share that code with us? David
Re: To Collate or Not to Collate? - UPDATE
We only back up 26 servers (NT, OS/2, Solaris, Linux, Mac) with one 3494 library and two 3590 drives. If we had collocation on our Copypool, it would mean sending 26 tapes off-site every morning, even if most of them had under a gig of data on them. All these tapes would then need to be reclaimed (we set the reclamation threshold to 60%) keeping our two poor tape drives permamnently busy. And, as we have a five day retention on our pending volumes, this means a potential 100 odd tapes floating about that we could be using. We do collocate our Tapepool though to speed up restore times. Also, we don't have the five day pending problem with the on-site tapes. Farren - John Wiley sons Please respond to ADSM: Dist Stor Manager [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: Re: To Collate or Not to Collate? - UPDATE It depends on the size of your library too. We don't Collocate and we had a Disaster Recovery test and it was successful. We had time on our hand too with the 36 hours time limits David C. Pearson IS Production Support Analyst System Network Service Snohomish County PUD # 1 -Original Message- From: Theresa Sarver [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 12:25 PM To: [EMAIL PROTECTED] Subject: Re: To Collate or Not to Collate? - UPDATE Yikes! Okay, point(s) taken...Copypool set back to collate @ node level! Thanks again; Theresa [EMAIL PROTECTED] 01/15/03 02:18PM Hi, I fully agree. Specially after the experience of restoring one single destroyed tape in primary pool that implied mounting 85 copy tapes!! René LAMBELET NESTEC SA GLOBE - Global Business Excellence Central Support Center Information Technology Av. Nestlé 55 CH-1800 Vevey (Switzerland) tél +41 (0)21 924 35 43 fax +41 (0)21 703 30 17 local UBS-Nestec, Bussigny mailto:[EMAIL PROTECTED] This message is intended only for the use of the addressee and may contain information that is privileged and confidential. -Original Message- From: Cook, Dwight E [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 8:05 PM To: [EMAIL PROTECTED] Subject: Re: To Collate or Not to Collate? - UPDATE Allen makes a critical implied statement of YOU MUST TEST YOUR RECOVERY PLAN ! If not and you have to use it and it doesn't go smooth... Personally, I classify myself as probably being at the lowest place on the earth... and even if something were to initially miss me, it would undoubtedly/eventually settle on top of me! ! ! So... you request the test and state its requirement as to ensure functionality. If management says no, make sure and put together a few things on what ~might~ go wrong like potentially 36 hours of nothing but tape mounts dismounts to restore just a single server (if like in Allen's case where 800 tapes were required) Then make sure and save all the e-mails (print out and lock in a fireproof safe) so you can mount a defense later ;-) Dwight -Original Message- From: Allen Barth [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 12:31 PM To: [EMAIL PROTECTED] Subject: Re: To Collate or Not to Collate? - UPDATE Glad you found it! However, regarding the collocation=no issue on copypools Having done TSM DR recoveries at an offsite location a few times, let me share my experiences. When I started with TSM I had one copypool with colloc=no. We then did our first DR recovery test where my goal was to recover the TSM server and ONE other AIX client. The base os (AIX) was to restored via sysback, user filesystems via TSM. Originally this required the ENTIRE copypool (800+ tapes back then) to be sent from the vault to the DR location as TSM provides no command to see which vols would be needed for a client node restore (hint, hint, IBM). Since then I've been able to put an SQL query together to get that info but it takes quite a while to execute. This trims down the number of tapes, but the number of tapes was still quite large(100 +). Furthermore, the number of tape mount requests during the restore was astronomical, as tapes were requested multiple times. After re-thinking TSM and DR needs, I now have a separated stgpool tree for unix data. Collocation is enabled for both primary and copypools. At the last DR test, the number of tapes needed from the vault was further reduced to around 40, and the restore process took significantly less time. Let's not forget to factor in the time required for physical tape processing (mount delay, seek time, rewind, unload). This can add up to significant wall time. Regards, Al
Re: To Collate or Not to Collate? - UPDATE
As embarassed as I am to admit thisI must confess that collation turned out NOT to
be the problem (with all my scratch tapes disappearing) afterall. Instead, it would
appear that I inadvertantly (or carelessly - whichever you prefer) deactiveated my
'Delete Volhist Admin Schedule' back in August 2002. After I deleted all the outdated
volhist I went from 66 scratch to 285 scratch tapes. Ahhh...to be yet again humbled
by life
But thanks to everyone for their responses I wouldn't have known to check/set
Collation=NO on the copy storage pool (as it was set to YES) if it wasn't for you all.
So thanks again;
Theresa
[EMAIL PROTECTED] 01/13/03 04:53PM
How many tapes do you have in the tapepool?
Select count(*) from volumes where stgpool_name='TAPEPOOL'
How many drives do you have?
How many mounts are you getting during a stgpool backup?
Do you have maxpr specified on the stgpool backup?
What is the device class mount retention?
Are you using a maximum scratch number for tapepool or are you using private
volumes?
Send a:
q stg tapepool f=d
q devclass [device class] f=d
q stg copypool f=d
Also, run this select to see if you have a lot of private volumes in the
library but not owned by any storage pool. This happens when a tape is not
labeled.
select volume_name from libvolumes where status='Private' and
libvolumes.volume_name not in (select volume_name from volumes) and
libvolumes.volume_name not in (select volume_name from volhistory where type
in ('BACKUPFULL', 'BACKUPINCR', 'DBSNAPSHOT', 'EXPORT'))
With this information I may be able to help show that the collocation is
maybe not the total culprit.
Paul D. Seay, Jr.
Technical Specialist
Naptheon Inc.
757-688-8180
-Original Message-
From: Theresa Sarver [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 13, 2003 4:06 PM
To: [EMAIL PROTECTED]
Subject: To Collate or Not to Collate?
Hi All;
Environment:
SP Complex (7 wide nodes) running AIX 433 ML10
TSM 415
IBM 3494 (2-3590E drives)
When this was setup a couple years ago, they chose to enable collation, I
understand why - however, scratch tapes are now at a premium. I would like
to know if I disabled collation if that would help to free up some
tapes...and can it be disabled on the fly? Or is my only solution to start
trimming backups?
Also, our tapepool to copypool backup is now running over 24 hours. Has
anyone else out there run into this problem before? And if so - how did you
get around it? Oh, and I'll save you the time...Management refuses to buy
another drive. - Time to get creative!
Thank you for your assistance;
Theresa
Re: To Collate or Not to Collate? - UPDATE
Glad you found it!
However, regarding the collocation=no issue on copypools
Having done TSM DR recoveries at an offsite location a few times, let me
share my experiences. When I started with TSM I had one copypool with
colloc=no. We then did our first DR recovery test where my goal was to
recover the TSM server and ONE other AIX client. The base os (AIX) was to
restored via sysback, user filesystems via TSM. Originally this required
the ENTIRE copypool (800+ tapes back then) to be sent from the vault to
the DR location as TSM provides no command to see which vols would be
needed for a client node restore (hint, hint, IBM). Since then I've been
able to put an SQL query together to get that info but it takes quite a
while to execute. This trims down the number of tapes, but the number of
tapes was still quite large(100 +). Furthermore, the number of tape mount
requests during the restore was astronomical, as tapes were requested
multiple times. After re-thinking TSM and DR needs, I now have a
separated stgpool tree for unix data. Collocation is enabled for both
primary and copypools. At the last DR test, the number of tapes needed
from the vault was further reduced to around 40, and the restore process
took significantly less time. Let's not forget to factor in the time
required for physical tape processing (mount delay, seek time, rewind,
unload). This can add up to significant wall time.
Regards,
Al
Theresa Sarver [EMAIL PROTECTED]
Sent by: ADSM: Dist Stor Manager [EMAIL PROTECTED]
01/15/03 08:15 AM
Please respond to ADSM: Dist Stor Manager
To: [EMAIL PROTECTED]
cc:
Subject:Re: To Collate or Not to Collate? - UPDATE
As embarassed as I am to admit thisI must confess that collation
turned out NOT to be the problem (with all my scratch tapes disappearing)
afterall. Instead, it would appear that I inadvertantly (or carelessly -
whichever you prefer) deactiveated my 'Delete Volhist Admin Schedule' back
in August 2002. After I deleted all the outdated volhist I went from 66
scratch to 285 scratch tapes. Ahhh...to be yet again humbled by life
But thanks to everyone for their responses I wouldn't have known to
check/set Collation=NO on the copy storage pool (as it was set to YES) if
it wasn't for you all.
So thanks again;
Theresa
[EMAIL PROTECTED] 01/13/03 04:53PM
How many tapes do you have in the tapepool?
Select count(*) from volumes where stgpool_name='TAPEPOOL'
How many drives do you have?
How many mounts are you getting during a stgpool backup?
Do you have maxpr specified on the stgpool backup?
What is the device class mount retention?
Are you using a maximum scratch number for tapepool or are you using
private
volumes?
Send a:
q stg tapepool f=d
q devclass [device class] f=d
q stg copypool f=d
Also, run this select to see if you have a lot of private volumes in the
library but not owned by any storage pool. This happens when a tape is
not
labeled.
select volume_name from libvolumes where status='Private' and
libvolumes.volume_name not in (select volume_name from volumes) and
libvolumes.volume_name not in (select volume_name from volhistory where
type
in ('BACKUPFULL', 'BACKUPINCR', 'DBSNAPSHOT', 'EXPORT'))
With this information I may be able to help show that the collocation is
maybe not the total culprit.
Paul D. Seay, Jr.
Technical Specialist
Naptheon Inc.
757-688-8180
-Original Message-
From: Theresa Sarver [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 13, 2003 4:06 PM
To: [EMAIL PROTECTED]
Subject: To Collate or Not to Collate?
Hi All;
Environment:
SP Complex (7 wide nodes) running AIX 433 ML10
TSM 415
IBM 3494 (2-3590E drives)
When this was setup a couple years ago, they chose to enable collation, I
understand why - however, scratch tapes are now at a premium. I would
like
to know if I disabled collation if that would help to free up some
tapes...and can it be disabled on the fly? Or is my only solution to
start
trimming backups?
Also, our tapepool to copypool backup is now running over 24 hours. Has
anyone else out there run into this problem before? And if so - how did
you
get around it? Oh, and I'll save you the time...Management refuses to buy
another drive. - Time to get creative!
Thank you for your assistance;
Theresa
Re: To Collate or Not to Collate? - UPDATE
Since then I've been able to put an SQL query together to get that info but it takes quite a while to execute. Can you share that code with us? David
Re: To Collate or Not to Collate? - UPDATE
Allen makes a critical implied statement of YOU MUST TEST YOUR RECOVERY PLAN ! If not and you have to use it and it doesn't go smooth... Personally, I classify myself as probably being at the lowest place on the earth... and even if something were to initially miss me, it would undoubtedly/eventually settle on top of me! ! ! So... you request the test and state its requirement as to ensure functionality. If management says no, make sure and put together a few things on what ~might~ go wrong like potentially 36 hours of nothing but tape mounts dismounts to restore just a single server (if like in Allen's case where 800 tapes were required) Then make sure and save all the e-mails (print out and lock in a fireproof safe) so you can mount a defense later ;-) Dwight -Original Message- From: Allen Barth [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 12:31 PM To: [EMAIL PROTECTED] Subject: Re: To Collate or Not to Collate? - UPDATE Glad you found it! However, regarding the collocation=no issue on copypools Having done TSM DR recoveries at an offsite location a few times, let me share my experiences. When I started with TSM I had one copypool with colloc=no. We then did our first DR recovery test where my goal was to recover the TSM server and ONE other AIX client. The base os (AIX) was to restored via sysback, user filesystems via TSM. Originally this required the ENTIRE copypool (800+ tapes back then) to be sent from the vault to the DR location as TSM provides no command to see which vols would be needed for a client node restore (hint, hint, IBM). Since then I've been able to put an SQL query together to get that info but it takes quite a while to execute. This trims down the number of tapes, but the number of tapes was still quite large(100 +). Furthermore, the number of tape mount requests during the restore was astronomical, as tapes were requested multiple times. After re-thinking TSM and DR needs, I now have a separated stgpool tree for unix data. Collocation is enabled for both primary and copypools. At the last DR test, the number of tapes needed from the vault was further reduced to around 40, and the restore process took significantly less time. Let's not forget to factor in the time required for physical tape processing (mount delay, seek time, rewind, unload). This can add up to significant wall time. Regards, Al
Re: To Collate or Not to Collate? - UPDATE
Hello David. I use this script to get a list of tapes. It is not perfect because it gets tapes with inactive files as well as active files but it is fairly quick. Usually under 5 minutes or so which is not too bad considering how much data it has to wade through! Usage: RUN BRSLIST SERVERNAME STGPOOLNAME i.e. 'Run brslist FS010 COPYVAULT' - Server and stgpool must be UPPER CASE. Name Line Command Number -- -- BRSLIST1 select volume_name,status from volumes where volume_name in (select volume_name from volumeusage where node_name='$1'and stgpool_name='$2') order by status,volume_name Take care, Al Alan Davenport Senior Storage Administrator Selective Insurance Co. of America [EMAIL PROTECTED] (973) 948-1306 -Original Message- From: David E Ehresman [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 1:41 PM To: [EMAIL PROTECTED] Subject: Re: To Collate or Not to Collate? - UPDATE Since then I've been able to put an SQL query together to get that info but it takes quite a while to execute. Can you share that code with us? David
Re: To Collate or Not to Collate? - UPDATE
Hi, I fully agree. Specially after the experience of restoring one single destroyed tape in primary pool that implied mounting 85 copy tapes!! René LAMBELET NESTEC SA GLOBE - Global Business Excellence Central Support Center Information Technology Av. Nestlé 55 CH-1800 Vevey (Switzerland) tél +41 (0)21 924 35 43 fax +41 (0)21 703 30 17 local UBS-Nestec, Bussigny mailto:[EMAIL PROTECTED] This message is intended only for the use of the addressee and may contain information that is privileged and confidential. -Original Message- From: Cook, Dwight E [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 8:05 PM To: [EMAIL PROTECTED] Subject: Re: To Collate or Not to Collate? - UPDATE Allen makes a critical implied statement of YOU MUST TEST YOUR RECOVERY PLAN ! If not and you have to use it and it doesn't go smooth... Personally, I classify myself as probably being at the lowest place on the earth... and even if something were to initially miss me, it would undoubtedly/eventually settle on top of me! ! ! So... you request the test and state its requirement as to ensure functionality. If management says no, make sure and put together a few things on what ~might~ go wrong like potentially 36 hours of nothing but tape mounts dismounts to restore just a single server (if like in Allen's case where 800 tapes were required) Then make sure and save all the e-mails (print out and lock in a fireproof safe) so you can mount a defense later ;-) Dwight -Original Message- From: Allen Barth [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 12:31 PM To: [EMAIL PROTECTED] Subject: Re: To Collate or Not to Collate? - UPDATE Glad you found it! However, regarding the collocation=no issue on copypools Having done TSM DR recoveries at an offsite location a few times, let me share my experiences. When I started with TSM I had one copypool with colloc=no. We then did our first DR recovery test where my goal was to recover the TSM server and ONE other AIX client. The base os (AIX) was to restored via sysback, user filesystems via TSM. Originally this required the ENTIRE copypool (800+ tapes back then) to be sent from the vault to the DR location as TSM provides no command to see which vols would be needed for a client node restore (hint, hint, IBM). Since then I've been able to put an SQL query together to get that info but it takes quite a while to execute. This trims down the number of tapes, but the number of tapes was still quite large(100 +). Furthermore, the number of tape mount requests during the restore was astronomical, as tapes were requested multiple times. After re-thinking TSM and DR needs, I now have a separated stgpool tree for unix data. Collocation is enabled for both primary and copypools. At the last DR test, the number of tapes needed from the vault was further reduced to around 40, and the restore process took significantly less time. Let's not forget to factor in the time required for physical tape processing (mount delay, seek time, rewind, unload). This can add up to significant wall time. Regards, Al
Re: To Collate or Not to Collate? - UPDATE
Yikes! Okay, point(s) taken...Copypool set back to collate @ node level! Thanks again; Theresa [EMAIL PROTECTED] 01/15/03 02:18PM Hi, I fully agree. Specially after the experience of restoring one single destroyed tape in primary pool that implied mounting 85 copy tapes!! René LAMBELET NESTEC SA GLOBE - Global Business Excellence Central Support Center Information Technology Av. Nestlé 55 CH-1800 Vevey (Switzerland) tél +41 (0)21 924 35 43 fax +41 (0)21 703 30 17 local UBS-Nestec, Bussigny mailto:[EMAIL PROTECTED] This message is intended only for the use of the addressee and may contain information that is privileged and confidential. -Original Message- From: Cook, Dwight E [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 8:05 PM To: [EMAIL PROTECTED] Subject: Re: To Collate or Not to Collate? - UPDATE Allen makes a critical implied statement of YOU MUST TEST YOUR RECOVERY PLAN ! If not and you have to use it and it doesn't go smooth... Personally, I classify myself as probably being at the lowest place on the earth... and even if something were to initially miss me, it would undoubtedly/eventually settle on top of me! ! ! So... you request the test and state its requirement as to ensure functionality. If management says no, make sure and put together a few things on what ~might~ go wrong like potentially 36 hours of nothing but tape mounts dismounts to restore just a single server (if like in Allen's case where 800 tapes were required) Then make sure and save all the e-mails (print out and lock in a fireproof safe) so you can mount a defense later ;-) Dwight -Original Message- From: Allen Barth [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 12:31 PM To: [EMAIL PROTECTED] Subject: Re: To Collate or Not to Collate? - UPDATE Glad you found it! However, regarding the collocation=no issue on copypools Having done TSM DR recoveries at an offsite location a few times, let me share my experiences. When I started with TSM I had one copypool with colloc=no. We then did our first DR recovery test where my goal was to recover the TSM server and ONE other AIX client. The base os (AIX) was to restored via sysback, user filesystems via TSM. Originally this required the ENTIRE copypool (800+ tapes back then) to be sent from the vault to the DR location as TSM provides no command to see which vols would be needed for a client node restore (hint, hint, IBM). Since then I've been able to put an SQL query together to get that info but it takes quite a while to execute. This trims down the number of tapes, but the number of tapes was still quite large(100 +). Furthermore, the number of tape mount requests during the restore was astronomical, as tapes were requested multiple times. After re-thinking TSM and DR needs, I now have a separated stgpool tree for unix data. Collocation is enabled for both primary and copypools. At the last DR test, the number of tapes needed from the vault was further reduced to around 40, and the restore process took significantly less time. Let's not forget to factor in the time required for physical tape processing (mount delay, seek time, rewind, unload). This can add up to significant wall time. Regards, Al
Re: To Collate or Not to Collate? - UPDATE
It depends on the size of your library too. We don't Collocate and we had a Disaster Recovery test and it was successful. We had time on our hand too with the 36 hours time limits David C. Pearson IS Production Support Analyst System Network Service Snohomish County PUD # 1 -Original Message- From: Theresa Sarver [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 12:25 PM To: [EMAIL PROTECTED] Subject:Re: To Collate or Not to Collate? - UPDATE Yikes! Okay, point(s) taken...Copypool set back to collate @ node level! Thanks again; Theresa [EMAIL PROTECTED] 01/15/03 02:18PM Hi, I fully agree. Specially after the experience of restoring one single destroyed tape in primary pool that implied mounting 85 copy tapes!! René LAMBELET NESTEC SA GLOBE - Global Business Excellence Central Support Center Information Technology Av. Nestlé 55 CH-1800 Vevey (Switzerland) tél +41 (0)21 924 35 43 fax +41 (0)21 703 30 17 local UBS-Nestec, Bussigny mailto:[EMAIL PROTECTED] This message is intended only for the use of the addressee and may contain information that is privileged and confidential. -Original Message- From: Cook, Dwight E [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 8:05 PM To: [EMAIL PROTECTED] Subject: Re: To Collate or Not to Collate? - UPDATE Allen makes a critical implied statement of YOU MUST TEST YOUR RECOVERY PLAN ! If not and you have to use it and it doesn't go smooth... Personally, I classify myself as probably being at the lowest place on the earth... and even if something were to initially miss me, it would undoubtedly/eventually settle on top of me! ! ! So... you request the test and state its requirement as to ensure functionality. If management says no, make sure and put together a few things on what ~might~ go wrong like potentially 36 hours of nothing but tape mounts dismounts to restore just a single server (if like in Allen's case where 800 tapes were required) Then make sure and save all the e-mails (print out and lock in a fireproof safe) so you can mount a defense later ;-) Dwight -Original Message- From: Allen Barth [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 12:31 PM To: [EMAIL PROTECTED] Subject: Re: To Collate or Not to Collate? - UPDATE Glad you found it! However, regarding the collocation=no issue on copypools Having done TSM DR recoveries at an offsite location a few times, let me share my experiences. When I started with TSM I had one copypool with colloc=no. We then did our first DR recovery test where my goal was to recover the TSM server and ONE other AIX client. The base os (AIX) was to restored via sysback, user filesystems via TSM. Originally this required the ENTIRE copypool (800+ tapes back then) to be sent from the vault to the DR location as TSM provides no command to see which vols would be needed for a client node restore (hint, hint, IBM). Since then I've been able to put an SQL query together to get that info but it takes quite a while to execute. This trims down the number of tapes, but the number of tapes was still quite large(100 +). Furthermore, the number of tape mount requests during the restore was astronomical, as tapes were requested multiple times. After re-thinking TSM and DR needs, I now have a separated stgpool tree for unix data. Collocation is enabled for both primary and copypools. At the last DR test, the number of tapes needed from the vault was further reduced to around 40, and the restore process took significantly less time. Let's not forget to factor in the time required for physical tape processing (mount delay, seek time, rewind, unload). This can add up to significant wall time. Regards, Al
Re: To Collate or Not to Collate? - UPDATE
Or, dump the ATL, go manual drives, and take management along on the test - to be your Picker Arm. They'll pay for what you need really fast! Another option to collocation of your offsite pool (you can send a tape offsite each day with 1 file on it if you're not careful) is to use multiple primary pools and multiple copypools. I've got an installation that supports a number of large Oracle databases. They have their own copypool (it's collocated by node), and the filesystem data goes to a different copypool (not collocated, but doing periodic full backups/archives). That works well at DR for us. Nick Cassimatis Today is the tomorrow of yesterday.
