Understanding Recovery Solution Server Space Management and Deletion Jobs
The Server Space Management and Deletion jobs withing Recovery Solution are at best poorly understood (and I won't claim to comprehend everything that is going on in there myself! ). However, having a little better understanding of what is going on in these extremely important jobs of Recovery is critical, particularly if you're constantly low on free disk space like we are.
Server Space Management - SSM is the process by which old revisions of files (or recently excluded files) are marked for deletion from the Recovery Solution storage BLOB files. During SSM, the Retention rules you apply in the RS Agent settings (about how long to keep snapshots and deleted files for, and any exceptions to these rules) are applied to all files backed up in the Recovery Solution's BLOB files.
Deletion - Deletion can be run separately from SSM (particularly useful if SSM terminates unexpectedly), but also runs as a separate thread as a component of SSM. The Deletion process goes through the DeletedBLOBs table to find the BLOB file and offset within that file which contains data which has been deleted and physically removes (NULLs out) the file data within the BLOB file. This results in the BLOB file's actual content being modified. Through the use of NTFS sparsing technology, the file uses less physical space on disk (so your 500MB BLOB file may only be using 175MB on disk). For example:
Compaction - Compaction is the process by which existing BLOBs are consolidated into new BLOBs by copying the data remaining from 2 or more BLOBs into a new file. Once the new file is created and database references updated relative to the file key and revision information, the original BLOB(s) is/are deleted from the disk.
For additional information about SSM, Deletion, and Compaction, take a look at AKB41309. The report following is based off the information in that KB article.
Monitoring SSM/Compaction Progress
With a lot of RS boxes to manage, sometimes you want to see how close a particular server is to completing its Deletion job (is it almost done deleting all the revisions and about to start the Compaction phase?, etc). So I have been running a couple of SQL commands directly against the SQL database for a while to achieve this. Well today I decided to make a report in NS that I can use for this. On RS 6.2 SP3 (and I assume RS7) there are some KB article updates which include this functionality; for now we are on RS 6.2 SP2 and don't have access to it yet and thus rely on the attached report.
The report should return two rows. One will have the total number of distinct FileKeys (individual files) and the total number of revisions of these FileKeys that are marked for deletion. These are good indicators of whether the initial phases of SSM are completed. If these numbers are going up, then Space Management is still marking file revisions to be deleted by the Deletion thread, and you are yet a while away from seeing storage reclaimed. If they are going down, then Deletion and Rebaselining has started and you'll want to monitor the second row for details about that.