Re: Export node to new server

[Grant Street]

Do you have any information on doing "server-to-server export"? Is there
a TSM name for it?

Thanks
Grant

On 24/08/12 09:31, Prather, Wanda wrote:

Better if you do that in reverse order, unless the clients are trivial in size.
If you let the client scheduled backup run, it will do a full, which for many 
clients can be painful.

If you get the export done first, all the existing data will be represented in 
the new server DB, and the client's scheduled backup to the new server will be 
incremental.

If there is a time lag between the time you do the first export and the time 
you get the clients dsm.opt file pointing to the new server, you can do an 
incremental export to catch up - add the FROMDATE=today-blah fromtime=xx:yy:zz 
to the EXPORT command.

Also IMHO it's easier to do what you suggest using server-to-server export than 
using media.  Then it's just one step.

Wanda

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of 
Vandeventer, Harold [BS]
Sent: Thursday, August 23, 2012 4:19 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Export node to new server

My goal is to relocate all backup data  for a node currently on a TSM 5.5.2 
server to a TSM 6.2.4 server.

There are no archive or space managed data in the system.

First time I've had to try this, so looking to the experts for comment.

Looks like a fairly simple process:
Define the node on the target server with appropriate schedules, policy, etc.
Have the node manager modify the DSM.OPT file to specify the new server.
Let scheduled backups run.

On source TSM: EXPORT NODE   FILEDATA=BACKUP DEVCLASS=

On target TSM: IMPORT NODE  FILEDATA=BACKUP DEVCLASS=  
DATES=ABSOLUTE MERGEFILESPACES=YES VOL=

An important parameter MERGEFILESPACES=YES to bring in the old data into the 
identical filespaces.



Harold Vandeventer
Systems Programmer
State of Kansas - Office of Information Technology Services 
harold.vandeven...@ks.gov
(785) 296-0631


[Confidentiality notice:]
***
This e-mail message, including attachments, if any, is intended for the person 
or entity to which it is addressed and may contain confidential or privileged 
information.  Any unauthorized review, use, or disclosure is prohibited.  If 
you are not the intended recipient, please contact the sender and destroy the 
original message, including all copies, Thank you.
***

Re: Export node to new server

[Prather, Wanda]

Better if you do that in reverse order, unless the clients are trivial in size.
If you let the client scheduled backup run, it will do a full, which for many 
clients can be painful.

If you get the export done first, all the existing data will be represented in 
the new server DB, and the client's scheduled backup to the new server will be 
incremental.

If there is a time lag between the time you do the first export and the time 
you get the clients dsm.opt file pointing to the new server, you can do an 
incremental export to catch up - add the FROMDATE=today-blah fromtime=xx:yy:zz 
to the EXPORT command.

Also IMHO it's easier to do what you suggest using server-to-server export than 
using media.  Then it's just one step.

Wanda

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of 
Vandeventer, Harold [BS]
Sent: Thursday, August 23, 2012 4:19 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Export node to new server

My goal is to relocate all backup data  for a node currently on a TSM 5.5.2 
server to a TSM 6.2.4 server.

There are no archive or space managed data in the system.

First time I've had to try this, so looking to the experts for comment.

Looks like a fairly simple process:
Define the node on the target server with appropriate schedules, policy, etc.
Have the node manager modify the DSM.OPT file to specify the new server.
Let scheduled backups run.

On source TSM: EXPORT NODE   FILEDATA=BACKUP DEVCLASS=

On target TSM: IMPORT NODE  FILEDATA=BACKUP DEVCLASS= 
DATES=ABSOLUTE MERGEFILESPACES=YES VOL=

An important parameter MERGEFILESPACES=YES to bring in the old data into the 
identical filespaces.



Harold Vandeventer
Systems Programmer
State of Kansas - Office of Information Technology Services 
harold.vandeven...@ks.gov
(785) 296-0631


[Confidentiality notice:]
***
This e-mail message, including attachments, if any, is intended for the person 
or entity to which it is addressed and may contain confidential or privileged 
information.  Any unauthorized review, use, or disclosure is prohibited.  If 
you are not the intended recipient, please contact the sender and destroy the 
original message, including all copies, Thank you.
***

NetApp for Primary Disk Pool

[Mayhew, James]

Hello All,

We are considering using a NetApp V6210 with some attached shelves as a block 
storage TSM primary disk pool. Do any of you have any experience using NetApp 
storage as a TSM primary disk pool? If so, how was your experience with this 
solution? Did you have any performance issues? How was it with sequential 
workloads? Any insight that you all can provide is greatly appreciated.

