Alright people, lets lay it out there. SharePoint comes with some recovery features built right in, out of the box. You don’t even have to turn it on or configure it and its still there… You have a two layer recycle bin in every site collection. The settings are based on time and size. If a user deletes a document or every document in January, it might get kicked to the 2nd stage in February. Then, as long as you don’t hit the right size limit on your site / recycle bin, the document will sit around in the 2nd stage recycle bin forever.
So why are people spending a ton of money on backup agents and storage / tapes to do brick level backups for 1 year at a time? Who knows? Why let content databases get to 100gigs and rely on SQL backups? Who knows? Here is the problem. Have you ever done a recovery? Have you done one of all of the possible recovery options? I have, and they all suck. That is a technical term for it sucks. Why you ask? Let me count the ways… (Note: Do not take any of this to mean not to do as many backups as possible in order to cover your own butt, I do use SQL, but its reserved for DR type scenarios and not day to day recovery’s.)
- SQL Backups (depending on the DB size) can take hours, especially if you do them to tape (disk is faster, mo’ better).
-
SQL Restores (regardless of DB Size) can take hours, especially if you need to pull from tapes, index, catalogue, restore, attach, etc.
- This can get to be even worse if you don’t need to recover all sites in the content DB, just a single site or a single document. Then you need to recover to a new location or new server, attach the database, create a new web application so you don’t jack up your managed paths, etc.
- SharePoint backup agents are a pain to get working, and then are they even really necessary? Do you need to take snapshots of the content that can be recovered from itself every night? Every week? Maybe once a month would be cool…
I just did a quick comparison of storage requirements, transfer times, and backup methods on a client’s environment. I compared the scripts output that I will share in a minute to Full SQL backups.
| |
FULL SQL Backup
|
Michael Script Backup
|
|
WSS_Content_DB1
|
28,181,080 KB
|
- 128,065 KB
- 50,658 KB
- 49,836 KB
- 11,352 KB
- 10,346 KB
- 5,471 KB
- 6,389,613 KB
|
A full SQL backup includes the content in the database, as well as the transaction logs, all rolled into one nice little package. If you need to move, backup, whatever, it’s a huge file. While the scripted backups are much smaller, much more portable, much more downloadable if you need to transfer from servers over the internet or a WAN. (I am actually downloading site backups from a clients dedicated server in a hosting environment in order to upgrade to SharePoint 2010 on an in-house system, so that’s where the reference comes from).
The scripts can be located at my previous post, https://stumpj.wordpress.com/2010/10/22/vbscript-better-sharepoint-backup-no-backup-exec-agents-no-sql-backups/
Filed under: Scripting, SharePoint | Leave a comment »