>> Can a restore be done in parallel? What (well, my boss) will do is use
the
>> GUI NWRECOVER, and choose all 10 folders to do the recover. If I can
speed
>> that up any, that would be great.
>
> Yo - Yes and No (or Yes, in principle).
:-)
> This depends in several circumstances (other than parallelisms):
> - You must use multiple recover commands (GUIs) at a time.
> - If all save sets are on one tape, all commands must be issued
> before the media is mounted.
This would be from AFTD device (disk). What we will probably do is present
2 2TB LUNs to the server from the SAN; span the drive using Windows into 1
4TB drive; then I will use that as an AFTD device. And we will write to
that drive. And restore from it.
> Of course the save sets must be multiplexed otherwise you can
> start the processes but the reads can only be sequential.
Not sure what you mean here about multiplexing in the restore context ...
or does this not matter if I am not restoring from tape?
> Bust at least you avoid rewinding.
> - If the save sets are on multiple tapes, you can start new
> recover jobs at any time.
> Of course you need multiple tape drives to support this feature
;-)
> - If you recover from disk, the behavior is similar, in general.
> I am just in doubt whether the recovery would be faster if you
> force the heads to move in and out all the time if you only use one
disk.
Hmmm ... yeah, I am doubtful, too. I would ordinarily say just use one GUI
recover, and choose all 10 folders, and let it go.
We're talking about 3.4 million files, and 2.6TB, BTW ... thank goodness
this weekend is a holiday in the US, and we're closed Monday. So the
restore should start early/mid-afternoon on Sat, and we can just let it go
...
And if it fails ... well, as long as we don't delete the old disks from
the SAN, we should be able to re-present them to the client, as an
absolute last resort. At least the client will still be functional, even
if the storage wasn't reconfigured as needed ...
|
