- Microsoft SharePoint 2013 Disaster Recovery Guide
- Peter Ward Peter Abreu Pavlo Andrushkiw
- 912字
- 2021-04-02 10:27:58
Identifying the components of your SharePoint environment
Before creating a DR plan, you should take a complete inventory of each component of your SharePoint environment. This inventory should include the following:
Physical architecture
You should begin the process of taking an inventory of each component of your SharePoint environment starting with the physical architecture. The physical architecture should include all farms and related components in your SharePoint environment, including any development, testing, staging, QA, and production farms.
Although the other SharePoint farms aside from your production farm may not be part of your SharePoint DR plan, it is good practice to make sure that you have an inventory of each farm. You may need to utilize individual components of the physical architecture of any of these environments as part of your overall SharePoint DR plan should you experience a failure in any of the physical components of your production SharePoint farm.
Each server in each SharePoint farm in your environment, needs to be identified. The information collected for each server should include the following:
- Server name
- Server description/purpose
- Server location
- Physical or virtual
- Host name (if virtual)
- Internet Protocol (IP) addresses:
- Internal
- External (if applicable)
- Operating System (including service packs, patch level and hotfixes)
- Processor(s)
- RAM
- Network Interface Cards (NIC)
- Hard drives:
- Backup schedule
- Services and roles:
- Installed software (version, service packs, patch level and hotfixes):
- SharePoint
- Anti-virus
- Utilities
- Tools
- Others
A complete inventory of all SharePoint related database servers should be collected. It may be necessary to work with a DBA to gather this information. Information gathered should include the following:
- SQL Server version (including service packs, patch level and hotfixes)
- SQL Server configuration (standalone, mirrored, clustered, always on, and so on)
- Database instances:
- Names
- Databases:
- Names
- Data file name
- Data file location
- Log file name
- Log file location
- Settings (auto-growth, log file size, and so on)
- Additional Services (reporting services, analysis services, integration services, and so on)
- Backup Tools
- Backup schedule:
- Full
- Incremental
Logical architecture
The next step in the process of taking an inventory of each component of your SharePoint environment deals with the logical architecture. The logical architecture should include the high-level logical components in your SharePoint environment, including all development, testing, staging, QA, and production farms.
The highest level in a SharePoint logical architecture for a SharePoint farm is the Web application. The information collected for each Web application in every one of your SharePoint farms should include the following:
It is important to identify each service account used by each SharePoint farm in the environment. Service account information that should be captured is as follows:
- Service account name
- Purpose
- Local rights
- Domain rights
Each SharePoint farm will have several associated service applications. Service application information that should be captured is as follows:
- Service application name
- Service application description
- Server(s) running the service application
- Service application pool(s)
- Service application database name(s)
- Service application service account(s)
- Additional Settings (for example, the Secure Store Service application needs to record and keep the passphrase that is used to encrypt the credential, in a secure location)
SharePoint 2013 introduces the concept of the apps model to the product. Apps are essentially web applications that fit seamlessly into the SharePoint website where they are installed, and therefore bring data and functionality to the users' familiar work environment.
For example, let's say you have a SharePoint website that is used to collaborate with a team, and you want to create a survey to gather more data. In SharePoint 2013, you can get a survey app, from the Office Store or from your SharePoint app catalog, and install it on your website.
Apps can be hosted in a variety of different ways, including in a private cloud, a public cloud such as Windows Azure, or directly within SharePoint. The following diagram summarizes the critical aspects of the various hosting approaches for the SharePoint 2013 App model:
You should capture information about all of the apps that are installed and used in your SharePoint farm, so that if you need to recover your environment in the event of a disaster you can reconfigure all of the apps in the farm. Information that should be collected about SharePoint apps is as follows:
- App name
- App ID
- App description/purpose
- App domain
- App service settings
- App authentication configuration
Note
Additional information on DR the SharePoint apps can be found in Chapter 7, Disaster Recovery with Custom Development.
- 精通API架構(gòu)：設(shè)計、運維與演進(jìn)
- Python 3破冰人工智能：從入門到實戰(zhàn)
- WordPress Plugin Development Cookbook（Second Edition）
- Scientific Computing with Scala
- Android項目實戰(zhàn)：手機(jī)安全衛(wèi)士開發(fā)案例解析
- 愛上micro:bit
- Kotlin開發(fā)教程（全2冊）
- Node學(xué)習(xí)指南（第2版）
- Developing SSRS Reports for Dynamics AX
- Building Serverless Web Applications
- 編程可以很簡單
- Clojure for Java Developers
- App Inventor少兒趣味編程動手做
- 零基礎(chǔ)C#學(xué)習(xí)筆記
- Ext JS 4 Plugin and Extension Development