Limit the number of revisions stored

Having unlimited versions of your content stored is handy and helpful if you publish content on a regular basis. You need a safe way back to retrieve any version of your content at any time. However, once you accumulate considerable amounts of content, and, therefore, stored versions, you may consider limiting the number of available revisions in the revision history, that is, limit how many versions back you want to store. This is useful when you do not use revisions all that often and, most importantly, when content revisions take too much storage space on your database. Say you are publishing a series of blog posts for this year’s best New Year vacations. You probably would not want the versions of this seasonal content to take up space in your database forever.

You can limit the revisions stored for:

• Content, both for built-in and dynamic content modules
• Widget templates
• Page templates
• Pages

What you do is modify the revision history settings and specify both of the following:

• For how long to keep versions (Draft and Published) for any page or content type on a global level
• The minimum number of published versions stored

Using a combination of these settings, you make sure no meaningful revisions are lost. For example, you may want to keep content versions for the last three months but make sure at least 10 published versions are kept, as well. Thus, content items with fewer updates and modifications are still available in the revision history.

NOTE: Keep in mind that revision history settings apply to all content types and pages.

To modify the settings:

1. Navigate to Administration » Settings » Revision history.
2. Choose whether for any content or page you want to keep:
   1. All versions (draft and published)

      NOTE: By default, this option is selected and Sitefinity CMS keeps unlimited number of revision versions.

   2. Limit versions to:
      • Published or draft, created within a specific period back in time
      • Minimum number of published versions to keep
3. Save your changes.

Once you specify the revision history settings, the system executes the cleanup of the versions you do not need at a scheduled time.

NOTE: If you are running the cleanup for the first time, you probably have a large amount of revisions stored. Consequently, this may result in higher SQL Server usage. This behavior is expected and occurs only when running the cleanup task for the first time.

You can modify the cleanup date and time by navigating to Administration > Settings > Advanced settings » Version » Cleanup » Scheduled for. Sitefinity CMS will automatically run the scheduled cleanup task on a daily basis, on the time you specified.

NOTE: Keep in mind that no matter how many times you edit and publish a content item or page, the cleanup task runs daily at the specified time, not upon publishing the item. As a result, in a day, you may have more than the specified number of published versions stored until the scheduled cleanup task is run.

Once you configure your desired Revision history cleanup policy, Sitefinity CMS takes care of cleaning up the database from unnecessary revision history versions of all content and continues doing so on a regular basis. This operation results in lots of unused space, as it cleans up your database tables. Although databases require some free space for regular operations, you can take advantage of the unused space, freed up by deleting revision history, and decrease your database size. This results in smaller overall database file size, and consecutively - easier backup and restore.  

To decrease your database size, you need to perform a shrink operation. This operation is external from Sitefinity CMS and depends on your selected database server. For example, if your Sitefinity CMS database is running on SQL Server, refer to the Microsoft documentation on how to shrink a database. 

Keep in mind that it is best to perform a shrink operation after the initial configuration of Revision History cleanup policy. The initial run of the cleanup operation will most likely free up a significant amount of space. Later on, you can run the shrink operation regularly, for example once a month.  Additionally, you can optimize your database performance after running the shrink operation by following the Rebuild database indexes procedure. This will help addressing any fragmentation in the data/indexes, caused by the shrinking operation.