Re: Rebuild a lost volhist for a dbrestore

2015-06-05 Thread Rick Adamson
Bill,
As per IBM docs you must have a copy of the volume history file to recover the 
server.  
But before I threw in the towel I would try to recreate it.

Do you have the disaster recovery file? 
If so, open it in notepad and search for VOLUME.HISTORY.FILE 
The information contained in that portion of the DR file on my version 7.1.1 
servers is an exact replica of my volume history file.

Next copy ALL of the volume information to a blank text file. 
Search the DR file for VOLHIST where you will find what to name the file and 
where to save it, alternatively that info can also be found in the server 
options file.
The volume history file format should look something like this: 

*
* 
* Sequential Volume Usage History
*   Updated 06/05/2015 06:46:19
* 
*
** 
 Operation Date/Time:   2015/06/05 06:29:12
 
 Volume Type:  BACKUPFULL
* Location for volume \\xxx.xxx.xxx.x\BACKUP\TSM\DB\500150.DBV is: ''
 Volume Name:  \\xxx.xxx.xxx.x\BACKUP\TSM\DB\500150.DBV
 Backup Series:2764
 Backup Op:   0
 Volume Seq:1001
  Device Class Name:  DD-TSMDB
** 
 Operation Date/Time:   2015/06/05 06:29:12
 
 Volume Type:  BACKUPFULL
* Location for volume \\ xxx.xxx.xxx.x \BACKUP\TSM\DB\500544.DBV is: ''
 Volume Name:  \\ xxx.xxx.xxx.x \BACKUP\TSM\DB\500544.DBV
 Backup Series:2764
 Backup Op:   0
 Volume Seq:1002
  Device Class Name:  DD-TSMDB
** 


Once you have that completed attempt a recovery following the documented 
process which can be found here:

http://www-01.ibm.com/support/knowledgecenter/SSGSG7_6.3.0/com.ibm.itsm.srv.ref.doc/r_cmd_dsmserv_restore_db_current.html
 

http://www-01.ibm.com/support/knowledgecenter/SS8TDQ_6.4.0/com.ibm.itsm.srv.doc/t_scen_srv_recover.html
 

Good luck !


-Rick Adamson
 


-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Bill 
Boyer
Sent: Friday, June 05, 2015 11:55 AM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Rebuild a lost volhist for a dbrestore

TSM V6.3 on Windows



The volhist file copies were all lost but the .DBS files are still around.
Is there a way to know the  backup Series: and Volume Seq: so I can fudge up a 
simple volhist with a single BACKUPFULL entry. Or doesn't that matter on a 
restore? Or is that information compared to what's in the .DBS file?



Really could use some help on this.



Bill


Rebuild a lost volhist for a dbrestore

2015-06-05 Thread Bill Boyer
TSM V6.3 on Windows



The volhist file copies were all lost but the .DBS files are still around.
Is there a way to know the  backup Series: and Volume Seq: so I can fudge up
a simple volhist with a single BACKUPFULL entry. Or doesn't that matter on a
restore? Or is that information compared to what's in the .DBS file?



Really could use some help on this.



Bill


Re: Moving nodes to a new policy

2015-06-05 Thread Rick Adamson
You could always use the COPY DOMAIN command to create the new domain, which 
would include all current policy sets, management classes, and copy groups. 
Then modify as needed.
May be easier than recreating the wheel ..

-Rick Adamson


-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Skylar 
Thompson
Sent: Friday, June 05, 2015 11:00 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Moving nodes to a new policy

I don't know that you have to restart the schedules after changing the node's 
policy domain, as long as you make sure to reset the schedule association.
Running QUERY ASSOCIATION when changing the domain is something I always 
remember to do the moment after hitting enter.

