Roger,
If you know which nodes are to be restored, or at least have some that are
good suspects, you might want to run some move nodedata commands to try
to get their data more contiguous. If you can get some of that DASD that's
coming real soon, even just to borrow it, that would help out
MOVE NODEDATA looks like it is going to be the key. I will simply move
the affected nodes into a disk storage pool, or into our existing
collocated tape storage pool. I presume it should be possible to restart
MOVE NODEDATA, in case it has to be interrupted or if the server
crashes, because what
Do you have any spare disk storage at all? If you do, you could start
staging some of the more important restores to disk using move nodedata.
On Jan 22, 2008 11:35 AM, Whitlock, Brett
[EMAIL PROTECTED] wrote:
Good Luck, Roger!
-Original Message-
From: ADSM: Dist Stor Manager
Roger,
You certainly want to get a best guess list of likely priority#1 restores.
If your tapes really are mostly uncollocated, you will probably experience lots
of
tape volume contention when you attempt to use MAXPRocess 1 or to run multiple
simultaneous restore, move nodedata, or export node
Good Luck, Roger!
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Roger Deschner
Sent: Tuesday, January 22, 2008 10:14 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Fw: DISASTER: How to do a LOT of restores?
MOVE NODEDATA looks like it is
James,
I like this idea a lot. The disadvantage, of course, is that it
requires a separate server. Is there a way to use this same (or
similar) idea to move just the active files into an active data pool (as
suggested by Maria), given that he's running 5.5 and has access to that
feature?
---
The procedure of creating active data pools (assuming you have TSM
version 5.4 or more) is the following:
1. Create FILE type DISK pool or sequential TAPE pool specifying
pooltype=ACTIVEDATA
2.Update node's domain(s) specifying ACTIVEDESTINATION=created active
data pool
3. Issue COPY ACTIVEDATA
Are files that are no longer active automatically expired from the
activedata pool when you perform the latest COPY ACTIVEDATA? This would
mean that, at some point, you would need to do reclamation on this pool,
right?
It would seem to me that this would be a much better answer to TOP's
Hi,
So far so good, move data, backup sets, active copyppool. You got plenty
to work with. I just wanted to add a example restore command.
Dsmc restore e:\?* e:\ -subdir=y or equivalent. In tests I did with 600k
files I reduced restore times from 4h17min to 52min.
Processing time without '?' in
For this scenario, the problem with Active Storagepools is it's a
pool-to-pool relationship. So ALL active data in a storagepool would be
copied to the Active Pool. Not knowing what percentage of the nodes on the
TSM Server will be restored, but assuming they're all in one storage pool,
you'd
Thanks Curtis, and everyone else too. It's great to have this much
assembled expertise out there.
Preliminary indications from a quick look at the building are that we're
going to be dealing with a count of nodes in the dozens, not hundreds.
The next step is for the IT guy of the affected
AhHAH! So this would only really work if he has a storage pool with
clients that should be copied in this manner. That makes sense.
What about the expiration of inactive files the next time you do a copy
activedata? It doesn't say in the manual that this is what it does, but
you would think it
Nick
I may well have a flawed understanding here but
Set up an active-data pool
clone the domain containing the servers requiring recovery
set the ACTIVEDATAPOOL parameter on the cloned domain
move the servers requiring recovery to the new domain,
Run COPY ACTIVEDATA on the primary tape pool
DR strategy using an ACTIVEdata STGpool is like Steve H said, but
with minor additions and a major (but temporary) caveat:
COPY ACTIVEdata is not quite ready for this DR strategy yet:
See APAR PK59507: COPy ACTIVEdata performance can be significantly degraded
(until TSM 5.4.3/5.5.1) unless
Obviously, being in Chicago this week has frozen my brain (or maybe I'm
downwind from UIC...). Yes, you're correct - it is Domain and Storagepool
combined.
Nick Cassimatis
- Forwarded by Nicholas Cassimatis/Raleigh/IBM on 01/22/2008 09:42 PM
-
ADSM: Dist Stor Manager
Curtis,
Suffering Frozen Brain Syndrome - it's Domain and Storagepool, combined,
that make data eligible to be put in the Activedata pool.
Nick Cassimatis
- Forwarded by Nicholas Cassimatis/Raleigh/IBM on 01/22/2008 09:45 PM
-
ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU wrote on
Bummer. :( But when it's fixed, I sure think it sounds like a better
solution to this situation than the traditional answers -- even if only
used on demand.
---
W. Curtis Preston
Backup Blog @ www.backupcentral.com
VP Data Protection, GlassHouse Technologies
-Original Message-
From:
17 matches
Mail list logo
