ADSM-L

Re: [ADSM-L] backup to wrong STGPOOL

2016-02-05 04:42:32
Subject: Re: [ADSM-L] backup to wrong STGPOOL
From: "Weidacher, Daniel" <daniel.weidacher AT INFONOVA DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 5 Feb 2016 09:40:50 +0000
Thank you, that did it.

Best regards,
Daniel

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Andreas Boesler
Sent: Mittwoch, 03. Februar 2016 15:18
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] backup to wrong STGPOOL

Hello Daniel,

if the client is a windows system, please check the dirmc option.
If you do not specify this option to associate a management class with 
directories, the client program uses the management class in the active policy 
set of your policy domain with the longest retention period.

To show the objects which are stored at the volume for the node, you can
use:
  Query CONtent A00069L4 NODE=VIDEO01


Best Regards
Andreas.



Von:    "Weidacher, Daniel" <daniel.weidacher AT INFONOVA DOT COM>
An:     ADSM-L AT VM.MARIST DOT EDU
Datum:  03.02.2016 11:39
Betreff:        [ADSM-L] backup to wrong STGPOOL
Gesendet von:   "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>



Hello,

I have a strange and annoying problem. Some backup data of one specific
node always seems to be moved to another storage pool, so that a whole
tape is used for just a few megabytes of data. This happens at some point
after the backup, as directly after the backup all the data is in the
NO_COPY_TAPE_POOL Storage Pool, where it should be. But next morning some
parts moved to the INC_TAPE_POOL. The NO_COPY_TAPE_POOL has no "next
storage pool" defined, and there is only one admin schedule running - and
it does not migrate the NO_COPY_TAPE_POOL. When I search the actlog with
the nodename, only the regular backup schedule and fileexpiration comes
up.
I have really no Idea why this data is moved to another storage pool...
does anyone else have any clues?
p.s.: INC_TAPE_POOL is the destination for the copygroup of the default
managementclass in this domain. But since at first everything seems to get
backed up into the right destination, this shouldn't be of any concern.

tsm: TSM01>q noded video01

Node Name    Volume Name                 Storage Pool  Name Physical Space
Occupied (MB)
--------------     -------------------------     ---------------- --------
VIDEO01           A00009L4                           NO_COPY_TAPE_POOL
8,963.09
VIDEO01           A00033L4                           NO_COPY_TAPE_POOL
13,383.13
VIDEO01           A00069L4                           INC_TAPE_POOL  1.02


Best Regards,
Daniel
________________________________
 INFONOVA GmbH
Sitz: Unterpremstätten bei Graz
Firmenbuchgericht: Landesgericht für ZRS Graz
Firmenbuchnummer: FN 44354b


The information in this email is confidential and may be legally
privileged. If you are not the intended recipient of this message, any
review, disclosure, copying, distribution, retention, or any action taken
or omitted to be taken in reliance on it is prohibited and may be
unlawful. If you are not the intended recipient, please reply to or
forward a copy of this message to the sender and delete the message, any
attachments, and any copies thereof from your system.
________________________________
 INFONOVA GmbH
Sitz: Unterpremstätten bei Graz
Firmenbuchgericht: Landesgericht für ZRS Graz
Firmenbuchnummer: FN 44354b


The information in this email is confidential and may be legally privileged. If 
you are not the intended recipient of this message, any review, disclosure, 
copying, distribution, retention, or any action taken or omitted to be taken in 
reliance on it is prohibited and may be unlawful. If you are not the intended 
recipient, please reply to or forward a copy of this message to the sender and 
delete the message, any attachments, and any copies thereof from your system.

<Prev in Thread] Current Thread [Next in Thread>