Re: Two different retention policies for the same node

[Steven Harris]

Michael

migdelay of 7 will keep newly changed files for 7 days.  Older ones will
move off.  So your basic OS files and so on won't be there.  Only way
around that is to run a selective once a week or change MODE to absolute in
the backup copygroup on Sunday morning and back to modified on Monday
morning.  But if you are going to do that, you might as well buy Netbackup.

Regards

Steve



   
 Michael Green 
   To
 Sent by: "ADSM:   ADSM-L@VM.MARIST.EDU
 Dist Stor  cc
 Manager"  
  Re: [ADSM-L] Two different  
   retention policies for the same 
   node
 25/03/2009 08:55  
 AM
   
   
 Please respond to 
 "ADSM: Dist Stor  
 Manager"  

   
   




Thanks Steven and Wanda!

Your ideas are very valuable!

I've been thinking about Steven's recipe number 2. It seems ok, but in
DR situation I wouldn't really want to mess with DB restores.

But what if..


1. Create a new domain for high priority servers (there are just a few
of them) with the same retention as before, but..
2. ...point the domain's copygroup destination to a separate DISK stgpool.
3. During incremental have simultaneous write put the active data to
offsite Active-data pool (of devt FILE, of course)
4. Migrate DISK stgpool down to an onsite FILE stgpool that will have
MIGR DELAY of 7.
5. Replicate that FILE stgpool (by the means of underlying storage)
to an offsite storage (with dedupe or without).

In DR situatiuon I'll have to:
1. Restore the DB
2. The active data is in the active-data pool
3. + 7 days old data is in the FILE stgpool.

How is that? Any flaws you can spot in this approach?
--
Warm regards,
Michael Green



On Wed, Mar 18, 2009 at 11:52 PM, Steven Harris 
wrote:
> Michael,
>
> I have two ideas about your problem.
>
> Idea 1.  Create another domain for your high priority servers, with the 7
> day retention period.  Move the nodes into this domain. Create new nodes
> for these machines in the old domain with different names.  For machines
> performing an "normal" incremental run two backups every day, one to each
> node name.  For machines with too many files for that run a weekly
> incremental to the longer retention domain.  For databases/tdp nodes run
a
> weekly extra backup to the longer retention domain.  Explain carefully to
> management that the coverage of the longer retention period data now has
> holes in it.
>
> Idea 2.  The "7day" retention for offsite sounds like a simple-minded
> notion of what might be nice to have.  What they really want is an
> activepool but they aren't comfortable with it.  Create an activepool
daily
> for the high priority data.  Send it offsite to disk.  Set the DB
> expiration to not less than 7 days.  Set activepool pending delay to 7
> days. Continue to send your normal copypool tapes offsite.  Have a small
> library offsite too.
>
> If you have a disaster all your active data is instantly available.  If
you
> need day -n, restore the db for that day and the activepool data for that
> day will be available. Alternatively use your small library and restore
day
> -n data from the usual copypool tapes.
>
> One loose end if your ERP is SAP, the backups are actually TSM
> archives.  I'm not sure how Activepools work with archives and don't have
> the time to look it up now.
>
> Regards
>
> Steve.
>
>
> Steven Harris
> TSM Admin, Sydney Australia
>
>
>
>
>             Michael Green
>                          .COM>                                                      To
>             Sent by: "ADSM:           ADSM-L@VM.MARIST.EDU
>             Dist Stor                                                  cc
>             Manager"
>                          .EDU>                     Re: [ADSM-L] Two different
>                                       retention policies for the same
>                                       node
>             19/03/2009 12:27
>             AM
>
>
>             Please respond to
>             "ADS

Re: Two different retention policies for the same node

[Michael Green]

Thanks Steven and Wanda!

Your ideas are very valuable!

I've been thinking about Steven's recipe number 2. It seems ok, but in
DR situation I wouldn't really want to mess with DB restores.

But what if..


1. Create a new domain for high priority servers (there are just a few
of them) with the same retention as before, but..
2. ...point the domain's copygroup destination to a separate DISK stgpool.
3. During incremental have simultaneous write put the active data to
offsite Active-data pool (of devt FILE, of course)
4. Migrate DISK stgpool down to an onsite FILE stgpool that will have
MIGR DELAY of 7.
5. Replicate that FILE stgpool (by the means of underlying storage)
to an offsite storage (with dedupe or without).

In DR situatiuon I'll have to:
1. Restore the DB
2. The active data is in the active-data pool
3. + 7 days old data is in the FILE stgpool.

How is that? Any flaws you can spot in this approach?
--
Warm regards,
Michael Green



