size of objects in the backups table

2015-02-03 Thread Rhodes, Richard L.
We are on TSM v6.2.5.

We keep running into the normal question that seems to come up when we start 
analyzing our backups.  We can tell the number of active/inactive files from 
the backups table, but not the size, which is in the contents table.  Does 
anyone have a way to get the active/inactive objects and their size without 
killing your system with a massive SQL join?  Maybe some kind of SQL join for a 
specific node.

I just can't believe TSM doesn't provide this info easily from the server!
(I suppose this belongs under the Rant thread!)


Rick


-
The information contained in this message is intended only for the personal and 
confidential use of the recipient(s) named above. If the reader of this message 
is not the intended recipient or an agent responsible for delivering it to the 
intended recipient, you are hereby notified that you have received this 
document in error and that any review, dissemination, distribution, or copying 
of this message is strictly prohibited. If you have received this communication 
in error, please notify us immediately, and delete the original message.


Re: size of objects in the backups table

2015-02-03 Thread Skylar Thompson
This has been a frustration for us too. Somehow the client is able to get
this information efficiently, so when I've needed it I've just piped dsmc
q b -su=yes ina to some awk/perl to get the information I need. Obviously
this is only good for ad-hoc queries, not for anything that's going to be
done regularly.

In an ideal world, q occ would display the active/inactive counts.

On Tue, Feb 03, 2015 at 02:25:52PM +, Rhodes, Richard L. wrote:
 We are on TSM v6.2.5.

 We keep running into the normal question that seems to come up when we start 
 analyzing our backups.  We can tell the number of active/inactive files from 
 the backups table, but not the size, which is in the contents table.  Does 
 anyone have a way to get the active/inactive objects and their size without 
 killing your system with a massive SQL join?  Maybe some kind of SQL join for 
 a specific node.

 I just can't believe TSM doesn't provide this info easily from the server!
 (I suppose this belongs under the Rant thread!)

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


Re: size of objects in the backups table

2015-02-03 Thread Jeanne Bruno
Hello.  I tested this and got the output:

ANR0986I Process 206 for EXPORT NODE running in the BACKGROUND processed 37,158 
items for a total of 10,206,832,635 bytes with a completion state of SUCCESS at 
16:58:30.

So I have 37,158 active items for this particular node, correct?

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of TH
Sent: Tuesday, February 03, 2015 12:21 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] size of objects in the backups table

Maybe a different way would be suitable for you - try to do EXPORT NODE xxx 
FILEDATA=BACKUPACTIVE PREVIEW=YES

The end of process will give you a total size of active data for a node.

Regards,

Tomasz Hubicki


-- Wiadomość oryginalna --
Temat: [ADSM-L] size of objects in the backups table
Nadawca: Rhodes, Richard L. rrho...@firstenergycorp.com
Adresat: ADSM-L@VM.MARIST.EDU
Data: Tue Feb 03 2015 15:25:52 GMT+0100

 We are on TSM v6.2.5.

 We keep running into the normal question that seems to come up when we start 
 analyzing our backups.  We can tell the number of active/inactive files from 
 the backups table, but not the size, which is in the contents table.  Does 
 anyone have a way to get the active/inactive objects and their size without 
 killing your system with a massive SQL join?  Maybe some kind of SQL join for 
 a specific node.

 I just can't believe TSM doesn't provide this info easily from the server!
 (I suppose this belongs under the Rant thread!)


 Rick


 -

 The information contained in this message is intended only for the personal 
 and confidential use of the recipient(s) named above. If the reader of this 
 message is not the intended recipient or an agent responsible for delivering 
 it to the intended recipient, you are hereby notified that you have received 
 this document in error and that any review, dissemination, distribution, or 
 copying of this message is strictly prohibited. If you have received this 
 communication in error, please notify us immediately, and delete the original 
 message.



Re: Availability of 7.1.1.200 server code

2015-02-03 Thread Schofield, Neil (Storage Middleware, Backup Restore)
Thomas

I don't know whether IBM have already communicated this to you, but it looks 
like server interim fix 7.1.1.200 that you were waiting for has now been 
slipped to Q2. It was previously slated for Q1 but I've just noticed the new 
information in the link below:

