Snapcenter backup metadata refresh.

[violet iris]

I had this issue, and didn't realize it until about 500 snapshots on my remote side had been stored.
https://kb.netapp.com/data-mgmt/SnapCenter/SC_KBs/SnapCenter_created_snapshots_do_not_get_deleted_by_SnapVault_retention_Policy

I manually cleaned up the mess, and I hope i've got the proper policy/rule/snapmirror-label now that it will work moving forward.

Unfortunately snapcenter now shows all 500 of those snapshots although they don't actually exist anymore. Is there a way to force snapcenter to actually look at the storage vs just hitting its local database for this information? I have tried to clean this up, but it seems to timeout if I try to delete more than 2 or 3 backups at a time and thats not really going to work to cleanup the 2000 plus snapshot metadata across all of my volumes.

This is with snapcenter 5.0 and ontap 9.14p5 for the DR side cluster.

[turbid topaz]

There is a job that runs every Sunday morning at 3am local time. At least I'm pretty sure it's at 3am. That job compares what exists on secondary compared to what exists in Snapcenter's database and cleans the database. So wait until Sunday morning or find the job in the Windows task scheduler and run it manually.

[violet iris]

This is the vmware appliane/plugin

But that would be great if it was the case, and I just need to give it some time.

[turbid topaz]

There is a similar process on SCV that runs once a week, Also on Sunday morning, though at 2:12am, instead of 3am.

[violet iris]

Thanks, I got things cleaned up but they are just building back again. The actual snapshots on the secondary location are being removed as they should, but I guess they just show up in the snapcenter gui until the process runs on Sunday? Mostly i'm concerned with end users trying to do a restore from a backup that SnapCenter list, but is actually already removed from the storage location.