- Remote BLOB Storage - With RBS, it is possible to have BLOBs from the all_docs table and customized pages in the database stored in a location outside of the database, such as on file system, allowing for a reduction in the amount of Microsoft SQL Server™ database storage. To use RBS, a provider is necessary. The RBS provider architecture is completely pluggable, meaning that third-party vendors can create and sell their own RBS providers and deliver specific capabilities.
- Read-Only Databases - SharePoint Server 2010 has the ability to recognize read-only SQL databases. Whenever SharePoint Server is connected to a SQL database that has been placed in read-only mode, SharePoint Server will security trim all site collections in the database so that they are read-only to all users, removing all add and edit functionality from the sites, even for administrators. This feature will provide the tools to help mitigate downtime during upgrades and server maintenance.
- Granular backups - Previously the ability to perform granular backups such as backing up a site collection, site, or list was only possible by using the Stsadm command line tool. New in SharePoint Server 2010 is the ability to perform these granular backups directly from the Backup and Restore page in Central Administration.
SharePoint 2010 has integrated granular backup restore operations(site collection backup,Export a site or list, Recover data from an unattached content database) into both Central Administrator and PowerShell. - Backups can be done by using the Central Administration pages or Windows PowerShell™.
- Central Administration provides a user interface where SharePoint Administrators will be prompted via menu structures to select the information that needs to be backed up.
- Windows PowerShell is a command line tool that provides SharePoint administrators a way to perform backup and recovery with additional options such as file compression or working with SQL snapshots.
- Windows PowerShell scripts can be developed and scheduled (with Windows Task Scheduler), whereas Central Administration is used for single-use backups and restores.
- Windows PowerShell has the advantage of running against SQL snapshots instead of the production database. One of the parameters of the Windows PowerShell command will cause a SQL snapshot to be generated, and then Windows PowerShell will run the action against the snapshot instead of the production database. This will reduce the resource impact of the backup operation on the production environment.
- With Windows PowerShell, SharePoint administrators will have more granular control of options for the backup or restore.
- A complete disaster recovery plan not only includes the ability to restore servers and databases but also how to recover smaller units of data like a single document.
- A broad range of levels for performing backups, including the entire farm, farm configuration information, site collections, subsites, or lists. Backing up a site collection will include the top level site and all subsites.
- Through Central Administration a SharePoint Administrator can configure a backup of a subsite or list.
- The administrator can also choose to export security and select the different versions that will be exported with the site or list.
- Unattached content database - In the past, recovering a single file often required an administrator to restore an entire content database to a separate SharePoint farm. SharePoint Server 2010 has added the ability to recover data from an unattached content database. you can browse the content of that content database as long as it is attached to a computer running SQL Server, even if it is not necessarily associated with SharePoint Server. Administrators can browse the content database, back up a site collection, or export a site or list. After the content has been located and saved into a separate location, it can quickly be restored to the production database.This eliminates the need to build a second farm for granular recovery. you will be able to browse, back up, or export the content.
- SharePoint Server 2010 has built in capabilities for backing up the entire farm to provide recovery for a catastrophic failure. This interface can be accessed from within Central Administration for ad hoc backups and recovery, or it can be scripted by using the Windows PowerShell cmdlets Backup-SPFarm and Restore-SPFarm, respectively. A new addition to the catastrophic backup scenario is the capability to do a configuration-only backup.The configuration-only backup outputs an XML file that can be used to restore all settings in the farm. This could be used for recovery of the farm or to build a different farm entirely by using the same settings.
- SQL Snapshots-SharePoint Server 2010 backup and export take advantage of SQL snapshots. When a Windows PowerShell command is run by using a SQL snapshot the first thing that happens is that a snapshot of the database is created and then the remaining command is executed against the SQL snapshot. This provides a method that will reduce the load on the production databases.
- Search and Index Backup and Restore - SharePoint Server 2010 has the ability to back up search and index databases by using a point and time approach. This will allow SharePoint Administrators to restore the search administration, crawl, and query databases. SharePoint Server will then be able to complete an incremental crawl based on all content that has been modified since the backup was taken.
- SQL Mirroring –
- SharePoint Server 2010 supports SQL mirroring natively. This allows a farm administrator to configure the SQL environment to mirror a SharePoint content database. Whenever a new database is created, the SharePoint administrator will be prompted to enter the failover server. SharePoint will then communicate with the witness server and issues are discovered, SharePoint Server will fail over to the hot backup of the environment.
- A failover partner is simply the other SQL server instance SharePoint might expect to find that particular database. If you are mirroring the configuration database between SQLServer1 and SQLServer2 and SQLServer1 is currently the principal server then SQLServer2 will be the failover partner. When SharePoint is unable to talk to the original SQL instance SQLServer1, it will automatically retry the connection on the failover partner, SQLServer2 after a specified timeout. Default of 15 seconds. Since each failover partner is defined at the connection string level, you no longer have to worry about Splits and since the connection will automatically be retried after 15 seconds and you don’t have to worry about changing anything manually.
More - SharePoint 2010 Top 10 Features
Source - SharePoint 2010 Resources
No comments:
Post a Comment