Steven =>
Thank you, for your advice.
* Steven Pemberton <stevep AT IBK.COM DOT AU> [2004:03:03:15:15:57+1100]
scribed:
> 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.
Yes, the disk array is currently successful managing the 7x150
configuration. Tape is not currently used, and my client wants to begin
offsite tape storage.
> 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).
Yes.
> > 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?
I have not yet seen DC#2, nor any formal, written plan. I suspect that
that part is yet to be implemented. All the more reason to implement
offsite tape storage ASAP. I have been told that DC#2 will also have
same tape system.
> > 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.
OK
> 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
OK
> 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.
OK -- how to do this?
> 8/ Finally, it's *CRITICAL* to backup your TSM database and send it off-site
> every day also!
OK -- but, this brings me back to calculating tape and magazine
requirements. I am told that 4 of the 6 TB disk is being used, and they
are currently backing up <200GB per night to this disk array.
How many tapes do we need per night? Will this fit one (1) ten (10)
slot magazine? How many magazines are required? How many total tapes
are required?
Moreover, what is the optimal tape rotation? When should offsite tapes
come back into production at DC#1?
> 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.
Yes, this will meet my client's requirements. Now, I need to know how
to do the math regarding tape, magazine, rotation requirements?
> > 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.
There exists some _other_ remote DC that will deal with the *NIX system
data. I do not know whether or not TSM is available at that site. My
client has told me to assume that the only difference between the two
(2) sets of offsite tapes are the systems backed up to each offsite tape
set. I would like to accept this now, and revisit that after we get
this current setup functioning.
> > 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.
Yes, I finally grasped that this morning.
> 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.
OK -- plus, it appears that `backup sets' cannot be _stacked_ on tape,
which means that one (1) tape is required for each backed up host per
night. Is that correct?
> 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.
OK
> ] 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.
I believe that this is all currently a pipe dream. When I asked for
details, how data moves between TSM#1 and TSM#2, I heard nothing
substantive.
> 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.
Yes, very cool!
> ] 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?
All of that remains to be seen. Once I demonstrate to my client that
their investment in TSM can produce something of tangible value, and
that they have in place a DR plan that gives them ease, then I can burst
their bubble and propose an even better system. Right now, my client
only sees that they are _not_ copying data to tape, and that no tapes
are sent offsite. In their collective mind, this is a terrible thing
and they blame TSM for this problem.
Consulting -- who knew ?!?!
Thank you, again, for valuable insight.
--
Best Regards,
mds
mds resource
877.596.8237
-
Dare to fix things before they break . . .
-
Our capacity for understanding is inversely proportional to how much
we think we know. The more I know, the more I know I don't know . . .
--
signature.asc
Description: Digital signature
|