On Wed, Mar 18, 2009 at 11:52 PM, Steven Harris  wrote:
> Michael,
>
> I have two ideas about your problem.
>
> Idea 1.  Create another domain for your high priority servers, with the 7
> day retention period.  Move the nodes into this domain. Create new nodes
> for these machines in the old domain with different names.  For machines
> performing an "normal" incremental run two backups every day, one to each
> node name.  For machines with too many files for that run a weekly
> incremental to the longer retention domain.  For databases/tdp nodes run a
> weekly extra backup to the longer retention domain.  Explain carefully to
> management that the coverage of the longer retention period data now has
> holes in it.
>
> Idea 2.  The "7day" retention for offsite sounds like a simple-minded
> notion of what might be nice to have.  What they really want is an
> activepool but they aren't comfortable with it.  Create an activepool daily
> for the high priority data.  Send it offsite to disk.  Set the DB
> expiration to not less than 7 days.  Set activepool pending delay to 7
> days. Continue to send your normal copypool tapes offsite.  Have a small
> library offsite too.
>
> If you have a disaster all your active data is instantly available.  If you
> need day -n, restore the db for that day and the activepool data for that
> day will be available. Alternatively use your small library and restore day
> -n data from the usual copypool tapes.
>
> One loose end if your ERP is SAP, the backups are actually TSM
> archives.  I'm not sure how Activepools work with archives and don't have
> the time to look it up now.
>
> Regards
>
> Steve.
>
>
> Steven Harris
> TSM Admin, Sydney Australia
>
>
>
>
>             Michael Green
>                          .COM>                                                      To
>             Sent by: "ADSM:           ADSM-L@VM.MARIST.EDU
>             Dist Stor                                                  cc
>             Manager"
>                          .EDU>                     Re: [ADSM-L] Two different
>                                       retention policies for the same
>                                       node
>             19/03/2009 12:27
>             AM
>
>
>             Please respond to
>             "ADSM: Dist Stor
>                 Manager"
>                                .EDU>
>
>
>
>
>
>
> On Tue, Mar 17, 2009 at 11:18 PM, Conway, Timothy
>  wrote:
>> Is this to avoid having two copypools?  That's a reasonable goal.   I
>> have only one copypool, which is my DR offsite pool.  Just make your
>> onsite copypool an offsite pool, and you can give them 25 times better
>> than they're asking for.
>
> No, the idea is to keep offsite 7 days history for very few most
> important servers (ERP, HR) on disk.  I don't much care if that will
> be primary pool or copy pool. As long as I can get my data back off it
> - it's fine.
> Today, I manage 3 servers here and am sitting on 0.5 peta of backup
> data. There is no point to have all that data (most of which is
> inactive) at DR site (we do have offsite vault though). At DR site we
> want to keep preconfigured turn-key ERP, HR servers, a preconfigured
> TSM server with its database and SAN or NAS attached disk that has the
> 7-days history. I have yet to work out how and by what means my 140GB
> database will get to DR site on daily basis. Maybe we will use a
> dedupe or maybe we will open a separate TSM instance  just for these
> few servers so that the DB that we will have to copy to DR site will
> be as small as possible. Also the smaller  DB, the better in DR
> situation.
>
>> Unless most of the data changes every day, the difference between 7 days
>> and 180 days worth of copypool is remarkably small.
>
> It can be big. ERP server backs up over 100G nightly. I guess it
> dedupes pretty well though.
>
>
>> If you have no copypool at all, the whole thing is a farce.
>> If they're wanting fast portable full restores of a subset of the total
>> nodes, how about backupsets?  Mak

Re: TSM V6 Tivoli Clients

[Schneider, John]

Greetings,
I think I will weigh in on this one.  I think most of our Windows TSM
client missed/failed backups fall pretty evenly into four groups:

1) Fixable problems within the OS, including VSS and WMI service
failures/hangs.  Included in this group is the occasional corrupt
file/filesystem, or Windows OS in memory meltdown.
2) On large filesystems, problems with the TSM scheduler or journal
services hanging.  Sometimes these are resolvable with Windows registry
hacks, or "memoryefficientbackup yes", or adding "3GB" to the
system.ini.
3) Unexplainable random events, where restarting the TSM services makes
the problem disappear, but we can't prove there was a certain cause.
4) Fixable problems with our processes, like other admins taking down a
system for maintencance, and not telling us to remove it from the
schedule. 

In the past year we upgraded all ~1500 Windows clients here to 5.4.2.0
(except for the Windows 2000 servers, that had to stay behind on 5.3.6.)
We tried various flavors of 5.5, but none were as reliable as 5.4.2,
which sort of surprised me.  We gave up trying 5.5 a few months ago, so
maybe it is cleaned up by newer version now.  We don't have enough hands
to upgrade all the clients more than about once a year, so when we find
a stable version, we generally stick with it.


Best Regards,

John D. Schneider
Sisters of Mercy Health Systems 
Email:  john.schnei...@mercy.net 


-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
Wanda Prather
Sent: Tuesday, March 24, 2009 2:18 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] TSM V6 Tivoli Clients

"VSS is like a nose.
Sometimes it runs, sometimes it blows." --- me.


On Tue, Mar 24, 2009 at 3:05 PM, Zoltan Forray/AC/VCU
wrote:

> And of course after M$ changes/fixes their problems, they screw-up the
TSM
> clients which results in another client
> patchlather--rinse--repeat
>
> "ADSM: Dist Stor Manager"  wrote on 03/24/2009
> 02:46:48 PM:
>
> > From:
> >
> > Richard Sims 
> >
> > To:
> >
> > ADSM-L@VM.MARIST.EDU
> >
> > Date:
> >
> > 03/24/2009 02:48 PM
> >
> > Subject:
> >
> > Re: [ADSM-L] TSM V6 Tivoli Clients
> >
> > Sent by:
> >
> > "ADSM: Dist Stor Manager" 
> >
> > On Mar 24, 2009, at 2:35 PM, Timothy Hughes wrote:
> >
> > > I agree there are too many issues with the 5.5 clients, I am also
> > > hoping
> > > for a big improvement with 6.x specifically regarding the VSS
issues.
> >
> >  From all I've read, the VSS issues are the result of ongoing
> > Microsoft programming errors, of which IBM is just one of the
victims.
> >
> > Richard Sims
>
This e-mail contains information which (a) may be PROPRIETARY IN NATURE OR
OTHERWISE PROTECTED BY LAW FROM DISCLOSURE, and (b) is intended only for the
use of the addressee(s) named above. If you are not the addressee, or the
person responsible for delivering this to the addressee(s), you are notified
that reading, copying or distributing this e-mail is prohibited. If you have
received this e-mail in error, please contact the sender immediately.

