Question about restoring a tsm db.

2014-03-12 Thread Plair, Ricky
Yesterday my TSM server crashed and lost the db.

Our TSM DB is approx. 1.5 TB on a windows system. I started a TSM DB RESTORE 
last night around midnight and it's still running this morning.

Is there any way to know how long it will run or follow the progress other than 
the scrolling console?

Ricky M. Plair
Storage Engineer
HealthPlan Services
Office: 813 289 1000 Ext 2273
Mobile: 757 232 7258


_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
CONFIDENTIALITY NOTICE: If you have received this email in error, please 
immediately notify the sender by e-mail at the address shown.This email 
transmission may contain confidential information.This information is intended 
only for the use of the individual(s) or entity to whom it is intended even if 
addressed incorrectly. Please delete it from your files if you are not the 
intended recipient. Thank you for your compliance.


Re: Backup Offsite

2014-03-12 Thread Prather, Wanda
There is a 3rd -party product called Autovault that will manage the vaulting of 
a primary pool.
(very well supported product,  by the way)

OTOH, best practice requires you still have a 2nd copy of the data.
Vaulted tapes can get lost, get eaten by a drive, etc...

W

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of 
Grigori Solonovitch
Sent: Tuesday, March 11, 2014 6:05 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Backup Offsite

No way for real tapes. You can use Data Domain VTL replication for primary 
pools, by the way.

Grigori Solonovitch, Senior Systems Architect, IT, Ahli United Bank Kuwait, 
www.ahliunited.com.kw

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Kiran
Sent: 11 03 2014 12:29 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Backup Offsite

Hi All, Is there a way to make the backup tapes offsite without copy pool tapes 
 in TSM



My daily backup window is around 1TB. So making copypool with the exisitng tape 
library is not possible.











Disclaimer: http://www.dqentertainment.com/e-mail_disclaimer.html



Please consider the environment before printing this Email.



CONFIDENTIALITY AND WAIVER: The information contained in this electronic mail 
message and any attachments hereto may be legally privileged and confidential. 
The information is intended only for the recipient(s) named in this message. If 
you are not the intended recipient you are notified that any use, disclosure, 
copying or distribution is prohibited. If you have received this in error 
please contact the sender and delete this message and any attachments from your 
computer system. We do not guarantee that this message or any attachment to it 
is secure or free from errors, computer viruses or other conditions that may 
damage or interfere with data, hardware or software.


Re: Recovering Linux TSM server from partial filesystem failure

2014-03-12 Thread Zoltan Forray
Thanks for the suggestion.  As SOP, we update all firmware, every few
months, so this box is up-to-date.

The Dell diagnostics finally finished, CLEAN.  No issues found.

I have some of the FODC logs when the first error occurred (was moving them
to another filespace as fast as I could when the disk was filling up to
100% due to DB2 dumps).  Don't know if there is enough info to show what
happened.

At this point it is going to be a wipe and rebuild.


On Tue, Mar 11, 2014 at 4:15 PM, Skylar Thompson
wrote:

> Since you mentioned Dell, one thing to check would be PERC and hard drive
> firmware levels. There have been a number of updates to both over the past
> few years concerning silent data corruption under a variety of conditions.
>
> On Tue, Mar 11, 2014 at 03:07:24PM -0400, Zoltan Forray wrote:
> > Thanks for finding that but, as you said, it doesn't help much.  The disk
> > filled to 100% due to DB2 taking dumps but that doesn't tell me what
> caused
> > the dumping in the first place.
> >
> > We are still running Dell full diagnostics (started yesterday afternoon
> and
> > was at 78% as of 2pm EDT).  My OS guy is watching the pot boil and will
> > report back once it finishes.  Then it that is clean, he will wipe it and
> > reinstall RH 6, since it doesn't look like what is left (/TSMDB, /TSMLOG,
> > /TSMARCHLOG) will be of any value without the root filesystem.
>
> --
> -- Skylar Thompson (skyl...@u.washington.edu)
> -- Genome Sciences Department, System Administrator
> -- Foege Building S046, (206)-685-7354
> -- University of Washington School of Medicine
>



--
*Zoltan Forray*
TSM Software & Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zfor...@vcu.edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://infosecurity.vcu.edu/phishing.html


Re: Backup Offsite

