Is there ever an instance where a volume will not go to the recovery queue for 12 hours when it is deleted? We verified that the recovery queue is enabled for 12 hours on the SVM, but my customer says she deleted a volume and a few hours later it was not in the queue. It was on a Snaplock aggregate.... maybe that has something to do with it?
#Volume doesn't go to the recovery queue when deleted
bleak wing
steep spire
if you delete it with volume delete -force, it will not go to the recovery queue, for example
lavish gull
Or you turn off the volume recovery queue (set the time to 0)
Or you turn off auditing which automatically force deletes the MDV volumes.
Or you delete volumes, then delete the SVM. (Without the svm, the recovery queue won’t work )
bleak wing
Thanks for the feedback, but doesn't look like any of those situations were in play here. She deleted other volumes tonight, and they all went into the recovery queue. The only one that didn't was a Snaplock volume. I think I have a test system, maybe I'll try it on there.
rare glade
Weird. Maybe it is Snaplock? IDK. Without seeing an ASUP or something during that time or CLI outputs I'd be guessing.
bleak wing
She did some testing, and it consistently seems to be the Snaplock volumes that don't go into the queue. THis is OnTap 9.8 BTW.
rare glade
Hmm.
SnapLock Compliance restrictions
There is a command that is modified to prevent it from carrying out its normal actions on SnapLock
Compliance volumes:
• Volume delete. Allowing a SnapLock Compliance volume deletion before the expiration of the
retention period of all the records and files on it violates the principle of WORM storage, especially in
the regulated data archived space. The delete command succeeds on a SnapLock Compliance
volume only if all the WORM records and files with specified retention periods have expired.
