TSM Webclient security

[Mathieu JOSSE]

Hello,

I try to secure the TSM web client (CAD) by implementing SSL. It seems that
it's not available in 5.5.1 client version and more.

Does anyone have success running the web client GUI through "stunnel" or
another software?

I managed to run the admin server GUI without any worries, but the web
client is still presenting problems. I would appreciate a feedback from one
of you if possible.

Thank you in advance. (sorry for my bad English)

Re: TSM Webclient security

[Erwann SIMON]

Hi Mathieu,

The web client is using 3 TCP ports, and 2 of these port are random ones 
by default.


In order to have it running through a TCP tunnel, you need to define 
fixed TCP ports in the client options file. See the HTTPPORT and the 
WEBPORTS client options.


Best regards / Cordialement / مع تحياتي
Erwann SIMON


Le 04/10/2011 11:04, Mathieu JOSSE a écrit :

Hello,

I try to secure the TSM web client (CAD) by implementing SSL. It seems that
it's not available in 5.5.1 client version and more.

Does anyone have success running the web client GUI through "stunnel" or
another software?

I managed to run the admin server GUI without any worries, but the web
client is still presenting problems. I would appreciate a feedback from one
of you if possible.

Thank you in advance. (sorry for my bad English)

Re: Ang: [ADSM-L] Migrate TSM server ( Win to Linux)

[Stefan Folkerts]

I would look into the option of renting a library or buying a refurbished
on.

I have no idea what kind of capacity we are talking about but you could also
migrate to disk (maybe with dedupe) and then migrate back to tape if you
happen to have (or be able to rent/borrow) the disk capacity you need.

As the others mention, if you can't attach some storage space it's not
possible.
The migration doesn require the full amount twice if you are able to cleanup
after every migration and do it node for node but 5 slots is not much in any
case.

Reclaims running ok?

On Tue, Oct 4, 2011 at 8:22 AM, Daniel Sparrman wrote:

> If you dont have space in your library, none of the options will work. Both
> require you to export/import data, which in turn requires space for the new
> TSM server in your library.
>
> No way of making space? Perhaps some old data that you can check out of
> your library and have outside the library? A copypool you can remove?
>
> If there's no way of making space in the library, it's going to be a hard
> thing migrating your TSM server from the Windows box to the Linux box, all
> available options require that you do a export/import since moving the
> database from Windows to Linux isnt supported.
>
> Best Regards
>
> Daniel
>
>
> Daniel Sparrman
> Exist i Stockholm AB
> Växel: 08-754 98 00
> Fax: 08-754 97 30
> daniel.sparr...@exist.se
> http://www.existgruppen.se
> Posthusgatan 1 761 30 NORRTÄLJE
>
>
> -"ADSM: Dist Stor Manager"  skrev: -
> Till: ADSM-L@VM.MARIST.EDU
> Från: Gibin
> Sänt av: "ADSM: Dist Stor Manager"
> Datum: 10/04/2011 08:06
> Ärende: [ADSM-L] Migrate TSM server ( Win to Linux)
>
> The Library we have does support partitioning,but it is packed to capacity
> with ability to accommodate  just 5 more tapes.So i do'nt think a secondary
> library  for the Linux server will help.
>
> So Daniel as you were saying i will :
> 1. Setup Library Manager /client between by New & old TSm servers
>
> 2.Import TSM database/policies/schedules  info from old TSM server to New
> TSm server
>
> 3.Switch Library Manager to New TSM sever
>
> +--
> |This was sent by gibi...@gmail.com via Backup Central.
> |Forward SPAM to ab...@backupcentral.com.
> +--
>

Re: Reducing/Reclaiming tsmlog space

[Stefan Folkerts]

*Matt Anglin's words during the TSM Symposium last week don't give me much
hope for a quick fix, i'm losely quoting here "we develop towards things
getting bigger all the time".*
He was talking about making logs smaller if I am not mistaking.

On Fri, Sep 30, 2011 at 5:06 PM, Zoltan Forray/AC/VCU wrote:

> I recently expanded the log size from 60GB to 120GB to allow for an
> expected increase in transactions (was deleted 190M objects).
>
> Now that this is over, I need to shrink it back down to 60GB since the
> filespace it is using is shared by the DB and now I get a daily messages
> that the DB is running low on space (89.40% utilized.
>
> So what does it take to do this?   I am guessing that simply changing the
> logsize to 60GB won't just magically reclaim the space
>
> Server is Linux 6.1.5.10
>
> 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: Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] vtl versus file systems for pirmary pool

[Stefan Folkerts]

My understanding is that each core in a TSM server can identify around 60GB
of undeduped data per hour.
This puts a quad core at about 3-4TB per day of newly undeduped data per day
(not running at night).
Of course there are differences in CPU architecture and memory/storage as
well but IBM say's they see abount 60GB/hour per core and advise not to go
above 3-4TB per day on a FILEPOOL with dedupe on TSM.


On Fri, Sep 30, 2011 at 12:29 AM, Colwell, William F.
wrote:

> Hi Daniel,
>
> My main point was to say that your previous posts seemed to be saying that
> dedup storagepools
> were recommended to be 6 TB in size at most.  It is my understanding the
> 6TB recommendation was
> a daily server thruput maximum design target when dedup is in use.
>
> I agree, a processor at 100% is not good and I have been adjusting the
> server design to reduce
> the load.
>
> I started re-hosting our backup service on v6 as soon as v6 was available.
>  I started out
> deduping everything but quickly ran into performance problems.  To solve
> them I started excluding
> classes of data from dedup - all Oracle backups, all outlook PST files and
> any other file larger
> than 1 GB.  I also replaced all the disks I started with over 12 months and
> greatly expanded the
> total storage.
>
> Where the Redbook says that expiration is much improved, that is only
> partly true.  If dedup is involved,
> a hidden process starts after the visible expiration process is done and
> runs on for quite a while longer.
> This process has to check if a chuck in an expired file can truly be
> removed from storage because
> it could be that other files are pointing to that chunk.  You can see the
> process by entering
> 'show dedupdeleteinfo' after expiration completes.
>
> The thing about big files is that they are broken into lots of chunks.
>  When a big file is expired,
> this hidden process will take a long time to complete and can bog down the
> system.  This is the
> real reason I exclude some files from dedup.
>
> As for SATA, I have been using some big arrays (20 2TB disks, raid 6), 8
> such arrays, for 18 months
> and have had only 1 disk fail.  But I try not to abuse them.  Backups first
> go onto jbod
> disks - 15K rpm, 600GB - and all the dedup activity is done there.  The
> storagepools on those disks
> are then migrated to storagepools on the SATA arrays.  It is a mostly
> sequential process.
>
> I can only suggest that if your customer does storagepool backup from the
> SATA arrays after migration or
> reclaim, and the copypool is not dedup, then there would be a lot of random
> requests to the SATA storagepools
> to rehydrate the backups.
>
> Regards,
>
> Bill Colwell
> Draper Lab
>
> -Original Message-
> From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
> Daniel Sparrman
> Sent: Thursday, September 29, 2011 1:24 AM
> To: ADSM-L@VM.MARIST.EDU
> Subject: Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] vtl versus
> file systems for pirmary pool
>
> Like it says in the document, it's a recommendation and not a technical
> limit.
>
> However, having the server running at 100% utilization all the time doesnt
> seem like a healthy scenario.
>
> Why arent you deduplicating files larger than 1GB? From my experience,
> datafiles from SQL, Exchange and such has a very large de-dup ratio, while
> TSM's deduplication skips files smaller than 2KB?
>
> I have a customer up north who used this configuration on an HP EVA based
> box with SATA disks. The disks where breaking down so fast that the arrays
> within the box was in a constant "rebuild" phase. HP claimed it was TSM
> dedup that was breaking the disks (they actually claimed TSM was writing so
> often that the disks broke), a scenario I have very hard to believe.
>
> Best Regards
>
> Daniel
>
>
>
> Daniel Sparrman
> Exist i Stockholm AB
> Växel: 08-754 98 00
> Fax: 08-754 97 30
> daniel.sparr...@exist.se
> http://www.existgruppen.se
> Posthusgatan 1 761 30 NORRTÄLJE
>
>
>
> -"ADSM: Dist Stor Manager"  skrev: -
>
>
> Till: ADSM-L@VM.MARIST.EDU
> Från: "Colwell, William F." 
> Sänt av: "ADSM: Dist Stor Manager" 
> Datum: 09/28/2011 20:43
> Ärende: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] vtl versus file
> systems for pirmary pool
>
> Hi Daniel,
>
>
>
> I remember hearing about a 6 TB limit for dedup in a webinar or conference
> call,
>
> but what I recall is that that was a daily thruput limit.  In the same
> section of the
>
> redbook as you quote is this paragraph -
>
>
>
> Experienced administrators already know that Tivoli Storage Manager
> database expiration
>
> was one of the more processor-intensive activities on a Tivoli Storage
> Manager Server.
>
> Expiration is still processor intensive, albeit less so in Tivoli Storage
> Manager V6.1, but this is
>
> now second to deduplication in terms of consumption of processor cycles.
> Calculating the
>
> MD5 hash for each object and the SHA1 hash for each chunk is a processor
> intensi

Reuse Delay

[Harris, Chad]

Good Morning/Afternoon/Evening fellow TSM Adminers, 

I have a question to pose to the group about the Reuse Delay parameter and what 
is the best way to utilize or not utilize it on your storage pools.  I have 
come across two different schools of thought on this subject and before I do 
something rash and change a config setting, that might regret changing later, I 
thought I would pose the question to the group.  

One school of thought on this subject is to keep the reuse delay parameter of 
your primary pool set to zero days while setting the reuse delay parameter to 5 
on your copy pools.  The idea behind this being that even if you do need to 
restore your database to an older version the file references that are no 
longer available in your primary pool will still be available in your copy pool 
while letting you reuse volumes in your primary pools sooner.  

The second school of thought is that the reuse delay on your primary pool and 
your copy pool should both be the same giving you the greatest chance to cover 
your posterior in the event of a database meltdown since you will have two 
copies of the files that an older database version might reference.  

With all this in mind, I just wanted to see what method other TSM Admins 
thoughts about this are and what they are using in their environments.

Thanks,
Chad Harris

SV: Reuse Delay

[Christian Svensson]

Hi Chad,
If you have enough scratch tapes to use reuse delay on Primary Pool it will 
save you time if a DB corruption happened.