Re: Dear Tuscon

[Jim Zajkowski]

On Mar 24, 2009, at 9:56 AM, Kauffman, Tom wrote:


The TSM database is about 30 GB used of 46 GB assigned. We have a
sub-rate T1 to our hot-site, with an RS-6000 installed. We are
currently running mksysb images out to the system with rsync; they
run to about 4.7 GB each and take about 1.2 hours. They also put
enough load on the corporate internet link that we can only run them
from 19:00 to 05:30 local time.


rsync, at least modern versions, have a bandwidth limiter option.

We store our database copies offsite using rsync (to a Solaris box
running ZFS with compression; with gzip compression enabled we're
seeing compression ratios of around 8.5x).

You could also consider other places to stash your database if you
have a better connection to the 'net than your DR site.  There are
companies that provide remote rsync space, joyent comes to mind, or
even amazon's s3 storage (not rsync).  I don't work in the Corporate
World so I have the flexibility to use those tools; YMMV.

--Jim

Re: TDP 5.5.2 Communication Delays

[Del Hoobler]

Look here:
   http://www-01.ibm.com/support/docview.wss?uid=swg21305911

Under the first bullet:
   "Slow application start up when there is no internet connection"

Thanks,

Del




"ADSM: Dist Stor Manager"  wrote on 03/24/2009
01:42:35 PM:

> [image removed]
>
> TDP 5.5.2 Communication Delays
>
> Neese, Thomas J
>
> to:
>
> ADSM-L
>
> 03/24/2009 01:45 PM
>
> Sent by:
>
> "ADSM: Dist Stor Manager" 
>
> Please respond to "ADSM: Dist Stor Manager"
>
> We recently upgraded one of our SQL Servers to TDP SQL 5.5.2. We
> noticed there was a lag in the time it took to run a manual backup
> of a database. To check things out, I installed Network Monitor on
> the server to get an idea of the packets being sent. Here is a summary:
>
> Traffic sent by the process tdpsqlc.exe:
> Several TCP packets outbound from the TDP client to contact
> crl.verisign.net on port 80
> after (4) attempts to contact the crl.verisign.net server and
> failing (took about a minute for the attempt/fail/retry sequence to
> play out), the client contacted our TSM server and transferred the
> backup data.
>
> We are running Windows Server 2003 SP2 and SQL Server 2005 SP2 on
> this server. This server is firewalled and does not allow outbound
> traffic on any port to leave our campus network. If I run the same
> test on a different firewalled server with TDP SQL 5.5.0 installed,
> I don't get the packet attempts outbound to crl.verisign.net and the
> backup happens without the extra overhead of trying to contact the
> VeriSign server.
>
> I know that TDP SQL 5.5.2 added a new SQL Native Client (SNAC) from
> SQL Server 2008, but is something trying to establish SSL
> connections and needing to verify a certificate revocation list
> (CRL)? I tried looking through the docs and can't find where I can
> disable this functionality. I added a line in the dsm.opt file that
> stated: SSL off, but with no affect.
>
> I'm open to ideas on how we can adjust this behavior on the TDP SQL
> client. Preference is to stop the attempt to contact
> crl.verisign.net, but I'm also open to temporary work arounds. Our
> TSM server is running on AIX and is version 5.5.1.1. Thanks for any
> help you can provide!
>
>
>
> <>< <>< <>< <>< <><
>
> Tom Neese, MCSE/CCEA
>
> ITS Systems and Platforms
>
> Windows Server Group
>
> University of Iowa
>
> (319)335-5980
>
> thomas-ne...@uiowa.edu
>
> <>< <>< <>< <>< <><

Re: Changing a Node´s password

[David McClelland]

Hi Mario,

>From the TSM Server? On the TSM Admin CLI this would be achieved by (logged
in as an administrator with appropriate privs):

UPDATE NODE  

You'd need to re-authenticate with this new password at the client side if
using PASSWORDACCESS GENERATE in your options file there. This process may
vary depending upon whether your client is a BA Client or a TDP client of
some flavour.

HTH,

/David Mc
London, UK

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
Mario Behring
Sent: 24 March 2009 19:09
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Changing a Node´s password

Hi list,

Is there any way to change the TSM password for a Node without knowing the
current password?

Thanks

Mario






No virus found in this incoming message.
Checked by AVG. 
Version: 7.5.524 / Virus Database: 270.11.18/2009 - Release Date: 18/03/2009
07:17
 

No virus found in this outgoing message.
Checked by AVG. 
Version: 7.5.524 / Virus Database: 270.11.18/2009 - Release Date: 18/03/2009
07:17
 

Re: TSM V6 Tivoli Clients

[Wanda Prather]

"VSS is like a nose.
Sometimes it runs, sometimes it blows." --- me.


On Tue, Mar 24, 2009 at 3:05 PM, Zoltan Forray/AC/VCU wrote:

