Back-up tools for Office 365

This thread has been locked for new comments by a moderator, if you have a new similar issue then please start a new thread.
Iron Contributor

Started this question a while back on Yammer. What tools do you use to back-up mail and files stored in Office 365?

 

The fact that your files are back-upped inside and outside the datacenters of Microsoft only protects you against hardware and software failures on Microsofts side. It will not protect you against accidentally deleted files and mails, which is discovered after 30+ days or after the site trashbins have been emptied.

 

At least that's what I think. Anyone has an answer? My customers are typically small companies, under 10 users. Sometimes even just 1 to 3.

 

I use de SkyKick Back-up tools in my own O365 tenant. Which was an offer in the Microsoft Partner Mail recently.

180 Replies
Hi Tony,

I tell my wife all the time that this one thread that I subscribed to a long time ago is better entertainment than a soap opera (no insult intended in that statement).
I thought I would share my experience with the need for having backups specifically for SharePoint online (of which I currently don't have yet). A few months ago I encountered a few excel files accessed in co-authoring mode that became corrupt. I don't think they were really corrupt, but I could not open the file from the excel web client or the desktop excel client (and the error "We found a problem with some content in 'file.xlsx' Do you want us to recover as much information as we can?") . After trying to recover the file through the error prompt and having nothing but a blank spreadsheet open , I thought to myself - no biggie, I will just go back to the revisions and restore the last one. In each case (have had 3 files so far in the last 3 months) I attempted to open the prior revision only to find out that it too was corrupt. I ended up having to go back 5 or 6 revisions to find a version of the file that opened successfully. I think I narrowed it down as to what caused it (column filtering in the desktop version sorted one way while another user was sorting it a different way all the while with autosave saving the file), but it didn't stop the autosave from saving successfully or kick the users out of the file. It did prevent anyone new user from being able to open the file. One of these files was open for 4 days while the user locked their pc, so we lost 4 days worth of information.
I didn't think there was any reason to have an independent backup of the data as the revisions were robust, but I proved myself wrong. I am now in the market (more so when I subscribed to the thread) for backup software for Office 365 and am waiting for the Veeam offering that is supposed to be out soon? (End of Q2 2018).

Thanks,

Brian

Thank you @Oleg Melnikov

 

Clients should simply be aware of Microsoft capabilities and really re-think their cloud backup strategy. Just relying on "Microsoft is doing the backup" will fail. Microsoft is responsible for the Service. However, the client is responsible for their data. If your mentioned scenarios are not need from a client, fine. But if companies want to protect against this, they cannot do with native tools.

 

Additionally, @Tony Redmond, what if a Office Add-In or any other service is accessing data and while doing the data get's corrupt. Your retention policy will not work.

 

In general, Retention policies need to be applied manually to each object or automatically with a rule, which match all documents. Do you know there is the same keyword in all you files to use it this way? Also, whenever you create and apply a retention label, you will never ever be able to change or delete it. Is this the flexibility we need in current dynamic times? Same for classification… This only applies for documents, but what about an entire column and the metadata stored in there? What about entire libraries, Sites, Groups, Teams, when the IT Admin deletes all of them by purpose? Sure, rare scenarios, but companies should be aware of them and think themselves, if they want to protect against this or not.

 

And Tony, you actually already answered yourself: when a user removes the label and deletes an item by purpose, then it's his fault. RIGHT! But how can a company protect against this scenario?" Additionally, "...and they better understand what they are doing" How many companies have you seen, where all employees totally understand their IT and know what they are doing?

 

 

Let us know, how we can get you ;) We are not talking about specific solutions. We just talk about the considerations of certain scenarios and options to solve them. If companies have evaluated this and still are fine with what you've mentioned - great. If companies identify gaps in their SLAs with native capabilities, why do you want to ignore them?

Re. retention.

 

Simple. Just put all important mailboxes on hold. Either a time-limited or litigation hold. No add-on or any other process can remove content from a mailbox that is on hold. 

 

Auto-label policies can find and assign classification labels to documents based on keyword searches or if the document contains sensitive data types like credit card numbers. This is all basic Office 365 functionality.

 

