Nils Haustein did such a migration from v7000 Unified to ESS last year. Used SOBAR to avoid recalls from HSM. I believe he wrote a whitepaper on the process..
-jf tir. 18. jul. 2017 kl. 21.21 skrev Simon Thompson (IT Research Support) < [email protected]>: > So just following up on my questions from January. > > We tried to do 2. I.e. Restore to a new file-system with different block > sizes. It got part way through creating the file-sets on the new SOBAR > file-system and then GPFS asserts and crashes... We weren't actually > intentionally trying to move block sizes, but because we were restoring > from a traditional SAN based system to a shiny new GNR based system, we'd > manually done the FS create steps. > > I have a PMR open now. I don't know if someone internally in IBM actually > tried this after my emails, as apparently there is a similar internal > defect which is ~6 months old... > > Simon > > From: <[email protected]> on behalf of Marc A > Kaplan <[email protected]> > Reply-To: "[email protected]" < > [email protected]> > Date: Friday, 20 January 2017 at 17:57 > > To: "[email protected]" <[email protected]> > 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)" < > [email protected]> > To: "[email protected]" < > [email protected]> > Date: 01/20/2017 10:44 AM > Subject: [gpfsug-discuss] SOBAR questions > Sent by: [email protected] > ------------------------------ > > > > 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 >
_______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
