BackUp and Restore Process in SharePoint

Backup and Restore in SharePoint 

It is essential to have proper backup/restore strategy in place for your SharePoint farms. SharePoint 2010 provides three types of tools for backup/restore for your server farm. The tools are                             

You need to carefully decide what you are going to backing up and where you are storing these backups. Be noted that SharePoint 2010 doesn’t provide a method to backup directly to tape. SharePoint 2010 backs up to a UNC file share. Technically UNC file share can be anywhere, but it is recommended that you take your backup to a UNC file share in your LAN.

Let me explore each tool available for backup.

Central Administration: You cannot schedule a backup via Central Administration. The primary use of Central Administration backups is to verify the configuration of the target backup location and to back up server farms before major operations. It is recommended to take backup using Central Administration, once you create all web applications and site collections required by your server farm. Also take one backup using Central Administration before any major upgrade of the farm.

Windows PowerShell: The preferred way to take backups in SharePoint Server 2010 is by using windows PowerShell. This method gives you the most options and will be fully supported in the future. You can also schedule the backup using Windows PowerShell.

Stsadm.exe: Stsadm was the command line administration tool available for SharePoint 2007. SharePoint 2010 also provides Stsadm, but it is recommended to use PowerShell as Stsadm is there to offer backward compatibility. Many of the Stsadm commands implemented in SharePoint Server 2010 existed in SharePoint Server 2007. Configuring command-line backups using Stsadm is easy, but it is limited to basic farm backup functionality

In this article I am going to demonstrate the PowerShell commandlets to take various types of backup from SharePoint 2010.

First you need to decide, where you are going to store the backups. Make a UNC share for that location. In order to back up to file share, the following accounts need full permissions to the backup location.

1. SQL Server service account
2. SharePoint 2010 Timer Log On account
3. User account, who is executing the command.

Also you have to ensure that you have enough disk space available for the backup. In the remaining section of this article details the various backup options available to you.

Farm Backup

To back up a server farm using Windows PowerShell, you can use Backup-SPFarm command. The syntax of the command is as follows.

Backup-SPFarm -directory <UNC File Share> -BackupMethod <Full | Differential>

The Backup-SPFarm supports the following options

• Directory - Defines the backup location previously prepared.
• BackupThreads - The default thread count is 3. Increasing the thread count will result in faster backup, but it will affect the server performance during backup. Also increasing the threads will make it difficult to check backup logs.
• ShowTree - Displays the objects in the farm those are available to be backed up. If you use this setting in conjunction with Item, it is scoped to the object underneath Item.
• ConfigurationOnly – This option specifies to backup only the farm configuration data. No content will be backed up when you specify ConfigurationOnly in the command.
• Item – You can back up a farm component—such as a Web application, content database, or service application—using the Item parameter. You cannot back up site collections, sites, list, libraries, or list items using the Item parameter.
• Percentage - You can specify the progress increments on the screen. If scripting, you do not need to use the Percentage option.
• Force - Using force will bypass the default behavior of halting the backup if the estimator calculates there is insufficient disk space.
• Verbose – This option will display the progress of the backup in the command line. If this is not presented, you won’t be presented with current progress information.
• WhatIf - This is a common PowerShell feature, if you specify this option, the command will display the output of running the backup without actually performing the backup.

Restore a Server Farm

The backups taken by PowerShell can be restored by Central Administration. Also it is possible to restore the farm using the PowerShell Script. To restore a farm from backup you can use Restore-SPFarm commandlet.

The UNC share where you configured your backup, may contains more than one backup. So the PowerShell command for restore requires you to specify the backup ID for the backup to restore. No problem, there is a command available to list all the backups available under a UNC share. The command is as follows.

Get-SPBackupHistory -Directory <Backup folder> -ShowBackup [-Verbose]

There is another way to find the backup ID, in the root folder of the UNC share used for backup; you can find an xml file named spbrtoc.xml (SharePoint Backup Restore Table Of Contents). To find the ID, open the UNC share in windows explorer, open the spbrtoc.xml in any text editor (e.g. notepad) and you can find all backups with IDs]

