Re: primary and copy storage pool comparisons

2006-08-04 Thread Choudarapu, Ramakrishna (GTI)
select stgpool_name,sum(num_files) as total_files, sum(logical_mb)as
total_logical_mb from occupancy group by stgpool_name

Regards,
Rama

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Whitlock, Brett
Sent: Thursday, August 03, 2006 5:09 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] primary and copy storage pool comparisons


query occupancy 

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Tim Brown
Sent: Thursday, August 03, 2006 12:19 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] primary and copy storage pool comparisons

I thought once I used a command that would compare the primary and copy
storage pools, showing whether or not they are in sync.

Does anyone know of this or am I just mistaken.

Tim Brown
Systems Specialist
Central Hudson Gas & Electric
284 South Ave
Poughkeepsie, NY 12601
Email: [EMAIL PROTECTED]
Phone: 845-486-5643
Fax: 845-486-5921
Cell: 845-235-4255


If you are not an intended recipient of this e-mail, please notify the sender, 
delete it and do not read, act upon, print, disclose, copy, retain or 
redistribute it. Click here for important additional terms relating to this 
e-mail. http://www.ml.com/email_terms/



Re: primary and copy storage pool comparisons

2006-08-04 Thread Richard Sims

Tim -

See "Copy Storage Pool up to date?"
in  http://people.bu.edu/rbs/ADSM.QuickFacts .

   Richard Sims


Re: backup schedule question?

2006-08-04 Thread Steve Harris
Joni,

Just code it up and run a q event against it with begind=+0 and endd=+14.
It will show you exactly when the chedule will be run.

Regards

Steve

Steve Harris
AIX and TSM Admin
Brisbane Australia

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Joni Moyer
Sent: Friday, 4 August 2006 4:00 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] backup schedule question?

Hello Rama,

I don't have the TSM server at 5.3 yet.  I am only at 5.2.7.1, so I don't
believe that that capability is there for my level of TSM code.  Is that
correct?


Joni Moyer
Highmark
Storage Systems, Senior Systems Programmer
Phone Number: (717)302-9966
Fax: (717) 302-9826
[EMAIL PROTECTED]




"Choudarapu, Ramakrishna (GTI)" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" 
08/03/2006 01:10 PM
Please respond to
"ADSM: Dist Stor Manager" 


To
ADSM-L@VM.MARIST.EDU
cc

Subject
Re: backup schedule question?






Use SCHEDStyle=Enhanced and DAYofweek=M,W,F

Regards,
Rama

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Joni Moyer
Sent: Thursday, August 03, 2006 12:51 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] backup schedule question?


Hey Everyone!

I need a backup to run on Monday, Wednesday and Friday only.  If I
create
a backup schedule that starts on a Monday, Period = 2, Period Unit=Days,
Day of Week=weekday will this backup schedule always run on Monday, Wed,
Friday only?  Or will it begin by running on M,W,F and then since Sunday
isn't a weekday it will then run on Tues, Thurs.  of the next week?
Thanks
in advance for your help with this matter!


Joni Moyer
Highmark
Storage Systems, Senior Systems Programmer
Phone Number: (717)302-9966
Fax: (717) 302-9826
[EMAIL PROTECTED]



If you are not an intended recipient of this e-mail, please notify the
sender, delete it and do not read, act upon, print, disclose, copy, retain
or redistribute it. Click here for important additional terms relating to
this e-mail. http://www.ml.com/email_terms/



SV: Need help with Bare Metal backup/restore on XP

2006-08-04 Thread Christian Svensson
Hi Ila,
You can always use IBM recommended software CBMR.
Talk to your IBM TSM contact person.

Thanks
Christian

-Ursprungligt meddelande-
Från: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] För Ila Patel
Skickat: den 3 augusti 2006 17:28
Till: ADSM-L@VM.MARIST.EDU
Ämne: Need help with Bare Metal backup/restore on XP

Hi All,

Can anyone please tell me if it possible to do a bare metal backup/restore
 of windows XP from incremental nightly backups?  Enduser makes change
weekly.
beside ASR.



Ila


Re: backup schedule question?

2006-08-04 Thread Choudarapu, Ramakrishna (GTI)
Joni,