Best Regards,

James Mayhew
Storage Engineer
HealthPlan Services
E-mail: jmay...@healthplan.com


_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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.

Export node to new server

[Vandeventer, Harold [BS]]

My goal is to relocate all backup data  for a node currently on a TSM 5.5.2 
server to a TSM 6.2.4 server.

There are no archive or space managed data in the system.

First time I've had to try this, so looking to the experts for comment.

Looks like a fairly simple process:
Define the node on the target server with appropriate schedules, policy, etc.
Have the node manager modify the DSM.OPT file to specify the new server.
Let scheduled backups run.

On source TSM: EXPORT NODE   FILEDATA=BACKUP DEVCLASS=

On target TSM: IMPORT NODE  FILEDATA=BACKUP DEVCLASS= 
DATES=ABSOLUTE MERGEFILESPACES=YES VOL=

An important parameter MERGEFILESPACES=YES to bring in the old data into the 
identical filespaces.



Harold Vandeventer
Systems Programmer
State of Kansas - Office of Information Technology Services
harold.vandeven...@ks.gov
(785) 296-0631


[Confidentiality notice:]
***
This e-mail message, including attachments, if any, is intended for the
person or entity to which it is addressed and may contain confidential
or privileged information.  Any unauthorized review, use, or disclosure
is prohibited.  If you are not the intended recipient, please contact
the sender and destroy the original message, including all copies,
Thank you.
***

NAS Restore failure, any thoughts?

[Moyer, Joni M]

Hi Everyone,

I have a TSM 5.5.5.0 AIX 5.3 server doing NAS NDMP backups/restores.  I got the 
following message.  Has anyone seen this before or know what it means?  It's 
kind of cryptic.  Thanks in advance!

Joni

08/23/12 14:01:28 ANRD_3279216401 ssRtrvRemote(ssremote.c:1811)
   Thread<175705>: Invalid offset 755.1600443456 for image
   restore(SESSION: 55984, PROCESS: 23348)
08/23/12 14:01:28 ANRD Thread<175705> issued message  from:
   (SESSION: 55984, PROCESS: 23348)
08/23/12 14:01:28 ANRD Thread<175705>  0001c7e8 StdPutText
   (SESSION: 55984, PROCESS: 23348)
08/23/12 14:01:28 ANRD Thread<175705>  0001fb90 OutDiagToCons
   (SESSION: 55984, PROCESS: 23348)
08/23/12 14:01:28 ANRD Thread<175705>  0001a2d0 outDiagfExt
   (SESSION: 55984, PROCESS: 23348)
08/23/12 14:01:28 ANRD Thread<175705>  0001004f8ab8 ssRtrvRemote
   (SESSION: 55984, PROCESS: 23348)
08/23/12 14:01:28 ANRD Thread<175705>  0001007f9838 AfRtrvRemoteThr-
   ead  (SESSION: 55984, PROCESS: 23348)
08/23/12 14:01:28 ANRD Thread<175705>  00010001509c StartThread
   (SESSION: 55984, PROCESS: 23348)
08/23/12 14:01:28 ANR1078E NAS Restore process 23348 terminated - internal
   server error detected. (SESSION: 55984, PROCESS: 23348)
08/23/12 14:01:28 ANRD Thread<175705> issued message 1078 from:
   (SESSION: 55984, PROCESS: 23348)
08/23/12 14:01:28 ANRD Thread<175705>  0001e138 StdPutMsg
   (SESSION: 55984, PROCESS: 23348)
08/23/12 14:01:28 ANRD Thread<175705>  000100013cd8 outRptf
   (SESSION: 55984, PROCESS: 23348)
08/23/12 14:01:28 ANRD Thread<175705>  0001007f81e4 EndRemoteProc
   (SESSION: 55984, PROCESS: 23348)
08/23/12 14:01:28 ANRD Thread<175705>  0001007f98f0 AfRtrvRemoteThr-
   ead  (SESSION: 55984, PROCESS: 23348)
08/23/12 14:01:28 ANRD Thread<175705>  00010001509c StartThread
   (SESSION: 55984, PROCESS: 23348)
08/23/12 14:01:28 ANR0988I Process 23348 for RESTORE NAS (SELECTIVE) running
   in the BACKGROUND processed 65,536 bytes with a
   completion state of FAILURE at 14:01:28. (SESSION: 55984,
   PROCESS: 23348)