https://www.ibm.com/developerworks/community/wikis/home?lang=en#/wiki/Tivoli%20Storage%20Manager/page/TSM%20Schedule%20for%20Fix-Packs

Time to dust off plan B?

Regards
Neil Schofield


Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. 
Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. 
Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England 
and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered 
Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. 
Telephone: 08457 21 31 41. Cheltenham  Gloucester plc. Registered Office: 
Barnett Way, Gloucester GL4 3RL. Registered in England and Wales 2299428. 
Telephone: 0845 603 1637

Lloyds Bank plc, Bank of Scotland plc are authorised by the Prudential 
Regulation Authority and regulated by the Financial Conduct Authority and 
Prudential Regulation Authority.

Cheltenham  Gloucester plc is authorised and regulated by the Financial 
Conduct Authority.

Halifax is a division of Bank of Scotland plc. Cheltenham  Gloucester Savings 
is a division of Lloyds Bank plc.

HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in 
Scotland no. SC218813.

This e-mail (including any attachments) is private and confidential and may 
contain privileged material. If you have received this e-mail in error, please 
notify the sender and delete it (including any attachments) immediately. You 
must not copy, distribute, disclose or use any of the information in it or any 
attachments. Telephone calls may be monitored or recorded.


Re: size of objects in the backups table

2015-02-03 Thread Nick Laflamme
I used to work with BACKUPS and CONTENTS a lot when auditing how well some
DBAs were policing their own backups. I don't have those scripts any
longer, but my recollection is that techniques I developed using those
tables in TSM 5.5 were unusable on TSM 6.1 and early TSM 6.2 servers. They
were usable again on TSM 6.3, and I thought they were usable again on later
TSM 6.2 releases -- but I probably was using repeated small queries, not
large joins.

I'd think you'd already be seeing this improvement if you're on 6.2.5, but
if not, it might be worth the effort to get to TSM 6.3.

Nick


On Tue, Feb 3, 2015 at 8:25 AM, Rhodes, Richard L. 
rrho...@firstenergycorp.com wrote:

 We are on TSM v6.2.5.

 We keep running into the normal question that seems to come up when we
 start analyzing our backups.  We can tell the number of active/inactive
 files from the backups table, but not the size, which is in the contents
 table.  Does anyone have a way to get the active/inactive objects and their
 size without killing your system with a massive SQL join?  Maybe some kind
 of SQL join for a specific node.

 I just can't believe TSM doesn't provide this info easily from the server!
 (I suppose this belongs under the Rant thread!)


 Rick


 -

 The information contained in this message is intended only for the
 personal and confidential use of the recipient(s) named above. If the
 reader of this message is not the intended recipient or an agent
 responsible for delivering it to the intended recipient, you are hereby
 notified that you have received this document in error and that any review,
 dissemination, distribution, or copying of this message is strictly
 prohibited. If you have received this communication in error, please notify
 us immediately, and delete the original message.



Re: 7.1.1 TDP for Exchange 2010 backup Task Details not updated?

2015-02-03 Thread Del Hoobler
Hello Wanda,

This changed when full remote PowerShell management support was added.
The backup progress timer was added and will be available in the next
DP/Exchange PTF.

Del




ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU wrote on 02/02/2015
08:20:08 PM:

 From: Prather, Wanda wanda.prat...@icfi.com
 To: ADSM-L@VM.MARIST.EDU
 Date: 02/02/2015 08:20 PM
 Subject: 7.1.1 TDP for Exchange 2010 backup Task Details not updated?
 Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU

 TSM 6.3.4 on Win2k8-64
 Exchange 2010 on Win2k8 64

 This is not a show-stopper, just in the annoying and mysterious
category.

 Installed Exchange 7.1.1 TDP for a customer today.
 The beautiful FCM interface popped in all the pre-reqs, VSS testing
 ran, I set the appropriate passwords and proxy relationships, full
 backup kicked off via the GUI ran like a champ.

 But in the GUI, in the Task List pane, you used to be able to hover
 over the WORKING line and see that the backup was actually
 running, or click the Task Details tab and see how many GB have
 moved so far.  It was cool and the Exchange guys could see progress
 (especially important for big restores) without needing access to a
 TSM server admin account to monitor from the server end.

 In this case the full backup ran over an hour, and there was never
 any updated information in the Task List or the Task Details until
 we got completed.
 Anybody else see this or figured out why?  Am I missing some java
