ADSM-L

Re: archive failure (continued)

2003-04-01 20:18:29
Subject: Re: archive failure (continued)
From: Steven Pemberton <stevep AT IBK.COM DOT AU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 2 Apr 2003 11:27:42 +1000
> >As big a fan of backupsets as I am, I feel the need to point out the
> >disadvantage of backupsets: you can't browse through them if you don't
> >the name of a desired file or its directory location. You can run Q
> >BACKUPSETCONTENTS, but then you'll have to grep through a *very* long
> >output.
>
> In our environment, a backupset would be ideal to keep our TSM DB from
> growing constantly due to archives, except for the fact we are limited in
> the number of tape drives available to process the backupset data migration
> tape-tape. Any ideas to circumvent this physical limitation would be much
> appreciated-

That's easy - buy more tape drives. :)

(A)
Actually, I'm almost serious about that; if you need more resources, then you 
need more resources. It's a simple problem of money. :)

But, back to reality...

(B)
The BackupSet needs to copy only the ACTIVE version of the files in the 
filespaces you are planning to retain for an extended period. By using disk 
storage pools (perhaps specific ones dedicated to the data to be "archived"), 
with CACHE and/or MIGDELAY, you could try to retain more of your ACTIVE 
backup versions on disk?

Or...

(C)
Another idea might be to create a "loopback" TSM server definition. This would 
allow you to generate the backupsets from local storage pools, to the 
"loopback" TSM server definition, where they would initially be saved to a 
disk storage pool. They could then later be migrated onto a separate tape 
storage pool. This way, with enough disk, you would only need a single tape 
drive during the backupset generation.

Using a loopback TSM server to store backupsets has some pro's and con's.

The benifits are potentially using fewer tape drives, and also consolidating 
multiple backupsets onto a single tape. Normally each backupset requires a 
unique tape, but when using a loopback TSM server each backupset uses a 
unique "virtual volume", multiples of which can be stored on each physical 
tape.

The downside of storing backupsets on virual volumes are that you lose the 
ability to restore the backupset in isolation from the TSM server. The index 
of the physical tape used to store the backupset virtual volumes is kept in 
the TSM database, so you will need access to the TSM server to retrieve the 
backupset virtual volumes.

Another important downside might be whether Tivoli would support this 
"innovative" configuration. :)

Or, finally...

(D)
Try to plan your normal policy to cater for >95% of your data restoration 
requirements. Restoring files from monthly "archives" should be the 
exception. Try to limit the data to be "archived" (ie. included in a 
BackupSet) to only the "critical" data. Perhaps separate important business 
data onto it's own filespace and only include that filespace in the 
backupset?

To assist in the recovery of files from a backupset you might consider saving 
a text file listing the contents of each backupset at creation time. You 
could use either "q backupsetcontents" or an SQL query to produce this list.

Another issue with backupsets is that the GUI cannot restore an individual 
file, only the entire backupset. You need to use the DSMC command line, and 
specify the filename, to restore an individual file from a backupset.

Though, my favorite option is still  (A) Buy more tape drives. However, (D) 
sounds good too. :)

Steven P.

-- 
Steven Pemberton                                      Mobile: +61 4 1833 5136
Innovative Business Knowledge                   Office: +61 3 9820 5811
Senior Enterprise Management Consultant    Fax: +61 3 9820 9907

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