[gpfsug-discuss] SOBAR

Orlando Richards orlando.richards at ed.ac.uk
Thu Feb 7 12:47:30 GMT 2013


On 07/02/13 12:28, Jez Tucker wrote:
> Hey all
>
>    Is anyone using the SOBAR method of backing up the metadata and NSD
> configs?
>
> If so, how is your experience?
>
>  From reading the docs, it seems a bit odd that on restoration you have
> to re-init the FS and recall all the data.
>
> If so, what’s the point of SOBAR?


Ooh - this is new. From first glance, it looks to be a DR solution? 
We're actually in the process of engineering our own DR solution based 
on a not-dissimilar concept:
  - build a second GPFS file system off-site, with HSM enabled (called 
"dr-fs" here)
  - each night, rsync the changed data from "prod-fs" to "dr-fs"
  - each day, migrate data from the disk pool in "dr-fs" to the tape 
pool to free up sufficient capacity for the next night's rsync

You have a complete copy of the filesystem metadata from "prod-fs" on 
"dr-fs", so it looks (to a user) identical, but on "dr-fs" some of the 
("older") data is on tape (ratios dependent on sizing of disk vs tape 
pools, of course).

In the event of a disaster, you just flip over to "dr-fs".

 From the quick glance at SOBAR, it looks to me like the concept is that 
you don't have a separate file system, but you hold a secondary copy in 
TSM via the premigrate function, and store the filesystem metadata as a 
flat file dump backed up "in the normal way". In DR, you rebuild the FS 
from the metadata backup, and re-attach the HSM pool to this 
newly-restored filesystem, (and then start pushing the data back out of 
the HSM pool into the GPFS disk pool). As soon as the HSM pool is 
re-attached, users can start getting their data (as fast as TSM can give 
it to them), and the filesystem will look "normal" to them (albeit slow, 
if recalling from tape).

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


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? 
Might get confusing...


Just my 2 cents from a quick skim read mind - plus a whole bunch of 
thinking we've done on this subject recently :)

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



More information about the gpfsug-discuss mailing list