[gpfsug-discuss] SOBAR questions

Mon Jan 23 15:35:41 GMT 2017

Regarding back level file systems and testing...

1. Did you know that the mmcrfs command supports --version which allows 
you to create a back level file system?

2. If your concern is restoring from a SOBAR backup that was made a long 
while ago with an old version of GPFS/sobar... 
I'd say that should work... BUT I don't know for sure AND I'd caution that 
AFAIK (someone may correct me)
Sobar is not intended for long term archiving of file systems. Personally 
( IBM hat off ;-) ), for that I'd choose a standard, vendor-neutral 
archival format that is likely to be supported in the future....

My current understanding: Spectrum Scal SOBAR is for "disaster recovery" 
or "migrate/upgrade entire file system" -- where presumably you do Sobar 
backups on a regular schedule...  and/or do one just before you begin an 
upgrade or migration to new hardware.

--marc

From:   "Simon Thompson (Research Computing - IT Services)" 
<S.J.Thompson at bham.ac.uk>
To:     gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>
Date:   01/23/2017 05:17 AM
Subject:        Re: [gpfsug-discuss] SOBAR questions
Sent by:        gpfsug-discuss-bounces at spectrumscale.org

Hi Mark,

Thanks. I get that using it to move to a new FS version is probably beyond 
design. But equally, I could easily see that having to support 
implementing the latest FS version is a strong requirement. I.e. In a DR 
situation say three years down the line, it would be a new FS of (say) 
5.1.1, we wouldn't want to have to go back and find 4.1.1 code, nor would 
we necessarily be able to even run that version (as kernels and OSes move 
forward). That’s sorta also the situation where you don't want to suddenly 
have to run back to IBM support because your DR solution suddenly doesn't 
work like it says on the tin ;-)

I can test 1 and 2 relatively easily, but 3 is a bit more difficult for us 
to test out as the FS we want to use SOBAR on is 4.2 already.

Simon

From: <gpfsug-discuss-bounces at spectrumscale.org> on behalf of Marc A 
Kaplan <makaplan at us.ibm.com>
Reply-To: "gpfsug-discuss at spectrumscale.org" <
gpfsug-discuss at spectrumscale.org>
Date: Friday, 20 January 2017 at 16:57
To: "gpfsug-discuss at spectrumscale.org" <gpfsug-discuss at spectrumscale.org>
Subject: Re: [gpfsug-discuss] SOBAR questions

I worked on some aspects of SOBAR, but without studying and testing the 
commands - I'm not in a position right now to give simple definitive 
answers - 
having said that....

Generally your questions are reasonable and the answer is: "Yes it should 
be possible to do that, but you might be going a bit beyond the design 
point..,
so you'll need to try it out on a (smaller) test system with some smaller 
tedst files.

Point by point.

1. If SOBAR is unable to restore a particular file, perhaps because the 
premigration did not complete -- you should only lose that particular 
file,
and otherwise "keep going".  

2. I think SOBAR helps you build a similar file system to the original, 
including block sizes.  So you'd have to go in and tweak the file system 
creation step(s).
I think this is reasonable... If you hit a problem... IMO that would be a 
fair APAR.

3. Similar to 2.

From:        "Simon Thompson (Research Computing - IT Services)" <
S.J.Thompson at bham.ac.uk>
To:        "gpfsug-discuss at spectrumscale.org" <
gpfsug-discuss at spectrumscale.org>
Date:        01/20/2017 10:44 AM
Subject:        [gpfsug-discuss] SOBAR questions
Sent by:        gpfsug-discuss-bounces at spectrumscale.org

We've recently been looking at deploying SOBAR to support DR of some of
our file-systems, I have some questions (as ever!) that I can't see are
clearly documented, so was wondering if anyone has any insight on this.

1. If we elect not to premigrate certain files, are we still able to use
SOBAR? We are happy to take a hit that those files will never be available
again, but some are multi TB files which change daily and we can't stream
to tape effectively.

2. When doing a restore, does the block size of the new SOBAR'd to
file-system have to match? For example the old FS was 1MB blocks, the new
FS we create with 2MB blocks. Will this work (this strikes me as one way
we might be able to migrate an FS to a new block size?)?

3. If the file-system was originally created with an older GPFS code but
has since been upgraded, does restore work, and does it matter what client
code? E.g. We have a file-system that was originally 3.5.x, its been
upgraded over time to 4.2.2.0. Will this work if the client code was say
4.2.2.5 (with an appropriate FS version). E.g. Mmlsfs lists, "13.01
(3.5.0.0) Original file system version" and "16.00 (4.2.2.0) Current file
system version". Say there was 4.2.2.5 which created version 16.01
file-system as the new FS, what would happen?

This sort of detail is missing from:
https://www.ibm.com/support/knowledgecenter/STXKQY_4.2.2/com.ibm.spectrum.s

cale.v4r22.doc/bl1adv_sobarrestore.htm

But is probably quite important for us to know!

Thanks

Simon

_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss

_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20170123/da61fca0/attachment-0002.htm>