> And of course after M$ changes/fixes their problems, they screw-up the TSM
> clients which results in another client
> patchlather--rinse--repeat
>
> "ADSM: Dist Stor Manager"  wrote on 03/24/2009
> 02:46:48 PM:
>
> > From:
> >
> > Richard Sims 
> >
> > To:
> >
> > ADSM-L@VM.MARIST.EDU
> >
> > Date:
> >
> > 03/24/2009 02:48 PM
> >
> > Subject:
> >
> > Re: [ADSM-L] TSM V6 Tivoli Clients
> >
> > Sent by:
> >
> > "ADSM: Dist Stor Manager" 
> >
> > On Mar 24, 2009, at 2:35 PM, Timothy Hughes wrote:
> >
> > > I agree there are too many issues with the 5.5 clients, I am also
> > > hoping
> > > for a big improvement with 6.x specifically regarding the VSS issues.
> >
> >  From all I've read, the VSS issues are the result of ongoing
> > Microsoft programming errors, of which IBM is just one of the victims.
> >
> > Richard Sims
>

Re: Changing a Node´s password

[Abid Ilias]

>From the TSM Server command line

Upd node  

Thanks
Abid Ilias
Networking Services and Information Technology
The University of Chicago


-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Mario 
Behring
Sent: Tuesday, March 24, 2009 2:09 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Changing a Node´s password

Hi list,

Is there any way to change the TSM password for a Node without knowing the 
current password?

Thanks

Mario

Re: Changing a Node´s password

[Lee, Gary D.]

log into the tsm server as n administrator with propper authority, and 
type as follows:

Update node node-name newpassword

All done.
 


Gary Lee
Senior System Programmer
Ball State University
phone: 765-285-1310

 
-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Mario 
Behring
Sent: Tuesday, March 24, 2009 3:09 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Changing a Node´s password

Hi list,

Is there any way to change the TSM password for a Node without knowing the 
current password?

Thanks

Mario

Re: Changing a Node´s password

[Huebschman, George J.]

UPdate it from the TSM server
UPDATE NODE  NEWPASSWORD

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Mario 
Behring
Sent: Tuesday, March 24, 2009 3:09 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Changing a Node´s password

Hi list,

Is there any way to change the TSM password for a Node without knowing the 
current password?

Thanks

Mario





IMPORTANT: E-mail sent through the Internet is not secure and timely delivery 
of Internet mail is not guaranteed. Legg Mason therefore, recommends that you 
do not send any  action-oriented or time-sensitive information to us via 
electronic mail, or any confidential or sensitive information including:  
social security numbers, account numbers, or personal identification numbers.

This message is intended for the addressee only and may contain privileged or 
confidential information. Unless you are the intended recipient, you may not 
use, copy or disclose to anyone any information contained in this message. If 
you have received this message in error, please notify the author by replying 
to this message and then kindly delete the message. Thank you.

Changing a Node´s password

[Mario Behring]

Hi list,

Is there any way to change the TSM password for a Node without knowing the 
current password?

Thanks

Mario

Re: TSM V6 Tivoli Clients

[Zoltan Forray/AC/VCU]

And of course after M$ changes/fixes their problems, they screw-up the TSM
clients which results in another client
patchlather--rinse--repeat

"ADSM: Dist Stor Manager"  wrote on 03/24/2009
02:46:48 PM:

> From:
>
> Richard Sims 
>
> To:
>
> ADSM-L@VM.MARIST.EDU
>
> Date:
>
> 03/24/2009 02:48 PM
>
> Subject:
>
> Re: [ADSM-L] TSM V6 Tivoli Clients
>
> Sent by:
>
> "ADSM: Dist Stor Manager" 
>
> On Mar 24, 2009, at 2:35 PM, Timothy Hughes wrote:
>
> > I agree there are too many issues with the 5.5 clients, I am also
> > hoping
> > for a big improvement with 6.x specifically regarding the VSS issues.
>
>  From all I've read, the VSS issues are the result of ongoing
> Microsoft programming errors, of which IBM is just one of the victims.
>
> Richard Sims

Re: TSM V6 Tivoli Clients

[Richard Sims]

On Mar 24, 2009, at 2:35 PM, Timothy Hughes wrote:


I agree there are too many issues with the 5.5 clients, I am also
hoping
for a big improvement with 6.x specifically regarding the VSS issues.


From all I've read, the VSS issues are the result of ongoing
Microsoft programming errors, of which IBM is just one of the victims.

   Richard Sims

Re: TSM V6 Tivoli Clients

[Timothy Hughes]

Thanks, Todd, Adrian and Robert !

Robert,

I agree there are too many issues with the 5.5 clients, I am also hoping
for a big improvement with 6.x specifically regarding the VSS issues.

regards!


Clark, Robert A wrote:


Ordinarily, I would agree with this sentiment. But as many problems as
I've seen with the 5.5. clients, I'm hoping all the break fix attention
at Tivoli has been focused on 6.x. There is also some pent-up demand for
features expected in 6.x.

[RC]

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
Adrian Compton
Sent: Monday, March 23, 2009 11:47 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] TSM V6 Tivoli Clients

Hi,

In a production environment, I would be very hesitant to go anywhere
near V6 until at least you have tested it in a test environment with
your database. As this version is a huge technology shift, I would be
very weary of staying on the bleeding edge of the product.

Regards



Adrian Compton
Aspen Pharmacare Port Elizabeth
tel: +2741 4072855
Fax: +2741 453 7452
Cell: +27823204495
Email: acomp...@aspenpharma.com
-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
Timothy Hughes
Sent: 23 March 2009 19:29 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] TSM V6 Tivoli Clients

Hello,

Does anyone  know how soon after TSM V6 is available which believe is on
3/27 will the 6.1 clients be available?


Thanks in advance!


DISCLAIMER:
This message is intended for the sole use of the addressee, and may contain 
information that is privileged, confidential and exempt from disclosure under 
applicable law. If you are not the addressee you are hereby notified that you 
may not use, copy, disclose, or distribute to anyone the message or any 
information contained in the message. If you have received this message in 
error, please immediately advise the sender by reply email and delete this 
message.