But maybe you should have different reuse delay values on Copypool and primary 
pool?
Let's say you only have 1-2 days on Primary Pool in case of the DB need to be 
recovered to early morning and longer retention on Copypool if a disaster 
happened.

Best Regards
Christian Svensson

Cell: +46-70-325 1577
E-mail: christian.svens...@cristie.se
Supported Platform for CPU2TSM:: 
http://www.cristie.se/cpu2tsm-supported-platforms


Från: Harris, Chad [c...@indiana.edu]
Skickat: den 4 oktober 2011 16:38
Till: ADSM-L@VM.MARIST.EDU
Ämne: Reuse Delay

Good Morning/Afternoon/Evening fellow TSM Adminers,

I have a question to pose to the group about the Reuse Delay parameter and what 
is the best way to utilize or not utilize it on your storage pools.  I have 
come across two different schools of thought on this subject and before I do 
something rash and change a config setting, that might regret changing later, I 
thought I would pose the question to the group.

One school of thought on this subject is to keep the reuse delay parameter of 
your primary pool set to zero days while setting the reuse delay parameter to 5 
on your copy pools.  The idea behind this being that even if you do need to 
restore your database to an older version the file references that are no 
longer available in your primary pool will still be available in your copy pool 
while letting you reuse volumes in your primary pools sooner.

The second school of thought is that the reuse delay on your primary pool and 
your copy pool should both be the same giving you the greatest chance to cover 
your posterior in the event of a database meltdown since you will have two 
copies of the files that an older database version might reference.

With all this in mind, I just wanted to see what method other TSM Admins 
thoughts about this are and what they are using in their environments.

Thanks,
Chad Harris

How to migrate 3592-E05 formatted tapes to 3592-E06 format

[Keith Arbogast]

We are buying some 3592-E06 drives to replace the 3592-E05 drives in our 3584 
tape libraries. The goal is to store more TB on the cartridges we already have. 
The 3592-E06 drives can read the E05 format, but they will write in E05 format 
too unless the tapes are re-formatted in the E06 format. So, we are wondering 
how best to migrate the E05 formatted tapes to the E06 format.

When we add the E06 drives we will remove the E05 drives.

Is this just a matter of; 1) reclaim the E05 tapes, 2) checkout the scratch 
tapes returned from reclamation, 3) 'label libv overwrite=yes' the just 
checked-out tapes.  

Or, is there a simpler, more efficient way to do this? Would new storage pools 
help in the transition?  

With my thanks,
Keith Arbogast

Re: How to migrate 3592-E05 formatted tapes to 3592-E06 format

[Robert J Molerio]

update the device class . see help update devclass

On Tue, Oct 4, 2011 at 10:50 AM, Keith Arbogast wrote:

> We are buying some 3592-E06 drives to replace the 3592-E05 drives in our
> 3584 tape libraries. The goal is to store more TB on the cartridges we
> already have. The 3592-E06 drives can read the E05 format, but they will
> write in E05 format too unless the tapes are re-formatted in the E06 format.
> So, we are wondering how best to migrate the E05 formatted tapes to the E06
> format.
>
> When we add the E06 drives we will remove the E05 drives.
>
> Is this just a matter of; 1) reclaim the E05 tapes, 2) checkout the scratch
> tapes returned from reclamation, 3) 'label libv overwrite=yes' the just
> checked-out tapes.
>
> Or, is there a simpler, more efficient way to do this? Would new storage
> pools help in the transition?
>
> With my thanks,
> Keith Arbogast

Strange behaviour...please Help

[Robert Ouzen]

Hi all

I run q libv I2000lib on my library here some of the output:

tsm: ADSM>q libv i2000lib

Library Name Volume Name Status   Owner  Last Use   
   HomeDevice

   Element Type
 ---  -- -  
   --- --
I2000LIB 01L2Private  ADSM   Data   
   4,150
I2000LIB 02L2Private  ADSM   Data   
   4,121
I2000LIB 04L2Private  ADSM   Data   
   4,110
I2000LIB 22L2Private  ADSM   Data   
   4,132
I2000LIB 23L2Private  ADSM   Data   
   4,116
I2000LIB 26L2Private  ADSM   Data   
   4,131
I2000LIB 29L2Private  ADSM   Data   
   4,100
I2000LIB 30L2Scratch
   4,122
I2000LIB 32L2Scratch
   4,174
I2000LIB 34L2Private  ADSM   Data   
   4,141
I2000LIB 35L2Scratch
   4,171
I2000LIB 59L2Private  ADSM   DbBackup   
   4,128
I2000LIB 65L2Scratch
   4,106
I2000LIB 66L2Scratch
   4,102
I2000LIB 71L2Private  ADSM   Data   
   4,115
I2000LIB 72L2Private  ADSM   Data   
   4,112
I2000LIB 75L2Scratch
   4,164
I2000LIB 80L2Private  ADSM   Data   
   4,098
I2000LIB 82L2Scratch
   4,178
I2000LIB 84L2Private  ADSM   Data   
   4,127
I2000LIB 87L2Private  ADSM   Data   
   4,124
I2000LIB 89L2Private  ADSM   Data   
   4,109
I2000LIB 93L2Scratch
   4,138
I2000LIB 97L2Private  ADSM   Data   
   4,189
I2000LIB 000100L2Private  ADSM   Data   
   4,105