Look, the FUD thrown out by backup companies talks a lot about rogue admins. I've got to say that in my 40 years in IT, I have never encountered such an admin. Yes, they do exist, and they do horrible things for unknown reasons, but they are not as common as the FUD makes out. And if Teams, Groups, etc. are deleted by an admin, they are soft-deleted and can be recovered within 30 days. Again, basic Office 365 functionality.

 

As to someone removing a label, they have to be a site owner to do that....

Hey @Tony Redmond,

 

you don't get my (our) point. Everybody knows (or should know) about the basic functionality. Our point is, companies should be totally aware of these capabilities and of course really use them. However, these are still basic functions, which work in your test tenant, but not for all productive company environments. Please respect this and do not ignore the thousands of companies out there, which need more than basic functionality for their intellectual property - their data!

 

Exchange:

In-Place Hold (copy-on-write) DEPRECATED!

-> Keep emails based on a query, as long as Search is not deleted, all new email matching criteria will go into this hold

Litigation Hold

-> Like In-Place hold, but for entire mailbox, without query (except for some filters)

 

What if Admin changes query or removes litigation?

 

SharePoint/OneDrive classification

- based on fixed keywords or one or a mixture of 82 pre-configured sensitive types

- make sure, these keywords or sensitives types will cover all content, even that, what will be created in the future?

- allow user to overwrite rules or not?

- Retention labels/policies cannot be changed after creation

- not possible to retain entire site collections or Groups/Teams

 

Soft Delete of Groups

- what if somebody realizes the deleted Group after 30 days?

- what if Admin uses this: Remove-AzureADMSDeletedDirectoryObject –Id <objectId> and permanently delete Group immediately?

 

Again, for many companies the basic functionalities are fine and that is great! Many others really need additional features.

 

… and for the rogue administrators (and all the other scenarios): Why do you have a car insurance? Because you plan to have an accident? Or because you just would like to be protected, but you hope you never need it?

 

My recommendation for everybody:

  1. Re-think your cloud backup strategy -> define your organization's SLA's and B&R scenarios, you need to cover
  2. Check, if native capabilities meet your SLA's
    a) if yes, go to #4
    b) yes with few acceptable limitations, go to #4, but note down limitations and make your colleagues aware of this
    c) no, go to #3
  3. Check 3rd party vendors in the market, if they can satisfy your SLA gaps
  4. Monitor your backups and perform different restore scenarios on regular basis to make sure everything is working

In-place holds aren't deprecated for Exchange. Instead, the in-place holds that are set by Exchange eDiscovery have been replaced by in-place holds set by Office 365 eDiscovery cases.

 

Litigation hold (equivalent to an in-place hold without a query) also remains intact and available.

 

Re. queries for auto-label policies - KQL is pretty extensive when it comes to finding documents. If you really want to lock down documents, then make them records and they can't be deleted by anyone (even Microsoft).

 

Re. soft-delete and realizing that groups have been deleted. I think that if they are important groups. their loss will be detected quickly. It's also very easy to script a check for deleted groups with PowerShell by querying either Azure Active Directory or the Office 365 audit log. I explain how in a Petri.com article. 

 

You keep on saying that an Admin could something. Yes, they could. But if they do, then consequences will flow. Admins can remove holds, permanently delete groups, and do all manner of things, and these actions are audited.  You can make the same argument for third-party software as well - someone has to have authority over the software and be able to change data.  I accept the argument that insurance is good, but insurance is often over-sold too.

For clarity on Holds:
https://techcommunity.microsoft.com/t5/SharePoint/SharePoint-and-Exchange-Online-eDiscovery-Transiti...

 

Difficult to argue, when you just repeat your points or find excuses for valid company scenarios. Your audits are funny. Congratulation to your audit logs, when a hacker deleted important documents with a stolen account. And please do not start with ATA, ATP, MFA, Conditional Access, etc. Yes, Yes, Yes, we all know about that. However, this is still not the point. The audit log will not get your data back.

 

Just to summarize:

You recommend native functionality, that was never build for backup & restore scenarios, hence, you're recommending workarounds. At the same time you complain about "workarounds" from 3rd party vendors, who use official Microsoft APIs for additional B&R scenarios, because these APIs are no dedicated Backup-APIs ("...lack of a suitable backup API for most of the Office 365 data sources"). At least I find this interesting...

 

I respect your opinion. You're still not a fan of additional backup solutions. You still don't really see the need for it. And you are critical with the solutions, which are out there in the market. I'm fine with that!

 

Other contributors and I also shared our points. I'd leave this now to the reader to build their own opinion (and re-think their cloud backup strategy).


@Robert Mulsow wrote:

For clarity on Holds:
https://techcommunity.microsoft.com/t5/SharePoint/SharePoint-and-Exchange-Online-eDiscovery-Transiti...

 

TR; That article confirms the move away from workload-dependent processing of holds to Office 365-wide holds imposed through eDiscovery cases. However, Exchange in-place holds are still valid (you can still impose them) as they have to remain in place for as long as a customer's retention needs exist. The point is that you can put mailboxes and SharePoint/OneDrive content on hold if you need to retain content, and you can do so with a single policy. It's part of the drive to have a unified view of data governance across Office 365 (see https://www.petri.com/office-365-data-governance).

 

Difficult to argue, when you just repeat your points or find excuses for valid company scenarios.

 

TR: I could equally argue that you continually point to rogue admins as the justification for backups. I'm not finding excuses. What I am doing is pointing out that a great deal of functionality is built into Office 365 that tenants sometimes overlook because they simply don't know it exists. I have also attended a couple of recent sessions where presenters talked about scenarios as if no solutions exist, leading people along the line that the only possible solution is their software.

 

To me, it seems like four issues need to be reviewed.

 

1. User error.

2. Administrator error.

3. Rogue administrator.

4. Attack (malware, cyber ransom, etc.)

 

User error (someone deletes a message or document in error) can usually be taken care of with functions built into clients or Office 365, such as Recover Deleted Documents, by an admin with the recent cmdlets (https://www.petri.com/recovering-deleted-email-exchange-online) or with a content search if the mailbox is on hold. The same for deleted documents if they are not in the recycle bin - documents on hold can be recovered by an admin by a content search because they are in the site's Preservation Hold Library. Loss of metadata or some other element of a SharePoint library is harder to recover, so that might be a reason to use backup software. On the other hand, the investment might be better made in user education so as to avoid accidents.

 

Administrators can screw up and lose data. In some cases, like recovering an account or group removed in error, the error is recoverable. In others, it might not be. Backup software can help, but only if it copies the data that the administrator removes.

 

Rogue administrators can cause chaotic damage. However, as noted before, I am unsure as to how many incidents of this kind actually happen. Good HR and management processes, including auditing of admin actions and restriction of admin permissions so that people only have elevated rights for a defined period help to solve this problem. I note that Office 365 is in a preview of privileged access management https://techcommunity.microsoft.com/t5/Security-Privacy-and-Compliance/Announcing-preview-of-privile... that will bring customers some of the same capabilities Microsoft uses to restrict access to its administrators in the Office 365 datacenters. The feature will be available for Exchange Online first and then other workloads.

 

Malware can corrupt documents and messages and a backup can help. However, the need is somewhat reduced through the introduction of features like OneDrive restore (coming to SharePoint too, or so the rumour goes).

 

Perhaps the biggest advantage of backup software is the ability to restore data belonging to many users in an automated manner. While users can restore deleted messages or their OneDrive library, it's a manual process. Possible but painful when you have hundreds of users affected.

 

Your audits are funny. Congratulation to your audit logs, when a hacker deleted important documents with a stolen account.

 

TR: Audits are only part of the solution.

 

And please do not start with ATA, ATP, MFA, Conditional Access, etc. Yes, Yes, Yes, we all know about that. However, this is still not the point. The audit log will not get your data back.

 

TR: No, but it will tell you what happened and who did what. And that information is often necessary to prosecute offenders. But you are right to point out to the range of features available in Azure and Office 365 to limit the ability of attackers to penetrate a tenant to access and steal data.

 

Just to summarize:

You recommend native functionality, that was never build for backup & restore scenarios,

 

TR: No, I recommend that tenants understand the full breadth of the functionality built into Office 365 and understand how to use that functionality to meet their data governance needs.

 

hence, you're recommending workarounds. At the same time you complain about "workarounds" from 3rd party vendors, who use official Microsoft APIs for additional B&R scenarios, because these APIs are no dedicated Backup-APIs ("...lack of a suitable backup API for most of the Office 365 data sources"). At least I find this interesting...

 

TR: I have commented that a lack of backup APIs restrict ISVs from being able to copy data from some Office 365 workloads like Teams and Planner, absolutely. I also have pointed out that some APIs in use for backups (like Exchange Web Services) were never designed for the purpose. Without APIs designed to handle the transfer of large quantities of data from Office 365 to another cloud datacenter, there will always be compromises.

 

I respect your opinion. You're still not a fan of additional backup solutions. You still don't really see the need for it. And you are critical with the solutions, which are out there in the market. I'm fine with that!

 

TR: I am glad that I made your day.

 

Other contributors and I also shared our points. I'd leave this now to the reader to build their own opinion (and re-think their cloud backup strategy).

 

TR: Certainly. But don't expect me to stay silent about the state of backup software for Office 365 and to prompt customers to understand the features of the software they have already bought. That just isn't the right thing to do, so I won't be doing it.


 

It's only a pitty they don't backup the Archive boxes :(

We are looking for a backup solution for O365, that cab backup to a local storage (NAS or SAN) and have the restore capabilities. I have been talking to many vendors and everyone seems to have a solution for cloud to cloud backup. can someone tell me is this even possible??

 

I looked at Synology today they have active backup office 365. Do anyone know about it, Please throw some light on it.

 

(we have 700+ users active on O365, and a very active SPO sites.)

The question is, where do you want to restore the data? Back to Office 365? Or are you looking for doing Exports directly onprem? (how should Lists and other SharePoint content be handled then?)

Be aware that there could be a lot of data to be moved to onprem Storage which can take some time.
Synology seems to only support Exchange Elements and OneDrive as far as I could see that on the website.

Since this conversation appears to still be ongoing, it's worth noting that AvePoint has a new product (I think called Cloud Backup? something like that) that does backup of Groups, mail, SharePoint, and OneDrive. Almost no assembly required, priced per GB storage. It ended up being cheaper for us than their previous tool when we went with one-year retention (they have an unlimited retention option, but it is really pricey). 

Thank you for your reply Thomas,  I think Onsite backup for Office 365 is not feasible as per my understanding right now. I think the only way is to, backup through another SaaS backup vendor who can give us the user friendly restore functionality. We are looking at several vendors demo's in coming weeks. I will post here how that goes. Spanning is what looks fine based on the preliminary talks with almost 6 vendors.

I was searching for a solution to backup office 365 on my local machine and found a 3rd Party Tool name SysTools Office 365 Backup v3.0. Systools if it works without a problem, then the ~$19 they want is of course low enough that it's a no-brainer. 

After visiting the website I found that tool sounds good on paper especially I like the Scheduling option.

 

So, Is anyone here familiar with this tool? Or anyone can recommend a better tool at that price. I don't want to backup data in the cloud.

schedule

 

Hi Nicolai, 

 

I recommend Druva. They backup up all O365 documents, Exchange Online, OneDrive, SharePoint sites, and system/application settings.

If it's still relevant to you, send me a message and I can share more info.

Does Druva support Planner and Teams?

 

Their white paper about Office 365 backup talks about their advantages and contains some inaccuracies. For instance:

 

Office 365 doesn’t index all file types, so search results will not be inclusive of all criteria across non-Microsoft file types.  [What file types are their worried about? Does Druva index all Office 365 data?]

 

Due to the lack of eDiscovery workflow, the review process can often be arduous. Search results are copied to an eDiscovery mailbox, which effectively looks and behaves like an online PST. This makes the review process time consuming and reduces accuracy [This is so outdated that I'm surprised that anyone could put this in a document. It's a description of Exchange on-premises eDiscovery and not Office 365 eDiscovery.]

 

Once I see inaccurate or misleading assertions in company documents, I start to worry about their technical capabilities.

Hi Tony,

Good points here. Druva supports Teams but not Planner.

In regards to the inconsistencies, Druva updates their product so frequently ambiguous/outdated whitepapers still float around... definitely a DevOps focused company.

Here's the update to the above:

Office 365 legal hold workflows:
"Search results for Exchange Online, SharePoint Online and OneDrive must be exported from Office 365 to facilitate the review process; the Exchange content as one or more PST files, and the SharePoint and OneDrive content as individual files (with an option for all versions). There are multiple problems with the Office 365 approach: it creates a duplicate set of content outside of Office 365 which must be protected, there is no reporting on actions taken on the exported content in the eDiscovery case in Office 365 because Office 365 is blind to post-export actions, if the search is run again in Office 365 then a subsequent export is required along with integration of multiple sets of data, and there is no connection between what was collected and the coding decisions made to that content in order to inform future cases and reduce the volume of potentially responsive content in Office 365. The need to export content to Azure – with the time delays that are introduced from Office 365 to Azure and then Azure to a local computer – creates unhelpful delays in an urgent process for compliance officers. With GDPR in effect, the potential existence of personal data in additional locations will raise significant data governance concerns."

I know that's long winded, but if you want to get more in the weeds, send me a dm.

Let's look at some of these points.

 

First, support of Teams. Is this through the capture of the compliance records found in group and personal mailboxes? If so, that might not be enough for some eDiscovery because these records are copies, not the actual data. For instance, they do not store records of user likes for a conversation (which might show that someone accessed a message).

 

Second, you're correct that there is no sight of post-search/post-export actions inside Office 365. Most companies have pretty stringent directions for how these searches are performed and the actions taken are recorded there. At least, that's been my experience (and recommendation). This also makes sure that the actions taken in Office 365 are integrated with all the other activities associated with eDiscovery.

 

Second, in practical terms, I don't think there is much wrong with the temporary (and secure) export of information gathered from across Office 365 workloads to Azure followed by the export/download from that location. It works, it handles different output formats (for instance, Exchange content can be exported to a PST or ZIP file, or as separate message files), and it doesn't take as long as the text seems to say that it does. I doubt that compliance officers will wait too long - and they probably have a lot more to get on with while the export proceeds.

 

Third, multiple content searches can be combined into one Office 365 eDiscovery case. The idea is that compliance officers can take several different approaches to finding the content they need. At the end of the day, they can combine all the search results that they want into a single export.

 

Fourth, for people who need to process large quantities of data, the Office 365 Advanced eDiscovery feature is available (E5 or separate add-on). It's really quite good.

 

Last, the GDPR point is pure unadulterated FUD. Any competent compliance officer will have secured the authority to process personal data according to whatever regulations are in force. I don't like exporting data to PST but it seems to be an industry standard, so we have to do our utmost to protect that data when it is in temporary use for search purposes.

 

All in all, the description seems to have been written with a certain lack of knowledge about what standard Office 365 functionality can do. Or perhaps that's the intention.

There are many tools available to Export Office 365 Mailbox data into PST format. So here I am suggesting you the MailsDaddy Office 365 Backup Tool for creating the backup of Office 365 Exchange Online Mailbox data like emails, contacts, calendars, appointments, and attachments etc. into PST or other required formats like MBOX, MSG, and EML etc. With this application, you can easily Export multiple O365 Mailboxes into PST or other required formats.

Thanks

Backing up to PST files is not a backup solution for Office 365. Anyone who thinks this way needs to reconsider the meaning of backup. Transferring data from a secure, online, protected environment that's designed to encourage compliance and offer super uptime to an insecure, unprotected, and fallible file on someone's personal workstation is an act of utter folly.

Thanks, for explaining taking backup in PST file format is a bad idea. What if we backup Office 365 emails in EML file format i.e. a single email message extension??

Capture.PNG