Re: TSM V6 Tivoli Clients

[Clark, Robert A]

Ordinarily, I would agree with this sentiment. But as many problems as
I've seen with the 5.5. clients, I'm hoping all the break fix attention
at Tivoli has been focused on 6.x. There is also some pent-up demand for
features expected in 6.x.

[RC] 

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
Adrian Compton
Sent: Monday, March 23, 2009 11:47 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] TSM V6 Tivoli Clients

Hi,

In a production environment, I would be very hesitant to go anywhere
near V6 until at least you have tested it in a test environment with
your database. As this version is a huge technology shift, I would be
very weary of staying on the bleeding edge of the product.

Regards

 
 
Adrian Compton
Aspen Pharmacare Port Elizabeth
tel: +2741 4072855
Fax: +2741 453 7452
Cell: +27823204495
Email: acomp...@aspenpharma.com
-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
Timothy Hughes
Sent: 23 March 2009 19:29 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] TSM V6 Tivoli Clients

Hello,

Does anyone  know how soon after TSM V6 is available which believe is on
3/27 will the 6.1 clients be available?


Thanks in advance!


DISCLAIMER:
This message is intended for the sole use of the addressee, and may contain 
information that is privileged, confidential and exempt from disclosure under 
applicable law. If you are not the addressee you are hereby notified that you 
may not use, copy, disclose, or distribute to anyone the message or any 
information contained in the message. If you have received this message in 
error, please immediately advise the sender by reply email and delete this 
message.

Re: TDP 5.5.2 Communication Delays

[Richard Sims]

I suspect that you are using SSL encryption, and thus certificates, as
the IBM Tivoli Storage Manager Versions 5.4 and 5.5 Technical Guide
redbook describes.  Look into that area.

   Richard Sims

TDP 5.5.2 Communication Delays

[Neese, Thomas J]

We recently upgraded one of our SQL Servers to TDP SQL 5.5.2. We noticed there 
was a lag in the time it took to run a manual backup of a database. To check 
things out, I installed Network Monitor on the server to get an idea of the 
packets being sent. Here is a summary:

Traffic sent by the process tdpsqlc.exe:
Several TCP packets outbound from the TDP client to contact crl.verisign.net on 
port 80
after (4) attempts to contact the crl.verisign.net server and failing (took 
about a minute for the attempt/fail/retry sequence to play out), the client 
contacted our TSM server and transferred the backup data.

We are running Windows Server 2003 SP2 and SQL Server 2005 SP2 on this server. 
This server is firewalled and does not allow outbound traffic on any port to 
leave our campus network. If I run the same test on a different firewalled 
server with TDP SQL 5.5.0 installed, I don't get the packet attempts outbound 
to crl.verisign.net and the backup happens without the extra overhead of trying 
to contact the VeriSign server.

I know that TDP SQL 5.5.2 added a new SQL Native Client (SNAC) from SQL Server 
2008, but is something trying to establish SSL connections and needing to 
verify a certificate revocation list (CRL)? I tried looking through the docs 
and can't find where I can disable this functionality. I added a line in the 
dsm.opt file that stated: SSL off, but with no affect.

I'm open to ideas on how we can adjust this behavior on the TDP SQL client. 
Preference is to stop the attempt to contact crl.verisign.net, but I'm also 
open to temporary work arounds. Our TSM server is running on AIX and is version 
5.5.1.1. Thanks for any help you can provide!



<>< <>< <>< <>< <><

Tom Neese, MCSE/CCEA

ITS Systems and Platforms

Windows Server Group

University of Iowa

(319)335-5980

thomas-ne...@uiowa.edu

<>< <>< <>< <>< <><

Re: Dear Tuscon

[Dwight Cook]

If you have multiple TSM servers, just backup to a flat file and push the db
backup to your other TSM server. (same with hourly incr db backups)
(and please don't go down the ~just use server to server communications with
virtual volumes~ road... I don't like using virtual volumes on another
server for that because it adds the complexity of having to establish server
to server communications before being able to perform the restore.)
There are also many other options of you don't like using a whole tape...
stick some NAS storage out there and just keep them on that.

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
Remco Post
Sent: Tuesday, March 24, 2009 9:08 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Dear Tuscon

On 20 mrt 2009, at 15:39, Nick Laflamme wrote:

> My heart leapt when my RSS reader presented me an article in the TSM
> udpates feed from IBM with the heading, "Keeping more than one TSM
> server database backup on a tape." As I'm implementing a new server
> using 3592 drives, I haven't been happy with my options for this
> particular issue. Maybe, I thought, I was about to learn something of
> immediate use and high value!
>
> My heart sank when I read the actual article, which might be
> paraphrased as, "Sorry, Charlie, too risky."
>
> Back to asking for some LTO drives just for small, inexpensive tapes
> for DB backups.


I had a discussion with IBM development on this subject just a few
months ago in the context of the TSM 6.1 beta program. That person at
that time agreed with me that given current tape capacities, having
multiple db backups on one tape might make sense. This doesn't mean
that this is in 6.1 or even on the roadmap, but it does mean that the
door isn't completely closed either. We'll probably only find out if
IBM decides to follow up on the suggestion

--
Met vriendelijke groeten/Kind regards,

Remco Post
r.p...@plcs.nl

Re: Dear Tuscon

[Ochs, Duane]

I'm not sure of the true concern with this ?
I'm using LTO-4 and yes my tapes that I perform DB backups on are
90%-95% empty afterwards. 
But to ensure recoverability I can live with that.

