Help - Office 365 Backup Policy

Brass Contributor

Can someone please point me to the official O365 backup policy(link/document). I'm interested to know the backup policy for SharePoint sites and OneDrive on Office 365.

42 Replies

Does Your Office 365 Tenant Need Backups?

Do you need to backup Office 365 data? The question isn't simple because technology changes all the time and it's hard to backup some applications like Teams and Planner because APIs don't exist. The important thing is for companies to review what data they use, the features available to them, and then figure out if any gaps exist.

93 days is the time files will be recoverable after deletion! For retention see:

@Micha1735 I am amused at how the proponents of backup software always make sweeping statements without taking into account the functionality built into Office 365. If you want unlimited retention, you can apply Office 365 retention policies to SharePoint. This has a consequence for storage but no more than if you engage a third-party backup solution. And if you keep everything online inside Office 365, you have the full suite of data governance functionality available to manage the data. Third party backups have some value, but companies should always understand what's available (and they are paying for) inside Office 365 and how the available functionality can meet business goals before considering deploying a third-party solution that only complicates the overall retention/data governance picture.

Retention and backup don’t always mean the same.
Retain most of your content based on retention policies and backup your most important data because the cloud is not accessible sometimes and because you want have to access to your data irrespective of cloud provider policies and features, both now and in the future.

@Dominic Horne I completely agree that retention and backup are different. However, I make the following observations:


  1. Having data online rather than in a third-party repository makes the data much more accessible to the organization.
  2. Being able to backup to a cloud repository is no guarantee that you can restore it quickly (or ever) when needed. For example, let's assume that Office 365 has an outage (which do happen). To where do you restore the SharePoint documents? An on-premises server? This question is especially pertinent when dealing with Office 365 data that has no on-premises equivalent, like Teams, Planner, and Yammer.

Again, I make the point that a third-party backup can be useful but you should fully understand the range of functionality available in Office 365 before you commit to anything that complicates your operational landscape.

I agree it’s important to understand all functionality available with O365 and then evaluate backup scope and options.

@Dominic Horne  Yep. Which has been my entire point all along. Naturally enough, backup vendors aren't keen to recommend that people understand what they pay for (a difficult task sometimes given the rate of development inside Office 365) nor do they like people to understand the difficulty of restoring data from a cloud backup repository. Everything works swimmingly in a demo; things are different when systems fail and data is needed fast.

@Michael82  It's wonderful to have a vendor representative hyping their product in a thinly disguised answer to someone's request for help. If CloudAlly was any good, it would even be worthwhile. I've never seen a reputable MVP or other subject matter expert recommend this service. All I hear are claims of its brilliance.... which doesn't say much.

@ManojDwivedi  Yet another thinly-disguised attempt by a backup vendor to lure people into believing that their software will do wonderful things? In this case, the backup product copies mail to PST files, which is just about the most brain-dead and stupid approach to backup of a cloud email solution known since the dawn of Office 365.

100% agree with Tony. The PST method is simply the worst possible approach.

@rosefresh Yet another crappy "let's export all the data in a cloud mailbox to a PST and see what happens" tool...

I've also been struggling to locate an official response from Microsoft on how long they backup data. I'm aware of OneDrive's restore capability.


Has anyone used AvePoint Cloud Backup or Veeam? I haven't used either, but have looked into AvePoint's product and like the look of it.

I think backup in this context is more of a legacy to on-premises data. In cloud services it's more integrated into the storage fabric, which is why little is published. 


Old style - take full backups and incremental backups off site.


Cloud - distribute multiple copies of data and version histories across multiple data centres.  Apply version history policies and data retention policies, giving administrators and staff the ability to go back in time and restore content. Then present back as SLAs.


So the question to ask is not "how to MS backup", but 1) are the SLAs good enough and 2) do i trust MS enough.  If no, then there are plenty of cloud backup providers that integrate into O365. 


Because there are plenty of O365 cloud backup providers, suggests there are plenty of customers who are nervous about MS SLAs.  I would suggest it is best practice to have another copy with another cloud service provider. 


Just my thoughts,




@RogueAgentNo clear official response from Microsoft, and that's why our partners and customers opted for 3rd party's backup solution for backing up their Office 365 data.

