Transcript Document
The Truth Behind SharePoint
Recovery and Availability
Meeting Your SLAs
Dan Holme (MVP, SharePoint Server)
Chief SharePoint Evangelist
AvePoint
Dan Holme
Chief SharePoint Evangelist – AvePoint
Based in Maui, Hawaii
5-year MVP
Microsoft Technologies Consultant, NBC Olympics
Speaker: SPC, TechEd, Connections
Columnist: SharePoint Pro magazine
Author: SharePoint 2010 Training Kit
[email protected]
@danholme
AGENDA
SharePoint Components
SLA Alphabet Soup
Backup and Restore Toolset
Backup and Recovery Scopes & Scenarios
High Availability
Best Practice Summary
SHAREPOINT COMPONENTS
SLA Alphabet Soup
Backup and Restore Toolset
Backup and Recovery Scopes & Scenarios
High Availability
Best Practice Summary
SharePoint
Farm
IIS, Windows services, file system, …
Zone
Web Application
Content DB
Site collection
Top-level site
Service Application
SQL Server
workflows
security
Sub site
List/Library
[Folder]
Item / Document
metadata
versions
SharePoint Components
SLA ALPHABET SOUP
Backup and Restore Toolset
Backup and Recovery Scopes & Scenarios
High Availability
Best Practice Summary
Service level agreements
RTO – Recovery Time Objective
RPO – Recovery Point Objective
RLO – Recovery Level Objective
Uptime
SharePoint Components
SharePoint databases
Recreated during restore to a rebuilt farm
Often excluded from backup:
IIS configuration
File system components
Visualizing RTO & RPO
RTO
Backup Window
Failure
Backed-up
RPO
Recovered
Recovery Level Objective
Farm
IIS, Windows services, file system, …
Zone
Web Application
Content DB
Site collection
Top-level site
Service Application
SQL Server
workflows
security
Sub site
List/Library
[Folder]
Item / Document
metadata
versions
SharePoint Components
SLA Alphabet Soup
BACKUP AND RESTORE TOOLSET
Backup and Recovery Scopes & Scenarios
High Availability
Best Practice Summary
Backup and recovery toolset
Recycle Bin
Third-party
SharePoint Central Administration
backup and restore
PowerShell
STSADM
IISBack.vbs
SQL Server tools and
maintenance plans
SharePoint Components
SLA Alphabet Soup
Backup and Restore Toolset
BACKUP AND RECOVERY SCOPES & SCENARIOS
High Availability
Best Practice Summary
List/website export
Granularity
Top-level site
Sub site
Lowest level of out-of-box granularity
Not full fidelity
Slowest of all backup types
Recommend < 1GB
List/Library
Site collection backup
Full fidelity
Faster than export
Read-only during backup
Recommend < 15GB
Site collection
Top-level site
Sub site
List/Library
[Folder]
Item / Document
Farm backup
Two forms
Full fidelity
Configuration
Data
Fastest backup type
Full or differential
Farm backup ≠ complete backup
Bits on each server in the farm
Services state: which services are running on which servers
Service application associations
Managed account passwords
Other considerations
No item level restore
No scheduling engine
Can only backup directly to UNC path
XML catalog
No way to archive backup sets
Recovery can be time consuming
Farm recovery
Scenario: farm has failed
Solution: rebuild farm
Create a new farm
Use Central Administration to restore farm
Apply manual changes to each server
Reconfigure services on each server
Reconfigure service application associations
Test!!
Content container recovery
Scenario: restore a list or library, website, site collection
Solution: unattached content database recovery
Key benefit: no need for a recovery farm
Three primary steps
Site collection backup
Exported site or list
Unattached content database
Key drawback: must restore a content database
Deleted content recovery
Scenario: User has deleted content
Solution: Recycle Bin
First-stage (end user)
Second-stage (site collection administrator)
Site Recycle Bin
Deleted sites are kept in the second stage (site collection) recycle bin
Site collection admin can restore in UI or PowerShell can be used
PowerShell (Get-SPDeletedSite, Restore-SPDeletedSite)
New in
SP1
Do you need a third-party solution?
Do any of the following apply?
Bottom line
Recovery scenarios not supported out-of-box
Granular (item/document or folder) content recovery
Platform recovery
SharePoint Components
SLA Alphabet Soup
Backup and Restore Toolset
Backup and Recovery Scopes & Scenarios
HIGH AVAILABILITY
Best Practice Summary
Service uptime
Downtime per year
95% Uptime
18.25 days
99% (2 nines)
3.65 days
99.9% (3 nines)
8.77 hours
99.99% (4 nines)
52.60 minutes
99.999% (5 nines)
5.26 minutes
$$$$
Uptime Percentage
$
COST
High availability comes at a very steep
price
95%
5 nines
SharePoint’s server roles
Web
front
end
App
server
DB
server
To achieve high availability
Web
front
end
App
server
DB
server
You must add redundancy for each role
Web front end
Use load balancing
Active/active design gives faster performance and fault tolerance
http://intranet
Load
balancer
WFE guidance
Use hardware load balancer for best performance & flexibility
Run Central Administration on multiple servers
Each server should be identical (hardware & software)
Virtualization is fully supported
For larger farms, do not run application services on WFE servers
Optimize application pools for performance and isolation
Application server
Use Central Admin to configure services on server
Active/active design – load balancing built into SharePoint
Very flexible
Metadata Mgmt Services
User Profile Services
Business Data Connectivity
Office Web Apps
…
Metadata Mgmt Services
User Profile Services
Business Data Connectivity
Office Web Apps
…
Query
Crawl
Query
Crawl
Application server guidance
Do not use the farm configuration wizard
Group services and deploy these as a unit to other servers
Create service applications for only those services needed
Virtualization is fully supported
Use cross-farm services where needed
Search services
Search services are configured within a search service application
Index can be divided up into index partitions
A crawl component is a server process that crawls content to create
index
A query component is a server process that consults index to
generate search results
Crawler
Crawler
Index partition 1
Query component
Index partition 1
Query component mirror
Database server
To scale, SharePoint supports multiple database servers
To improve fault tolerance, two primary options
Both are active/passive designs
Failover
Primary
Active
Passive
Clustering
Mirroring
To cluster or mirror?
Cluster
Mirror
Protection level
Server
Database
Require shared storage
Yes
No
Protect all databases
Yes
No
Setup ease
Hard
Easier
Configuration flexibility
Inflexible
More flexible
Failover ease
Easy
Harder
Failover speed
Fast
Slower
Cost
Expensive
Cheaper
Server location
Side by side
Can be
separated
In SharePoint farms, database mirroring
is more commonly implemented
Database server guidance
Do not run non-SQL apps on database server
Dedicate server to one SharePoint farm
Use SAN for all database storage
Configure disks as RAID 10 for tempdb, content & search databases
Backup log files regularly
In general, keep content databases limited to 200GB
If using RBS, be sure to consider recovery aspects
SharePoint Components
SLA Alphabet Soup
Backup and Restore Toolset
Backup and Recovery Scopes & Scenarios
High Availability
BEST PRACTICE SUMMARY
Best practices
Define recovery objectives
Document environment and keep a change log
Use solution packages (WSP) for custom code deployments
Keep DBs small - DB size often dictates RTO
Have a test/QA/staging farm
Consider third-party solutions
Perform trial restores
Resources
TechNet
technet.microsoft.com/en-us/library/cc748824.aspx
technet.microsoft.com/en-us/library/ee662536.aspx
Architecting a fault tolerant farm (Michael Noel)
Optimizing SQL Server for SharePoint (Randy Williams)
Speeding up SharePoint recovery (Randy Williams)
SharePoint 2010 Disaster recovery (Todd Klindt)
Questions