Recovering SharePoint content
To effectively plan a SharePoint data protection strategy, you have to consider content recovery and disaster recovery (DR). Widespread adoption of SharePoint within an organization will likely mean that SharePoint servers will eventually replace existing file servers. In other words, users will access documents via SharePoint Web portals (and, ultimately, SQL databases) rather than as files in a shared directory. I don't believe the potentially enormous implication on traditional nightly backup has been adequately considered. There are masses of files currently managed as individual entities by a backup app that would now be stored in monolithic (from a backup app perspective) SQL databases under SharePoint.

But a more immediate issue might be understanding how SharePoint content is recovered. While this version represents a significant step forward from earlier versions in this regard, it still leaves much room for improvement. C...

BROWSE BY TAG Columns,   Data Protection,   Disaster recovery and planning,   VIEW ALL TAGS

Prior to the 2007 version, a similarly arduous process was required for SharePoint. But Microsoft has added an important timesaver--a recycle bin--to ease the pain. Actually, SharePoint now has two recycle bins: a user and a site-level (or administrative) recycle bin. Recycle bin functionality can be disabled, and both size quotas and object expirations can be applied. In addition, SharePoint inherently supports document versioning, so it's possible to revert to an earlier version without necessarily having to do a recovery. While the recycle bin will help eliminate many nuisance-level file recovery issues, if a document must be recovered the only options are the traditional Exchange-like recovery process or via a third-party product--more about these later.

DR for SharePoint environments is even trickier. SharePoint provides GUI and command line (stsadm.exe) options to back up an entire farm, for example, but Microsoft subtly suggests that these options are most effective for "small to medium" deployments. Also, there's no scheduling mechanism within SharePoint, so automation would need to be performed by scripts executed via the Windows Task Scheduler.

Of course, because SharePoint largely consists of SQL Server databases, one approach is to simply back up or protect those databases using the tried-and-true approach of your choice. This is certainly a viable option, but one must further consider that, because traditional SQL backups will lack knowledge or context of a SharePoint environment, additional time-consuming postprocessing activities will have to be performed to reintegrate the database back into SharePoint. Furthermore, SQL backups can't adequately address the aforementioned content recovery issues nor the additional steps needed to recover WFEs and application servers. Even index servers, if they're large, may need a recovery strategy as rebuilding would be very time-consuming.

< PREV PAGE   |   1  |   2  |   3  |   4  |   NEXT PAGE  >