Once you have the basics covered (bare-metal, disaster recovery, make sure
to keep the correct data)
To restore faster, goals should be
1. Multiple threads (how can I use 5 tape drives restoring data at
once)
Solutions: two copies of all data, break up client
restore, multithreaded API restore, increase amount of hardware, collocation
by filespace
2. Minimize time WAITING for tape mounts and spinning through tapes.
Solutions: collocation by node, full backups,
separate data into separate storage pools
3. Eliminate database bottle necks
Solutions: Increase database cache, spread across
more spindles, create separate database instances, more paths to spindles
4. Push the throughput bottleneck down to the client
Solution: cache data to disk, bigger server, Gigabit
ethernet on server, switched network, multiple threads on restore
Jeff Bach
Home Office Open Systems Engineering
Wal-Mart Stores, Inc.
WAL-MART CONFIDENTIAL
-----Original Message-----
From: Prather, Wanda [SMTP:[EMAIL PROTECTED]]
Sent: Monday, December 17, 2001 10:18 AM
To: [EMAIL PROTECTED]
Subject: Re: Incremental forever -- any problems?
We have the opposite situation - we have fast robotics and use
collocation.
With collocation on fast tape, it doesn't matter whether you are
doing 2
weeks or 2 years of data, a restore takes the same amount of time.
Doing periodic fulls doesn't "refresh" anything, from TSM's point of
view -
the original backups are still in the TSM DB and still available,
even if
they are 5 years old. If you do periodic fulls, you have to
retransmit
everything over the network again, and you have to adjust your
policies to
make sure you allow those redundant versions to be kept; you
increase the
size of your DB and the amount of reclaims you have to do.
Doing periodic "fulls" would do nothing whatever for us, except bog
down the
network.
I suggest you try doing a large restore to test your own
capabilities. If
you can't restore in a timely fashion, FIRST figure out what your
bottleneck
is before you decide to "fix" it by doing full backups.
Then if you find out you still can't do restores in a timely
fashion, at
least check out the use of BACKUPSETS. They give you all the
client's
active data on one tape, without retransmitting all the data, and
without
creating an extra zillion entries in your DB.
-----Original Message-----
From: Tim Melly [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 17, 2001 10:46 AM
To: [EMAIL PROTECTED]
Subject: Re: Incremental forever -- any problems?
Adam,
We were only doing incrementals and we had a situation where we had
to
restore a
Novell server.
The restore had to go through two years worth of incremental tapes
to
complete
the restore. I would
strongly recommend doing periodic fulls (and colocation) unless you
have a
SLA
which allows for extremely long restores.
Regards, Tim
NAFTA IS Technical Operations
(203) 812-3469
[EMAIL PROTECTED]
Adam J Boyer
<adam.j.boyer To:
[EMAIL PROTECTED]
@FRB.GOV> cc:
Sent by: Subject: Incremental
forever --
any problems?
"ADSM: Dist
Stor Manager"
<[EMAIL PROTECTED]
RIST.EDU>
12/17/2001
09:31 AM
Please
respond to
"ADSM: Dist
Stor Manager"
Hey,
Our management is wondering if it's safe to just do incrementals
forever, or whether we should try to do a forced full every few
months
to keep things fresh. Our experience has been that the incremental
system works great-- we once restored a whole raid 5 array, with
many
files from years ago. But, nonetheless, I'd appreciate any stories
or
testaments to help build a case.
Thanks much,
adam
**********************************************************************
This email and any files transmitted with it are confidential
and intended solely for the individual or entity to
whom they are addressed. If you have received this email
in error destroy it immediately.
**********************************************************************