2014-03-12 Thread Zoltan Forray
TSMManager has a vaulting management option to select "Primary pools to
vault".  Go to http://www.tsmmanager.com. From my sig, I do not work for
them (other than as a beta tester).  Just a satisfied customer.


On Wed, Mar 12, 2014 at 8:56 AM, Prather, Wanda wrote:

> There is a 3rd -party product called Autovault that will manage the
> vaulting of a primary pool.
> (very well supported product,  by the way)
>
> OTOH, best practice requires you still have a 2nd copy of the data.
> Vaulted tapes can get lost, get eaten by a drive, etc...
>
> W
>
> -Original Message-
> From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
> Grigori Solonovitch
> Sent: Tuesday, March 11, 2014 6:05 AM
> To: ADSM-L@VM.MARIST.EDU
> Subject: Re: [ADSM-L] Backup Offsite
>
> No way for real tapes. You can use Data Domain VTL replication for primary
> pools, by the way.
>
> Grigori Solonovitch, Senior Systems Architect, IT, Ahli United Bank
> Kuwait, www.ahliunited.com.kw
>
> -Original Message-
> From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
> Kiran
> Sent: 11 03 2014 12:29 PM
> To: ADSM-L@VM.MARIST.EDU
> Subject: [ADSM-L] Backup Offsite
>
> Hi All, Is there a way to make the backup tapes offsite without copy pool
> tapes  in TSM
>
>
>
> My daily backup window is around 1TB. So making copypool with the exisitng
> tape library is not possible.
>
>
>
>
>
>
>
>
>
>
>
> Disclaimer: http://www.dqentertainment.com/e-mail_disclaimer.html
>
>
>
> Please consider the environment before printing this Email.
>
> 
>
> CONFIDENTIALITY AND WAIVER: The information contained in this electronic
> mail message and any attachments hereto may be legally privileged and
> confidential. The information is intended only for the recipient(s) named
> in this message. If you are not the intended recipient you are notified
> that any use, disclosure, copying or distribution is prohibited. If you
> have received this in error please contact the sender and delete this
> message and any attachments from your computer system. We do not guarantee
> that this message or any attachment to it is secure or free from errors,
> computer viruses or other conditions that may damage or interfere with
> data, hardware or software.
>



--
*Zoltan Forray*
TSM Software & Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zfor...@vcu.edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://infosecurity.vcu.edu/phishing.html


Re: Tape Drive compatibility

2014-03-12 Thread Neil Strand
George,
   Sounds like you found yourself in a bowl of spaghetti with just a spoon
to eat your way out.
   Some general recommendations:
1. Check all of your tapes for different generations of media.  There may
be a mix of JA, JB and JC media.
2. Assuming that you have both onsite and offsite tape pools, you may want
to create two virtual libraries using ALMS and designate one for onsite
use and the other for offsite os some other easy to manage scheme to
differentiate their use.
3. Thinking ahead to manage & growth, you will need to divide the media
and assign a volser range to assign to each library.  If you do have
different generation of media(JA,JB,JC), then it is relatively simple to
assign one generation to each virtual library but if all media is say, JB
media, then you will need to specify volser ranges for each library and
when you get a new set of media in the current sequence, you will need to
assign new volser ranges for each virtual library - not difficult just
another thing to manage.

Cheers,
Neil Strand



From:   George Huebschman 
To: ADSM-L@VM.MARIST.EDU,
Date:   03/11/2014 01:56 PM
Subject:[ADSM-L] Tape Drive compatibility
Sent by:"ADSM: Dist Stor Manager" 



My question is:
Is there a way to determine what tapes in a 3584 library have been written
to by E05 or E06 3592 tape drives?

Because:
I have a library with two generations of drives.

I discovered this morning that my DR Tape Library had no scratch tapes.  I
expected around 200.
I found that I had 167 libvolumes that were marked "Private" with no last
use.
I checked and found that they were not in volhistory, so I updated them to
scratch status.

Then I wanted to know why.
I found a drive offline, with an online path.  I offlined the path until I
could determine why the drive was offline.
I queried the actlog for a plethora of error messages over the last day. I
wondered if I would see a lot of attempts to use the path to the drive
that was offline, but I didn't.
I saw a number of "ANR8779E Unable to open drive" errors matched with
"ANR8381E 3592 volume Volser01 could not be mounted in drive 3592_x", for
a different drive, just one.  TSM used that one drive and eventually tried
all the scratch media and marked them private.
I tried again forcing TSM to use different E05 drives with the same
result.  ( I think all my scratch media is now formatted for E06.)