The syntax for Restore-SPFarm command is as follows

Restore-SPFarm -Directory UNCShare -BackupId <id of backup>

The Restore-SPFarm supports the following options.

• Directory - specifies the path to the SharePoint Server 2010 backup location you want to restore from. There must be a valid spbrtoc.xml file in the root of the backup directory.
• RestoreMethod – Either New or Overwrite. The New option restores the selected backup components and configuration using either new database names or a new SQL Server instance, or both. The Overwrite option restores the content and configuration to the same database instances.
• BackupId - The unique backup ID you want to restore.
• ConfigurationOnly - Restores only the farm configuration data, it will not restore any content.
• Confirm - Requires you to confirm the backup by typing Y, it is just a precautionary option.
• FarmCredentials - You must supply the farm credentials when restoring content and configuration data.
• Force – if you want to restore to the existing farm, use this option.
• Item - Indicates the part of the backup you want to restore. For example, if you have performed a full farm backup, you might choose to only restore a Web application or content database.
• NewDatabaseServer - If you want to restore to an alternate database server, you can specify that during the restore process.
• Percentage - You can specify the progress increments on the screen. Percentage complete is seen only when using the Verbose option.
• RestoreThreads - The default number of process threads is 3. This can be increased to 10 or decreased to 1.
• WhatIf - Displays the effect of a command without running an actual restore process.
• Verbose - Displays the output of a command.

Backup web applications using PowerShell

You can use the –item option to the Backup-SPFarm command to back up a particular component in a farm. By specifying the item option with the Backup-SPFarm command, you can backup a web application, a service application or a content database. Also using the Restore-SPFarm command, you can restore any of these.

You can also restore individual items from a full back up without restoring the entire farm backup. So if you are taking full farm backup, it is not necessary to take item wise backups separately.

In order to backup an item, you need to specify the item name you need to backup. To retrieve the item names for backing up, you can use the following command.

Backup-SPFarm –showtree

This command will list the hierarchical items available in the farm. You can retrieve the item name by following the command output.

To backup a particular item, you can

Backup-spfarm –directory <uncpath> -item “Hierarchical item name” –backupmethod FULL |Differential

e.g.:

Backup-spfarm –directory \\ServerName\UNCShare -item “Farm\ Microsoft SharePoint Foundation Web Application\SharePoint - 2038” –backupmethod FULL

Similarly you can Restore a particular item from a farm backup. See the sample command

Restore-SPFarm –directory <uncpath> -backupid <backup id> -item <item to be backed up>

Backup Site Collection

Sharepoint 2010 supports granular backup and restore. You can backup/restore site collections, individual sites and lists. In this section I am going to cover only the site collection backup.

Windows PowerShell will automatically lock the site collection during backup to reduce the risk of SQL blocking and locking errors. Also it is possible to backup site collection using a SQL snapshot to back up the data. To backup site collections you can use the command Backup-SPSite. The following are the options available for Backup-SPSite.

• Identity - specifies the URL or GUID of the site collection to back up
• Path -The full backup path, including the file name.  Here you can use the file path, it is not necessary to specify the UNC path here. 
• Confirm - Requires you to confirm the backup by typing Y.
• Force - If you want to overwrite an existing back up file, use the Force option.
• NoSiteLock - If you want to back up the site collection without making it read-only, use the NoSiteLock option. If you are taking large site collection backups, without a site lock, the back up may fail.
• UseSqlSnapshot - If you need to back up site collections during the day and require users to continue full read/write operations, you’ll need to create a SQL snapshot to back up from. Using this option creates a temporary SQL Server database snapshot. After the snapshot is created, the backup will be from the snapshot, not the live database. This is the best method to get a full fidelity site collection backup.
• WhatIf Shows the effects of a command without performing the actual backup

E.G.: Backup-spsite –identity http://win-hgdsnnuakhv/sites/testsite -path c:\sitebkup\mysite.bak

Schedule backups

Once the server farm is up and running, you need to take regular backups. You need to automate the server backup procedure. You need to decide your backup plan. This depends on your farm. You need to carefully decide the backup plan. Also test your back up by restoring it to a test environment, for making sure you are ready for disaster recovery.