thingy?

 Thanks

 Wanda Prather
 TSM Consultant
 ICF International Enterprise and Cybersecurity Systems Division



Re: Ransomware deleted TSM backups from node

2015-02-03 Thread Zoltan Forray
A good idea but for us, most of our backups/archives on Oracle systems are
done manually/system managed, not TSM server scheduled.  Plus you have no
realistic idea of how long the backup could run.  We have Notes backups
that run 10-days!

On Mon, Feb 2, 2015 at 5:54 PM, Marcel Anthonijsz mar...@anthonijsz.net
wrote:

 Can Schedule an admin schedule around the Oracle/Notes backup window to
 enable/disable BACKDEL=YES/NO.

 It is not an ideal situation, but decreases the risk. And if you configured
 these nodes with specific nodenames (like you should) the malware could not
 get to those clients.
 Or they should scan the host for all available TSM OPT files and act from
 these...

 2015-02-02 19:44 GMT+01:00 Zoltan Forray zfor...@vcu.edu:

  Same goes for Oracle and Notes backups.  They manage their own backups so
  no way to get around this.  Same goes for PASSWORDACCESS GENERATE - AFAIK
  can't schedule backups without it
 
  On Mon, Feb 2, 2015 at 12:44 PM, Schneider, Jim jschnei...@ussco.com
  wrote:
 
   Roger,
  
   According to my TSM Data Protection for SQL 6.4 manual, servers that
 run
   TDP for SQL require backdelete authority.  I don't know how to get
 around
   this problem.
  
   Jim Schneider
  
   -Original Message-
   From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf
 Of
   Roger Deschner
   Sent: Friday, January 30, 2015 7:40 PM
   To: ADSM-L@VM.MARIST.EDU
   Subject: [ADSM-L] Ransomware deleted TSM backups from node
  
   I'm not sure there's anything that can be done about this, but take it
 as
   a warning anyway.
  
   A Windows 7 desktop node here was attacked by CryptoWare 3.0
 ransomware.
   They encrypted all files on the node, and left a ransom note.
  
   The node owner called me because they were having trouble restoring
 their
   files from TSM using a point-in-time restore. The files were gone!
   Apparently this villian located which backup program was installed,
 found
   it was TSM, and issued actual dsmc delete backup commands, which they
  were
   allowed to do since PASSWORDACCESS GENERATE was in effect. So this
 attack
   vector is not limited to TSM; it would work with any backup program
 that
   the villian can figure out how to use.
  
   I have moved this node to a domain that includes VEREXISTS=NOLIMIT
   VERDELETED=NOLIMIT RETEXTRA=NOLIMIT RETONLY=NOLIMIT for that Copy
 Group,
   while our data security people investigate.
  
   I am planning to change all TSM client nodes to BACKDEL=NO ARCHDEL=NO
 to
   prevent a hacker from deleting backups. Anybody got a better idea?
  
   Roger Deschner  University of Illinois at Chicago
 rog...@uic.edu
   === ALL YUOR BASE ARE BELONG TO US!!
 ===
  
   **
   Information contained in this e-mail message and in any attachments
   thereto is confidential. If you are not the intended recipient, please
   destroy this message, delete any copies held on your systems, notify
 the
   sender immediately, and refrain from using or disclosing all or any
 part
  of
   its content to any other person.
  
 
 
 
  --
  *Zoltan Forray*
  TSM Software  Hardware Administrator
  BigBro / Hobbit / Xymon 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
 



 --
 Kind Regards, Groetje,

 Marcel Anthonijsz
 T: +31(0)299-776768
 M:+31(0)6-53421341




--
*Zoltan Forray*
TSM Software  Hardware Administrator
BigBro / Hobbit / Xymon 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


Antwort: Re: Antwort: Re: GPFS 4.1 on windows and TSM Backup

2015-02-03 Thread TSM
Hi Christian,

tsm incr backup wants to find gpfs.dll on

C:\Windows\SUA\usr\lpp\mmfs\bin\gpfs.dll