I WAS able to run a DB backup to an E06 tape drive by taking all of the
E06 tape paths offline.

When the newer tape drives were  installed, it was believed that they
would be compatible with the earlier drives. (before my time here)
But, while they can read tapes written by E05, the E05 can not read or
write to tapes written by an E06 drive.

I could just turn off the two E06 tape drives, I will still have six E05
drives.  But that leaves me with two problems that I see.
 - Tapes written to by E06 will be unusable.
 - Any tapes brought from Production (Export tapes, DB tapes, Data) would
be unreadable, because Prod is only using E06 tape drives. (Because we had
this same problem there.)   (Of course, I can always put the E06 Path back
online as needed.)


George Huebschman (George H.)



The contents of this email are the property of PNC. If it was not
addressed to you, you have no legal right to read it. If you think you
received it in error, please notify the sender. Do not forward or copy
without permission of the sender. This message may contain an
advertisement of a product or service and thus may constitute a commercial
electronic mail message under US Law. The postal address for PNC is 249
Fifth Avenue, Pittsburgh, PA 15222. If you do not wish to receive any
additional advertising or promotional messages from PNC at this e-mail
address, click here to unsubscribe.
https://pnc.p.delivery.net/m/u/pnc/uni/p.asp
By unsubscribing to this message, you will be unsubscribed from all
advertising or promotional messages from PNC. Removing your e-mail address
from this mailing list will not affect your subscription to alerts,
e-newsletters or account servicing e-mails.


Re: Tape Drive compatibility

2014-03-12 Thread George Huebschman
Cheers back to you Neil!

 - They are all JA volumes.  I have to wait for them to fail to ID them.
 -  There are copypools so a second virtual library is a good option.
 -  I was able to determine that all of the scratch made private were
formatted for E06 drives.  I took the E06 drives/paths offline and the
tapes were all umountable.  The volser label could not be read.
 I was able to make them usable by labeling them back in using only
E05 drives.
Since then I found 1,432 "ANR8447E .No drives are currently available in
library" in the actlog.  Normally that would make my mouth dry, but I know
that I DO have paths to drives available.  I expect that the errors are
symptoms of TSM trying to mount E06 media with no E06 drives, so it is a
reassuring symptom.  I can look up the media involved and either do a
restore volume or move data.   I would need to use an E06 drive for the
move data and possibly (pretty likely) for the restore volume operations.

- My favored solution would be to upgrade the drives to all the same type,
but I am not writing the check and neither is our customer.

I like the idea of utilizing the two E06 drives for another reason beyond
just using full capacity.
 We are correcting an issue with replication of SVC volumes over
Global Mirror.  It is billed as asynchronous, but ...it isn't.
When daily changes were a quarter of what they are now it caused
detectable but trivial slowness in Prod applications.  Now it is a serious
problem.
The cure requires restructuring replication...and reshipping ALL of the
production data.  It's going to take ten days more or less.
That is ten days without a recovery pointwell, without one that meets
the SLA
Management demands on the one hand that service interruptions and delays
to the customer end, but they are unwilling to accept such a serious gap
in DR capability  So, the problem gets worse.
(To me) Export media seems to be a way to mitigate that recovery gap.
Daily exports are not elegant, they are a poor plug in the gap, but the
alternative is no plug in the gap.  Export media don't need to be in the
destination TSM DB, which makes it unnecessary to restore a Prod db
_backup to the DR TSM server.  The idea is not popular though.

The catch is that Prod is using E06.  However, it has unused E05 drives.
Partitioning the libraries looks ever better.

Thanks Neil and Norman
George Huebschman (George H.)



The contents of this email are the property of PNC. If it was not addressed to 
you, you have no legal right to read it. If you think you received it in error, 
please notify the sender. Do not forward or copy without permission of the 
sender. This message may contain an advertisement of a product or service and 
thus may constitute a commercial electronic mail message under US Law. The 
postal address for PNC is 249 Fifth Avenue, Pittsburgh, PA 15222. If you do not 
wish to receive any additional advertising or promotional messages from PNC at 
this e-mail address, click here to unsubscribe. 
https://pnc.p.delivery.net/m/u/pnc/uni/p.asp
By unsubscribing to this message, you will be unsubscribed from all advertising 
or promotional messages from PNC. Removing your e-mail address from this 
mailing list will not affect your subscription to alerts, e-newsletters or 
account servicing e-mails.


