Save to My DOJO
On-premises SharePoint deployments need to be regularly backed up according to long-established best practices. However, backing up SharePoint Online (the version of SharePoint that is included with Microsoft 365) is equally important. This article explains why Office 365 SharePoint backup is so important and how to backup SharePoint.
Why is it Important to Back up SharePoint Online?
The main reason why it is so important to back up SharePoint Online (which I will be referring to simply as SharePoint for the remainder of this article) is that if you don’t back up SharePoint, no one else will. Including the big M. Microsoft uses a shared responsibility model for its Microsoft 365 platform. This shared responsibility model essentially states that Microsoft is responsible for keeping the Microsoft 365 applications and the underlying infrastructure running, but Microsoft 365 subscribers are responsible for securing and protecting their own data. If an organization were to suffer a data loss event within the Microsoft 365 cloud, it is up to the organization, not Microsoft, to recover the lost data. That’s why Microsoft 365 backups are so important.
The other reason why it is so important for an organization to protect its data that resides within the Microsoft 365 cloud is that although Microsoft does indeed go to great lengths to protect the Microsoft 365 cloud, there are still a number of ways that data could potentially be lost.
Ransomware represents one of the single biggest threats to SharePoint data. At one time, ransomware was designed to target the contents of the victim’s hard drive. Over time, however, ransomware has evolved into something far more sophisticated. While it is true that ransomware capabilities vary from one type of ransomware to the next, any data repository that a user is connected to could potentially be at risk of being encrypted. This includes data that is hosted on SharePoint sites. Regular backups are easily the best defence against the damage caused by a ransomware attack.
A data loss event does not necessarily have to stem from malicious activity. A user may delete a file by accident, or perhaps overwrite good data with something that is incorrect. SharePoint has native versioning capabilities, as well as a recycle bin, and both of these features (which will be discussed later on) can help a user to get their data back if a file was accidentally deleted or modified. Even so, these tools have their limitations. If a user were to accidentally delete a file, for example, the recycle bin will only store the file for so long. The user must realize that the file was gone and retrieve it from the recycle bin before the retention period expires.
Of course, it is entirely possible that a user may have malicious intent. We have probably all heard stories of disgruntled users or even administrators who take it upon themselves to delete vast amounts of data just before leaving the organization. In such a situation, a disgruntled employee might also empty the recycle bin as a way of making it more difficult for the organization to get its data back. Even if the employee doesn’t empty the recycle bin, however, the SharePoint recycle bin was never intended to be used as a bulk data recovery tool. A regular backup is much better suited to the task of recovering large amounts of data.
One more reason why an organization might need a SharePoint backup is that organizations that operate within regulated industries are typically required to retain data for a specific length of time. Although such regulations usually leave it up to the individual company as to how they will comply with the various regulatory requirements, a backup is often the least expensive and least complex option for dealing with data retention requirements.
What Are the Backup and Recovery Options Available?
There are four primary options for protecting data in a SharePoint environment. As you would probably expect, there are advantages and disadvantages to each of the options. Three of the options that are discussed below are native to SharePoint and are not true backup replacements. Even so, they will be discussed because they are tools that some organizations use to protect their SharePoint data. Additionally, it is important to understand what level of protection each of these options does and does not provide.
The SharePoint Recycle Bin
The SharePoint Recycle Bin is not a backup and recovery substitute by any stretch of the imagination, but it is the easiest and most convenient mechanism for recovering accidentally deleted files. As such, it seemed appropriate to at least mention it.
When a user deletes a file, the file is automatically moved to the Recycle Bin. To recover the file, go to the team site where the file previously resided, and click on the Recycle Bin tab. Now, just right click on the file and choose the Restore option from the shortcut menu, as shown in Figure 1.
Right-click on the file within the SharePoint recycle bin and choose the Restore option.
There are numerous reasons why the SharePoint recycle bin is not a true backup substitute. First, deleted items only remain in the recycle bin for 93 days. At that point, they are permanently deleted. Microsoft Support can perform restorations of deleted items within 14 days, but in order to do so, they must restore entire site collections or subsites. Microsoft cannot recover individual files, lists, libraries, etc.
Another reason why the SharePoint recycle bin isn’t a good backup substitute is because while it might protect you against accidental file deletions, it won’t protect you against malicious activity such as a ransomware infection, or a mass deletion by a rogue administrator who decided to permanently delete SharePoint files. Additionally, even if data is recoverable from the recycle bin, the recycle bin is not well suited to performing bulk recovery operations and files can only be recovered if their container objects are present (although it may be possible to restore a container and then restore the files within it).
The Microsoft 365 E3 and E5 plans include access to an eDiscovery tool that some organizations use as an alternative to traditional backups. The eDiscovery tool was primarily designed to help organizations gather and/or retain data that is related to legal proceedings. During litigation, for instance, opposing counsel might subpoena all of an organization’s data that is related to a particular client or event. The eDiscovery feature can help the organization to locate that data and to hold the data so that it is protected against accidental deletion or modification. It is this ability to retain data as it existed at a particular point in time that has led to some organizations using eDiscovery as a backup alternative, even though Microsoft never intended for the feature to be used in this way.
You can find the eDiscovery feature in the Microsoft 365 Compliance Admin Center. To use it, choose the Core eDiscovery option and click the Create a Case button. At that point, you are prompted to enter a case name and description. Once you have created a case, click on it and then select the Hold tab. Click the Create button to create a new legal hold. Enter a name and an optional description for your new hold, and then enable the hold for SharePoint sites. You will need to click the Choose Sites link to specify which sites should be placed on hold. As you can see in Figure 2, you can also place a hold on Exchange mailboxes and public folders. From there, you have the option to specify keywords and conditions that determine which individual items will be included in the hold.
You will need to place a hold on SharePoint sites.
One of the biggest disadvantages to using eDiscovery as a backup alternative is that creating an eDiscovery hold is a manual process, whereas backups are generally automated.
In spite of the automation issue, eDiscovery might initially work well as a backup alternative, especially in smaller organizations. Eventually, though, organizations will likely run into storage limitations. Each Microsoft 365 user has a specific amount of storage space available within the Microsoft 365 cloud. Data that is placed under legal hold counts against that storage limit, which can cause users to quickly run out of space.
Another Microsoft 365 feature that organizations sometimes use as an alternative to regular backups is retention policies. Retention policies are sometimes referred to as the versioning feature because the policies store immutable copies of previous file versions. As such, if an organization needs to go back to an earlier point in time then it can restore an earlier version of a file.
To create a retention policy, open the Microsoft 365 Compliance Admin Center and then click on Policies, followed by Retention. When prompted, click the New Retention Policy button. At this point, you will be prompted to enter a name and an optional description for your retention policy. Next, you will be prompted as to what types of data to include in the retention policy. As you can see in Figure 3, SharePoint sites are automatically included.
SharePoint sites are automatically included in retention policies.
Once you have specified the types of information to include within the retention policy, you will be taken to another screen that asks you how long the data should be retained, and what to do with the data once the retention period expires. You can opt to have old data deleted automatically, or you can retain data indefinitely, as shown in Figure 4.
You will need to specify how long data should be retained.
Because retention policies store all previous file versions, they would initially seem to be an ideal solution for backing up Microsoft 365 data. After all, they allow you to revert a file back to a previous state (which can help to protect the data against ransomware) and they allow data to be protected against deletion. However, there are several disadvantages to using retention policies as opposed to a traditional backup.
Like eDiscovery, using retention policies can rapidly erode the space that you have available in the Microsoft 365 cloud. This is especially true if large files are updated frequently and need to be retained for a long period of time.
Another major disadvantage to using retention policies is that restoring a previous file version is not as straightforward as you might expect. You can’t just restore a previous file version. Instead, you have to export the file version and then manually place it into the SharePoint document library. This process isn’t usually a big deal for recovering a single file, but imagine what would happen if an organization were to suffer a ransomware attack and needed to recover hundreds of thousands of files. The sheer number of files that need to be recovered would make a manual export completely impractical. The organization’s only option at that point would probably be to create a complex PowerShell script to automate the export and import processes.
The third option for protecting your SharePoint data is to use a third-party backup application. Although there is a cost associated with licensing a third-party backup product, organizations must consider the fact that a backup application is specifically engineered for data backups. In contrast, native Microsoft 365 features such as eDiscovery and retention policies were designed to assist with compliance, not data protection. As such, these features can be used in a pinch, but they are not good long-term data protection solutions.
One of the most compelling reasons for adopting a dedicated third-party backup solution is that native tools such as eDiscovery, retention policies, and even the SharePoint recycle bin can offer a degree of protection for files that are stored in SharePoint libraries. However, there is more to SharePoint than just libraries. The native features do little to protect against the loss of an entire SharePoint site.
Another reason why an organization should consider using a third-party backup solution is that eDiscovery and retention policies do not work for protecting non-Microsoft 365 data. This means that an organization that relies on native features for protecting its SharePoint data would effectively be creating data siloes. SharePoint data would be somewhat protected by the native tools, but the organization would have to use a different data protection solution to protect any data that resides outside of the Microsoft ecosystem. It is far more efficient to use a single backup solution to protect everything. Perhaps more importantly, a piecemeal data protection strategy has the potential for gaps in coverage and for inconsistent data protection policies across data types.
Can you Back up SharePoint?
SharePoint can and should be backed up. Microsoft’s shared responsibility model states that it is the subscriber’s responsibility to protect their own data, hence necessitating the need for backups. Although the native tools can protect SharePoint to some degree, they are not a backup substitute.
Does SharePoint Automatically backup?
While Microsoft does perform backups of SharePoint, these backups are not readily accessible. To initiate a restoration, organizations must contact Microsoft support within 14 days of when the deletion occurred. Even then, Microsoft will only restore site collections or subsites. They do not restore individual files, lists, libraries, etc. As such, Microsoft’s automated backup is a last resort option. Organizations should protect their own SharePoint data using a third-party backup application.
How do I Back up my SharePoint Library?
The best option for backing up a SharePoint document library is usually to use a third-party backup application. It is possible to manually back up SharePoint libraries by manually downloading the files and saving them to a secure location, however, this is a tedious manual process. A backup application can automate the backup process, ensuring that the latest library data is always protected.
How is Data Stored in SharePoint?
SharePoint Online stores all of its data inside of Azure SQL Databases, which are hosted in the Microsoft Azure cloud. This data includes files and documents, lists, sites, and metadata. The data is not stored in just one database, but rather across multiple content databases. Incidentally, organizations that use Microsoft 365 need to back up SharePoint even if they do not actually use SharePoint because some of the other Microsoft 365 Applications leverage SharePoint as a data storage mechanism. Microsoft Planner, for example, does not have its own data repository, but rather stores data in Exchange, SharePoint, and other locations. All of this is to say, that when you backup Microsoft 365, you should be backing up all of the various Office applications, even if there are some applications that you do not use because those applications likely contain data tied to other applications.
The Best Practice for SharePoint Backup
While the way in which you protect this data is up to you as the system admin, there are easy-to-use and fully featured M365 backup applications available on the market today. A good example of this would be Total Protection Enterprise Backup from Hornetsecurity. Total Protection Enterprise Backup makes the backup and recovery of your M365 data simple and quick. Not only does the service protect your M365 data, but it also provides several other critical security services for your M365 tenants ranging from spam and malware filtration to encryption and advanced threat protection. Additionally, the service includes backup and recovery services for the endpoints in your organization as well, which enables end-to-end protection for your organization’s M365 data.
Be sure to let us know in the comments section below if you have follow-up questions, or if you’re still not convinced, tell us why! We’d love to hear your stance and your story! What do you think about backup and recovery for SharePoint Online?
Thanks for reading!
Not a DOJO Member yet?
Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!