Providing a recommendation for backup farm is depends on the implementation. Recently I worked with a farm, where I have 3 site collections in 3 different web applications. I have decided the following backup sets.

1. Monthly full backup for the entire server farm
2. Weekly differential backup for the entire server farm
3. Weekly full backup for each site collection
4. Daily differential backup for each site collection

Make sure you are taking the decision by carefully considering your back up plans.

Next you need to schedule the scripts. You need to do the following tasks for scheduling the back up.

1. Create a .ps1 file with your PowerShell commands
2. Create a batch file that calls the ps1 file
3. Configure the batch file to execute in certain interval.

The following steps demonstrate scheduling a full farm backup using PowerShell. First create a Windows PowerShell script file with the following contents.

Add-PSSnapin Microsoft.SharePoint.PowerShell
Backup-SPFarm -directory \\win-hgdsnnuakhv\farmbkup -backupmethod FULL

Save this file with extension .ps1. I have named the file as farmfullbkup.ps1.

Now create a batch file, which calls this PowerShell Script. The batch file content is as follows.

PowerShell -command C:\BackupScheduleScripts\FarmFullBkup.ps1

Save this file with extension .bat. In my case, I named the file as FarmFullBkup.bat

Now you can schedule this batch file as you required using Windows task scheduler. In my case I configured this to execute once in a month.

Conclusion

SharePoint provides lot of options for backup/ restore, from a full farm level to list level. Planning for backup / restore in very important in any server farm and you need to carefully decide what backup / restore strategy will help you.

SharePoint PowerShell Backup and Restore Commands

The following are examples of different SharePoint PowerShell commands you can use to back up and restore various components of your SharePoint environment.

A complete farm backup followed by a restore:

Backup-SPFarm –Directory \\App01\SharePointBackups -BackupMethod Full
Restore-SPFarm –Directory \\App01\SharePointBackups -RestoreMethod New

Backup and restore a service application:

Backup-SPFarm –Directory \\App01\SharePointBackups -BackupMethod Full –Item "Excel Services"
Restore-SPFarm –Directory \\App01\SharePointBackups -RestoreMethod New –Item "Excel Services"

Backup and restore farm configuration information only:

Backup-SPConfigurationDatabase –Directory \\App01\SharePointBackups
Restore-SPFarm –Directory \\App01\SharePointBackups –RestoreMethod Overwrite –ConfigurationOnly

Backup and restore your SharePoint content databases:

Backup-SPFarm –Directory \\App01\SharePointBackups -BackupMethod Full –Item ContosoPortal
Restore-SPFarm –Directory \\App01\SharePointBackups -RestoreMethod New –Item ContosoPortal

Backup and restore a site collection:

Backup-SPSite –Identity http://App01/Sites/ContosoPortal -Path \\App01\SharePointBackups\PortalSiteCollection.bak -Force
Restore-SPSite –Identity http://App01/Sites/ContosoPortal -Path \\App01\SharePointBackups\PortalSiteCollection.bak –Force

Export and import a subsite, list, or library:

Export-SPWeb –Identity http://App01/Sites/ContosoPortal/ -Path \\App01\SharePointBackups\SharedDocuments.bak -Itemurl "Shared Documents" -Force
Import-SPWeb –Identity http://App01/Sites/ContosoPortal/ -Path \\App01\SharePointBackups\SharedDocuments.bak –Force -IncludeUserSecurity

SharePoint STSADM Backup and Restore Commands

The following are examples of different STSADM commands you can use to back up and restore various components of your SharePoint environment.

A full farm backup followed by a restore:

stsadm -o backup -url http://app01/ -directory \\app01\sharepointbackups -BackupMethod Full -Quiet
stsadm -o restore -url http://app01/ -filename \\app01\sharepointbackups –Overwrite

Back up and restore configuration information only:

stsadm -o backup -url http://app01 -directory \\app01\sharepointbackups -configurationonly -quiet
stsadm -o restore -url http://app01 -filename \\app01\sharepointbackups -configurationonly –quiet