This e-mail and any attachments to it are confidential and are intended solely 
for use of the individual or entity to whom they are addressed. If you have 
received this e-mail in error, please notify the sender immediately and then 
delete it. If you are not the intended recipient, you must not keep, use, 
disclose, copy or distribute this e-mail without the author's prior permission. 
The views expressed in this e-mail message do not necessarily represent the 
views of Highmark Inc., its subsidiaries, or affiliates.

Re: SQL TDP 6.3 question (red X)

[Stackwick, Stephen]

Thanks, Del. That will make the customer happy, they don't like seeing the 
little red x.

Steve

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Del 
Hoobler
Sent: Wednesday, August 22, 2012 2:56 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] SQL TDP 6.3 question (red X)

Steve,

You don't need to run VSS backups, but you need to configure for it in order to 
make the little red x to go away.

Thanks,

Del



"ADSM: Dist Stor Manager"  wrote on 08/22/2012
10:26:53 AM:

> From: "Stackwick, Stephen" 
> To: ADSM-L@vm.marist.edu
> Date: 08/22/2012 10:51 AM
> Subject: SQL TDP 6.3 question (red X)
> Sent by: "ADSM: Dist Stor Manager" 
>
> It looks to me like, out of the box, the configuration wizard for the 
> 6.3 SQL TDP expects and seems to require VSS. For instance, it 
> populates the VSS agent with the name of the BA client node and won't 
> accept a blank (i.e., no entry).
>
> Well, no matter. I can always configure the TDP manually to do legacy 
> backups through configuration file editing. But now, when I run the DP 
> for SQL management console, my SQL server has a small red "X" over it 
> under the "Protect and Recover" menu. Backups and restores seem to 
> work OK, but it *is* a bit unnerving and I've had client questions 
> about it. Any answer?
>
> Steve

Re: database backup and dr plans

[Rick Adamson]

I too would be interested in some additional details on how you are using the 
sleeping approach.


Thanks!

~Rick


-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Robert 
Ouzen
Sent: Wednesday, August 22, 2012 9:10 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] database backup and dr plans

Hi Chadvar

I am now thinking of a solution like this ... Replication from primary site to 
secondary site with Tsm replication 6.3.X.

Replicate just critical nodes and in step one only active data.

I will be please if you can elaborate (maybe a paper) of what are you doing.

You can send it explanation to my personal e-mail rou...@univ.haifa.ac.il

T.I.A Regards

Robert Ouzen

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of 
Chavdar Cholev
Sent: Thursday, August 23, 2012 3:03 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] database backup and dr plans

Hi Tim,
just ot add something to Erwann's note ...
consider using "sleeping" instance of TSM from site 1 at site 2 ...
I am using such solution and it works ...

Regards
Chadvar


On Wed, Aug 22, 2012 at 6:59 PM, Erwann Simon  wrote:
> Hi Tim,
>
> You should look at virtual volumes feature in order to backup the DB and the 
> DR Plan file to a target server.
>
> Note that there is no way to do multiple DB backups on a one tape.
>
> Regards,
> Erwann
>
> - Mail original -
> De: "Tim Brown" 
> À: ADSM-L@VM.MARIST.EDU
> Envoyé: Mercredi 22 Août 2012 15:56:49
> Objet: [ADSM-L] database backup and dr plans
>
> We currently have a 2 site TSM system, primary with secondary replicated.
>
> The primary has disk storage pools first drop, primary storage second drop
>
> as device type file and lto copy storage pools. We backup the database also
>
> to a file device type. The replicated site just has primary storage as device
>
> type file but without a copy storage pool.
>
>
>
> Is there a way to backup the primary TSM DB  directly to the recovery server.
>
>
>
> Is there a way to have the plan files sent to the other server , I attempted 
> via mapped
>
> drives but since the TSM service uses local system it could not write to the 
> mapped location.
>
> I know I can do it using  a batch file outside of TSM.
>
>
>
> Can TSM stack multiple TSM backups on one LTO tape or is it one tape per 
> backup.
>
>
>
>
>
> Thanks,
>
>
>
> Tim Brown
> Supervisor Computer Operations
>
> Central Hudson Gas & Electric
> 284 South Ave
> Poughkeepsie, NY 12601
> Email:   tbr...@cenhud.com << 
>  mailto:tbr...@cenhud.com>>
> Phone: 845-486-5643
> Fax: 845-486-5921
> Cell: 845-235-4255
>
>
>
>
> "This message contains confidential information and is only for the intended 
> recipient. If the reader of this message is not the intended recipient, or an 
> employee or agent responsible for delivering this message to the intended 
> recipient, please notify the sender immediately by replying to this note and 
> deleting all copies and attachments."