I2000LIB 000103L2Private  ADSM   DbBackup   
   4,104

But trying to view more details of some volumes (a few) as volume 01L2 
running the command: q vol 01L2  f=d

I got:
tsm: ADSM>q vol 01L2 f=d
ANR2034E QUERY VOLUME: No match found using this criteria.
ANS8001I Return code 11.

I did more investigation on each storage pool using this library  as q vol * 
stg=I-SAPDB …..

No record at all about volume 01L2 and another few volumes with the same 
behavior in any storage .

How can I eliminate  those volumes.

My environment is TSM V5.5.2.0 on ADSM: AIX-RS/6000

Any help will be really appreciate.

Regards Robert Ouzen

Re: Strange behaviour...please Help

[Remco Post]

Hi Robert,

TSM can and will mark a volume as private when a write error is encountered on 
a scratch volume to prevent reuse. It's worth investigating if that could have 
been the case. You may find recent cases in the actlog.

If you had a defective drive that (possibly) cause this, you could update 
libvol l2000lib 01L2 stat=scr (for example)
If you suspect the media, just checkout libvol and destroy LTO2 tapes could 
be quite worn out by now, depending on their usage history


On 4 okt. 2011, at 19:48, Robert Ouzen wrote:

> Hi all
> 
> I run q libv I2000lib on my library here some of the output:
> 
> tsm: ADSM>q libv i2000lib
> 
> Library Name Volume Name Status   Owner  Last Use 
>  HomeDevice
>   
> Element Type
>  ---  -- 
> - --- --
> I2000LIB 01L2Private  ADSM   Data 
>  4,150
> I2000LIB 02L2Private  ADSM   Data 
>  4,121
> I2000LIB 04L2Private  ADSM   Data 
>  4,110
> I2000LIB 22L2Private  ADSM   Data 
>  4,132
> I2000LIB 23L2Private  ADSM   Data 
>  4,116
> I2000LIB 26L2Private  ADSM   Data 
>  4,131
> I2000LIB 29L2Private  ADSM   Data 
>  4,100
> I2000LIB 30L2Scratch  
>  4,122
> I2000LIB 32L2Scratch  
>  4,174
> I2000LIB 34L2Private  ADSM   Data 
>  4,141
> I2000LIB 35L2Scratch  
>  4,171
> I2000LIB 59L2Private  ADSM   DbBackup 
>  4,128
> I2000LIB 65L2Scratch  
>  4,106
> I2000LIB 66L2Scratch  
>  4,102
> I2000LIB 71L2Private  ADSM   Data 
>  4,115
> I2000LIB 72L2Private  ADSM   Data 
>  4,112
> I2000LIB 75L2Scratch  
>  4,164
> I2000LIB 80L2Private  ADSM   Data 
>  4,098
> I2000LIB 82L2Scratch  
>  4,178
> I2000LIB 84L2Private  ADSM   Data 
>  4,127
> I2000LIB 87L2Private  ADSM   Data 
>  4,124
> I2000LIB 89L2Private  ADSM   Data 
>  4,109
> I2000LIB 93L2Scratch  
>  4,138
> I2000LIB 97L2Private  ADSM   Data 
>  4,189
> I2000LIB 000100L2Private  ADSM   Data 
>  4,105
> I2000LIB 000103L2Private  ADSM   DbBackup 
>  4,104
> 
> But trying to view more details of some volumes (a few) as volume 01L2 
> running the command: q vol 01L2  f=d
> 
> I got:
> tsm: ADSM>q vol 01L2 f=d
> ANR2034E QUERY VOLUME: No match found using this criteria.
> ANS8001I Return code 11.
> 
> I did more investigation on each storage pool using this library  as q vol * 
> stg=I-SAPDB …..
> 
> No record at all about volume 01L2 and another few volumes with the same 
> behavior in any storage .
> 
> How can I eliminate  those volumes.
> 
> My environment is TSM V5.5.2.0 on ADSM: AIX-RS/6000
> 
> Any help will be really appreciate.
> 
> Regards Robert Ouzen

-- 
Met vriendelijke groeten/Kind Regards,

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

Re: How to migrate 3592-E05 formatted tapes to 3592-E06 format

[Keith Arbogast]

Robert et al;
Will updating the device class make the new drives write files to tapes in E06 
format which have previously been formatted and written to in E05 format? 
Filling volumes would then have a mixture of E05 and E06 formats. Will TSM do 
that?  Are the device drivers, or what not, smart enough to read tape content 
of mixed formats without a hiccup?

Thank you,
Keith


   

Re: Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] vtl versus file systems for pirmary pool

[Shawn Drew]

The other side of this is that with 3rd party deduplicated replication, my 
offsite copy is rarely more than one hour behind the source copy.  Before 
I moved to this, we would schedule our backup-stg pools to run once a day, 
and they would have to run several hours before it was in sync.   If there 
was a real DR situation, we would lose much more data by being up to 
24-hours out of sync with the old "backup-stg" solution.   And it's always 
recent "just backed-up" data that is the most desirable after a DR 
situation. 

 The chances of a real DR situation seem higher to me than a logical 
error.  Perhaps just feeling like that after seeing a minor earthquake and 
a hurricane within a couple weeks of each other. 

 I have seen a few logical errors and a few DR situations in my career and 
