Forum Discussion
Versioning consuming TB's of tenant storage
Is anyone else seeing version history in Document libraries consuming HUGE (I am seeing TB's of storage consumed in my Tenant)?
I noticed we were consuming a lot of storage month over month, so checked out the largest sites.... YIKES!!!! Spotted PowerPoint files that were consuming almost 900 GB, Yes GB!! I drilled in to version history.....Turns out it is a 400-500MB PowerPoint, but had 500 versions (actually on version 735) but the default is to save 500 versions. So the number gets rather large as far as total storage consumption. I am sure in my use case example, the end user doe snot know this or care about having 500 versions. They would be happy with 3-10 versions to roll back to, but having to set this at the library level for all libraries is crazy.
This is crazy! I have found a PowerShell script that I am testing to eliminate all versions except xx (I am little surprised that this is not included with Library settings from MS, the only way a user can "cleanup" is delete all versions or go 1 by 1 and delete the older versions.
Oh, and the other thing I noticed is I can set version history limit via the interface for a Comms Site to 10 versions, but the lowest number I can set a Teams based SP site is 100... which if the file is 100-500 MB and lots of collaboration is happening, well that chews up a ton of storage. Outside of an extreme example or maybe legal requirement - how many versions do most users need to roll back to?
I am the only one that is feeling this pain? How are you managing this in your tenants without constantly buying more storage from MS? I am not against buying more storage when the service is being used, but this seems like a bad approach from MS to drive the version history to 500 by default and not provide a way to set the limit to something else for the entire tenant without having to develop our own solutions to manage this.
This is a known limitation.
Organizations typically resort to using PowerShell scripts or apps (example) to keep the versions (and the associated storage consumption) under control.
Looks like Microsoft is going to address this: see Roadmap 145802
This is a known limitation.
Organizations typically resort to using PowerShell scripts or apps (example) to keep the versions (and the associated storage consumption) under control.
Looks like Microsoft is going to address this: see Roadmap 145802
- Thanks for sharing Paul! Looking forward to the Roadmap item you shared! It cant get here soon enough!
- I have a tangential observation. We are also looking for solutions to keep versions from eating up our storage without losing all of the functionality. So, I created a new Doc Library and turned versioning OFF (via PnP Powershell). The plan is that users move Final versions of the files to this new library but collaborate and edit in the old library which still has versioning.
I did a test and moved files from the old library to the new library. I did get a warning that the new library had a lower version limit and that those versions would be lost. Great! However, the size, of those files collectively, and the site itself, is still exactly the same. So...did the versions really get deleted? I did wait about 24 hours as storage metrics don't seem to be real-time. As others have mentioned, there are scripts and tools that can help deal with these issues.
For example, this tool can delete versions in bulk (by number of versions to keep). Furthermore, it can update versioning settings in bulk (e.g. for all libraries in a site collection or in the entire tenant). It can also set major version limit below 100. DMS-Shuttle
