SharePoint Content Database are configured to run with a different recovery model than Full Recovery,is it important to configure content database recovery model to full recovery. We have 3 TB size of content db which RBS enabled.
2
-
are you using mirroring?– Waqas Sarwar MVP ♦Commented Jul 20, 2016 at 14:02
-
not using mirroring using sql server always on– adilahmedCommented Jul 24, 2016 at 12:13
Add a comment
|
3 Answers
The default recovery model of a Content database in SharePoint 2010 is full, as per the article Database types and descriptions (SharePoint Server 2010). And I would recommend keeping the full recovery model because it's (arguably) the most important database of your farm. All your users added value gets stored in the content database.
Content databases store all content for a site collection, including site documents or files in document libraries, list data, Web Part properties, audit logs, and sandboxed solutions, in addition to user names and rights.
If you can't recover an entire farm, make sure your content is saved. You can always set up a new farm, but you can't add content that has been lost. 3 TB of data in a content database is a lot. It works, but if you need to recover from disaster, restoring 3 TB of data takes far too long. Microsoft recommends having only 200 GB in one content database for this reason.
answered Jul 20, 2016 at 11:19
The recovery model of a content database has to be configured depending on your backup plan :
If you don't plan on doing transactional backups, you can configure your database to "Simple" recovery model.
If you plan doing transactional backups, you can configure your database to "Full" recovery model.
If you put your recovery model to "Full" and don't do any transactional backups :
The transaction log will just increase/expand until it maxes the configuration or the disk.
If this happens, this will generate a service stop.
Transaction logs are recycled when all these markers are reached :
- Transaction Commit
- CheckPoint (triggered automatically + manual checkpoints)
- Transaction backup (only if recovery model is not simple)
- Mirror sync (only if mirroring is configured)
What I advise customers is set the databases to the Simple Recovery Model if:
1) You're not using a replication method (Mirroring, AlwaysOn, Log Shipping) that requires the Full Recovery Model.
2) You will not be performing point-in-time restores, which is another benefit of the Full Recovery Model with appropriately timed Transaction Log backups.
If neither of these apply to you, switch to the Simple Recovery Model for simplified management of your databases.