Re: Tape Drive compatibility

2014-03-12 Thread Nick Marouf
Hi George,
 I've had mixed drives in a library from before. What I've had to do
set the devc format to the lesser drive format. I know this does not
utilize the features of the new drives. But administratively when you
no choice, it is much easier than splitting the library.

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/index.jsp?topic=%2Fcom.ibm.itsm.srv.doc%2Ft_devclass_define_ulw.html

Best of Luck,
-Nick


On Wed, Mar 12, 2014 at 2:46 PM, George Huebschman
 wrote:
> Cheers back to you Neil!
>
>  - They are all JA volumes.  I have to wait for them to fail to ID them.
>  -  There are copypools so a second virtual library is a good option.
>  -  I was able to determine that all of the scratch made private were
> formatted for E06 drives.  I took the E06 drives/paths offline and the
> tapes were all umountable.  The volser label could not be read.
>  I was able to make them usable by labeling them back in using only
> E05 drives.
> Since then I found 1,432 "ANR8447E .No drives are currently available in
> library" in the actlog.  Normally that would make my mouth dry, but I know
> that I DO have paths to drives available.  I expect that the errors are
> symptoms of TSM trying to mount E06 media with no E06 drives, so it is a
> reassuring symptom.  I can look up the media involved and either do a
> restore volume or move data.   I would need to use an E06 drive for the
> move data and possibly (pretty likely) for the restore volume operations.
>
> - My favored solution would be to upgrade the drives to all the same type,
> but I am not writing the check and neither is our customer.
>
> I like the idea of utilizing the two E06 drives for another reason beyond
> just using full capacity.
>  We are correcting an issue with replication of SVC volumes over
> Global Mirror.  It is billed as asynchronous, but ...it isn't.
> When daily changes were a quarter of what they are now it caused
> detectable but trivial slowness in Prod applications.  Now it is a serious
> problem.
> The cure requires restructuring replication...and reshipping ALL of the
> production data.  It's going to take ten days more or less.
> That is ten days without a recovery pointwell, without one that meets
> the SLA
> Management demands on the one hand that service interruptions and delays
> to the customer end, but they are unwilling to accept such a serious gap
> in DR capability  So, the problem gets worse.
> (To me) Export media seems to be a way to mitigate that recovery gap.
> Daily exports are not elegant, they are a poor plug in the gap, but the
> alternative is no plug in the gap.  Export media don't need to be in the
> destination TSM DB, which makes it unnecessary to restore a Prod db
> _backup to the DR TSM server.  The idea is not popular though.
>
> The catch is that Prod is using E06.  However, it has unused E05 drives.
> Partitioning the libraries looks ever better.
>
> Thanks Neil and Norman
> George Huebschman (George H.)
>
>
>
> The contents of this email are the property of PNC. If it was not addressed 
> to you, you have no legal right to read it. If you think you received it in 
> error, please notify the sender. Do not forward or copy without permission of 
> the sender. This message may contain an advertisement of a product or service 
> and thus may constitute a commercial electronic mail message under US Law. 
> The postal address for PNC is 249 Fifth Avenue, Pittsburgh, PA 15222. If you 
> do not wish to receive any additional advertising or promotional messages 
> from PNC at this e-mail address, click here to unsubscribe. 
> https://pnc.p.delivery.net/m/u/pnc/uni/p.asp
> By unsubscribing to this message, you will be unsubscribed from all 
> advertising or promotional messages from PNC. Removing your e-mail address 
> from this mailing list will not affect your subscription to alerts, 
> e-newsletters or account servicing e-mails.


Delete Volhist

2014-03-12 Thread Maness, Eric
If I wanting to keep two weeks of database backups I'm a little confused on how 
to run the delete volhist command.  Usually I would run the following command:

delete volhist type=dbb todate=today-14

With running only type=dbb I'm noticing a lot of volumes that no longer exist 
in the volhist file, so I wanted to ask this forum if I would run into any 
issues running the following command instead:

delete volhist type=all todate=today-14

Regards,
Eric


Re: Delete Volhist

2014-03-12 Thread Jeanne Bruno
Hello.  We include parms: force and devc



DELETE VOLHISTORY type=dbb todate=today-7 force=yes devc=xxxclass



