VMware Site Recovery Manager 8.x
VMware Live Site Recovery Manager 9.x
Site Recovery Manager (SRM) does not have any built-in automation or internal process capable of deleting Protection Groups without user intervention.
Log analysis indicates that the Protection Groups were manually removed from the SRM configuration through an authenticated user action.
The SRM logs (vmware-dr.log) captured deletion events for the affected Protection Groups at the reported time.
Example:
From /var/log/vmware/srm/vmware-dr.log on SRM appliance, you may see the below events confirming the deletion of Protection groups.
2025-10-02T16:03:15.602Z verbose vmware-dr[614655] [SRM@6876 sub=StorageProvider opID=d6####40] RemoveGroupPreparePersist: 'vm-protection-group-#####', 'PG-#########'2025-10-02T16:03:15.6462 verbose vmware-dr[02226] [SRM@6876 sub=StorageProvider ctxID=21####3c] RemoveGroupCommit: 'vm-protection-group-#####', 'PG-#########'2025-10-02T16:03:15.6472 verbose vmware-dr[01261] [SRM@6876 sub=StorageProvider opID=22####f5] RemoveGroupCommitPersist: 'vm-protection-group-#####', ''PG-#########2025-10-02T16:03:15.674Z verbose vmware-dr[01261] [SRM@6876 sub=Default opID=22####f5] Unreserved reservation for PG-#########2025-10-02T16:03:15.675Z verbose vmware-dr[01261] [SRM@6876 sub=Replication opID=22####f5] Posting N2Dr7EventEx21ProtGroupRemovedEvent sent to the local VC for group 'PG-#########'
From /var/log/vmware/srm/vmware-dr-audit.log you may see the below events with user and IP address.
2025-10-02T16:03:15.547 info vmware-dr[02231] [SRM@6876 sub=Audit opID=99####85-waitForUpdatesEx] [Success] User:VSPHERE.LOCAL\SRM-remote-9e70c7a3-####-####-####-88d3#####fe1, Method:vmodl.query.PropertyCollector.waitForUpdatesEx, From:1##.1#.##.##
To restore functionality:
Recreate the missing Protection Groups using the same replicated datastore or device pairs.
Reconfigure virtual machine associations under each recreated Protection Group.
Verify placeholder datastore configuration for each PG.
Rebuild associated Recovery Plans, ensuring that the recreated PGs are added back to their original recovery workflows.
Validate Recovery Plan integrity by performing a Test Recovery operation.
Since the Protection Groups were manually removed, the SRM metadata (protection group definitions and mappings) was permanently deleted.
The underlying replication remains intact at the array level, but SRM requires the recreation of logical constructs (PGs and Recovery Plans) to restore orchestration of disaster recovery operations.
Restrict access to SRM administrative operations to authorized personnel only.
Enable SRM logging retention to capture audit trails of configuration changes.
Implement change control procedures before executing any SRM cleanup or modification tasks.
Regularly export SRM configuration data for quick recovery in case of accidental deletions.