even in my conservative bank environment, a 
single-pool-3rd-party-replicated is lower risk than the slow-backup-stg 
solution.  We still keep periodic longer term backups on Tape, so we would 
have a "last resort" restore source if there was a logical error, but it 
is still not a daily backup.

In the end, its a risk trade-off decision that you have to make for 
yourself.  And decide if you can afford the time that a backup-stg takes 
each day. 


Regards, 
Shawn

Shawn Drew





Internet
steven.langd...@gmail.com

Sent by: ADSM-L@VM.MARIST.EDU
10/04/2011 02:57 AM
Please respond to
ADSM-L@VM.MARIST.EDU


To
ADSM-L
cc

Subject
Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: 
Re: [ADSM-L] vtl versus file systems for pirmary pool






The "logical error" question has come up before.  With no TSM managed copy
pool you are perhaps at a slightly higher risk.

An option is to still have a copy pool, but on the same DD.  So little 
real
disk usage, but some protection from a TSM logical error.  That obviously
does not protect you from a DD induced one.

FWIW, when we implement VTL's, and if the bandwidth allows, we use TSM to
create the copy.  Small sites with limited bandwidth, we rely on the
appliance.

Steven



On 4 October 2011 06:41, Daniel Sparrman  wrote:

> > If someone puts a high-caliber bullet through my Gainesville DD, then
> > I recover it from the replicated offsite DD, perhaps selecting a
> snapshot.
> >
> > If someone puts a high-caliber bullet through both of them, then I
> > have lost my backups of a bunch of important databases.
>
> And if you have a logical error on your primary box, which is then
> replicated to your 2nd box? Or even worse, a hash conflict?
>
> I dont consider someone putting a bullet through both the boxes a high
> risk, I do however consider other errors to be more of a high risk.
>
> Best Regards
>
> Daniel
>
>
>
>
>
> Daniel Sparrman
> Exist i Stockholm AB
> Växel: 08-754 98 00
> Fax: 08-754 97 30
> daniel.sparr...@exist.se
> http://www.existgruppen.se
> Posthusgatan 1 761 30 NORRTÄLJE
>
>
> -"ADSM: Dist Stor Manager"  skrev: -
> Till: ADSM-L@VM.MARIST.EDU
> Från: "Allen S. Rout"
> Sänt av: "ADSM: Dist Stor Manager"
> Datum: 10/03/2011 23:38
> Ärende: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: 
[ADSM-L]
> vtl versus file systems for pirmary pool
>
> On 09/28/2011 02:16 AM, Daniel Sparrman wrote:
>
> > In this mail, it really sounds like you're using your DD as both
> > primary storage and for TSM storage.
>
> I am, right now, using the DD as a target for direct-written database
> backups, only.  So that's not really "primary storage", as I think
> about it.
>
>
> > If the DD box fails, what are your losses?
>
> If someone puts a high-caliber bullet through my Gainesville DD, then
> I recover it from the replicated offsite DD, perhaps selecting a 
snapshot.
>
> If someone puts a high-caliber bullet through both of them, then I
> have lost my backups of a bunch of important databases.
>
>
>
> > Sorry for all the questions, I'm just trying to get an idea how
> > you're using this box.
>
> No problem. Our conversation is fuzzed by the fact that I am also
> talking about how one _might_ use it for TSM storage.  I'm
> contemplating it, but not doing it at the moment.
>
> > [ ... if you lose a DD, then ... ] you have to restore the data from
> > somewhere else (tape?).
>
>
> In my planning, the DD gets copied / offsited to a remote DD, so
> that's the somewhere else.
>
> - Allen S. Rout
>



This message and any attachments (the "message") is intended solely for 
the addressees and is confidential. If you receive this message in error, 
please delete it and immediately notify the sender. Any use not in accord 
with its purpose, any dissemination or disclosure, either whole or partial, 
is prohibited except formal approval. The internet can not guarantee the 
integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) 
not therefore be liable for the message if modified. Please note that certain 
functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.

Re: Reuse Delay

[Shawn Drew]

A non-zero reuse delay on your primary pool protects you from a situation
where you need to restore your database, but your primary pool tapes are
not lost.  (Not a full DR situation).

If you have a reuse delay of 0, you will still have the data available in
the copypool, but if you wanted to get back into a full production state,
you will need to audit all the volumes in your primary storage pool and
rebuild the lost data from the copypool.  (You will be able to service
restore requests during this time, but it will take a long time to fully
recover)  If you don't have than many volumes in the pool and a small
library, it might be worth it.

Ideally, if you can afford the slots and tapes, you would have a reuse
delay on both pools that will match the amount of time you retain your DB
backups.

Regards,
Shawn

Shawn Drew





Internet
c...@indiana.edu

Sent by: ADSM-L@VM.MARIST.EDU
10/04/2011 10:38 AM
Please respond to
ADSM-L@VM.MARIST.EDU


To
ADSM-L
cc

Subject
[ADSM-L] Reuse Delay






Good Morning/Afternoon/Evening fellow TSM Adminers,

I have a question to pose to the group about the Reuse Delay parameter and
what is the best way to utilize or not utilize it on your storage pools. I
have come across two different schools of thought on this subject and
before I do something rash and change a config setting, that might regret
changing later, I thought I would pose the question to the group.