but it is in directory

c:\cygwin\usr\lpp\mmfs\win

and in

c:\cygwin\usr\lpp\mmfs\bin

and in

c:\windows\gpfs_cygwin\usr\lpp\mmfs\win  and  in
c:\windows\gpfs_cygwin\usr\lpp\mmfs\bin



after copying c:\cygwin\usr\lpp\mmfs\win to
C:\Windows\SUA\usr\lpp\mmfs\bin\gpfs.dll


tsm backup is ok.


thank you very much

with best regards
stefan savoric


Re: size of objects in the backups table

2015-02-03 Thread TH

Maybe a different way would be suitable for you - try to do
EXPORT NODE xxx FILEDATA=BACKUPACTIVE PREVIEW=YES

The end of process will give you a total size of active data for a node.

Regards,

Tomasz Hubicki


-- Wiadomość oryginalna --
Temat: [ADSM-L] size of objects in the backups table
Nadawca: Rhodes, Richard L. rrho...@firstenergycorp.com
Adresat: ADSM-L@VM.MARIST.EDU
Data: Tue Feb 03 2015 15:25:52 GMT+0100


We are on TSM v6.2.5.

We keep running into the normal question that seems to come up when we start 
analyzing our backups.  We can tell the number of active/inactive files from 
the backups table, but not the size, which is in the contents table.  Does 
anyone have a way to get the active/inactive objects and their size without 
killing your system with a massive SQL join?  Maybe some kind of SQL join for a 
specific node.

I just can't believe TSM doesn't provide this info easily from the server!
(I suppose this belongs under the Rant thread!)


Rick


-

The information contained in this message is intended only for the personal and 
confidential use of the recipient(s) named above. If the reader of this message 
is not the intended recipient or an agent responsible for delivering it to the 
intended recipient, you are hereby notified that you have received this 
document in error and that any review, dissemination, distribution, or copying 
of this message is strictly prohibited. If you have received this communication 
in error, please notify us immediately, and delete the original message.



Re: size of objects in the backups table

2015-02-03 Thread TH

Yes, and total size of these active items is about 10 GB.

Regards,

Tomasz Hubicki

 Original Message  
Subject: Re: [ADSM-L] size of objects in the backups table
From: Jeanne Bruno jbr...@cenhud.com
To: ADSM-L@VM.MARIST.EDU
Date: Tue Feb 03 2015 23:00:12 GMT+0100


Hello.  I tested this and got the output:

ANR0986I Process 206 for EXPORT NODE running in the BACKGROUND processed 37,158 
items for a total of 10,206,832,635 bytes with a completion state of SUCCESS at 
16:58:30.

So I have 37,158 active items for this particular node, correct?

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of TH
Sent: Tuesday, February 03, 2015 12:21 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] size of objects in the backups table

Maybe a different way would be suitable for you - try to do EXPORT NODE xxx 
FILEDATA=BACKUPACTIVE PREVIEW=YES

The end of process will give you a total size of active data for a node.

Regards,

Tomasz Hubicki


-- Wiadomość oryginalna --
Temat: [ADSM-L] size of objects in the backups table
Nadawca: Rhodes, Richard L. rrho...@firstenergycorp.com
Adresat: ADSM-L@VM.MARIST.EDU
Data: Tue Feb 03 2015 15:25:52 GMT+0100


We are on TSM v6.2.5.

We keep running into the normal question that seems to come up when we start 
analyzing our backups.  We can tell the number of active/inactive files from 
the backups table, but not the size, which is in the contents table.  Does 
anyone have a way to get the active/inactive objects and their size without 
killing your system with a massive SQL join?  Maybe some kind of SQL join for a 
specific node.

I just can't believe TSM doesn't provide this info easily from the server!
(I suppose this belongs under the Rant thread!)


Rick


-

The information contained in this message is intended only for the personal and 
confidential use of the recipient(s) named above. If the reader of this message 
is not the intended recipient or an agent responsible for delivering it to the 
intended recipient, you are hereby notified that you have received this 
document in error and that any review, dissemination, distribution, or copying 
of this message is strictly prohibited. If you have received this communication 
in error, please notify us immediately, and delete the original message.