Re: database backup and dr plans

[Tim Brown]

I had tried that prior and couldn’t get it working, I revisited it and now it 
is.
Thanks to java, Juan Valdez version.

But when the process is running it states

PROCESS_NUM: 1093
PROCESS: Database Backup
 START_TIME: 2012-08-23 07:17:08.00
FILES_PROCESSED: 7016
BYTES_PROCESSED: 29305165541
 STATUS: TYPE=FULL in progress. Bytes backed up: 4,209 MB. Current
  output volume(s): TSMNBG.DBV.345721035.

and the files get stored in the target server as .bfs


Is this normal, how could one recover from these if needed.

Volume Name   Storage  Device  EstimatedPct   Volume
  Pool NameClass Name   Capacity   Util   Status
  ---  --  -  -  
D:\DBBACKUP\TSMPOK\-  POKDBNBGCLASS2.0 G  100.0Full
 09E6.BFS
D:\DBBACKUP\TSMPOK\-  POKDBNBGCLASS2.0 G  100.0Full
 09E7.BFS
D:\DBBACKUP\TSMPOK\-  POKDBNBGCLASS2.0 G  100.0Full
 09E8.BFS
D:\DBBACKUP\TSMPOK\-  POKDBNBGCLASS2.0 G   17.4  Filling

A q content shows TSMNBG.DBV.345721035 in 09e7.bfs

tsm: TSMNBG_SERVER1>q content 09e7.bfs

Node NameType  Filespace   FSID  Client's Name for File
   Name
---    --    --
TSMPOK   Arch  ADSM.SERV- 1  ADSM/TSMNBG.DBV.345720835DBV.OBJ.1
ER
TSMPOK   Arch  ADSM.SERV- 1  ADSM/TSMNBG.DBV.345720883DBV.OBJ.1
ER
TSMPOK   Arch  ADSM.SERV- 1  ADSM/TSMNBG.DBV.345720931DBV.OBJ.1
ER
TSMPOK   Arch  ADSM.SERV- 1  ADSM/TSMNBG.DBV.345720981DBV.OBJ.1
ER
TSMPOK   Arch  ADSM.SERV- 1  ADSM/TSMNBG.DBV.345721035DBV.OBJ.1
ER

Thanks,

Tim
-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Erwann 
Simon
Sent: Wednesday, 22 August, 2012 12:00 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: database backup and dr plans

Hi Tim,

You should look at virtual volumes feature in order to backup the DB and the DR 
Plan file to a target server.

Note that there is no way to do multiple DB backups on a one tape.

Regards,
Erwann

- Mail original -
De: "Tim Brown" 
À: ADSM-L@VM.MARIST.EDU
Envoyé: Mercredi 22 Août 2012 15:56:49
Objet: [ADSM-L] database backup and dr plans

We currently have a 2 site TSM system, primary with secondary replicated.

The primary has disk storage pools first drop, primary storage second drop

as device type file and lto copy storage pools. We backup the database also

to a file device type. The replicated site just has primary storage as device

type file but without a copy storage pool.



Is there a way to backup the primary TSM DB  directly to the recovery server.



Is there a way to have the plan files sent to the other server , I attempted 
via mapped

drives but since the TSM service uses local system it could not write to the 
mapped location.

I know I can do it using  a batch file outside of TSM.



Can TSM stack multiple TSM backups on one LTO tape or is it one tape per backup.





Thanks,



Tim Brown
Supervisor Computer Operations

Central Hudson Gas & Electric
284 South Ave
Poughkeepsie, NY 12601
Email:   tbr...@cenhud.com << 
 mailto:tbr...@cenhud.com>>
Phone: 845-486-5643
Fax: 845-486-5921
Cell: 845-235-4255




"This message contains confidential information and is only for the intended 
recipient. If the reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to the intended 
recipient, please notify the sender immediately by replying to this note and 
deleting all copies and attachments."

Re: Do you perform Windows SYSTEMSTATE backups?

[Rick Harderwijk]

Hi,

I am confused. We had this long discussion on backing up system state, and
that for some it was working well, while others strongly forbid it. We also
concluded that the system state backup for W2k8R2 is very large.

Just going over the client logs on a w2k8r2 machine (running client
5.5.3.3), and I noticed a backup in the weekend was only 600Mb. Not much
changed on the server, but still, I would expect several GBs for the system
state backup.

To be sure, I checked another w2k8r2 machine, and the same behaviour there.

What's happened to the large system states?

Cheers,

Rick