Also the concern of "expensive" tapes over cheaper lower capacity is
relative.
"Back in the day" we used lower capacity tapes that were state of the
art but also the same price as the current technology. Yes you can back
up a TSM DB on one tape without too much left over capacity, but is it
really that important in the long run ? 

I'll get off my soapbox now.
Have good day everyone.


-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
Remco Post
Sent: Tuesday, March 24, 2009 9:08 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Dear Tuscon

On 20 mrt 2009, at 15:39, Nick Laflamme wrote:

> My heart leapt when my RSS reader presented me an article in the TSM
> udpates feed from IBM with the heading, "Keeping more than one TSM
> server database backup on a tape." As I'm implementing a new server
> using 3592 drives, I haven't been happy with my options for this
> particular issue. Maybe, I thought, I was about to learn something of
> immediate use and high value!
>
> My heart sank when I read the actual article, which might be
> paraphrased as, "Sorry, Charlie, too risky."
>
> Back to asking for some LTO drives just for small, inexpensive tapes
> for DB backups.


I had a discussion with IBM development on this subject just a few
months ago in the context of the TSM 6.1 beta program. That person at
that time agreed with me that given current tape capacities, having
multiple db backups on one tape might make sense. This doesn't mean
that this is in 6.1 or even on the roadmap, but it does mean that the
door isn't completely closed either. We'll probably only find out if
IBM decides to follow up on the suggestion

--
Met vriendelijke groeten/Kind regards,

Remco Post
r.p...@plcs.nl

Re: Dear Tuscon

[Remco Post]

On 20 mrt 2009, at 15:39, Nick Laflamme wrote:


My heart leapt when my RSS reader presented me an article in the TSM
udpates feed from IBM with the heading, "Keeping more than one TSM
server database backup on a tape." As I'm implementing a new server
using 3592 drives, I haven't been happy with my options for this
particular issue. Maybe, I thought, I was about to learn something of
immediate use and high value!

My heart sank when I read the actual article, which might be
paraphrased as, "Sorry, Charlie, too risky."

Back to asking for some LTO drives just for small, inexpensive tapes
for DB backups.



I had a discussion with IBM development on this subject just a few
months ago in the context of the TSM 6.1 beta program. That person at
that time agreed with me that given current tape capacities, having
multiple db backups on one tape might make sense. This doesn't mean
that this is in 6.1 or even on the roadmap, but it does mean that the
door isn't completely closed either. We'll probably only find out if
IBM decides to follow up on the suggestion

--
Met vriendelijke groeten/Kind regards,

Remco Post
r.p...@plcs.nl

Re: Dear Tuscon

[Kauffman, Tom]

The TSM database is about 30 GB used of 46 GB assigned. We have a sub-rate T1 
to our hot-site, with an RS-6000 installed. We are currently running mksysb 
images out to the system with rsync; they run to about 4.7 GB each and take 
about 1.2 hours. They also put enough load on the corporate internet link that 
we can only run them from 19:00 to 05:30 local time. We're actually running our 
corporate WAN over AT&T's EVPN service, so all out manufacturing locations are 
tied in through the same local router interfaces.

And SAP's GUI interface does NOT handle time-outs at all well . . .

We'd need a higher bandwith permanent allocation both at our hot-site and at 
corporate to handle the load, and the cost-justification just isn't there. So 
we take 6 TSM database tape to the hot-site when we run tests (two each, from 
roughly 12 hour intervals) and figure that worst-case we'll lose half a day. 
Like I said, we haven't had a database read failure - yet - so I can't really 
build a case for the datacom costs.

Tom

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of 
Richard Rhodes
Sent: Tuesday, March 24, 2009 9:22 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Dear Tuscon

How big is your TSM db?

If it's not too big and you have extra disk space at both sites, you could:

   tsm db backup to local file devices
   compress the file devices
   copy/rdist/rsync to the dr site







 "Kauffman, Tom"
To
 Sent by: "ADSM:   ADSM-L@VM.MARIST.EDU
 Dist Stor  cc
 Manager"
  Re: Dear Tuscon


 03/24/2009 09:10
 AM


 Please respond to
 "ADSM: Dist Stor
 Manager"
 






I only have one TSM server - and I'm not worried about my local TSM
database. Its on an IBM DS-8100 (raid5) mirrored to a second DS-8100. My
concern is having a readable TSM database backup off-site for use in a
disaster recovery. We're not a big company; we flirt with the bottom end of
the Forbes 500 privately held companies from time to time - so there's no
way I'm getting a big enough network pipe to do any kind of electronic
off-site storage. I'm stuck with tape. I will say that I've had fewer
permanent read errors on LTO-2 than any other media since we got off 1600
BPI Phase-encoded open reel tape - but there's always that first time.

Tom

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
Strand, Neil B.
Sent: Monday, March 23, 2009 2:36 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Dear Tuscon

Tom,
   If you have more than one TSM server you can have multiple copies of
the same backup just by using virtual volumes to another TSM server.
- Backup to virtual volume on server A - storage pool A
- Create offsite copy of storage pool A on server A
- Create a second copy if you are really paranoid or have poor tape
reliability.

If your virtual volume is on RAID disk, it is probably a bit more
reliable than most tape.
If you really want to get fancy, put the virtual volume storage pool on
mirrored disk and immediately after the backup completes, break the
mirror and you have two instant copies of your DB backup.

Cheers,
Neil Strand
Storage Engineer - Legg Mason
Baltimore, MD.
(410) 580-7491
Whatever you can do or believe you can, begin it.
Boldness has genius, power and magic.


