Enterprise Data Protection for SharePoint

Enterprise Data Protection for

SharePoint

Saguenay (Sag) Baruss

Senior TSP, AvePoint Canada **

This presentation was created and distributed independently of AvePoint. For additional

information on AvePoint’s products and services please visit http://www.avepoint.com. **

Introduction

Section 1

| Slide 2 |

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

| Slide 3 |

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

| Slide 4 |

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

| Slide 5 |

Data Protection in General

Section 2

| Slide 6 |

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.


| Slide 7 |

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.


| Slide 8 |

Types of Failures

• Incremental data loss.

• Component failure.

• Application or service failure.

• Disaster.


| Slide 9 |

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.


| Slide 10 |

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.


| Slide 11 |

What Makes SharePoint Data

Protection so Difficult

Presenter’s Editorial

| Slide 12 |

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

| Slide 13 |

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

| Slide 14 |

Data Protection for SharePoint

Section 3

| Slide 15 |

Let’s Build a SharePoint Farm


| 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

SQL Cluster

Users

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.


| Slide 17 |

Backing Up Dedicated App Servers

• Components Requiring Backup: – Configuration settings.

– Service-specific data.

• Considerations: – Dedicated App servers often represent single points of failure.


| Slide 18 |

Backing Up External App Servers


– 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.


| Slide 19 |

Backing Up SQL Servers


– Database and log files.

– External BLOBs.

• Considerations: – SQL backups are SQL-specific, not application-specific.

– Watch out for externalized content.


| Slide 20 |

Backing Up SharePoint Data

• Components Requiring Backup: – Configuration databases

– Content databases

– Remote BLOBs

• Considerations: – ‘SharePoint data’ and ‘SharePoint configuration’ are not the same

thing.


| Slide 21 |

An Holistic View of SharePoint


| Slide 22 |

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.


| Slide 23 |

Native Data Protection (cont.)

• SQL Database Backup: – SQL can backup and restore SharePoint databases and associated

configuration.


| Slide 24 |

SharePoint Recycle Bin


| Slide 25 |

SharePoint Backup


| Slide 26 |

Data Export / Import


| Slide 267 |

SQL Backup


| Slide 28 |

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.


| Slide 29 |

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.


| Slide 30 |

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.


| Slide 31 |

Supporting Large Quantities of Data

Section 4

| Slide 32 |

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.


“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

| Slide 33 |

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.

| Slide 34 |

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.


| Slide 35 |

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.


| Slide 36 |

High Availability for SharePoint

Section 5

| Slide 37 |

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.


| Slide 38 |

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.


| Slide 39 |

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.


| Slide 40 |

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.


| Slide 41 |

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.


| Slide 42 |

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.


| Slide 43 |

Closing Thoughts

Section 6

| Slide 44 |

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

| Slide 45 |

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

| Slide 46 |

Recommended Next Steps

1. Revisit your SharePoint documentation.

2. Reconsider your SharePoint data protection

strategy.

3. Schedule a disaster recovery test.

Closing Thoughts

| Slide 47 |

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



• 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

| Slide 48 |

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 |

(a) 1 minute (d) 1 week

(b) 1 hour (e) Not sure

(c) 1 day

Questions?

Closing Thoughts

| Slide 50 |

Enterprise Data Protection for SharePoint

Documents