Back up and restore a service application:

stsadm -o backup -directory \\app01\sharepointbackups -quiet -backupmethod full -item "Excel Services"
stsadm -o restore -directory \\app01\sharepointbackups -item "Excel Services" –quiet

Back up and restore a site collection:

stsadm -o backup -url http://app01/portalsitecollection -filename \\app01\SharePointBackups\portalsitecollection.bak -overwrite
stsadm -o restore -url http://app01/portalsitecollection -filename \\app01\SharePointBackups\portalsitecollection.bak –overwrite

Export and import a subsite, list, or library:

stsadm -o export –url http://app01/sites/contosoportal/Shared%20documents –filename \\app01\sharepointbackups\SD.bak -quiet -overwrite
stsadm -o import –url http://app01/sites/contosoportal/Shared%20documents –filename \\app01\sharepointbackups\SD.bak -quiet

Boundaries and limits for SharePoint 2013

Web Application Limits

The following table lists the recommended guidelines for web applications.

Limit	Maximum value	Limit type	Notes
Web application	20 per farm	Supported	We recommended limiting the number of web applications as much as possible. Create additional host named site collections where possible instead of adding web applications.
Zone	5 per web application	Boundary	The number of zones defined for a farm is hard-coded to 5. Zones include Default, Intranet, Extranet, Internet, and custom.
Managed path for host-named site collections	20 per farm	Supported	Managed paths for host-named site collections apply at the farm level. Each managed path that is created can be applied in any Web application.
Managed path for path-based site collections	20 per web application	Supported	Managed paths are cached on the web server, and CPU resources are used to process incoming requests against the managed path list. Managed paths for path-based site collections apply at the Web application level. You can create a different set of managed paths for each Web application. Exceeding 20 managed paths per web application adds more load to the web server for each request. If you plan to exceed twenty managed paths in a given web application, we recommend that you test for acceptable system performance.
Solution cache size	300 MB per web application	Threshold	The solution cache allows the InfoPath Forms service to hold solutions in cache in order to speed up retrieval of the solutions. If the cache size is exceeded, solutions are retrieved from disk, which may slow down response times. You can configure the size of the solution cache by using the Windows PowerShell cmdlet Set-SPInfoPathFormsService.

Limit	Maximum value	Limit type	Notes
Application pools	10 per web server	Threshold	The maximum number is determined by hardware capabilities. This limit is dependent largely upon: The amount of memory allocated to the web servers The workload that the farm is serving, that is, the user base and the usage characteristics (a single highly active application pool can utilize 10 GB or more)

Content Database Limits

The following table lists the recommended guidelines for content databases.

 