-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
Kauffman, Tom
Sent: Friday, March 20, 2009 4:38 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Dear Tuscon

I go a step further - I want the ability to cut two matching copies of
the database backup to two tapes simultaneously. I'm currently running
two backups back-to-back, but I'm unable to have sessions disabled for
40 minutes, so they are NOT identical backups.

Tom

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
Wanda Prather
Sent: Friday, March 20, 2009 2:24 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Dear Tuscon

I agree.  I want my TSM DB backup on the MOST RELIABLE MEDIA/DEVICE I
CAN GET.
If you EVER need that DB backup tape, it's because you are already in
deep do-do, and in a hurry to fix it.  The last thing you'll want to
deal with is the risk of encountering an I/O error on a DB restore...

On Fri, Mar 20, 2009 at 2:05 PM, David E Ehresman
wrote:

> Gee. Our 3592 tapes cost somewhere around 100 dollars.  We keep 5 days

> worth of TSM DB backups.  $500 is real cheap in order to keep a copy
> of our most important DR resource on our most reliable backup medium.
>
> David Ehresman
> University of Louisville
>
> >>> Nick Laflamme  3/20/2009 10:39 AM >>>
> My heart leapt when my RSS reader presented me an article in the TSM
> udpates feed from IBM with 

Re: Dear Tuscon

[Richard Rhodes]

How big is your TSM db?

If it's not too big and you have extra disk space at both sites, you could:

   tsm db backup to local file devices
   compress the file devices
   copy/rdist/rsync to the dr site







 "Kauffman, Tom"
To
 Sent by: "ADSM:   ADSM-L@VM.MARIST.EDU
 Dist Stor  cc
 Manager"
  Re: Dear Tuscon


 03/24/2009 09:10
 AM


 Please respond to
 "ADSM: Dist Stor
 Manager"
 






I only have one TSM server - and I'm not worried about my local TSM
database. Its on an IBM DS-8100 (raid5) mirrored to a second DS-8100. My
concern is having a readable TSM database backup off-site for use in a
disaster recovery. We're not a big company; we flirt with the bottom end of
the Forbes 500 privately held companies from time to time - so there's no
way I'm getting a big enough network pipe to do any kind of electronic
off-site storage. I'm stuck with tape. I will say that I've had fewer
permanent read errors on LTO-2 than any other media since we got off 1600
BPI Phase-encoded open reel tape - but there's always that first time.

Tom

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
Strand, Neil B.
Sent: Monday, March 23, 2009 2:36 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Dear Tuscon

Tom,
   If you have more than one TSM server you can have multiple copies of
the same backup just by using virtual volumes to another TSM server.
- Backup to virtual volume on server A - storage pool A
- Create offsite copy of storage pool A on server A
- Create a second copy if you are really paranoid or have poor tape
reliability.

If your virtual volume is on RAID disk, it is probably a bit more
reliable than most tape.
If you really want to get fancy, put the virtual volume storage pool on
mirrored disk and immediately after the backup completes, break the
mirror and you have two instant copies of your DB backup.

Cheers,
Neil Strand
Storage Engineer - Legg Mason
Baltimore, MD.
(410) 580-7491
Whatever you can do or believe you can, begin it.
Boldness has genius, power and magic.


-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
Kauffman, Tom
Sent: Friday, March 20, 2009 4:38 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Dear Tuscon

I go a step further - I want the ability to cut two matching copies of
the database backup to two tapes simultaneously. I'm currently running
two backups back-to-back, but I'm unable to have sessions disabled for
40 minutes, so they are NOT identical backups.

Tom

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
Wanda Prather
Sent: Friday, March 20, 2009 2:24 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Dear Tuscon

I agree.  I want my TSM DB backup on the MOST RELIABLE MEDIA/DEVICE I
CAN GET.
If you EVER need that DB backup tape, it's because you are already in
deep do-do, and in a hurry to fix it.  The last thing you'll want to
deal with is the risk of encountering an I/O error on a DB restore...

On Fri, Mar 20, 2009 at 2:05 PM, David E Ehresman
wrote:

> Gee. Our 3592 tapes cost somewhere around 100 dollars.  We keep 5 days

> worth of TSM DB backups.  $500 is real cheap in order to keep a copy
> of our most important DR resource on our most reliable backup medium.
>
> David Ehresman
> University of Louisville
>
> >>> Nick Laflamme  3/20/2009 10:39 AM >>>
> My heart leapt when my RSS reader presented me an article in the TSM
> udpates feed from IBM with the heading, "Keeping more than one TSM
> server database backup on a tape." As I'm implementing a new server
> using 3592 drives, I haven't been happy with my options for this
> particular issue. Maybe, I thought, I was about to learn something of
> immediate use and high value!
>
> My heart sank when I read the actual article, which might be
> paraphrased as, "Sorry, Charlie, too risky."
>
> Back to asking for some LTO drives just for small, inexpensive tapes
> for DB backups.
>


CONFIDENTIALITY NOTICE:  This email and any attachments are for the
exclusive and confidential use of the intended recipient.  If you are
not the intended recipient, please do not read, distribute or take
action in reliance upon this message. If you have received this in
error, please notify us immediately by return email and promptly delete
this message and its attachments from your computer system. We do not
waive attorney-client or work product privilege by the transmission of
this message.

IMPORTANT: E-mail sent through the Internet is not secure and timely
delivery of Internet mail is not guaranteed. Legg Mason therefore,
recommends that you do not send any  action-oriented or time-sensitive
information to us via electronic mail, 