You are right.

Seems, the only way out is to define three different schedules, one each
for Mon, Wed and Fri, as Kurt suggested...

Regards,
Rama

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Joni Moyer
Sent: Thursday, August 03, 2006 2:00 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] backup schedule question?


Hello Rama,

I don't have the TSM server at 5.3 yet.  I am only at 5.2.7.1, so I
don't
believe that that capability is there for my level of TSM code.  Is that
correct?


Joni Moyer
Highmark
Storage Systems, Senior Systems Programmer
Phone Number: (717)302-9966
Fax: (717) 302-9826
[EMAIL PROTECTED]




"Choudarapu, Ramakrishna (GTI)" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" 
08/03/2006 01:10 PM
Please respond to
"ADSM: Dist Stor Manager" 


To
ADSM-L@VM.MARIST.EDU
cc

Subject
Re: backup schedule question?






Use SCHEDStyle=Enhanced and DAYofweek=M,W,F

Regards,
Rama

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Joni Moyer
Sent: Thursday, August 03, 2006 12:51 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] backup schedule question?


Hey Everyone!

I need a backup to run on Monday, Wednesday and Friday only.  If I
create
a backup schedule that starts on a Monday, Period = 2, Period Unit=Days,
Day of Week=weekday will this backup schedule always run on Monday, Wed,
Friday only?  Or will it begin by running on M,W,F and then since Sunday
isn't a weekday it will then run on Tues, Thurs.  of the next week?
Thanks
in advance for your help with this matter!


Joni Moyer
Highmark
Storage Systems, Senior Systems Programmer
Phone Number: (717)302-9966
Fax: (717) 302-9826
[EMAIL PROTECTED]



If you are not an intended recipient of this e-mail, please notify the
sender, delete it and do not read, act upon, print, disclose, copy,
retain
or redistribute it. Click here for important additional terms relating
to
this e-mail. http://www.ml.com/email_terms/



Strange Admin Schedule/Script behavior

2006-08-04 Thread Timothy Hughes
Hello,

I have a Admin Schedule/Script that runs the following Housecleaning
tasks,
daily which has been working fine months. This morning though the
BA STG Backuppool rmtpool process and the Migrate Stgpool process
was ACTIVE at the same time! I checked the log an it shows nothing
as to why this happened as you can see the the Migrate Process
should WAIT UNTIL the BA STG backuppool process ends before
starting which it has been doing. This could be just a isolated
incident not sure has this ever happened to anyone else?
Any guesses?

serial
BACKUP DB DEVCLASS=BKP TYPE=INCREMENTAL wait=yes
serial
BA STG backuppool rmpool maxpr=2 wait=yes
serial
migrate stgpool backuppool lowmig=0 wait=yes
serial
Ba STG LTpool RMpool maxpr=2 wait=yes
serial
expire inventory



F.Y.I - Automatic Migration has been turned off for a while.


TSM 5.3.3.2
AIX 5.3

Thanks for any help or suggestions!


56 Backup Storage Pool  Primary Pool BACKUPPOOL, Copy Pool RMPOOL, Files

Backed Up: 1232, Bytes Backed Up: 122,055,233,5
36, Unreadable Files: 0, Unreadable Bytes: 0.
Current Physical File (bytes): 4,195,590,144
Current output volume: A00251.


57 Backup Storage Pool  Primary Pool BACKUPPOOL, Copy Pool RMPOOL, Files

Backed Up: 8952, Bytes Backed Up: 110,488,518,6
56, Unreadable Files: 0, Unreadable Bytes: 0.
Current Physical File (bytes): 4,296,290,304
Current output volume: A00254.

60 Migration  Disk Storage Pool BACKUPPOOL, Moved Files: 0,
 Moved Bytes: 0, Unreadable Files: 0, Unreadable
 Bytes: 0. Current Physical File (bytes):
 32,520,241,152 Current output volume: 100275.


61 Migration  Disk Storage Pool BACKUPPOOL, Moved Files: 314,
 Moved Bytes: 6,635,995,136, Unreadable Files: 0,
 Unreadable Bytes: 0. Current Physical File
 (bytes): 8,592,568,320 Current output volume:100273.


Re: Using tsm-encryption and want to change the hostname at the Client

