[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