I am not sure if you have 4 TSM Servers (instances) or 4 TSM
Clients/Nodes.
- A VTL will not reduce the size of a TSM Database.
- Yes, the TSM DB tracks the location of the data in all of the primary
and copy pools. It has to in order to be able to use the data.
- Their disk pool is their first "Primary" pool. It sounds like the VTL
is a migration destination as the next Primary pool in the hierarchy.
If the VTL is large enough to keep all of your active and inactive
versions of objects, you would not necessarily need a next step in the
Primary Pool hierarchy to tape. But, since the user wants a tape "copy"
of the data, it is possible to migrate to a tape PRIMARY storage pool
and/or copy to a tape COPY storage pool.
TSM's INCREMENTAL backups backup objects, not the entire server
or desktop. An incremental backup is an event, not an entire entity.
There is nothing unified to move, or copy to anywhere.
TSM does have a SELECTIVE backup option. That behaves as a FULL
backup. Making frequent Selective backups will make your database grow
a lot more than incremental backups will.
- Our practice is to do incremental backups. We write the data to
disk or VTL (it varies) then migrate to tape primary pools (for onsite
copies) and copy to tape copy pools (for offsite copies.) We move the
most recent copy pool tapes offsite daily. TSM takes care of expiring
the data on tapes according to the retention polices defined under the
Management Classes in the Copy Group definitions.
So we back up the data. We have one copy, on disk for example.
COPY operations move (as much data as possible in the time
available) to a tape copy pool. Some data now has two copies.
At a scheduled time, or when a threshold is met, data MIGRATES
to the next PRIMARY storage pool (VTL in this example), no new copy of
it is made, it just moves from one media pool to another.
Copy operations move more data from the VTL pool to the Tape
Copy Pool. Now more data has a second copy.
Again, a Migration process moves data to the final Tape PRIMARY
Pool. It is still just a move operation from lower capacity expensive
media to less expensive higher capacity media, no new copy is made.
Finally, any remaining Primary Pool data in the Tape PRIMARY
Pool that has not been copied to the Tape Copy Pool...is copied. Now
there are two copies of all the data that was backed up at date
mm/dd/yyyy hh:mm for a particular client node.
*** We do not use storage pools for Active data. They might suit
your needs. They keep copies of objects that were current on the Clients
as of the last backup.
- If you want to do a Point-It-Time restore for a folder or entire
server you can do that, TSM knows where all the data resides. It does
not care if it is all on one tape, or even in the same pool.
- What level of granularity - That is a wide question - you can manage
by file or folder; for example, you could keep all the data in one
folder for 5 days, and another folder for 15 days; or, retain files of
one type for 5 days and files of other types for 30 days. I am not
aware of a way to keep particular types of data in a storage pool level
for any period of time other than adjusting migration policies.
- What is their reason for wanting fresh backups on VTL and older
backups on Tape, speed of restore from VTL, with tape for added
capacity?
- If your DB is growing too much, look at what you are backing up, and
how long you keep it; both the length of time, and number of versions.
Windows Systemstate backups involve a LOT of objects, each of them adds
space to the database. (Note that the database grows by the number of
objects that it tracks, not the amount of data backed up. Five thousand
1KB files take up more space in the DB than one 200 GB file.)
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Capo
Sent: Friday, October 15, 2010 4:35 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] TSM + VTL and physical tape library
Hi all,
I'm involved in a TSM + VTL project but, unfortunately, I'm quite new in
TSM world: please apology me if I make trivial questions:
My customer has currently got 4 TSM instances copying to a small disk
pool and then to an IBM Tape library.
They would like to introduce a VTL in the existing environment to
improve overall performances and give TSM servers a little break.
My questions:
1. TSM catalog is growing too much. Would VTL help them to reduce its
size ? When data are copied offline (I suppose via a copy pool), does
the catalog still keeps track of them?
2. Physical tape generation from Virtual media is really important in
this project: customer would like to keep fresh backups on VTL and old
ones on tape. With other BU applications this would be quite easy but,
since TSM has got a peculiar way to manage files (versions), I am a
confused: do you think that defining the tape library as a copy pool is
a good idea? What level of granularity can I reach with the storage
policies and copy pools? Can I simulate the lifecycle policy of other
backup applications ? Can I tell migrate XX backup to tape after 1
month and remove it from the VTL and stuff like that ?
3. Any real life experience to share ? The candidates for this project
are Centricstor and DXi 7500 (or the new DXi 8500).
Thanks for your help
Max
+----------------------------------------------------------------------
|This was sent by max.capo 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.
|
