Intranoggin

Blither, Blather, Web Content Management.
Blog » Space and Site Quota Strategy

Space and Site Quota Strategy

I mentioned in a previous post that one of there is a WSS report that gives you very useful information about how the space in your site is allocated, but that you need to enable a site quota for the collection to enable the report. So I thought I'd post up my general strategy for setting site quotas.

Over the long term, I try to keep my databases under about 50GB. That seems to me to be a reasonable size for SQL and STSADM backups. Once they get much above that the duration of the backups is longer than I'd like which also makes it harder to move the files around and restore them if necessary (or refresh a dev/staging environment). I back track from there when developing my site structure and placing sites in content DBs. I'll identify the different types of sites that we'll be creating within an organization, project sites, publishing sites, team sites, RAD solution sites, etc. Sites of the same type have the same purpose, and often will also have similar space and retention requirements that you can generalize.

Quick Tip:

When you are determining space requirements, don't forget that version history and the recycle bin also require DB space. My target DB size is 50GB, but when you consider versions and recycle bin, my target space for active content may be 30GB-40GB

Using the generalized storage requirements, I develop a strategy for how sites get broken out into collections. Alternatively, if I have business reasons for breaking sites into individual collections, such as isolating a RAD solution, I develop a strategy for how multiple sites may share a single content DB. I have different strategies for each of these cases.

First, assume I have a single collection in its own content DB. I'll want some warning as it grows before it hits my 50GB target. So I'll set the site collection quota at 30GB. When we get the 30GB limit warning, we'll bump it up to 40GB, but we'll also take a look at how the space is being used. Are wasting too much space with unlimited versions? Do we need to sunset unused documents or webs? Also, when did we hit this limit? Was it in the first year? Were our space requirements growth assumptions correct, and are they still valid? When we hit 40GB, we'll do the same evaluation again and bump the quota up by 5GB. At this point we'll put a little more pressure on the site administrator or site owners to monitor their usage. Beyond 45GB, we'll begin only increasing by 2-3GB at a time. We'll continue that strategy, even over 50GB, until backups become an issue. At which point, we'll need to figure out how to split the collection up.

Now assume we have multiple small sites in the same content DB. For example, say I have business reasons to split each project site into its own collection. If my average project generates 3GB of information, maybe I want to pad it out to 5GB for the same of versions and recycle bin. Extrapolating, I can then fit 10 project sites in a single collection DB. When I create my content DB I'll just set the max number of sites to 10. It's pretty easy to move these smaller sites from one DB to another, so I don't require a warning as they grow. I'll simply set the quotas for these sites at 5GB. However, if DB space isn't an issue, I don't care if these sites go over 5GB. I'll just increase their quotas a GB at a time as necessary. If my overall DB backups become a problem, I'll just use stsadm to back up the collection, then delete it, cap out that content DB, and restore the site to a different collection.

And that's it. It's a simple strategy, but it's powerful. Used in this way, quotas don't just protect your farm from runaway collections; they also serve as a notification system to keep you informed about how your farm is growing.


Posted: 9/1/2010 9:12:00 AM by Ryan Miller | with 0 comments
Filed under: SharePoint