@Tony Redmond , with "no backup for Exchange Online" approach, how Exchange Administrator would help with following requests:

1. "I messed up my calendar and now I lost all my appointments"

2. "My Inbox does not look how it looked yesterday (or week ago, or before vacation).  Where are my important emails?  Can I get my Inbox restored to a way it looked 2 months ago (to PST)?"  (usually after doing a good job organizing emails and moving them to folders)

That's when backup software comes to rescue.

I wish Exchange Online (and other O365 services) would have "point-in-time" restore feature.

I totally understand why it is not available, though I would struggle to agree that absence of "point-in-time" backup/restore is good.




I think you must look at things in context. First, we’ve all been using Exchange Native Data Protection since the launch of Office 365 in 2011. You don’t hear many tales of woe from Exchange Online administrators who need to recover information like the examples you cite. I certainly have never heard or experienced such incidents.


But accepting that bad things do happen in an environment as large as Office 365 (258 million paid seats at the last reported number), let’s ask how such things might come to pass. Could someone “mess up my calendar and lose all my appointments”? What steps does someone take to do this? What client are they using? I have no idea of how anyone could do such a thing. And is this a case of poor user education and training about how to use email clients?


“My inbox does not look like it did yesterday” – is that because retention policies processed the mailbox? Does someone else have access to the mailbox? Do users really want their mailbox to be restored to the way it looked 2 months ago? (I doubt it). Again, how did this happen – what steps were taken to change the mailbox and what clients were involved?


Both examples look like the kind of FUD backup vendors cheerfully throw around to try to convince people that backups are needed. When this happens, I want to know the details of what happened so that I can understand how to stop the same problem happening again. When I understand that, I’ll be able to tell you how an administrator should respond. Sometimes the solution will be found in the basic features built into Office 365; sometimes it might need external software like an online backup. It then becomes a question of whether you want to spend the money on backups to avoid a problem that might only ever occur once in a blue moon.


SharePoint Online and OneDrive for Business have point in time restores back to 30 days. It’s much harder to do something like this for Exchange Online because of the higher traffic (people create many more messages than they do documents) and because other applications (like Teams) use Exchange Online mailboxes to store data.


But remember that you can ensure that deleted items are kept for 30 days so that users can recover mistakes themselves. Past this point, administrators can retrieve information for users with eDiscovery searches if retention policies are used. I know that retention policies need Exchange Online Plan 2 licenses, but that’s probably a good spend to make sure that information can be retrieved if problems do occur. And above all, to avoid the need to go anywhere near PSTs.

@Tony Redmond , thank you for your reply. “My inbox does not look like it did yesterday” - in most cases I dealt with this - it's an user error - email was moved somewhere and user can't locate it any more.

eDiscovery searches would be useful to find single email or group of emails, but it is not a recovery for complicated structure with nested folders user might have under Inbox. 

I am struggling to define RPO ("recovery point objective") for Exchange Online and Azure AD for information placed in Office 365.

I do not think that the fact that 258 mil paid seats in Exchange Online and nothing catastrophic has not happened yet ensures that it can't happen in theory in the future.   



You're going to have user errors whether you have backups or not. The only antidote for user error is training and education so that people understand the applications they work with whether it is email, Planner, Teams, or SharePoint. In cases of misfiled email, a simple search should be enough to find the missing message. At least, that's what I do.


As to complicated folder structures, there's no doubt that people can overcomplicate their lives and create nested folder upon nested folder. This replicates the approach taken with paper documents and is what happened in the early days of email right up to the point where search functionality became reliable enough to eliminate the need for many folders (some of which held just a few folders). It is my observation today that most users today are "pilers" rather than "filers"; the trend appears to be towards using small numbers of folders and depending on search to find information when it's needed. I would dissuade people from using complicated folder structures whenever possible. 


Of course bad things could happen in the future. But the same could happen with or without a backup in place. One challenge people often forget is the restore location. Let's assume that Office 365 has a catastrophic outage and a multi-datacenter region is taken offline. This would mean that two separate datacenters are out of action in country-level regions or four in larger regions. For instance, in EMEA, the datacenters in Dublin, Helsinki, Vienna, and Amsterdam would all have to be inaccessible. You will have to put your own probability on that happening...


