jonathan at buzzard.me.uk
Thu Feb 7 13:40:30 GMT 2013
On Thu, 2013-02-07 at 12:47 +0000, Orlando Richards wrote:
> Nice - good to see this kind of thing coming from IBM - restore of huge
> filesystems from traditional backup really doesn't make much sense
> nowadays - it'd just take too long.
Define too long? It's perfectly doable, and the speed of the restore
will depend on what resources you have to throw at the problem. The main
issue is having lots of tape drives for the restore. Having a plan to
buy more ASAP is a good idea. The second is don't let yourself get
sidetracked doing "high priority" restores for individuals, it will
radically delay the restore.
Beyond that you need some way to recreate all your storage pools,
filesets, junction points and quotas etc. Looks like the mmbackupconfig
and mmrestoreconfig now take care of all that for you. That is a big
time saver right there.
> This kind of approach doesn't
> necessarily accelerate the overall time to restore, but it allows for a
> usable filesystem to be made available while the restore happens in the
The problem is that your tape drives will go crazy with HSM activity. So
while in theory it is usable it practice it won't be. Worse with the
tape drives going crazy with the HSM they won't be available for
restore. I would predict much much long times to recovery where recovery
is defined as being back to where you where before the disaster
> I'd look for clarity about the state of the filesystem on restore -
> particularly around what happens to data which arrives after the
> migration has happened but before the metadata snapshot is taken. I
> think it'd be lost, but the metadata would still point to it existing?
I would imagine that you just do a standard HSM reconciliation to fix
that. Should be really fast with the new policy based reconciliation
after you spend several months backing all your HSM'ed files up
Jonathan A. Buzzard Email: jonathan (at) buzzard.me.uk
Fife, United Kingdom.
More information about the gpfsug-discuss