One school of thought on this subject is to keep the reuse delay parameter
of your primary pool set to zero days while setting the reuse delay
parameter to 5 on your copy pools.  The idea behind this being that even
if you do need to restore your database to an older version the file
references that are no longer available in your primary pool will still be
available in your copy pool while letting you reuse volumes in your
primary pools sooner.

The second school of thought is that the reuse delay on your primary pool
and your copy pool should both be the same giving you the greatest chance
to cover your posterior in the event of a database meltdown since you will
have two copies of the files that an older database version might
reference.

With all this in mind, I just wanted to see what method other TSM Admins
thoughts about this are and what they are using in their environments.

Thanks,
Chad Harris



This message and any attachments (the "message") is intended solely for
the addressees and is confidential. If you receive this message in error,
please delete it and immediately notify the sender. Any use not in accord
with its purpose, any dissemination or disclosure, either whole or partial,
is prohibited except formal approval. The internet can not guarantee the
integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will)
not therefore be liable for the message if modified. Please note that certain
functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.

Re: How to migrate 3592-E05 formatted tapes to 3592-E06 format

[Robert J Molerio]

Yes.

But to be sure open up a ticket with TSM support to verify this. We did this
using TSM v 6.2.x and it worked fine.

On Tue, Oct 4, 2011 at 2:05 PM, Keith Arbogast  wrote:

> Robert et al;
> Will updating the device class make the new drives write files to tapes in
> E06 format which have previously been formatted and written to in E05
> format? Filling volumes would then have a mixture of E05 and E06 formats.
> Will TSM do that?  Are the device drivers, or what not, smart enough to read
> tape content of mixed formats without a hiccup?
>
> Thank you,
> Keith
>
>
>

Re: How to migrate 3592-E05 formatted tapes to 3592-E06 format

[Keith Arbogast]

Robert,
Thank you, I just did. We're on 6.2.2 also.  I'll update the thread when they 
respond.

Best wishes,
Keith

Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] vtl versus file systems for pirmary pool

[Daniel Sparrman]

Not entirely true since you dont have todo backup stgpool as a only resort with 
TSM 6.2. Since the simultaneous copy feature is now not only available for 
client, but for server processes, there is nothing saying you have to copy all 
the data by using backup stgpool.

And it's not a matter if it's a risk or not getting a logical error. The risk 
is there, and if it hits you, you dont loose a few hours of data. A hash 
conflict would strike you across both primary and secondary storage, and it 
could strike you for a huge amount of data if you're unlucky. You get a hash 
conflict on a common hash key, and it could strike you all across the board.

So, having your offsite replicated within the hour instead of 4 hours with the 
risk of loosing most of it, or letting it take 4 hours, but be sure you'll be 
able to recover?

The descriptions around here sometimes scares me (not in particular this 
description). Some people seem to think that 0.1% chance of loosing it all is 
worth it for other benefits.

If you told your boss (not your IT manager, but your business developer for 
example) that there's a 0.1% chance you'll loose all your backups and all your 
versions, think he'd be ok with it? My guess? I'd say he wouldnt even answer 
it...

If you feel replication is such a good way of going, you can always go sync or 
async mirroring instead. You're doing just the same (since you can actually 
have verification on your mirroring). You're syncing/replicating bits and 
bytes, but there's no way for the mirroring / replication to be sure it's 
actually readable for the app. Unlike having your app creating a 2ndary copy.

Best Regards & nice evening

Daniel


Daniel Sparrman
Exist i Stockholm AB
Växel: 08-754 98 00
Fax: 08-754 97 30
daniel.sparr...@exist.se
http://www.existgruppen.se
Posthusgatan 1 761 30 NORRTÄLJE


-"ADSM: Dist Stor Manager"  skrev: - 
Till: ADSM-L@VM.MARIST.EDU
Från: Shawn Drew 
Sänt av: "ADSM: Dist Stor Manager" 
Datum: 10/04/2011 20:17
Ärende: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: 
Re: [ADSM-L] vtl versus file systems for pirmary pool

The other side of this is that with 3rd party deduplicated replication, my 
offsite copy is rarely more than one hour behind the source copy.  Before 
I moved to this, we would schedule our backup-stg pools to run once a day, 
and they would have to run several hours before it was in sync.   If there 
was a real DR situation, we would lose much more data by being up to 
24-hours out of sync with the old "backup-stg" solution.   And it's always 
recent "just backed-up" data that is the most desirable after a DR 
situation. 

 The chances of a real DR situation seem higher to me than a logical 
error.  Perhaps just feeling like that after seeing a minor earthquake and 
a hurricane within a couple weeks of each other. 

 I have seen a few logical errors and a few DR situations in my career and 
even in my conservative bank environment, a 
single-pool-3rd-party-replicated is lower risk than the slow-backup-stg 
solution.  We still keep periodic longer term backups on Tape, so we would 
have a "last resort" restore source if there was a logical error, but it 
is still not a daily backup.

In the end, its a risk trade-off decision that you have to make for 
yourself.  And decide if you can afford the time that a backup-stg takes 
each day. 


Regards, 
Shawn

Shawn Drew





Internet
steven.langd...@gmail.com

Sent by: ADSM-L@VM.MARIST.EDU
10/04/2011 02:57 AM
Please respond to
ADSM-L@VM.MARIST.EDU


To
ADSM-L
cc

Subject
Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: 
Re: [ADSM-L] vtl versus file systems for pirmary pool