2006-08-04 Thread Alexei Kojenov
Rainer,

The windows client is using computername to encrypt passwords in registry.
When one changes computername, the stored passwords also become invalid. So
on Windows, you should do the same , i.e. delete (or rename, just in case)
the corresponding registry entries which are currently located under
HKLM\SOFTWARE\IBM\ADSM\CurrentVersion\BackupClient\Nodes
Unfortunately, there is no TSM command or utility for doing that.

You are right, TSM should not be using wrong encryption key. As a matter of
fact, there is already an APAR - please see IC48782:
http://www-1.ibm.com/support/docview.wss?uid=swg1IC48782
It was fixed on Mac in 5.3.4 and is planned to be fixed on unix, linux and
windows in 5.4.0.

Alexei Kojenov
TSM Client Development


"ADSM: Dist Stor Manager"  wrote on 07/31/2006
11:12:48 PM:

> Alexei,
> thanks a lot for your detailled explanation  !  It's clearer to me now
:-)
> ... just only two more questions ?
> What about the windows-Clients - do I then (when changing the
> windows system-name)
> also have to manually remove the  equivalent 'TSM.PWD' entry
> in the registry or elsewhere ?
> if so: Is that something to be done with the windows registry-editor
> or is there a tsm-windows-client function that can do for me the
> renaming/refresh of the locally stored tsm-pwds on windows so I can
reenter
> the (same) encryption key passord once again ?
>
> About the 'using some garbage encryption key' : Isn't that something
> where the tsm-client really should say 'NO'
> stop backup and generate an error message ?
> ... preventing the user to have something unrecoverable
> - is there an existing apar ?
>
> Best regards
> Rainer
>
>
> Alexei Kojenov schrieb:
>
> > Rainer,
> >
> > Your data is always encrypted with the key generated from the password
that
> > you enter, regardless of the hostname. The hostname is only used to
store
> > the password locally. For example,
> >
> > 1) Let's say the hostname is 'mercury'
> > 2) You run your first backup and are prompted for encryption key
password.
> > Let's say you enter 'secret'
> > 3) The string 'secret' is encrypted with 'mercury' and is stored in
TSM.PWD
> > 4) The data are encrypted with 'secret'.
> > 5) On the next backup, the stored password is retrieved from TSM.PWD
and
> > decrypted with 'mercury', and 'secret' is used for data backup.
> >
> > 6) Let's say you change the hostname to 'venus' and delete/rename
existing
> > TSM.PWD
> > 7) TSM prompts you for encryption key password and you enter 'secret'
> > again.
> > 8) 'secret' is encrypted with 'venus' and is stored in TSM.PWD (note,
> > TSM.PWD will binary differ from the one from step 3, because the key,
which
> > is dependent on hostname, is different)
> > 9) The data are encrypted with 'secret' (the same as in step 4,
regardless
> > of hostname).
> > 10) On the next backup, stored password is decrypted with 'venus', and
the
> > same password 'secret' is used for backup.
> >
> > So you shouldn't worry about validity of your old backups as long as
you
> > use the same encryption password and you deleted/renamed TSM.PWD when
> > changing the hostname.
> >
> > The problems come when someone changes the hostname bud does not delete
> > TSM.PWD. In the example above, a backup following the hostname change
will
> > try to decrypt stored password with 'venus' and will get an incorrect
> > result (because 'secret' was originally encrypted with 'mercury'!), so
the
> > new backups will be using some garbage encryption key, and it would be
> > really hard to restore the new data correctly if TSM.PWD is lost or if
the
> > restore happens on a different machine.
> >
> > Alexei
> >
> >
> > "ADSM: Dist Stor Manager"  wrote on 07/27/2006
> > 06:31:17 AM:
> >
> >
> >>Hi Alexei,
> >>
> >>thanks for your hint - now i come with a new question concerning the
> >>'restore' :
> >>Because nothing changes other than the 'hostname' of that linux system
> >
> > ...
> >
> >>... what about the data that has been backed up prior to the time
> >>I rename the hostname and reenter the 'encryption key password' ?
> >>
> >>Because I stay with 'encryptkey save' what happens when (some time)
> >>I may do a full restore of the '/home/' -Filespace ?
> >>
> >>Because this Filespace '/home/'  has data backed up that is encrypted
> >>with both encryption-key-usage of the old and the new 'hostname'
> >>( but always the same 'tsm-Nodename' )
> >>... will I am able to restore(and decrypt) all of it ?
> >>
> >>... i fear to go into problems - Or do I have to start backup again
> >>from 'zero' - for example :
> >>by renaming  the filespace on the server
> >>at the time changing the hostname ?
> >>
> >>Thanks again for any hints !
> >>-- that is something really confusing to me :-|
> >>
> >>Rainer
> >>
> >>
> >>
> >>Alexei Kojenov schrieb:
> >>
> >>
> >>>Rainer,
> >>>
> >>>You need to make TSM client prompt you for encryption key password on
> >
> > the
> >
> >>>next backup after you changed the hostname. The only way to do this is
> >
> > 