-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of 
Maness, Eric
Sent: Wednesday, March 12, 2014 5:06 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Delete Volhist



If I wanting to keep two weeks of database backups I'm a little confused on how 
to run the delete volhist command.  Usually I would run the following command:



delete volhist type=dbb todate=today-14



With running only type=dbb I'm noticing a lot of volumes that no longer exist 
in the volhist file, so I wanted to ask this forum if I would run into any 
issues running the following command instead:



delete volhist type=all todate=today-14



Regards,

Eric


Re: Delete Volhist

2014-03-12 Thread Jeanne Bruno
Also...
on source server do:
RECONCILE VOLUMES xxxCLASS  (where xxxCLASS is the device classthis will 
tell you if any volumes are invalid)

Output Example:  Volume TSMNBG.DSS.372056474 not valid, source server missing 
corresponding entry for
 target server. 

RECONCILE VOLUMES xxxCLASS  fix=yes  (to mark the invalid files for deletion)


-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of 
Maness, Eric
Sent: Wednesday, March 12, 2014 5:06 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Delete Volhist

If I wanting to keep two weeks of database backups I'm a little confused on how 
to run the delete volhist command.  Usually I would run the following command:

delete volhist type=dbb todate=today-14

With running only type=dbb I'm noticing a lot of volumes that no longer exist 
in the volhist file, so I wanted to ask this forum if I would run into any 
issues running the following command instead:

delete volhist type=all todate=today-14

Regards,
Eric


Re: Tape Drive compatibility

2014-03-12 Thread George Huebschman
Nick, the catch here is that  I already have media in Generation 3
format..
After setting the Gen 3 drives to write in Gen 2 density, they are also
restricted to reading at Gen2.  I would still have to remediate the Gen3
media.

Hi George,
 I've had mixed drives in a library from before. What I've had to do
set the devc format to the lesser drive format. I know this does not
utilize the features of the new drives. But administratively when you
no choice, it is much easier than splitting the library.

http://publib.boulder.ibm.com/infocenter/tsminfo/v6/index.jsp?topic=%2Fcom.ibm.itsm.srv.doc%2Ft_devclass_define_ulw.html


Best of Luck,
-Nick

George Huebschman (George H.)
(301) 699-4013
(301) 875-1227 (Cell)



The contents of this email are the property of PNC. If it was not addressed to 
you, you have no legal right to read it. If you think you received it in error, 
please notify the sender. Do not forward or copy without permission of the 
sender. This message may contain an advertisement of a product or service and 
thus may constitute a commercial electronic mail message under US Law. The 
postal address for PNC is 249 Fifth Avenue, Pittsburgh, PA 15222. If you do not 
wish to receive any additional advertising or promotional messages from PNC at 
this e-mail address, click here to unsubscribe. 
https://pnc.p.delivery.net/m/u/pnc/uni/p.asp
By unsubscribing to this message, you will be unsubscribed from all advertising 
or promotional messages from PNC. Removing your e-mail address from this 
mailing list will not affect your subscription to alerts, e-newsletters or 
account servicing e-mails.


Re: Delete Volhist

2014-03-12 Thread Remco Post
Op 12 mrt. 2014, om 22:05 heeft Maness, Eric  het 
volgende geschreven:

> If I wanting to keep two weeks of database backups I'm a little confused on 
> how to run the delete volhist command.  Usually I would run the following 
> command:
> 
> delete volhist type=dbb todate=today-14
> 
> With running only type=dbb I'm noticing a lot of volumes that no longer exist 
> in the volhist file, so I wanted to ask this forum if I would run into any 
> issues running the following command instead:
> 
> delete volhist type=all todate=today-14
> 

yes, that's safe to do. It will not delete volhist for volumes either assigned 
to a pool, or used by a library sharing client (if applicable). Do not, under 
any circumstances, ever include force=yes in a scripted del volhist, force=yes 
is an option that should only be used if you have verified 10 times that this 
is indeed what you want. No matter what anyone else does, force=yes is rarely 
needed and should not be used routinely.

I usually do something like

del volhist t=ddb todate=-5
del volhist t=all todate=-30

but I rarely use the longer retention of the 'other' volhist info. But do clean 
it up once in a while...

> Regards,
> Eric

-- 

 Met vriendelijke groeten/Kind Regards,

Remco Post
r.p...@plcs.nl
+31 6 248 21 622