Hi Thierry,
Our TSM server is an RS/6000 H-50. The clients are both SUN E3500's
with 2GB RAM which access their disk via fibre-channel. If I'm not
mistaken, the backplane on the E3500's is also fibre-channel based,
making it extremely fast. Data is moved between the server and backup
clients over a dedicated 100Base-T network. The DLT drive is a
DLT7000 attached via single-ended SCSI to the RS/6000 & its the only
device on its controller.
The DLT backups are just a once a week process to create off-site
data. What we do for the bulk of our data is, I think, pretty much
what you are looking to do: Between our 3 clients (the 2 Domino's
mentioned before, and 1 NT fileserver), we backup about 100GB of data
on weekend when we run full backups of our Domino databases and an
incremental of our NT data. But, we only have about 40GB of disk.
So, I send all the data to disk, and set HIGHMIG=95 and LOWMIG=80.
When the disk starts getting full, migration will kick off and migrate
data to tape (not the DLT, we have a MagStar 3575 library that holds
our 'everyday' data). The LOWMIG isn't set too low, so that I can
keep as much data on disk as possible.
I used to send my backups straight to the 3570 drives. But there was
a time that we had some big problems with the drives which caused
backup jobs to sit and wait endlessly. But with data going to disk
first, and then to tape, if one of my drives dies, only one migration
process is affected. The backups will still finish, though they may
have to wait a bit if the remaining tape drive can't migrate data
faster than the clients want to backup.
The one caveat to this method -- something that you don't need to
worry about when there's enough disk to hold an entire night's backups
-- is that you need to make sure you have enough capacity in your tape
library to handle one night's worth of backups. Until expiration
library to handle one night's worth of backups. Until expiration
runs, you'll be storing more than your retention policies would
normally allow. If you're running at near capacity (like we were for
a while), it can be quite a balancing act. On a number of occassions,
I had to move data from tape to disk in order for reclamation to run.
I hope this helps.
Eric S. Lindbeck
Data Storage Administrator
Network Infrastructure Services
SCT
Thierry ITTY
<thierry.itty@BES To: ADSM-L AT VM.MARIST DOT
EDU
ANCON.ORG> cc:
Sent by: "ADSM: Subject: Re: Backupset Restore
of TDP Domino Data
Dist Stor
Manager"
<[email protected]
.EDU>
01/23/01 02:30 AM
Please respond to
"ADSM: Dist Stor
Manager"
A 20:09 22/01/2001 -0500, vous avez écrit :
>Many thanks to James & Richard for your input. You got me thinking
of
>the problem from another angle and here's what I came up with....
...
>To my surprise, the backups straight to DLT were insignificantly
>slower than our backups to disk -- even during the middle of the day.
Hmmm interesting
can you tell me a bit more about your hardware ?
i'm facing a performance problem with a F50 with 2 ibm's 3590 (14
MB/sec,
10 GB/tape) and an ATM 155 Mbps network connexion (thus 14 MB/sec
too).
some guys want me to have backups processed in two steps (client ->
disk
pool via network, then, when finished, internal disk to tape migration
on
server), what needs considerable amount of disk space on the server,
while
i believe concurrent backup and migration is as fast (that is, using
the
disk pool as a buffer), and even that a backup directly to tape would
not
take that longer...
so i'm interested in some details
tia,
- * - * - * - * - * - * -
Mes idees n'engagent que moi (vieux proverbe du Net)
Thierry ITTY
eMail : Thierry.Itty AT Besancon DOT org FRANCE
|