Limit	Maximum value	Limit type	Notes
Number of content databases	500 per farm	Supported	The maximum number of content databases per farm is 500. With 500 content databases per web application, end user operations such as opening the site or site collections are not affected. But administrative operations such as creating a new site collection will experience decrease in performance. We recommend that you use Windows PowerShell to manage the web application when a large number of content databases are present, because the management interface might become slow and difficult to navigate. With 200GB per content database, and 500 content databases per farm, SharePoint Server 2013 supports 100TB of data per farm.
Content database size (general usage scenarios)	200 GB per content database	Supported	The default file size is 50 MB, which can be increased to a maximum of 2 GB. You can fit 100 files in each content database. Multiple site collections can share a single content database. Each site collection needs to be fully stored in a single content database. We strongly recommended limiting the size of content databases to 200 GB, except when the circumstances in the following rows in this table apply. If you are using Remote BLOB Storage (RBS), the total volume of remote BLOB storage and metadata in the content database must not exceed the 200GB limit.
Content database size (all usage scenarios)	4 TB per content database	Supported	Content databases of up to 4 TB are supported when the following requirements are met: ·         Disk sub-system performance of 0.25 IOPS per GB. 2 IOPS per GB is recommended for optimal performance. ·         You must have developed plans for high availability, disaster recovery, future capacity, and performance testing. You should also carefully consider the following factors: ·         Requirements for backup and restore may not be met by the native SharePoint Server 2013 backup for content databases larger than 200 GB. It is recommended to evaluate and test SharePoint Server 2013 backup and alternative backup solutions to determine the best solution for your specific environment. ·         It is strongly recommended to have proactive skilled administrator management of the SharePoint Server 2013 and SQL Server installations. ·         The complexity of customizations and configurations on SharePoint Server 2013 may necessitate refactoring (or splitting) of data into multiple content databases. Seek advice from a skilled professional architect and perform testing to determine the optimum content database size for your implementation. Examples of complexity may include custom code deployments, use of more than 20 columns in property promotion, or features listed as not to be used in the over 4 TB section below. ·         Refactoring of site collections allows for scale out of a SharePoint Server 2013 implementation across multiple content databases. This permits SharePoint Server 2013 implementations to scale indefinitely. This refactoring will be easier and faster when content databases are less than 200 GB. ·         It is suggested that for ease of backup and restore that individual site collections within a content database be limited to 100 GB. ·         Not recommend the use of content databases that exceed 4 TB, except in document archive scenarios (described in the next row in this table). If, in the future, you need to upgrade your SharePoint Server 2013 installation, upgrading the site collections within the content databases can be very difficult and time consuming. It is strongly recommended that you scale out across multiple content databases, rather than exceed 4 TB of data in a single content database.
Content database size (document archive scenario)	No explicit content database limit	Supported	Content databases with no explicit size limit for use in document archive scenarios are supported when the following requirements are met: ·         You must meet all requirements from the “Content database size (all usage scenarios)” limit earlier in this table, and you should ensure that you have carefully considered all the factors discussed in the Notes field of that limit. ·         SharePoint Server 2013 sites must be based on Document Center or Records Center site templates. ·         Less than 5% of the content in the content database is accessed each month on average, and less than 1% of content is modified or written each month on average. ·         Do not use alerts, workflows, link fix-ups, or item level security on any SharePoint Server 2013 objects in the content database. Note :   Document archive content databases can be configured to accept documents from Content Routing workflows.
Content database items	60 million items including documents and list items	Supported	The largest number of items per content database that has been tested on SharePoint Server 2013 is 60 million items, including documents and list items. If you plan to store more than 60 million items in SharePoint Server 2013, you must deploy multiple content databases.
Site collections per content database	10,000 maximum (2,500 non-Personal site collections and 7,500 Personal Sites, or 10,000 Personal Sites alone)	Supported	We strongly recommended limiting the number of site collections in a content database to 5,000. However, up to 10,000 site collections in a database are supported. Note that in a content database with up to 10,000 total site collections, a maximum of 2,500 of these can be non-Personal site collections. It is possible to support 10,000 Personal site collections if they are the only site collections within the content database. These limits relate to speed of upgrade. The larger the number of site collections in a database, the slower the upgrade with respect to both database upgrade and site collection upgrades. The limit on the number of site collections in a database is subordinate to the limit on the size of a content database that has more than one site collection. Therefore, as the number of site collections in a database increases, the average size of the site collections it contains must decrease. Exceeding the 5,000 site collection limit puts you at risk of longer downtimes during upgrades. If you plan to exceed 5,000 site collections, we recommend that you have a clear upgrade strategy to address outage length and operations impact, and obtain additional hardware to speed up the software updates and upgrades that affect databases. To set the warning and maximum levels for the number of sites in a content database, use the Windows PowerShell cmdlet Set-SPContentDatabase with the -WarningSiteCount parameter. For more information, see Set-SPContentDatabase.
Remote BLOB Storage (RBS) storage subsystem on Network Attached Storage (NAS)	Time to first byte of any response from the NAS should remain within 40 milliseconds 95% of the time.	Boundary	When SharePoint Server 2013 is configured to use RBS, and the BLOBs reside on NAS storage, consider the following supported limit. From the time that SharePoint Server 2013 requests a BLOB, until it receives the first byte from the NAS, 95% of the time no more than 40 milliseconds can pass.

Site Collection Limits

The following table lists the recommended guidelines for site collections.

 

