[gpfsug-discuss] SOBAR

[Orlando Richards]

On 07/02/13 13:40, Jonathan Buzzard wrote:
> On Thu, 2013-02-07 at 12:47 +0000, Orlando Richards wrote:
>
> [SNIP]
>
>> 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.

I can tell you speak from (bitter?) experience :)

I've always been "disappointed" with the speed of restores - but I've 
never tried a "restore everything", which presumably will run quicker. 
One problem I can see us having is that we have lots of small files, 
which tends to make everything go really slowly - but getting the thread 
count up would, I'm sure, help a lot.

> 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.

Quite.


> 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
>> background.
>>
>
> 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
> occurred.

Yup - I can see that too. I think a large disk pool would help there, 
along with some kind of logic around "what data is old?" to sensibly 
place stuff "likely to be accessed" on disk, and the "old" stuff on tape 
where it can be recalled at a more leisurely pace.

>>
>> 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
> again :-)
>

Ahh - but once you've got them in TSM, you can just do a storage pool 
backup, presumably to a third site, and always have lots of copies 
everywhere!

Of course - you still need to keep generational history somewhere...


-- 
             --
    Dr Orlando Richards
   Information Services
IT Infrastructure Division
        Unix Section
     Tel: 0131 650 4994

The University of Edinburgh is a charitable body, registered in 
Scotland, with registration number SC005336.