George,
In a short answer, no not everything is being kept forever.
First it looks like the your active, inactive and delete files needs some
shoring up.
You will not be able to restore any deleted files after the next expiration
runs.
You will be able to restore files that were changed forever
Based on what you sent.
# of different file versions: no limit
Files that are modified and in the same location with the same name will be
retained forever.
( I have mine set to 10)
# of days to keep inactive versions: no limit
Previous versions of changed files will be retained forever.
( I have standard set to 30)
Deleted versions to keep: 0
Means no files that have been deleted will be retained on tape
( I have mine set to 2)
Amount of time to keep the last file version:0
All deleted files will be expired from the tsm server after the next expiration
process is run
(I have mine set to 90)
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Huebschman, George J.
Sent: Tuesday, August 10, 2010 11:44 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: NBU guy in TSM shop and I need help
You have three questions really.
You need numerous tapes for restore because backups write to tape every
day. Not every file is on the same tape, unless you use collocation for
the storage pool. (Then you need more tapes to backup!) Not every file
is going to be deleted every day. So a Point in Time restore, or a
restore of all active objects is going to have to access tapes that were
written over a span of time.
Also, reclamation of tapes impacts where data is kept. As data ages and
expires and tapes/data are consolidated, the data moves onto new tapes.
TSM doesn't care (unless collocation is in use) what tape the data goes
onto.
You can accelerate restores by running them in pieces if they are large,
and running them from the command line.
Second question about retention.
Retention has nothing to do with how many tapes your data is on. You
are either restoring Active versions, Inactive versions to a point in
time (which is going to be the same for all of the objects), or a
specific inactive file or files. Except for the fact that the longer
the retention, the more tapes there are generally going to be in the
storage pool, retention doesn't affect where the specific objects are
stored.
Are you keeping data forever?
I am not sure. Your translation is a little murky. It would be plainer
if you used TSM's terms.
If Versions Data Deleted AND Retain Extra Versions really is No Limit,
then yes, you are keeping things forever.
We have some like that:
Policy Policy Mgmt Copy Versions
Versions Retain Retain
Domain Set Name Class Group Data
Data Extra Only
Name Name Name Exists
Deleted Versions Version
--------- --------- --------- --------- --------
-------- -------- -------
X-FILES ACTIVE FOREVER STANDARD No Limit No
Limit No Limit No Limit
Does your CopyGroup look more like this example?
Policy Policy Mgmt Copy Versions
Versions Retain Retain
Domain Set Name Class Group Data
Data Extra Only
Name Name Name Exists
Deleted Versions Version
--------- --------- --------- --------- --------
-------- -------- -------
5_YEAR ACTIVE 1825DAYS STANDARD No Limit No
Limit 1,830 1,830
* Versions Data Exists is how many VERSIONS of objects that are Active
on the Client may be kept.
* Versions Data Deleted (or changed) is how many VERSIONS of objects
that are Inactive on the client may be kept.
* Retain Extra Versions (TSM never automatically deletes the Active
version)is how many DAYS to keep Inactive versions.
* Retain Only Version, is how many DAYS to keep the last Inactive
version.
If I ran backups three times a day, morning, noon, night, I could have
three copies of a file daily, if it was changed each time. (For example
a very frequent SQL Dump with a timestamp name.)
In five years I would accumulate three times 1,830 VERSIONS, but each
version would only live 1,830 DAYS.
A reason it is good to have VDE and VDD set to No Limit is to avoid
busting an requirement to keep data for a specific length of time.
In the above example, if the government wanted me to keep data for 1,830
days, and I had my VERSIONS set to 1,830 days, I would be 1,220 days
SHORT, because the newest version would bump the oldest version
regardless of age.
If you are confused by copygroup terminology, you are in good company!
George Huebschman
Legg Mason
Media Librarian
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
ego3456
Sent: Tuesday, August 10, 2010 10:54 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] NBU guy in TSM shop and I need help
I'm trying to understand why there are so many tapes required for
restore and have started to look at one aspect of our management
classes.
this is the setup in question:
Backup Versions
__________________
Days between backups = 0
_______________________
How many different versions of the file should be kept?
No limit
_________________
Number of days to keep inactive versions
No limit
_________________________
For backup files that a user has deleted from the client node:
Number of file versions to keep
This number of versions : 0
_____________________________
Amount of time to keep the last file version
This number of days: 0
________________________
under this configuration is it really keeping all files forever? I'm so
lost on this its not funny and the conversion from NBU to TSM seems like
going from a working system to a broken system even though i know its
just bad configuration that is the cause its becoming hard for me not to
throw the baby out with this bathwater and start fresh with a simple NBU
system (simple because i know it backward and forward not because its
better per se.. i really am trying hard to make this TSM configuration
work)
Thanks for any help you can give.
-eric
+----------------------------------------------------------------------
|This was sent by ericgosnell AT gmail DOT com via Backup Central.
|Forward SPAM to abuse AT backupcentral DOT com.
+----------------------------------------------------------------------
IMPORTANT: E-mail sent through the Internet is not secure. Legg Mason
therefore recommends that you do not send any confidential or sensitive
information to us via electronic mail, including social security numbers,
account numbers, or personal identification numbers. Delivery, and or timely
delivery of Internet mail is not guaranteed. Legg Mason therefore recommends
that you do not send time sensitive
or action-oriented messages to us via electronic mail.
This message is intended for the addressee only and may contain privileged or
confidential information. Unless you are the intended recipient, you may not
use, copy or disclose to anyone any information contained in this message. If
you have received this message in error, please notify the author by replying
to this message and then kindly delete the message. Thank you.
|