You have a backup. Or do you? First, can you get to the online copy? Some backup vendors use Azure as a backup location. If the Office 365 datacenters are down, there's a fair chance that the Azure data is inaccessible too. But let's assume that the backup is in Azure in a different region or datacenter. The next question is where do you restore the data to in such a way that it is useful to end users? On-premises servers? Do you have any? And can the backups be restore there? And how quickly can this be done? To another Office 365 region? Probably not... To another cloud platform? Maybe, but maybe not, and certainly not fast.


I have my doubts about the notion of RPO in a cloud environment. My point about Office 365 and its large number of users is simply that the platform seems to be doing well at serving such a load with the facilities like Native Data Protection in place. It's reasonable to assume that Office 365 would not have this success had large numbers of users experienced problems with losing data...

@Tony Redmond, thanks again for your reply! "It's reasonable to assume that Office 365 would not have this success had large numbers of users experienced problems with losing data..." - well, I think success might be direct effect by great job Microsoft is doing promoting the platform and getting users on (ie. work of Marketing and other non-technical departments). I highly agree with the point "even if you have a backup - where do you restore it?".  That's opening up a bigger topic than just a backup.  De-prioritizing the on-prem Exchange (with promotion of Exchange Online), seems like not be the best strategic direction in my opinion, b/c direct cause of this is putting "all eggs in one bucket"  (even though it's very well secured, protected and distributed across the planet bucket) and elimination of subject matter experts in Exchange (and IT overall) from the work force.  When (if?) Exchange Online happen to have a hiccup that IT professionals of the customers would need to be involved to get a resolution, they will likely not be available....  and even if some customers would still have SMEs in the work force (or access to consultants), they will not have tools (like no native backups, or 3rd party backups nowhere to restore to).  

What is probability that some of Exchange Online databases will become "dial tone" databases in case of disaster?  If this probability is anything, but zero, customers may face empty mailboxes.

Would be nice to see:

- more support of 3rd party backup solutions in Exchange Online with clear way to restore

- "Azure Stack"-like solution for Exchange Online

- re-think the approach to on-prem Exchange: on-prem Exchange can play nicely with Exchange Online and complement Exchange Online in some use cases (at the end of the day improving and beefing up an Exchange Online offering)


As far as the probability of taking more than one data centers down as catastrophic event, I was not talking about this type of failure.  I was talking about user error that caused the user to request you to restore mailbox "as it was at <point in time in the past>".  It does not include any problems with Exchange Online.  And by the way, the way to recover with the user error for the single user was to restore mailbox from the backup to PST.  No question, that PST is not the good target for backup, but it can be a good target for restore to single user.


I do not have a backup now for Exchange Online.  I regret not having one, and regret not having a way to keep the business running with email, if Exchange Online would have an issue.  



There's no doubt that Microsoft has done an effective job of marketing Office 365. This has helped the platform reach its current user base, but it's also true that the worth of the platform has been demonstrated by its robustness, reliability, and security since 2011. Added to the innovation available in the cloud that can't be delivered on-premises, you get a compelling offering.


Deemphasizing on-premises Exchange was always going to happen. Customers will still be able to run on-premises Exchange for many years yet, but with a declining user base, the justification for increased engineering resources doesn't exist. Remember, Microsoft now generates > $50 billion from commercial cloud annually; that's a number big enough to justify huge engineering resources. Even in its glory days, Exchange on-premises never approached a tenth of that amount.


Many ISVs offer Exchange Online backup. Feel free to bring your ideas to them. I doubt Microsoft will change their current approach now. This is a journey they began with Exchange 2007 "log shipping", so they are kind of embedded in what they do.


I don't decry the use of a PST to recover data. Because the format is supported everywhere., it is still used for eDiscovery. So in your situation, had you recovered data from a mailbox for a user with a content search, you would have exported it to a PST and imported it back into the mailbox. This is fine; it's an appropriate use of technology. I'm just dead set against anyone advocating for PSTs as a general-purpose backup methodology for Exchange Online.