Start of change

Overview

This section provides a brief introduction to SOBAR and the step-by-step instructions for backup and restore by using SOBAR.

Scale out backup and restore (SOBAR) for Cloud services is a method of disaster recovery or service migration that uses existing GPFS™ or SOBAR commands along with Cloud services scripts to back up configuration and file system metadata on one cluster and restore this on a recovery cluster using one sharing container pair set per node class.
Note: SOBAR works on file system boundaries, but with the Cloud services scripts, this procedure should work whether you have configured Cloud services by file system or by fileset.
The high-level steps are as follows:
Note: This procedure is designed only for data tiered to object storage by Cloud services. All other data needs to be backed up some other way.
Primary site
  1. Allocate space in object storage for the backup: Create one sharing container pair set per Cloud services node class that is shared between the primary and recovery clusters.
    • This is used to export configuration data and metadata from the primary cluster to cloud and import to the recovery cluster.
  2. Allocate space in the associated file system for backup: Create a global file system directory to handle the temporary space requirements of the SOBAR backup.
  3. File system configuration backup: Back up the configuration of each file system associated with Cloud services on the primary site. If you have defined Cloud services by file set, then specify the file systems that those file sets are in. Back up the configuration of each file system on the primary site.
    1. Securely transfer these files to a safe place
    2. Use these to recreate compatible recovery-site file systems
  4. File system metadata backup: Back up the Cloud services inode/metadata for file systems from a Cloud services node on the primary site using mcstore_backup.sh. If you have defined Cloud services by file set, then specify the file systems that those file sets are in.
    • This script automatically uploads the backup to the sharing container pair set on the cloud that you created earlier.
  5. Cloud services configuration backup. Back up the Cloud services configuration data from a Cloud services node on the primary site by using the mmcloudgateway service backupConfig command.
    • Securely transfer the resulting file to a safe place.
For detailed backup instructions, see Procedure for backup.
Recovery site
  1. Recovery site hardware and configuration preparation: Prepare the recovery site to accommodate all the file systems that you want to recover from the primary:
    • Each file system on the recovery site must have at least as much capacity as its corresponding primary-site file system. These file systems must be created, but not mounted.
      Note: You need the full space for the entire file system even if you are restoring just file set subsets - per SOBAR.
    • If you do not already have these file systems created, then you can wait until after running the mmrestoreconfig command in the subsequent step. The output generated by the mmrestoreconfig command offers guidance on how to create the recovery file system.
  2. Allocate temporary restore staging space for the file system backup image: It is recommended to use a separate dedicated file system.
  3. File system configuration restore: Restore the policies of each file system, fileset definitions, etc.
  4. Cloud services configuration restore: Download the Cloud services configuration file (that was generated and pushed to the cloud by the mcstore_backup.sh script) using the mcstore_download.sh script on the recovery cluster.
  5. File system metadata restore: Restore the file system metadata by running the mcstore_sobar_restore.sh script on the recovery site.
For detailed recovery instructions, see Procedure for restore.
Note: You can recall offline files from the cloud (both manually and transparently) on the restore site only. Trying to recall offline files, migrated from the primary site, using a recall policy template does not work, because the restore site cluster does not recognize these files to be part of an external pool. However, files once migrated from the restore site can be recalled in bulk using a recall policy.
End of change