ADSM-L

Re: archive to tape ???

2004-03-02 23:20:02
Subject: Re: archive to tape ???
From: Steven Pemberton <stevep AT IBK.COM DOT AU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 3 Mar 2004 15:15:57 +1100
On Tuesday 02 March 2004 14:05, Michael D Schleif wrote:
> My client has an existing TSM setup that is quite different from the
> textbook examples ;>

Michael,

I've joined this thread pretty late, so I've cut and pasted some comments from
subsequent posts.

> They are running TSM v5.1.5.4 on Windows 2000, and also have DRM.
>
> Currently, they are keeping seven (7) versions for 150 days, and the
> backups are going to a 6TB array.  That's right -- currently, there is
> *no* tape involved.

There is _nothing_ wrong with this configuration, assuming that the 6 TB disk
array is sufficiently large to contain all your primary backup data.

I understand that you have a second TSM server at another site, connected via
T1 (1.5 Mb/s) soon to be upgraded to DS3 (45 Mb/s).

> In January, they bought an Overland LoaderXpress LTO-2 system, including
> one (1) magazine with eleven (11) slots.  Can anybody comment on any
> gotchas using this device with TSM?

No problems that I'm aware of, I've configured several similar for customers
recently. Although I'd (almost) always recommend getting two tape drives for
use with TSM, in your specific environment, one drive may be sufficient.

I assume you only purchased one of these libraries, for the DC1 site?

> The client says that they want to copy daily to tape only the most
> recent version of files that have changed since previous day.
>
> They will accept copy daily to tape all most recent file versions.
>
> Each morning, those tapes last written will be taken offsite, and tapes
> from seven (7) days ago brought back onsite and available.

Essentially, what you want to do, sending the most recent files off-site, and
configuring some kind of "tape rotation" is exactly what TSM is designed for.
This is not really a "non-standard" requirement at all.

However, the way you are trying to do it is... :)

I think you are missing one of the main advantages of TSM, in that the data
retention and data location are completely independent, and can be managed
separately. There is no need (indeed it is problematic) to synchronize the
two.

The easiest "off-site backup" solution to implement in your environment is
probably to simply define a single "copy storage pool" to use the new tape
library. Then, follow the next few steps...

1/ Run "backup stgpool" to copy *ALL* the primary backup data to tape.
2/ Send those tapes off-site.

3/ The next day, run "backup stgpool" again - this will only copy the new
files from disk to tape (as per your requirements)
4/ Send those tapes off-site.
5/ Repeat steps 3 + 4 every day

6/ Determine any "empty" off-site tapes that need to return on-site. You can
use the DRM commands or TSM queries to identify these tapes.
7/ Repeat step 6 every day.

8/ Finally, it's *CRITICAL* to backup your TSM database and send it off-site
every day also!

So, this should leave you with the following:
a/ All your primary backup data on the 6 TB disk array
b/ A "copy pool" duplicate of all this data, on tape, at the off-site location
c/ Several new tapes containing only new backup data, to go offsite every day
d/ A TSM database backup tape, to go offsite every day
e/ Several old tapes, now empty, to return every day.

> Furthermore, there are two (2) offsite locations, one for Windows
> platforms, and one for *NIX platforms.

I don't understand this point, but it's certainly possible to create two copy
storage pools, and send the tape from each to separate off-site locations.

> I am thinking that this can be accomplished by _archiving_ from the
> arrays to tape.  I am not clear how to specify policy.  Any ideas?

OK, "archiving" is normally something that the client would do, thus sending
"archive" data to TSM for extended retention. As your data is already in the
TSM server this is not appropriate.

However, the "backup set" option can be though of as an "archive" of the
existing backup data. But I don't think it's the best solution for your
needs, and the tape management would be far more complex.

Below are some comments from other posts in this thread:

] Please, let me put my predispositions aside.  What data do you suggest
] that we put on tape, how do you suggest that we get it there, and how do
] you suggest that we rotate tapes offsite?

If you are aiming for more than "malicious compliance" and actually want to
use these tapes for recovery :) then you *need* to have *ALL* the data
duplicated to the off-site tapes. Refer to my recommendations above.

] The catastrophic failure my client wants to address is the total
] destruction of DC#1 (data center).  In that event, although TSM#2 at
] DC#2 is supposed to be an exact mirror of TSM#1 at DC#2, which no longer
] exists, my client wants to know that they have at least two (2) recovery
] options:
]
]    [1] recover from TSM#2, or
]    [2] recover from offsite tape.

Interesting, is TSM2 somehow "replicated" from TSM1? Does the replication also
deal with the disk storage pool contents on the 6 TB disk array? Since the
inter-site link is only T1, I assume not... But after it's upgraded to the
DS3 you'll have several options.

With the DS3 link you could implement server-to-server virtual vaulting -
sending copy pool data directly from TSM1 to TSM2, with no tape media
involved.

Or, even better, backup the DC1 clients across the DS3 directly to the TSM2
server, then later duplicate this data back to TSM1. That way the clients
backup data is *immediately* off-site at backup time.

] Current expectation is twenty-four (24) hours for _all_ critical servers
] to be functional.

I can't comment on this requirement without knowing more about your
environment, ie, how many "critical servers", amount of data, etc.

Something you may want to consider is long-term archiving of company data. The
current policy you describe only retains data for 150 days. Don't they have
any legal or business need for longer term retention?

Regards,
Steven P.

--
Steven Pemberton
Senior Enterprise Management Consultant
IBK, Senetas Group

Mobile: +61/0 418 335 136 | Phone: +61/3 9820 5811 | Fax: +61/3 9820 9907
Level 1, 11 Queens Road, Melbourne, Victoria, 3004, Australia
http://www.senetas.com.au | http://www.ibk.com.au | http://www.datum.com.au

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