The "logical error" question has come up before.  With no TSM managed copy
pool you are perhaps at a slightly higher risk.

An option is to still have a copy pool, but on the same DD.  So little 
real
disk usage, but some protection from a TSM logical error.  That obviously
does not protect you from a DD induced one.

FWIW, when we implement VTL's, and if the bandwidth allows, we use TSM to
create the copy.  Small sites with limited bandwidth, we rely on the
appliance.

Steven



On 4 October 2011 06:41, Daniel Sparrman  wrote:

> > If someone puts a high-caliber bullet through my Gainesville DD, then
> > I recover it from the replicated offsite DD, perhaps selecting a
> snapshot.
> >
> > If someone puts a high-caliber bullet through both of them, then I
> > have lost my backups of a bunch of important databases.
>
> And if you have a logical error on your primary box, which is then
> replicated to your 2nd box? Or even worse, a hash conflict?
>
> I dont consider someone putting a bullet through both the boxes a high
> risk, I do however consider other errors to be more of a high risk.
>
> Best Regards
>
> Daniel
>
>
>
>
>
> Daniel Sparrman
> Exist i Stockholm AB
> Växel: 08-754 98 00
> Fax: 08-754 97 30
> daniel.sparr...@exist

Re: Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] vtl versus file systems for pirmary pool

[Shawn Drew]

We were using the copystg feature of the storage pools before, and even 
then our TSM cycle was growing, growing and eventually passed 24 hours. 
For us, it wasn't 4 hours vs 1 hour.  It was 24+hours+finger crossing vs 
one hour.  We reached the point where we had to kill the backup-stg's and 
try and catch up on the weekends.

As far as the hash conflict, I think all of these systems use 
cryptographic level hashes (MD5/SHA1). From my understanding, the chances 
of a collision are way, way, exponentially lower than .1%.  Where did that 
number come from, Is that a commonly accepted number for this issue? Maybe 
I'm not understanding the proposed error. Are you referring to a 
cryptographic hash collision? or something else? 

In order to update our environment to handle the traditional TSM copypool 
architecture, we would have had to spend an additional million dollars (at 
a minimum) and many more expensive WAN links.   Considering this is for 
short-term data (30 days or less) , we still have weekly tape backups, and 
I've never seen anything to convince me that the chances of these specific 
errors are anywhere near the quoted .1%,  I'm still confident this was the 
right move for us. 

I do keep looking for where I could be wrong, so I want to make sure I 
completely understand what you are saying.

Regards, 
Shawn

Shawn Drew





Internet
daniel.sparr...@exist.se

Sent by: ADSM-L@VM.MARIST.EDU
10/04/2011 04:44 PM
Please respond to
ADSM-L@VM.MARIST.EDU


To
ADSM-L
cc

Subject
[ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: 
[ADSM-L] Ang: Re: [ADSM-L] vtl versus file systems for pirmary pool






Not entirely true since you dont have todo backup stgpool as a only resort 
with TSM 6.2. Since the simultaneous copy feature is now not only 
available for client, but for server processes, there is nothing saying 
you have to copy all the data by using backup stgpool.

And it's not a matter if it's a risk or not getting a logical error. The 
risk is there, and if it hits you, you dont loose a few hours of data. A 
hash conflict would strike you across both primary and secondary storage, 
and it could strike you for a huge amount of data if you're unlucky. You 
get a hash conflict on a common hash key, and it could strike you all 
across the board.

So, having your offsite replicated within the hour instead of 4 hours with 
the risk of loosing most of it, or letting it take 4 hours, but be sure 
you'll be able to recover?

The descriptions around here sometimes scares me (not in particular this 
description). Some people seem to think that 0.1% chance of loosing it all 
is worth it for other benefits.

If you told your boss (not your IT manager, but your business developer 
for example) that there's a 0.1% chance you'll loose all your backups and 
all your versions, think he'd be ok with it? My guess? I'd say he wouldnt 
even answer it...

If you feel replication is such a good way of going, you can always go 
sync or async mirroring instead. You're doing just the same (since you can 
actually have verification on your mirroring). You're syncing/replicating 
bits and bytes, but there's no way for the mirroring / replication to be 
sure it's actually readable for the app. Unlike having your app creating a 
2ndary copy.

Best Regards & nice evening

Daniel


Daniel Sparrman
Exist i Stockholm AB
Växel: 08-754 98 00
Fax: 08-754 97 30
daniel.sparr...@exist.se
http://www.existgruppen.se
Posthusgatan 1 761 30 NORRTÄLJE


-"ADSM: Dist Stor Manager"  skrev: - 
Till: ADSM-L@VM.MARIST.EDU
Från: Shawn Drew 
Sänt av: "ADSM: Dist Stor Manager" 
Datum: 10/04/2011 20:17
Ärende: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] 
Ang: Re: [ADSM-L] vtl versus file systems for pirmary pool

The other side of this is that with 3rd party deduplicated replication, my 

offsite copy is rarely more than one hour behind the source copy.  Before 
I moved to this, we would schedule our backup-stg pools to run once a day, 

and they would have to run several hours before it was in sync.   If there 

was a real DR situation, we would lose much more data by being up to 
24-hours out of sync with the old "backup-stg" solution.   And it's always 

