Thanks for the help in the thread I posted earlier.
I am going to go forward with changing the failure groups, and creating the descOnly disk, but obviously not without the proper planning.
My biggest concern is the DR/rollback procedures. Is there any way to backup GPFS metadata only? Mind you, the metadata is kept on 12 fusion-io cards.
The only reference I've seen on this forum about metadata backup is here:
I also haven't found anything in the advanced administration guide.
Is there any ways to backup metadata, even on a low level? Of course I know of the 'dd' command, but I would assume it's not as simple as that, and might require completely stopping the filesystem, etc.
NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
This topic has been locked.
6 replies Latest Post - 2012-03-06T18:59:08Z by SystemAdmin
Pinned topic GPFS Metadata backup
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2012-03-06T18:59:08Z at 2012-03-06T18:59:08Z by SystemAdmin
Re: GPFS Metadata backup2012-03-05T15:20:45Z in response to SystemAdminA good file system backup should include all data and metadata, together.
And a good backup plan includes testing -- e.g. pull some of those tapes at random and try to restore at least a randomly chosen subset of your files.
That said, if your question is "can I do a backup by LUN/volume copies and flash copy/snapshot?" --
Yes, I suppose so, BUT as you suggest - you'd better mmunmount filesystem -a - before making your (flash) copies ...
Also be sure to make copies of critical cluster and volume configuration information kept in various /var/mmfs/* files.
And warning - test, test and re-test --- in theory it ought to work ...
BUT -- you're pretty much "on your own" -- AFAIK IBM does not support; does not recommend -- volume based backup of GPFS.
Re: GPFS Metadata backup2012-03-05T18:45:54Z in response to SystemAdminmarc,
we do have filesystem backups, but a restore would take probably more than a week.
So basically, it sounds like there isn't a way to backup our metadata. I only ask, because once in the past a mmrestripefs operation corrupted some data, so we're always a bit weary of doing that, especially on a 260TB filesystem...
it sounds like it's possible to make a volume (read: LUN) based backup of metadata, but it's completely unsupported, and any sort of restoration or disaster recovery from said LUN backups is most likely an exercise in exorcism.
thanks for the help.
Re: GPFS Metadata backup2012-03-05T21:58:19Z in response to SystemAdminIt's not magic - bits are still bits when copied -- BUT -- you've got to get them all frozen and copied together, so that the set of volumes, taken together are a valid GPFS filesystem .
Backing up metadata does you no good, if you don't have the matching data laid out on disk exactly the way the metadata indicates.
For example, restriping changes the metadata AND the data volumes.
gcorneau 0100003X4E148 PostsACCEPTED ANSWER
Re: GPFS Metadata backup2012-03-06T15:20:08Z in response to SystemAdminOne point of clarification here:
GPFS does support the use of LUN-level storage-based copies for disaster recovery purposes.
There are two important things here:
a. You'll want to flush all GPFS cache/buffers to disk using the "mmfsctl suspend" function.
You don't have to unmount the file system.
After kicking off the FlashCopy (or whatever the vendor's byte-level LUN copy program is), you should
use "mmfsctl resume" to resume I/O.
b. You can't mount that copied file system on the original cluster. In fact, you don't want to make those
copied LUNs visible AT ALL on the source cluster. Those disks will have the same NSD ID.
When you use this for DR functions, you have to use "mmfsctl syncFSconfig" to get the file system definition from
the source cluster to the destination cluster.
IBM Power Systems Advanced Technical Skills
Re: GPFS Metadata backup2012-03-06T18:59:08Z in response to gcorneauHi all, thanks for the responses, I'll mark this as answered.
Going by what's been mentioned in this thread, there are ways to backup a filesystem on a per LUN basis, but that is more geared towards a physical site disaster, i.e. asteroid hits your primary datacenter.
This is what I figured, so we'll make sure our full backups are up to speed.