On Fri, Jun 05, 2015 at 02:52:48PM +, Thomas Denier wrote:
 This should work fine. There will be some additional complications if you use 
 the TSM central scheduler to trigger backups for the affected nodes.

 You will need to copy schedule definitions from the old policy domain to the 
 new one, unless the new one already has suitable schedule definitions.

 You will need to execute define association commands.

 You may need to restart the schedule services (Windows) or processes 
 (Linux/Unix) on the affected nodes. My best guess is that this will be 
 necessary if prompt mode scheduling is used and will not be necessary if 
 polling mode scheduling is used.

 Thomas Denier
 Thomas Jefferson University

 -Original Message-
 From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf 
 Of Paul_Dudley
 Sent: Thursday, June 04, 2015 8:33 PM
 To: ADSM-L@VM.MARIST.EDU
 Subject: [ADSM-L] Moving nodes to a new policy

 If I have nodes that are currently under a policy that keeps 5 backup 
 versions, can I move them to another policy which keeps only 2 backup 
 versions?

 Will TSM then start expiring all the older backup versions of files which are 
 no longer needed?

 We have two nodes which are taking up a lot of backup space in TSM and want 
 to reduce this.
 The information contained in this transmission contains privileged and 
 confidential information. It is intended only for the use of the person named 
 above. If you are not the intended recipient, you are hereby notified that 
 any review, dissemination, distribution or duplication of this communication 
 is strictly prohibited. If you are not the intended recipient, please contact 
 the sender by reply email and destroy all copies of the original message.

 CAUTION: Intended recipients should NOT use email communication for emergent 
 or urgent health care matters.

--
-- Skylar Thompson (skyl...@u.washington.edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine


Re: Moving nodes to a new policy

2015-06-05 Thread Thomas Denier
This should work fine. There will be some additional complications if you use 
the TSM central scheduler to trigger backups for the affected nodes.

You will need to copy schedule definitions from the old policy domain to the 
new one, unless the new one already has suitable schedule definitions.

You will need to execute define association commands.

You may need to restart the schedule services (Windows) or processes 
(Linux/Unix) on the affected nodes. My best guess is that this will be 
necessary if prompt mode scheduling is used and will not be necessary if 
polling mode scheduling is used.

Thomas Denier
Thomas Jefferson University

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of 
Paul_Dudley
Sent: Thursday, June 04, 2015 8:33 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Moving nodes to a new policy

If I have nodes that are currently under a policy that keeps 5 backup versions, 
can I move them to another policy which keeps only 2 backup versions?

Will TSM then start expiring all the older backup versions of files which are 
no longer needed?

We have two nodes which are taking up a lot of backup space in TSM and want to 
reduce this.
The information contained in this transmission contains privileged and 
confidential information. It is intended only for the use of the person named 
above. If you are not the intended recipient, you are hereby notified that any 
review, dissemination, distribution or duplication of this communication is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender by reply email and destroy all copies of the original message.

CAUTION: Intended recipients should NOT use email communication for emergent or 
urgent health care matters.


Re: Moving nodes to a new policy

2015-06-05 Thread Skylar Thompson
I don't know that you have to restart the schedules after changing the
node's policy domain, as long as you make sure to reset the schedule 
association.
Running QUERY ASSOCIATION when changing the domain is something I always
remember to do the moment after hitting enter.

On Fri, Jun 05, 2015 at 02:52:48PM +, Thomas Denier wrote:
 This should work fine. There will be some additional complications if you use 
 the TSM central scheduler to trigger backups for the affected nodes.

 You will need to copy schedule definitions from the old policy domain to the 
 new one, unless the new one already has suitable schedule definitions.

 You will need to execute define association commands.

 You may need to restart the schedule services (Windows) or processes 
 (Linux/Unix) on the affected nodes. My best guess is that this will be 
 necessary if prompt mode scheduling is used and will not be necessary if 
 polling mode scheduling is used.

 Thomas Denier
 Thomas Jefferson University

 -Original Message-
 From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of 
 Paul_Dudley
 Sent: Thursday, June 04, 2015 8:33 PM
 To: ADSM-L@VM.MARIST.EDU
 Subject: [ADSM-L] Moving nodes to a new policy

 If I have nodes that are currently under a policy that keeps 5 backup 
 versions, can I move them to another policy which keeps only 2 backup 
 versions?

 Will TSM then start expiring all the older backup versions of files which are 
 no longer needed?

 We have two nodes which are taking up a lot of backup space in TSM and want 
 to reduce this.
 The information contained in this transmission contains privileged and 
 confidential information. It is intended only for the use of the person named 
 above. If you are not the intended recipient, you are hereby notified that 
 any review, dissemination, distribution or duplication of this communication 
 is strictly prohibited. If you are not the intended recipient, please contact 
 the sender by reply email and destroy all copies of the original message.

 CAUTION: Intended recipients should NOT use email communication for emergent 
 or urgent health care matters.

--
-- Skylar Thompson (skyl...@u.washington.edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine