Enterprise Data Protection for SharePoint

(1)

Enterprise Data Protection for

SharePoint

Saguenay (Sag) Baruss

Senior TSP, AvePoint Canada **

(2)

Introduction

Section 1

(3)

Session Overview

• This is a 200-level session intended for SharePoint architects and technical leads, in particular the

individuals responsible for:

– SharePoint backup and restore, – SharePoint high availability, and

– Disaster recovery planning for SharePoint.

Introduction

(4)

Session Objectives

• To draw attention to the various components of an enterprise SharePoint implementation.

• To contrast the various data protection options available for SharePoint.

• To provide guidance on how to develop a complete and effective SharePoint data protection strategy.

Introduction

(5)

Agenda

Introduction 5 min

Data Protection in General 5 min

Data Protection for SharePoint 15 min

Supporting Large Quantities of Data 10 min

High Availability for SharePoint 10 min

Closing Thoughts 10 min

Introduction

(6)

Data Protection in General

Section 2

(7)

Terminology

• Service Level Agreement ( SLA )

– An agreement between the business owner(s) of an application or service and the technical team responsible for providing that

service.

• Data Protection:

– The process of ensuring application or service data is not lost in the event of a failure.

• High Availability:

– The process of ensuring the functionality provided by an

application or service is not interrupted in the event of a failure.

Data Protection in General

(8)

Terminology (cont.)

• Recovery Point Objective ( RPO ):

– The point in time to which a system must be recovered in the event of a failure.

• Recovery Time Objective ( RTO ):

– The amount of time between the point of failure and restoration of service.

• System Recovery / Continuity Objectives:

– What objectives must be met following a failure in order for failover and / or system recovery to be considered successful.

(9)

Types of Failures

• Incremental data loss. • Component failure.

• Application or service failure. • Disaster.

(10)

Data Protection Strategies

1. Don’t back it up.

2. Manual or end-user data protection. 3. Data capture.

4. Component capture. 5. System capture.

(11)

Data Protection Prerequisites

• A completed system architecture, including all dependencies.

• A completed Service Level Agreement which

includes all items from the previous two slides. • Business motivation.

• Sufficient resources.

(12)

What Makes SharePoint Data

Protection so Difficult

Presenter’s Editorial

(13)

On One Hand …

• Nothing, it’s not difficult.

• SharePoint is fundamentally the same as any other enterprise system.

• The same rules and guidance for data protection that apply to every other system also apply to

SharePoint.

What Makes SharePoint Data Protection so Difficult

(14)

On the Other Hand …

• SharePoint is a ‘platform’ not an ‘application’.

• SharePoint implementations tends to include a large number of servers.

• SharePoint can be customized.

• SharePoint can be integrated with other applications or services.

What Makes SharePoint Data Protection so Difficult

(15)

Data Protection for SharePoint

Section 3

(16)

Let’s Build a SharePoint Farm

Data Protection for SharePoint

| Slide 16 | Dedicated App Server SQL Server Internal WFEs Internal Users Public-facing WFEs External User SharePoint Databases BLOB Storage External App Server Corporate Data SharePoint Server Web Front End

Servers

(17)

Backing Up WFEs

• Components Requiring Backup:

– IIS.

– Customizations.

• Considerations:

– Multiple WFEs can be deployed in parallel.

– It is recommended to deploy identical WFEs.

– Only a small portion of the WFE needs to be backed up.

(18)

Backing Up Dedicated App Servers

– Configuration settings. – Service-specific data.

• Considerations:

– Dedicated App servers often represent single points of failure.

(19)

Backing Up External App Servers

– Configuration settings.

– Service or application-specific data ( … not stored within SharePoint ).

• Considerations:

– For services or applications storing data both in SharePoint and external to SharePoint, backup synchronicity needs to be

considered.

(20)

Backing Up SQL Servers

– Configuration settings. – Database and log files. – External BLOBs.

• Considerations:

– SQL backups are SQL-specific, not application-specific. – Watch out for externalized content.

(21)

Backing Up SharePoint Data

– Configuration databases – Content databases

– Remote BLOBs

• Considerations:

– ‘SharePoint data’ and ‘SharePoint configuration’ are not the same thing.

(22)

An Holistic View of SharePoint

(23)

Native Data Protection

• SharePoint Recycle Bin:

– Protects against the ‘controlled’ deletions of individual items. – With SharePoint 2010 SP1, can also protect against the

‘controlled’ deletion of sites.

• SharePoint Backup:

– Backs up farms, down to the content database level.

• Data Export / Import:

– SharePoint Designer and can be used to export and import sites.

(24)

Native Data Protection (cont.)

• SQL Database Backup:

– SQL can backup and restore SharePoint databases and associated configuration.

(25)

SharePoint Recycle Bin

(26)

SharePoint Backup

(27)

Data Export / Import

(28)

SQL Backup

(29)

External Data Protection

• Microsoft Data Protection Manager ( DPM ):

– Provides SharePoint-specific backup and restore.

– Does not provide a ‘complete’ solution for SharePoint.

• Enterprise Backup Solutions:

– Can backup all components identified during previous slides. – Uses the same backup method for SharePoint as for all other

enterprise applications.

• SharePoint-Specific Data Protection:

– Provides advanced data protection for SharePoint only.

– Integrates with an existing enterprise backup solution for long-term retention of SharePoint backup data.

(30)

Selecting an Appropriate Solution

• The ‘best’ data protection technology for a given situation depends on:

– Available data protection technologies, – The parameters of the SLA,

– System size and complexity, and – System criticality.

(31)

Recommendations

1. Understand the different components of SharePoint and how they tie together.

2. Know your SharePoint landscape.

3. Determine which components of SharePoint are most important to you.

4. Understand the limitations of your data protection technology.

5. Develop a phased backup and restore strategy.

(32)

Supporting Large Quantities of Data

Section 4

(33)

How Large is ‘Large’?

• It depends on the organization. • Key considerations are:

– Corporate data landscape. – Data usage patterns.

– Underlying sub-systems.

– Legal and retention requirements.

Supporting Large Quantities of Data

“Your data is ‘critical’

when you have to worry about it. Your quantity of data is ‘large’ when you have to plan for it.”

Informal Definition

(34)

SharePoint Storage Scenarios

Scenario Database Size Fine Print

1 < 200 GB No fine print.

2 < 4 TB Requires a certain level of performance from the disk sub-system.

Subject to SharePoint boundaries and limits. 3 > 4 TB Must be an archive database using Document

Center or Records Center site template.

No alerts, workflows, link fix-ups or item-level security.

Usage < 5% read and 1% write.

(35)

Recommendations

1. Embrace RBS. There is no way to take advantage of these increased storage limits without externalizing content.

2. Understand your data and data usage patterns.

3. Rethink ILM and data governance policies for large quantities of data.

4. Consider tiered SLAs.

(36)

Recommendations (cont.)

5. Configure backups based on business criticality of the data, not how it’s stored.

6. Be prepared to invest in your storage sub-systems.

(37)

High Availability for SharePoint

Section 5

(38)

Preparing for SharePoint HA

• SharePoint HA is one component of a broader HA strategy.

• SharePoint HA is dependent on other services:

– Networking services, – Active Directory,

– SAN fabric, and

– Perimeter security services.

• Remember, high availability is not about preventing failures, it’s about mitigating risk.

High Availability for SharePoint

(39)

Virtual Machine-Based HA

• Warm-standby SAN-based HA solution leveraging SAN-based replication to

transport VM images between locations.

• In the event of a failure,

VM’s are restarted in the HA location as user sessions are redirected.

(40)

GeoClustering-Based HA

• Warm-standby SAN-based HA solution leveraging

SAN-based replication of shared cluster resources.

• In the event of a failure, Windows clustering causes services to transition to the HA location as user sessions are redirected.

(41)

Database-Based HA

• Warm-standby SQL-based HA solution leveraging SQL

database mirroring or log shipping.

• In the event of a failure of the principle database, the mirror becomes the

principle copy and user sessions are redirected.

(42)

Replication-Based HA

• Hot-hot HA solution

leveraging SharePoint inter-farm replication.

• In the event of failure, user sessions are redirected to the alternate farm.

• Farm changes are managed through release

management processes.

(43)

Recommendations

1. Select a solution based on requirements. 2. Play to your organization’s strengths.

3. Weigh the costs of each solution.

4. Look for opportunities to re-use your SharePoint HA technologies.

5. Favour simplicity.

(44)

Closing Thoughts

Section 6

(45)

Common Causes of Failure

1. Unclear requirements.

2. Mismatched expectations.

3. Incomplete backups / missed components. 4. Insufficient skills / experience.

5. Insufficient capacity. 6. Lack of governance.

Closing Thoughts

(46)

Data Protection Survival Kit

1. Corporate commitment to SharePoint. 2. Documented business expectations. 3. SharePoint usage patterns.

4. Corporate data landscape. 5. Service levels for each.

6. Corporate ILM strategy.

7. SharePoint governance strategy.

Closing Thoughts

(47)

Recommended Next Steps

1. Revisit your SharePoint documentation.

2. Reconsider your SharePoint data protection strategy.

3. Schedule a disaster recovery test

.

Closing Thoughts

(48)

Resources

• SharePoint Data Protection:

–http://technet.microsoft.com/en-us/library/bb821259.aspx –http://technet.microsoft.com/en-us/library/cc261687.aspx

• SharePoint Capacity Planning:

–http://technet.microsoft.com/en-us/library/cc298801.aspx –http://technet.microsoft.com/en-us/library/cc261700.aspx –http://technet.microsoft.com/en-us/library/cc262787.aspx

• SharePoint Content Database Sizing:

–http://sharepoint.microsoft.com/blog/Pages/BlogPost.aspx?pID=988

• DocAve SharePoint Community

–http://www.docave.com/

• Sag Baruss’ Blog

–http://saplingdata.wordpress.com/

Closing Thoughts

(49)

One Last Question

• Suppose a SharePoint user in your organization has overwritten several versions of his/her critical

documents. The user now needs the missing versions, but can’t lose their changes to the

remaining versions. How long will it take you to recover the missing document versions?

Closing Thoughts

| Slide 49 |

(50)

Questions?

Closing Thoughts