Re: Dear Tuscon

[Kauffman, Tom]

I only have one TSM server - and I'm not worried about my local TSM database. 
Its on an IBM DS-8100 (raid5) mirrored to a second DS-8100. My concern is 
having a readable TSM database backup off-site for use in a disaster recovery. 
We're not a big company; we flirt with the bottom end of the Forbes 500 
privately held companies from time to time - so there's no way I'm getting a 
big enough network pipe to do any kind of electronic off-site storage. I'm 
stuck with tape. I will say that I've had fewer permanent read errors on LTO-2 
than any other media since we got off 1600 BPI Phase-encoded open reel tape - 
but there's always that first time.

Tom

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of 
Strand, Neil B.
Sent: Monday, March 23, 2009 2:36 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Dear Tuscon

Tom,
   If you have more than one TSM server you can have multiple copies of
the same backup just by using virtual volumes to another TSM server.
- Backup to virtual volume on server A - storage pool A
- Create offsite copy of storage pool A on server A
- Create a second copy if you are really paranoid or have poor tape
reliability.

If your virtual volume is on RAID disk, it is probably a bit more
reliable than most tape.
If you really want to get fancy, put the virtual volume storage pool on
mirrored disk and immediately after the backup completes, break the
mirror and you have two instant copies of your DB backup.

Cheers,
Neil Strand
Storage Engineer - Legg Mason
Baltimore, MD.
(410) 580-7491
Whatever you can do or believe you can, begin it.
Boldness has genius, power and magic.


-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
Kauffman, Tom
Sent: Friday, March 20, 2009 4:38 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Dear Tuscon

I go a step further - I want the ability to cut two matching copies of
the database backup to two tapes simultaneously. I'm currently running
two backups back-to-back, but I'm unable to have sessions disabled for
40 minutes, so they are NOT identical backups.

Tom

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
Wanda Prather
Sent: Friday, March 20, 2009 2:24 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Dear Tuscon

I agree.  I want my TSM DB backup on the MOST RELIABLE MEDIA/DEVICE I
CAN GET.
If you EVER need that DB backup tape, it's because you are already in
deep do-do, and in a hurry to fix it.  The last thing you'll want to
deal with is the risk of encountering an I/O error on a DB restore...

On Fri, Mar 20, 2009 at 2:05 PM, David E Ehresman
wrote:

> Gee. Our 3592 tapes cost somewhere around 100 dollars.  We keep 5 days

> worth of TSM DB backups.  $500 is real cheap in order to keep a copy
> of our most important DR resource on our most reliable backup medium.
>
> David Ehresman
> University of Louisville
>
> >>> Nick Laflamme  3/20/2009 10:39 AM >>>
> My heart leapt when my RSS reader presented me an article in the TSM
> udpates feed from IBM with the heading, "Keeping more than one TSM
> server database backup on a tape." As I'm implementing a new server
> using 3592 drives, I haven't been happy with my options for this
> particular issue. Maybe, I thought, I was about to learn something of
> immediate use and high value!
>
> My heart sank when I read the actual article, which might be
> paraphrased as, "Sorry, Charlie, too risky."
>
> Back to asking for some LTO drives just for small, inexpensive tapes
> for DB backups.
>


CONFIDENTIALITY NOTICE:  This email and any attachments are for the
exclusive and confidential use of the intended recipient.  If you are
not the intended recipient, please do not read, distribute or take
action in reliance upon this message. If you have received this in
error, please notify us immediately by return email and promptly delete
this message and its attachments from your computer system. We do not
waive attorney-client or work product privilege by the transmission of
this message.

IMPORTANT: E-mail sent through the Internet is not secure and timely delivery 
of Internet mail is not guaranteed. Legg Mason therefore, recommends that you 
do not send any  action-oriented or time-sensitive information to us via 
electronic mail, or any confidential or sensitive information including:  
social security numbers, account numbers, or personal identification numbers.

This message is intended for the addressee only and may contain privileged or 
confidential information. Unless you are the intended recipient, you may not 
use, copy or disclose to anyone any information contained in this message. If 
you have received this message in error, please notify the author by replying 
to this message and then kindly delete the message. Thank you.


CONFIDENTIALITY NOTICE:  This email and any attachments are for the
exclusive and confidential use of the intended recipient.  If you are not
the i

unsubscribe

[Terry McColgan]

Terry McColgan
Help Desk Support Specialist
Tivoli Storage Manager Specialist

Ontario College of Teachers
121 Bloor Street East, Floor 6
Toronto, Ontario
M4W 3M5

tmccol...@oct.ca
416-961-8800ext. 670

"Go ahead... backup."




-

Please consider the environment before printing this e-mail.

This communication is intended for use by the individual(s) to whom
it is specifically addressed.  Such communication may contain
privileged or confidential information.  If you have received this
communication in error, please notify the sender and permanently
delete the communication.  Thank you for your co-operation.

Re: how do I recover DSM records from a crashed SGI server?

[Richard Sims]

The contemporary computer to receive the old SGI's files needs to have
a file system which is compatible with the SGI's file system, and the
TSM client needs to be programmed to handle that, where you would use
the Virtualnodename option in conjunction with the old SGI's client
password to access its data.  The first command you should then
perform is 'dsmc query filespace' to verify what's there, and then
drill into it with 'dsmc query backup'.  Whereas SGI has been
discontinued as a supported platform in the latest TSM clients, you
may need to use an older client level, like 5.1.

   Richard Simshttp://people.bu.edu/rbs/