With an ever-growing Office 365 ecosystem, the question of data backup and recovery often arises. The data used in the apps is stored across multiple SharePoint Online sites, Exchange Online mailboxes, and other specific apps. There are two types of backup scenarios that may you need to cope with
- Service backup, which ensures that all the content is backed up on a regular basis in the case there is corruption or the service fails
- Deletion backup, where users will accidentally or purposely delete content
In SharePoint Online, by default, content is stored indefinitely in your sites. Without someone explicitly deleting the content or having information management policies or other external actors that would delete content, you don't have to worry about your data disappearing. But, in reality, there will be scenarios, where content is purposely or inadvertently deleted. Whether it's a single file or entire site collection, you need ways to get your data back. Before we look at the types of solutions available, ask yourself what it is you really need to back up and why. Wiping out your intranet will likely cause disruption to your organization, but will you be able to recover from it?
You can break down your SharePoint environment into several layers
- Documents - Word, Excel, PDF, or whatever format you work in. This is the key work product your teams depend on and one of the core reasons SharePoint, an Enterprise Management System) is being used. Documents are created and updated frequently across the sites
- List Items - Calendars, action items, risks registers, etc. Like the Documents, these are core to your SharePoint environment and change frequently.
- Metadata - Over the years, there has been a lot said about the importance of metadata. There are many great reasons for having it. Yet, without discounting any of the reasons, as long as the core metadata can be recreated from the content itself, you're probably safe. Some metadata will be manually set by users once a document is created or is modified (for example, changing a status). Other metadata, such as Modified by or Modified date will change automatically.
- Site structure - The site structure entails everything else that makes up your SharePoint site - information architecture, navigation, branding, custom web parts, and other elements that make the SharePoint the IT centerpiece of many organizations. Lots of effort is spent in setting it up, and once you've reached that point, the rate of change to the environment itself is lower than content itself.
Now, imagine that your SharePoint environment got destroyed (picture a virtual meteor). What would it take to get your organization back up and running in the shortest time possible? Remember how you used to work before SharePoint. Like a good science fiction movie, where all metropolitan cities are destroyed and people are living out of run-down campers, you may find yourself going back to the days where documents were stored on network drives and lists were Excel worksheets (but only for a short while).
Today, third party software providers offer some great options for backing up your cloud content. However, these solutions are often costly and may be too advanced for your specific use case. Let's have a look at some alternative options you have.
Document Version Control
This is the simplest solution available to you. As a document gets updated, new versions are created. At any time you can get back to an older version and even restore it as the current version. When using versions, you can control how many versions will be saved at any time. For instance, suppose you set the limit to 50 versions. Once you have reached 50 versions for a document and save it again, version 1 will be deleted and you will be left with versions 2 to 51. Keep in mind that for each version stored, you are storing a copy of the document, hence taking up additional space on your tenant.
Using the SharePoint Recycle Bins
When documents or list items are deleted, they go to the User recycle bin (first-stage recycle bin). Content remains there for 93 days, during which the user can restore the content to its original location or delete it from the User recycle bin. Content deleted from the User recycle bin moves to the Site Collection recycle bin (second-stage Recycle bin) for the remainder of the 93 days. The second-stage recycle bin can contain anything from a single item to entire site collections. To restore content from the Site Collection recycle bin, you will need to contact your site collection administrator to restore the data via the SharePoint Online Administration Center Recycle Bin (https://<tenant>-admin.sharepoint.com/_layouts/15/online/RecycleBin.aspx)
Requesting Backups from Microsoft
If content was deleted permanently from your SharePoint Online environment, you may still be able to get it back for a limited amount of time directly from Microsoft. In this case, a user with Office 365 global admin rights will need to contact Microsoft through the help channels to request a restore. The restore process will bring back an entire site collection with all its content to the original location. This is important to remember as you may have only lost a single file and will need to manually reconcile all the other content. Microsoft backs up content every 12 hours, and take a few days to restore, so depending on the urgency for getting the data, this may not be a viable solution.
Retention Policies
The purpose of Retention Policies is not to act as a backup for your data, but rather restrict what data can be deleted (or should be deleted) and when. The decisions to keep to delete content are usually bound by regulatory or legal policies. With Retention Policies you can apply such rules to all content or just content meeting certain conditions, such as content containing specific keywords or specific types of sensitive information.
When content is subject to a retention policy, you can continue to modify your content in its original location. But if someone edits or deletes content that’s subject to the policy, a copy is saved to a secure location where it’s retained while the policy is in effect. To further restrict how your content is handled, Retention Policies can be configured so that once they have been turned on for a specific piece of content, they cannot be turned off or made less restrictive. To meet this requirement, you can use Preservation Lock. After a policy’s been locked, no one—including the administrator—can turn off the policy or make it less restrictive. Again, the Retention Policies are a safeguard against accidental (or malicious) deletion of content, not backup. If you introduce a Retention Policy that permanently deletes content, you will not be able to get it back once the policy takes effect.
Manual Content Backup
Alerts
Alerts themselves are not a backup method. However, you can use them to stay informed if there is any sensitive information being deleted and allows you time to determine how to react. For instance, if there are specific document libraries you mostly care about, you can enable alerts on them for document deletion, which will then give you time to decide what to do once the documents are in either the first-stage or second-stage recycle bins
Use a Flow to act on modified or deleted content
Microsoft Flow offers a number of triggers and actions that can help you automatically react to events where documents or items are deleted or modified. The Flow would use an item/file deleted or item/file modified as a trigger to start the workflow. Based on your specific scenario, you could then decide what you want to do with it. For example, copy the file to another location, such as SharePoint site, Azure storage, OneDrive for Business, file system, or other service or simply send an email with the file's information (similar to an alert). To maintain the existing metadata, you can export it together with the file in the form of an XML structure or similar. This way, you could recreate it in the case you need to restore the file. Depending on the size of your organization and amount of content being created or modified, you need to consider the number of such workflows that would be triggered so that you are within the limits of your service plan. By default, a user can run up to 2,000 workflow executions in a month.
PowerShell to copy data
PowerShell will give you lots more flexibility, but comes at a cost of developing and maintaining the scripts. Using PowerShell, you can write scripts to automate much of these backup activities to copy files, extract metadata, and manage the content and report on it from another location.
OneDrive for Business Syncing
With OneDrive for Business, you're able to sync specific document libraries to your local machine. The same scenario could be set up using a service account that will sync content from SharePoint Online to a folder on a network file share. This continuous mechanism is easy to set up, but you need to ensure two things - 1) you are still responsible to back up your file share and 2) you need to also set up a mechanism that will copy the content from the sync folder to another location on your file share or other location outside of your SharePoint or OneDrive for Business setup as files deleted from the document library will also be removed from the sync folder, which is what you're trying to avoid with this backup setup.
Leveraging Migration tools
If you have already made an investment into a migration tool, you may be able to leverage it for your backup needs. Most migration tools allow you to do delta migrations, where only content that have changed is migrated. Furthermore, such migrations can often be scheduled to run at specific times. This lets you run the migrations when system usage is low to minimize the impact on your organization.
If you are using a migration tool that offers these features, then you should set up a one-way migration/sync that will pull data from your active SharePoint environment and copy it to a backup location. Depending on your needs, you can migrate specific document libraries or entire site collections to a number of locations - another site collection in your existing tenant, a separate tenant, Azure, an on-premises SharePoint farm or file share, or more. Obviously, there are cost and infrastructure implications to each. For example, storing the content in an on-premises SharePoint farm will require you to maintain a separate farm and infrastructure to support it. If you are copying the content to another location within your tenant, your backup may be compromised if your tenant or the data center it's managed from becomes unavailable. Having an alternate tenant in a different datacenter provides a level of redundancy, but at an additional cost. You can, however, reduce the cost by adding your users to the alternate site collection but not license them. This way, the ownership of content can remain the same, but license costs are not incurred. Just remember that in order to achieve this, you will also need to sync your user accounts (minus the licensing part).
Regardless of which way you go with a migration tool, one of the largest advantages you have over the Microsoft Backup request is that you can restore granular content as needed or even an entire site collection to another URL so you can pick what to keep.
As you can see, there are a number of viable options available for backing up your data in SharePoint Online that don't require you to invest in an expensive solution. As with anything else in Office 365, proper governance is important to reduce the risk of inadvertently deleting content you may need and having a way to get it back if accidentally deleted.
