Best Practices

  • Use a single volume-group per VM

    • Can be more than one AIX VG or IBM i iASP
    • Creates a single consistency group per VM
    • Controls cost and failover complexity

  • Onboard all volumes as soon as the volume-group is created (or any time volumes are added to a volume-group)

    • Volumes are easily “forgotten” if not onboarded promptly
    • Volumes must be onboarded for failover to function
    • Onboarding post-disaster is not possible

  • When cloning volumes at the target site for a DR test, clone all the volumes in one volume group with a single command.

    • All volumes will be at the same consistency point.

  • For backup volumes (ie, volumes that are used as the target for your Database backups) it is best practice to replicate those using some alternate method, not SBR. Replicating via another method will help ensure that these volumes are recoverable in the event of an issue with SBR. Replicating them with SBR can also affect the RPO of all volumes in the volume-group they are in, or in extreme cases cause consistency issues or problems cycling the change volumes in a reasonable time.

    • Examples may incude:
      • NFS
      • Google Storage Buckets
      • rsync
      • Oracle RMAN to a remote destination

  • Test and document your DR process

    • OS Recovery
    • Data volume recovery
    • Network considerations (IP, Routing, DNS, etc)
    • Application Recovery