Limit	Maximum value	Limit type	Notes
Site collections per farm	750,000 (500,000 Personal Sites and 250,000 other sites per farm)	Supported	The maximum recommended number of site collections per farm is 500,000 Personal Sites plus 250,000 for all other site templates. The Sites can all reside on one web application, or can be distributed across multiple web applications. Note that this limit is affected by other factors that might reduce the effective number of site collections that can be supported by a given content database. Care must be exercised to avoid exceeding supported limits when a container object, such as a content database, contains a large number of other objects. For example, if a farm contains a smaller total number of content databases, each of which contains a large number of site collections, farm performance might be adversely affected long before the supported limit for the number of site collections is reached. For example, Farm A contains a web application that has 200 content databases, a supported configuration. If each of these content databases contains 1,000 site collections, the total number of site collections in the web application will be 200,000, which falls within supported limits. However, if each content database contains 10,000 site collections, even though this number is supported for a content database, the total number of site collections in the farm will be 2,000,000, which exceeds the limit for the number of site collections per web application. Memory usage on the web servers should be monitored, as memory usage is dependent on usage patterns and how many sites are being accessed in given timeframe. Similarly, the crawl targets might also exhibit memory pressure, and if so the application pool should be configured to recycle before available memory on any web server drops to less than 2 GB.
Web site	250,000 per site collection	Supported	The maximum recommended number of sites and subsites is 250,000 sites. You can create a very large total number of web sites by nesting subsites. For example, in a shallow hierarchy with 100 sites, each with 1,000 subsites, you would have a total of 100,000 web sites. Or a deep hierarchy with 100 sites, each with 10 subsite levels would also contain a total of 100,000 web sites. Note: Deleting or creating a site or subsite can significantly affect a site’s availability. Access to the site and subsites will be limited while the site is being deleted. Attempting to create many subsites at the same time may also fail.
Site collection size	Maximum size of the content database	Supported	A site collection can be as large as the content database size limit for the applicable usage scenario. In general,strongly recommend limiting the size of site collections to 100 GB for the following reasons: ·         Certain site collection actions, such as site collection backup/restore or the Windows PowerShell cmdlet Move-SPSite, cause large SQL Server operations which can affect performance or fail if other site collections are active in the same database. For more information, see Move-SPSite. ·         SharePoint site collection backup and restore is only supported for a maximum site collection size of 100 GB. For larger site collections, the complete content database must be backed up. If multiple site collections larger than 100 GB are contained in a single content database, backup and restore operations can take a long time and are at risk of failure.
Number of device channels per publishing site collection	10	Boundary	The maximum allowed number of device channels per publishing site collection is 10.

List and Library Limits

