![]() ![]() License Summary Report shows Front End Application Size consumed by clients, so while this doesn’t translate to disk usage, it might highlight clients where size is significantly higher than expected.ĭisk Library Utilization Report shows libraries low on space, but I assume this is already known, added for reference. Growth and Trends Report may show clients/subclients that have exhibited significant or unexpected growth. Here are some reports to check where the space consumed and if this is expected for your environment.Ĭlient Storage Utilization by Storage Policy Copy Report will show largest clients by data written size. Need to identify where the disk space is used and by which clients/subclients, then you can make an informed decision on what steps to take. With that in mind, deleting these jobs would not be a sensible course of action. Removing this data would invalidate all the jobs that ran later. So, even though that original job may have qualified for aging, because subsequent jobs refer to this original data, it is still retained. Then subsequent jobs do not write this data again to the disk, which is the principle of deduplication only write data once. So, what this means for deduplicated jobs is that an original job that protected all of the application data on a client was written to disk. However Size on Disk, which takes into account Data Written + aged jobs which are still referenced by valid jobs is still very high. I am out of ideas and need to figure this out quickly, so any help would be appreciated. How can I reduce Size on Disk? Is there a way to force a physical purge of aged referenced jobs so that I can finally free up some space? Storage Resources → Storage Policy Copy → Databases → Validate And Pruned Aged Data (successfully validated and resync-ed).Storage Resources → Storage Policy Copy → Databases → Run Data Verification.It seems that the data got aged (deleted) but it’s still being referenced and therefore… not deleted? However Size on Disk, which takes into account Data Written + aged jobs which are still referenced by valid jobs is still very high. ![]() So I checked the Mountpaths Space Usage for that DL:ĭata Written corresponds to amount of space used by the Primary copy: 19.8 TB However, when I check the Free Space on the Library I got very little: The Primary copy (blue) went from 52.95TB down to 19.81 TB. So, I assume quite a bit of data was deleted. I also ran Data Aging and could clearly see data chunks being deleted in SIDBPhysicalDeletes.log and after a while I got this: There were some backup jobs with an extended retention - so I’ve deleted those, and some more of the old backup jobs to make space. The main culprit were SQL server backups: After haveing a look at the utilization, indeed it turned out to be 99,7% full. I ran into a bit of an issue… Yesterday, one of the Disk Libraries got filled up and the backups went into waiting status. ![]()
0 Comments
Leave a Reply. |