FW: Tape Drive Choices: What, and why?

2006-08-04 Thread Prather, Wanda
Hi Allen,

I've been VERY pleased/surprised at how durable IBM LTOx drives have
been overall.  LTO2 gave less problems than LTO1, and I think LTO3 has
had fewer problems than LTO2.   For many sites they are an EXCELLENT
value and totally appropriate for TSM use.  

On the other hand, I doubt there are many TSM installations running
their LTO drives truly at a 100% duty cycle.  

In my experience, there is NO QUESTION that the 359x drives are tougher.
I think most people are just willing to deal with occasional drive
outages in return for lower initial cost.

Things that I have personally experienced:

1) When LTO drives fail, they don't get repaired.  The CE just comes in
and replaces them.  They are essentially "BIC" drives - plastic parts,
no refills.  

2) LTO MEDIA aren't nearly as tough as the 3592 media.  The tape has to
be pulled out of the cartridge by a little pin.  If that pin doesn't get
reseated properly (or if the tape has been jiggled too much during
shipping), the cartridge will jam in the drive on the next load. 

3) If a cartridge gets jammed in a drive, the CE has to come remove it
for you.  He/she has to open up the drive and try to un-thread the
cartridge manually.  There is about a 60% chance you will lose the
drive, the cartridge, or both (see also #1 above).  When we had this
happen once (LTO2), we lost the drive, but the CE tried to save the
cartridge for us.  We loaded that cartrdige into another drive, and it
promptly jammed that drive, too.  Had to replace the 2nd drive as well,
throw the cartridge away.  For LTO3, I believe they have replaced the
threading motor, so this shouldn't happen as often.  

4) If you look at TCO instead of initial cost, the 3592's may not cost
you significantly more.  What different sites pay differs these days
(all drives from all manufacturers are often heavily discounted).
Monthly maint for LTO may be HIGHER than for 359x (see #1 and #3
above!).

5) Another issue around TCO:  When you get ready to upgrade to get more
capacity, you have to replace BOTH the drives and media for LTO to get
additional capacity in your library.  For the 3592's, the next upgrade
is supposed to be drive-only, no replacement of media required.  For
many sites, the media is a SIGNIFICANT part of the cost.


So what I tell people who ask the question and haven't bought yet:

a) If you are going to push the drives really hard (in my opinion, that
means more than 12 hours per day), or if you can't afford to have a
drive down, or if you don't have the PEOPLE time to mess with failed
drives, you should be buying 3592's, because they are designed to take a
beating.

b) If you are located a long way from your IBM maintenance personnel,
don't even think about buying LTO; they WILL break.

c) As an alternative to (b) above, if you need 10 drives, buy 11 and
just expect one to be down at any given time.

d) If you have DLT drives now, you will be pleased and amazed at how
much more durable the LTO drives are.

e) If you have 3590 drives now, you would NOT be pleased at the relative
durability of the LTO drives.

f) I have never had a customer who bought 359x technology and later said
"gee, that was a bad choice".

My opinion, and nobody else's...

Wanda  

   




 

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Allen S. Rout
Sent: Wednesday, August 02, 2006 10:37 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Tape Drive Choices: What, and why?

Hi, all.

I'm looking into what choices folks have made for their tape drives,
and why they picked what they did.  I'm really happy with what I've
got, but I figure that state is perpetuated by questioning it, rather
than settling in.


