Eric,
Regarding TSM as being the right product. You may want to assess it
as part of your entire storage infrastructure and the services this
environment provides to the business and end users.
Last year I had an issue that almost resulted in my having to recover
several (~30) TB of user data (many millions of files). During the
initial phase of the problem, we initiated a TSM recovery to an
alternate device, just to get the recovery started in the event we
couldn't resolve the issue. What did save my bacon was the data being
mirrored to another device that I brought online. We were able to
resolve the issue and everything was returned to normal.
This event caused me to really look hard at our backups. Had we
really needed to recover all of that data from tape, we would have been
down or partially operational for a week or so. I am using 18 TS1120
drives in a 10 frame dual robot TS3500 library and IBM P550 TSM servers
with 4Gb SAN connections - not cutting edge but still pretty good
stuff.
Currently, I do not rely on tape backup for large scale recovery. It
can be accomplished, but the RTO (for large amounts of data) is
unacceptable for normal business operations. For NAS data, I use
snapshots for short term RPO (<2weeks) with mirroring to protect from
disaster. Tape recovery fits in between these two scenarios to provide
recovery for older data (more than 2 weeks old) and for long term
archives (7 years). Production devices with SAN or local storage are
mirrored using the OS or DB tools and also backed up but the tape backup
is a secondary recovery mechanism to the OS & DB tool recovery and also
provides for long term archive.
In general, as we become more virtualized and RTO requirements shrink
to minutes, the amount of data to recover grows to terabytes and the
number of files to recover is rounded to the nearest 1/10 of a million,
tape recovery becomes ineffective for large recovery scenarios and the
only alternative is snapshot or mirror recovery methods. Tape still
offers a cost effective long term archive solution and can provide a
bridge for recovering older data that is not in a snapshot. It also
provides an alternative storage device to store data and should not be
affected by OS or application bugs or malicious software - kind of a
failsafe device (assuming the backup processes are successful).
Eventually, we may go to a cloud based backup solution if it proves to
be operationally and cost effective and secure.
Cheers,
Neil Strand
Storage Engineer - Legg Mason
Baltimore, MD.
(410) 580-7491
Whatever you can do or believe you can, begin it.
Boldness has genius, power and magic.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
Loon, EJ van - SPLXO
Sent: Thursday, May 12, 2011 12:11 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] TSM Recovery log is pinning since upgrade to
5.5.5.0 code
Hi Paul!
We are already running 5.5.5.2 and the log is still filling up, even
after switching from rollforward to normal mode.
Management currently is questioning whether TSM is the right product for
the future. Although I'm a big fan of TSM for 15 years, I'm really in
doubt too...
Kind regards,
Eric van Loon
KLM Royal Dutch Airlines
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.