Limit	Maximum value	Limit type	Notes
List row size	8,000 bytes per row	Boundary	Each list or library item can only occupy 8,000 bytes in total in the database. 256 bytes are reserved for built-in columns, which leaves 7,744 bytes for end-user columns.
File size	2 GB	Boundary	The default maximum file size is 250 MB. This is a configurable limit that can be increased up to 2 GB (2,047 MB). However, a large volume of very large files can affect farm performance.
Documents	30,000,000 per library	Supported	You can create very large document libraries by nesting folders, or using standard views and site hierarchy. This value may vary depending on how documents and folders are organized, and by the type and size of documents stored.
Major versions	400,000	Supported	If you exceed this limit, basic file operations—such as file open or save, delete, and viewing the version history— may not succeed.
Minor versions	511	Boundary	The maximum number of minor file versions is 511. This limit cannot be exceeded.
Items	30,000,000 per list	Supported	You can create very large lists using standard views, site hierarchies, and metadata navigation. This value may vary depending on the number of columns in the list and the usage of the list.
Rows size limit	6 table rows internal to the database used for a list or library item	Supported	Specifies the maximum number of table rows internal to the database that can be used for a list or library item. To accommodate wide lists with many columns, each item may be wrapped over several internal table rows, up to six rows by default. This is configurable by farm administrators through the object model only. The object model method is SPWebApplication.MaxListItemRowStorage.
Bulk operations	100 items per bulk operation	Boundary	The user interface allows a maximum of 100 items to be selected for bulk operations.
List view lookup threshold	8 join operations per query	Threshold	Specifies the maximum number of joins allowed per query, such as those based on lookup, person/group, or workflow status columns. If the query uses more than eight joins, the operation is blocked. This does not apply to single item operations. When using the maximal view via the object model (by not specifying any view fields), SharePoint will return up to the first eight lookups. Note: After applying the SharePoint Server 2013 cumulative update package released on August 13, 2013 (https://support.microsoft.com/en-us/kb/2817616), the default value is increased from 8 to 12.
List view threshold	5,000	Threshold	Specifies the maximum number of list or library items that a database operation, such as a query, can process at the same time outside the daily time window set by the administrator during which queries are unrestricted.
List view threshold for auditors and administrators	20,000	Threshold	Specifies the maximum number of list or library items that a database operation, such as a query, can process at the same time when they are performed by an auditor or administrator with appropriate permissions. This setting works with Allow Object Model Override.
Subsite	2,000 per site view	Threshold	The interface for enumerating subsites of a given web site does not perform well as the number of subsites surpasses 2,000. Similarly, the All Site Content page and the Tree View Control performance will decrease significantly as the number of subsites grows.
Coauthoring in Word and PowerPoint for .docx, .pptx and .ppsx files	10 concurrent editors per document	Threshold	Recommended maximum number of concurrent editors is 10. The boundary is 99. If there are 99 co-authors who have a single document opened for concurrent editing, each successive user sees a "File in use" error, and can only open a read-only copy. More than 10 co-editors will lead to a gradually degraded user experience with more conflicts, and users might have to go through more iterations to successfully upload their changes to the server.
Security scope	50,000 per list	Threshold	The maximum number of unique security scopes set for a list cannot exceed 50,000. For most farms, we recommend that you consider lowering this limit to 5,000 unique scopes. For large lists, consider using a design that uses as few unique permissions as possible. When the number of unique security scopes for a list exceeds the value of the list view threshold (set by default at 5,000 list items), additional SQL Server round trips take place when the list is viewed, which can adversely affect list view performance. A scope is the security boundary for a securable object and any of its children that do not have a separate security boundary defined. A scope contains an Access Control List (ACL), but unlike NTFS ACLs, a scope can include security principals that are specific to SharePoint Server 2013. The members of an ACL for a scope can include Windows users, user accounts other than Windows users (such as forms-based accounts), Active Directory groups, or SharePoint groups.

Security Limits

Limit	Maximum value	Limit type	Notes
Number of SharePoint groups a user can belong to	5,000	Supported	This is not a hard limit but it is consistent with Active Directory guidelines. There are several things that affect this number: The size of the user token The groups cache: SharePoint Server 2013 has a table that caches the number of groups a user belongs to as soon as those groups are used in access control lists (ACLs). The security check time: as the number of groups that a user is a member of increases, the time that is required for the access check increases also.
Users in a site collection	2 million per site collection	Supported	You can add millions of people to your web site by using Microsoft Windows security groups to manage security instead of using individual users. This limit is based on manageability and ease of navigation in the user interface. When you have many entries (security groups of users) in the site collection (more than one thousand), you should use Windows PowerShell to manage users instead of the UI. This will provide a better management experience.
Active Directory Principles/Users in a SharePoint group	5,000 per SharePoint group	Supported	SharePoint Server 2013 enables you to add users or Active Directory groups to a SharePoint group. Having up to 5,000 users (or Active Directory groups or users) in a SharePoint group provides acceptable performance. The activities most affected by this limit are as follows: Fetching users to validate permissions. This operation takes incrementally longer with growth in number of users in a group. Rendering the membership of the view. This operation will always require time.
SharePoint groups	10,000 per site collection	Supported	Above 10,000 groups, the time to execute operations is increased significantly. This is especially true of adding a user to an existing group, creating a new group, and rendering group views.
Security principal: size of the Security Scope	5,000 per Access Control List (ACL)	Supported	The size of the scope affects the data that is used for a security check calculation. This calculation occurs every time that the scope changes. There is no hard limit, but the bigger the scope, the longer the calculation takes.

References:  Microsoft Site