I'm running 3590s (on the way out) and 3592s.  The capacity is close
to the top per-cartridge (500G raw per cart), and the speed is quite
good, ~80GB/s.

When we added the 1-gen 3592s a few years ago, seek speed was an
important difference between that and the then current LTO2; I
understand that LTO3 has made up some ground there but not all the
way.

My drives are getting a duty cycle approaching 100%; there are very
few times of the day I don't have jobs waiting in line for them.  My
SE is kind of nervous about them; he says we're mean to them. :)

I am given to understand that this kind of treatment tears LTO3s
apart; they aren't designed for that kind of 24x7 usage.

In a nutshell, I love my 3592s, I run them constantly and have
essentially no maintenance issues with them.  I've got some of them in
a remote installation ~300 miles away, and run them with confidence,
so far borne out. (8 months of production)



So, any opinions?  Love stories for LTO3 or that sun whatever-1000 ?
Hate stories?



- Allen S. Rout


Re: Strange Admin Schedule/Script behavior

2006-08-04 Thread John Monahan
"ADSM: Dist Stor Manager"  wrote on 08/04/2006
10:05:54 AM:

> Hello,
>
> I have a Admin Schedule/Script that runs the following Housecleaning
> tasks,
> daily which has been working fine months. This morning though the
> BA STG Backuppool rmtpool process and the Migrate Stgpool process
> was ACTIVE at the same time! I checked the log an it shows nothing
> as to why this happened as you can see the the Migrate Process
> should WAIT UNTIL the BA STG backuppool process ends before
> starting which it has been doing. This could be just a isolated
> incident not sure has this ever happened to anyone else?
> Any guesses?
>
> serial
> BACKUP DB DEVCLASS=BKP TYPE=INCREMENTAL wait=yes
> serial
> BA STG backuppool rmpool maxpr=2 wait=yes
> serial
> migrate stgpool backuppool lowmig=0 wait=yes
> serial
> Ba STG LTpool RMpool maxpr=2 wait=yes
> serial
> expire inventory
>
>
>
> F.Y.I - Automatic Migration has been turned off for a while.


Does the log indicate the migration was started by the script?  What were
processes 58 and 59?



__
John Monahan
Consultant Infrastructure Solutions Group
Computech Resources, Inc.
Office: 952-833-0930 ext 109
Cell: 952-221-6938
http://www.computechresources.com


Re: FW: Tape Drive Choices: What, and why?

2006-08-04 Thread John Monahan
"ADSM: Dist Stor Manager"  wrote on 08/04/2006
11:34:00 AM:

> Hi Allen,
>
> I've been VERY pleased/surprised at how durable IBM LTOx drives have
> been overall.  LTO2 gave less problems than LTO1, and I think LTO3 has
> had fewer problems than LTO2.   For many sites they are an EXCELLENT
> value and totally appropriate for TSM use.
>
> On the other hand, I doubt there are many TSM installations running
> their LTO drives truly at a 100% duty cycle.
>
> In my experience, there is NO QUESTION that the 359x drives are tougher.
> I think most people are just willing to deal with occasional drive
> outages in return for lower initial cost.

I agree.  Many who go the LTO route save enough money where they can throw
in an extra drive to help them cope with more frequent drive outages.  I
experienced roughly a 20% yearly failure rate with LTO1 overall.  Mostly a
mixture of low to medium-high usage TSM environments.  So if you had 5
drives, one drive per year would be replaced.  LTO2 was better.  LTO3 is
outstanding so far.  I'm not aware of a single drive failure in any of my
customers that have LTO3 and there are a few that hammer their drives
pretty hard.

>
> Things that I have personally experienced:
>
> 1) When LTO drives fail, they don't get repaired.  The CE just comes in
> and replaces them.  They are essentially "BIC" drives - plastic parts,
> no refills.

One of the items in the LTO spec that the 3 vendor LTO consortium created
doesn't allow for field replaceable parts or piecemeal upgrades for the
drives.  The drives must be upgraded or replaced as an entire unit.  Not
quite sure why this was decided.  That means when LTO encryption capable
drives come out, it will be a whole new drive instead of a field upgrade
like that for 3592.