recent "just backed-up" data that is the most desirable after a DR 
situation. 

 The chances of a real DR situation seem higher to me than a logical 
error.  Perhaps just feeling like that after seeing a minor earthquake and 

a hurricane within a couple weeks of each other. 

 I have seen a few logical errors and a few DR situations in my career and 

even in my conservative bank environment, a 
single-pool-3rd-party-replicated is lower risk than the slow-backup-stg 
solution.  We still keep periodic longer term backups on Tape, so we would 

have a "last resort" restore source if there was a logical error, but it 
is still not a daily backup.

In the end, its a risk trade-off decision that you have

Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] vtl versus file systems for pirmary pool

[Daniel Sparrman]

Not really sure why you would need +24 hours to handle copying data to your 
secondary site.

With features like:

- Copy storage pool feature for client backups
- Copy storage pool feature on migration
- Normal backup storage pool

With the first 2, there shouldnt really be much data left to copy for the 3rd 
one. I've seen sites handling up to 35TB per day using these features and they 
never had to spend 24 hours doing backup storagepool.

Ofc, it also depends on the throughput your getting. There are VTL's out there 
that can handle up to 45TB/hour that costs alot less than 1 million. However, 
it does require the infrastructure (fiber) connections to reach those numbers.

As with the hash conflict, the DD uses SHA-1 with a variable block length for 
deduplication. Theoretically, there is a 2^160 chance it will happen. Doesnt 
seem to be that bad, but your first hash collision is randomly more likely to 
happen than that number suggests.

Best Regards

Daniel


Daniel Sparrman
Exist i Stockholm AB
Växel: 08-754 98 00
Fax: 08-754 97 30
daniel.sparr...@exist.se
http://www.existgruppen.se
Posthusgatan 1 761 30 NORRTÄLJE


-"ADSM: Dist Stor Manager"  skrev: - 
Till: ADSM-L@VM.MARIST.EDU
Från: Shawn Drew 
Sänt av: "ADSM: Dist Stor Manager" 
Datum: 10/05/2011 00:14
Ärende: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: 
Re: [ADSM-L] Ang: Re: [ADSM-L] vtl versus file systems for pirmary pool

We were using the copystg feature of the storage pools before, and even 
then our TSM cycle was growing, growing and eventually passed 24 hours. 
For us, it wasn't 4 hours vs 1 hour.  It was 24+hours+finger crossing vs 
one hour.  We reached the point where we had to kill the backup-stg's and 
try and catch up on the weekends.

As far as the hash conflict, I think all of these systems use 
cryptographic level hashes (MD5/SHA1). From my understanding, the chances 
of a collision are way, way, exponentially lower than .1%.  Where did that 
number come from, Is that a commonly accepted number for this issue? Maybe 
I'm not understanding the proposed error. Are you referring to a 
cryptographic hash collision? or something else? 

In order to update our environment to handle the traditional TSM copypool 
architecture, we would have had to spend an additional million dollars (at 
a minimum) and many more expensive WAN links.   Considering this is for 
short-term data (30 days or less) , we still have weekly tape backups, and 
I've never seen anything to convince me that the chances of these specific 
errors are anywhere near the quoted .1%,  I'm still confident this was the 
right move for us. 

I do keep looking for where I could be wrong, so I want to make sure I 
completely understand what you are saying.

Regards, 
Shawn

Shawn Drew





Internet
daniel.sparr...@exist.se

Sent by: ADSM-L@VM.MARIST.EDU
10/04/2011 04:44 PM
Please respond to
ADSM-L@VM.MARIST.EDU


To
ADSM-L
cc

Subject
[ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: 
[ADSM-L] Ang: Re: [ADSM-L] vtl versus file systems for pirmary pool






Not entirely true since you dont have todo backup stgpool as a only resort 
with TSM 6.2. Since the simultaneous copy feature is now not only 
available for client, but for server processes, there is nothing saying 
you have to copy all the data by using backup stgpool.

And it's not a matter if it's a risk or not getting a logical error. The 
risk is there, and if it hits you, you dont loose a few hours of data. A 
hash conflict would strike you across both primary and secondary storage, 
and it could strike you for a huge amount of data if you're unlucky. You 
get a hash conflict on a common hash key, and it could strike you all 
across the board.

So, having your offsite replicated within the hour instead of 4 hours with 
the risk of loosing most of it, or letting it take 4 hours, but be sure 
you'll be able to recover?

The descriptions around here sometimes scares me (not in particular this 
description). Some people seem to think that 0.1% chance of loosing it all 
is worth it for other benefits.

If you told your boss (not your IT manager, but your business developer 
for example) that there's a 0.1% chance you'll loose all your backups and 
all your versions, think he'd be ok with it? My guess? I'd say he wouldnt 
even answer it...

If you feel replication is such a good way of going, you can always go 
sync or async mirroring instead. You're doing just the same (since you can 
actually have verification on your mirroring). You're syncing/replicating 
bits and bytes, but there's no way for the mirroring / replication to be 
sure it's actually readable for the app. Unlike having your app creating a 
2ndary copy.

Best Regards & nice evening

Daniel


Daniel Sparrman
Exist i Stockholm AB
Växel: 08-754 98 00
Fax: 08-754 97 30
daniel.sparr...@exist.se
http://www.existgruppen.se
Posthusgatan 1 761 30 NORRTÄLJE