On Fri, Jul 27, 2012 at 4:13 AM, Prather, Wanda wrote:

> There is a known problem with TSM 5.5 servers backing up Win2K8
> systemstate from 6.2.0+ clients.  (5.5 servers with 5.5 clients don't have
> the problem; V6 servers with 5.5 clients don't have the problem.  )
>
> Starting at 6.2.0, the backup client tries by default to do a "true
> incremental" of systemstate, which means it has to keep track of which
> pieces of the system state get changed and link them together in case you
> do a systemstate restore.
>
> The resulting pointers are complex enough that it pretty much gets the 5.5
> server tangled in its underwear, and a simple systemstate backup can bring
> the server to its knees if it's heavily used.  (First symptom we saw, was
> that the Win2K8 clients that had been upgraded from 5.5 to 6.2 would take
> hours to back up systemstate if the server was busy doing backup stgpool or
> something else that required heavy use of the DB.)
>
> Two solutions:
>
> a) move the client to a V6 server, poof the problem goes away
>
> b) there is a new option (not in the manual) called
> systemstatebackupmethod; if you set SYSTEMSTATEBACKUPMETHOD FULL, the
> systemstate backup is done like it used to be in the 5.5 client (not as a
> "true incremental") and you won't have the problem, you'll just have the
> huge Win2K8 systemstate backup as usual.
>
> Here's the info:
>
> http://www-01.ibm.com/support/docview.wss?uid=swg21470662&myns=swgtiv&mynp=OCSSGSG7&mync=E
> http://www-01.ibm.com/support/docview.wss?uid=swg1IC80331
>
> w
>
>
>
>
> -Original Message-
> From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
> Rick Harderwijk
> Sent: Thursday, July 26, 2012 3:24 AM
> To: ADSM-L@VM.MARIST.EDU
> Subject: Re: [ADSM-L] Do you perform Windows SYSTEMSTATE backups?
>
> Roger,
>
> We do not backup desktop clients, but we do have working system state
> backups from servers (2000,2003, 2003R2, 2008, 2008R2) with server version
> 5.4.3.0 and various clientversions (though we did need to upgrade the
> clients on the 2008 family of servers to  5.5.3.3 - but then again, we do
> the DR trainings for a reason). We have not seen the issues you report in
> backing up our servers.
>
> Regards,
>
> Rick
>
> On Thu, Jul 26, 2012 at 8:54 AM, Grigori Solonovitch <
> grigori.solonovi...@ahliunited.com> wrote:
>
> > I am very sorry, but I am a little bit confused by discussion about
> > SYSTEMSTATE backup. We are backing up SYSTEMSTATE for Windows 2003
> > (all
> > editions) and Windows 2008 (all editions) with the latest patches and
> > VSS hot fixes without any problems (TSM Client 6.2.4.0 and TSM Server
> 5.5.6).
> > We have restored successfully a few servers after real Windows
> > disaster. In addition, we are testing Windows image restores
> > periodically. As a small problem I can declare only huge number of
> > files in Windows 2008 SYSTEMSTATE. It delays incremental backups
> > checking all files without backing up them (finally must of the files
> > are re-assigned with message like " ANS4085I Assigned '82817' objects
> > from previous systemstate backup to the new systemstate backup.")
> >
> > Grigori G. Solonovitch
> > Senior Technical Architect  Ahli United Bank Kuwait
> > www.ahliunited.com.kw
> >
> > Please consider the environment before printing this E-mail
> >
> >
> > -Original Message-
> > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf
> > Of Roger Deschner
> > Sent: 26 07 2012 8:54 AM
> > To: ADSM-L@VM.MARIST.EDU
> > Subject: Re: [ADSM-L] Do you perform Windows SYSTEMSTATE backups?
> >
> > We do not back up the Windows System State, and I run a program to
> > find them, delete them, and change the cloptset for offending nodes to
> > one that forbids it. The problem started with Vista, and it hit us
> > real hard. It's a problem that keeps on giving, as people gradually
> > upgrade from XP to Win7 and from Server 2003 to Server 2008.
> >
> > A pet peeve of mine in this regard is that XP calls it "System
> > Object", and TSM very inflexibly enforces this semantic detail. If you
> > assign a
> > Vista+ node to a cloptset that contains DOMAIN -SYSTEMOBJECT you get a
> > fatal error and no backup. If you assign an XP node to a cloptset that
> > contains DOMAIN -SYSTEMSTATE you also get a fatal error. TSM should
> > accept SYSTEMSTATE and SYSTEMOBJECT as aliases for one another. Thi