Re: Strange Admin Schedule/Script behavior

2006-08-04 Thread Timothy Hughes
Hi John,

Process 58 was reclamation and process 59 was the Backup DB portion
of the script  and yes the log indicates Migration was started by
the script.

Thanks

John Monahan wrote:

> "ADSM: Dist Stor Manager"  wrote on 08/04/2006
> 10:05:54 AM:
>
> > Hello,
> >
> > I have a Admin Schedule/Script that runs the following Housecleaning
> > tasks,
> > daily which has been working fine months. This morning though the
> > BA STG Backuppool rmtpool process and the Migrate Stgpool process
> > was ACTIVE at the same time! I checked the log an it shows nothing
> > as to why this happened as you can see the the Migrate Process
> > should WAIT UNTIL the BA STG backuppool process ends before
> > starting which it has been doing. This could be just a isolated
> > incident not sure has this ever happened to anyone else?
> > Any guesses?
> >
> > serial
> > BACKUP DB DEVCLASS=BKP TYPE=INCREMENTAL wait=yes
> > serial
> > BA STG backuppool rmpool maxpr=2 wait=yes
> > serial
> > migrate stgpool backuppool lowmig=0 wait=yes
> > serial
> > Ba STG LTpool RMpool maxpr=2 wait=yes
> > serial
> > expire inventory
> >
> >
> >
> > F.Y.I - Automatic Migration has been turned off for a while.
>
> Does the log indicate the migration was started by the script?  What were
> processes 58 and 59?
>
> __
> John Monahan
> Consultant Infrastructure Solutions Group
> Computech Resources, Inc.
> Office: 952-833-0930 ext 109
> Cell: 952-221-6938
> http://www.computechresources.com


Re: Determining archive sizes for recharge?

2006-08-04 Thread Prather, Wanda
I've never done this, so you'll have to test it for yourself to see how
practical these suggestions are:

1) If the machine is a UNIX variant, and you specify VIRTUALMOUNTPOINT
for each of the users' directories, doesn't TSM store it as though it is
a separate filespace?  Then does Q OCC filespacename give you what you
want?  

2) If that doesn't work, consider just giving each user a script that
invokes archiving using an options file with his own NODENAME.  Allow OS
backups to run under the host NODENAME as usual, but force archives to
be stored under separate NODENAMEs.  Then for sure you can get the
amount of GB that person has backed up.  

Wanda Prather
"I/O, I/O, It's all about I/O"  -(me)


  

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Jim Zajkowski
Sent: Tuesday, August 01, 2006 11:17 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Determining archive sizes for recharge?

Hi folks,

Right now we only backup servers to TSM.  We are considering allowing
individuals to use TSM as an archive repository, and the first question
that came up was how to figure out how much space a particular client or
person is using in the archive, so we can send them a bill.

The caveat: one of the machines that people will archive from is used by
more than one billable group (specifically, more than one research lab).
I will need to be able to figure out which person has archived however
much they did.  While the idea of having more than one management class
with different tape pools seems like a sound idea, I cannot necessarily
rely on the users choosing the right class.  Each user's directory has
their name on it, so we can probably figure it out from a q arch on the
client.

Has anyone done this?  I know how much we all love recharging, but that
is
out of my control.

Thanks!

--Jim


Client GUI does not see archives

2006-08-04 Thread Orville Lantto
I have run into an issue where the occupancy table lists archives for a
node, but the client GUI does not show any available archives.  Anybody
seen this before?

 

 

 

Orville L. Lantto

Storage Consultant

GlassHouse Technologies, Inc. 

200 Crossing Boulevard

Framingham, MA 01702

[EMAIL PROTECTED] 

www.glasshouse.com   

 


Re: Client GUI does not see archives

2006-08-04 Thread Richard Sims

On Aug 4, 2006, at 2:06 PM, Orville Lantto wrote:


I have run into an issue where the occupancy table lists archives
for a
node, but the client GUI does not show any available archives.
Anybody
seen this before?


Well, that's a normal case where the archives do not belong to the
user doing the looking, and if not the superuser.

Provide more detailed info if not that.

   Richard Sims


Re: Data expiration

