RPO snapshots

Recovery point objective (RPO) snapshots are peer snapshots that are taken at the same time on the primary and the secondary sides. RPO is disabled by default, and the minimum value you can set is 720 minutes and increment in multiples of 5 minutes . You can update afmRPO parameter while creating the primary to change the interval, or after creating the fileset by using the mmchfileset -p command with the afmRPO parameter.

mmchfileset <FileSystemName> <filesetname> -p afmRPO=<time_in_minutes>

Each RPO interval triggers a snapshot at fileset level on both the primary and the secondary sides, that results in the file system being quiesced. Quiescing the file system is a data-transfer intensive action. Therefore, as a performance optimization, if multiple caches have similar RPOs, their snapshots are batched together so that the file system is quiesced only once. As further optimization, RPO snapshots are only taken for primary filesets whose data or metadata is modified since the last RPO period.

afmAsyncDelay specifies the minimum time that the primary site must wait before flushing the pending data that needs to be transferred to the secondary site. An RPO request in queue flushes the queue before creating a snapshot on the secondary site. The general guidelines for afmAsyncDelay is to set the asynchronous delay less than the RPO interval.

afmRPOMiss event occurs when RPO is missed because of a network delay or failure to create the RPO snapshot on the secondary site. If RPOs are missed, AFM waits for the expiration of the next RPO and during next RPO, a message is logged in mmfs.log and a new RPO snapshot is created. Failed RPOs are queued on the gateway again, and are run again at the secondary site until they succeed. At any point in time, two RPO snapshots that are not psnap0 are retained on both sides. If RPOs are not played at the secondary due to some reason and primary does not get acknowledgment for the create from the secondary, the RPO is also deleted from primary. To improve the performance of more than one fileset taking RPOs at the same time, the RPO snapshots are batched together. In this process, the RPOs of few filesets might get slightly adjusted to make use of the batching facility.

Normal RPO deletions from the primary site are performed and queued when the new RPO snapshots are received. While there is every attempt to ensure that the delete operations are successful on the secondary site, there can be some extra snapshots as some delete operations might not be successful. In such cases, you must manually delete the extra snapshots on the secondary site by using mmdelsnapshot -p. Apart from automatic RPO snapshots, you can create user snapshots by running mmpsnap create with - rpo. These are intermediate snapshots between scheduled RPOs and are not deleted during the RPO snapshot delete process.

When the primary site fails, you can roll back the last consistent snapshot present on the secondary site while converting it to the current primary site. However, it is recommended to convert the secondary as-is into the acting primary, because in most cases the data in the secondary is always greater than or equal to the last RPO snapshot. When applications are moved to the current primary fileset after the failover operation, RPO snapshots are not taken because no secondary is associated with the current primary. Therefore, RPO is not applicable to the current primary site. The gateway node mapped to serve a fileset is called the primary gateway of the fileset. The primary gateway acts as the owner of the fileset. If the primary gateway fails, another gateway node takes over the fileset as primary gateway. The recovery is triggered on the new primary gateway while taking over the fileset. If the next RPO snapshot is due at the time when recovery gets triggered, a new RPO snapshot is taken and used for recovery. Whenever RPO snapshots are used for recovery, the normal cleanup process of the older RPO snapshots does not take place. Therefore, some extra RPO snapshots are temporarily displayed on the primary and secondary sites and are cleaned up on subsequent RPO intervals. No regular RPO snapshots are taken on a fileset that is running recovery until the recovery process is complete.

All user-created and system-created RPO snapshots except the psnap0 belonging to an active primary-secondary must be deleted before the primary-secondary is deleted. You can change the RPO interval by running mmchfileset. The time for the next RPO snapshot (Tnext) is calculated by adding the RPO interval that you set (Irpo) to the time at which the previous snapshot occurred (Tprev): Tnext = Tprev + Irpo. If no file in the RPO snapshot changes during the interval, AFM does not take the snapshot, and the time for the next RPO snapshot is calculated as Tnext = Tnext + Irpo.

The RPO management deletes the oldest snapshot when it creates a new one but it never deletes the psnap0. The mmpsnap command can be run to delete psnap0. By deleting psnap0, storage utilization improves because data blocks used by psnap0 are not held down. These data blocks can be significant over a period of time. Also, deletion of psnap0 can improve the performance of subsequent creation and deletion of RPO snapshots. However, you must delete psnap0 only when other RPO snapshots are present in the primary and secondary filesets to handle disaster recovery. If psnap0 is deleted without any other RPO snapshots, data is lost. Also, psnap0 can be deleted from secondary in cases like failing over to the secondary, and a new primary being set up.