2006-08-04 Thread Prather, Wanda
Perhaps your problem results from what is BOUND to each management
class.
90 days is a LONG time to keep backup versions, not surprised your DB
grows.  

Some things to be careful of:

1) By default, ALL directories are bound to the management class with
the longest RETONLY value, even if the FILES belonging to those
directories are bound to a different management class.

Since you have a management class with a RETONLY value of UNLIMITED,
that's where your directories will be bound by default.  Unless you
specify another mgmt class using DIRMC  for the client, NO directories
are getting deleted in your environment.  Ever.  A directory is backed
up as a separate object in the TSM DB, and takes up just as much DB
space as a file.


2) For your Windows clients, be very careful of where your SYSTEM OBJECT
filespaces are bound.  If you are keeping 90 days worth, that is at
least 3000 files, PER CLIENT, PER BACKUP, for the Windows SYSTEM OBJECT
filespaces.  I recently worked with a customer having DB growth
problems, and calculated they had 35 MILLION entries in the DB just
associated with SYSTEM OBJECt/SYSTEM STATE filespaces, because they were
keeping them for 90 days.  Bind the SYSTEM OBJECT to something more
reasonable; a management class that is retained for only 2 weeks,  for
example.  (Ask your Windows admins if they would ever restore a registry
that was 90 days old?  I sure wouldn't!).  Or bind the SYSTEM OBJECT to
a management class that doesn't back up every day (backup frequency >1).

3) Also for Windows clients, MAKE SURE you are putting in reasonable
EXCLUDES.  Junk files that have unique names, but get deleted, will live
for 90 days in your environment.  Windows creates a LOT of files like
that every day that you don't need, esp. in \Temporary Internet Files
and \RECYCLE.  Results in a lot of DB entries.  You just don't need to
back those up, period.


Been there, felt that pain.

Wanda Prather
"I/O, I/O, It's all about I/O"  -(me)


  

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Levi, Ralph
Sent: Wednesday, August 02, 2006 9:00 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Data expiration

I am still working understanding why my TSM DB continues to grow and
think I may have come upon something.  I have many retention policies in
the management class for all my file servers.  The goal was to keep most
data for only 90 days after it was deleted and to keep 90 versions if it
was a file that would be updated daily.
Incremental backups are run nightly.  TSM is AIX 5.3 and TSM 4.2.7.  The
file servers are mostly W2K with backup-restore client 5.1.x - 5.3.x.

My expiration runs successfully daily but I believe what is happening is
the majority of data being expired are the files that are overwritten
daily.  It looks to me like the files that someone overwrites once or
twice lives out in TSM forever, certainly beyond the 90 days I was
expecting it to be there.

Here are my management classes.  Is the unlimited "retain extra
versions" overriding my 90 days in the primary management class ?

Any help would be appreciated.
Thanks,
Ralph


The default management class is defined as:

versions data exist: unlimited
versions data deleted: 9
retain extra versions: 9
retain only version: 9

The primary management class used (95% of all data)

versions data exist: unlimited
versions data deleted: 90
retain extra versions: 90
retain only version: 90

The 2 long retention management classes are:

versions data exist: unlimited
versions data deleted: 366
retain extra versions: 366
retain only version: 366

versions data exist: unlimited
versions data deleted: unlimited
retain extra versions: unlimited
retain only version: unlimited


Re: Client GUI does not see archives

2006-08-04 Thread Orville Lantto
This turned out to be a case of the directory (and client) no longer
existing.  The archives became visible using the command line "q archive
{filespace}".

Thanks for the reply!

Orville L. Lantto
Storage Consultant
 
 
GlassHouse Technologies, Inc. 
200 Crossing Boulevard
Framingham, MA 01702
[EMAIL PROTECTED] 
www.glasshouse.com 
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Richard Sims
Sent: Friday, August 04, 2006 1:53 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Client GUI does not see archives

On Aug 4, 2006, at 2:06 PM, Orville Lantto wrote:

> I have run into an issue where the occupancy table lists archives
> for a
> node, but the client GUI does not show any available archives.
> Anybody
> seen this before?

Well, that's a normal case where the archives do not belong to the
user doing the looking, and if not the superuser.

Provide more detailed info if not that.

Richard Sims