ISVs Say Office 365 Backup is Critical – But Is It?

Office 365 backup - Six Debatable Reasons

Debugging FUD

A reader of this blog contacted me to discuss a report they received from a well-known software vendor. The report advances six reasons why Office 365 backups are critical. I was asked what I thought of the arguments. After reading the document, my answer was “not much.”

The document makes the bold claim that:

The misconception that Microsoft fully backs up your data on your behalf is quite common, and without a shift in mindset, could have damaging repercussions when this responsibility is left unattended.”

I’m not sure where this misconception exists. Microsoft is quite clear that, apart from SharePoint Online, they do not perform Office 365 backups. Instead, Microsoft depends on functionality built into the software (like Exchange Online’s Native Data Protection) coupled with hardware resilience to protect customer data. It has been this way since Microsoft launched Office 365 in June 2011.

Nevertheless, projecting the view that it’s important to backup data is goodness for backup vendors, especially when they can infuse customers with the feeling that they have a responsibility to backup their Office 365 data (because Microsoft won’t). Let’s review the reasons advanced to justify Office 365 backups.

The Hazards of the Recycle Bin

The document proclaiming the need for Office 365 backup begins its discussion about the six reasons by focusing on SharePoint Online and the 93-day standard processing cycle for deleted items through its recycle bin  The report notes that “the average length of time from data compromise to discovery is over 140 days” and, somewhat breathlessly, says that this is “a shockingly large gap.” (assuming the gap is the 57 days difference).

This is good example of classic FUD. A picture is painted to tell customers that they might lose important data and the only solution is to deploy software that the vendor just happens to have available. What’s ignored is the simple fact that the tenant might have deployed retention policies to ensure that important information is kept for much longer. The author doesn’t seem to have heard about the SharePoint Preservation Hold Library, where documents coming under the scope of retention policies are kept safe and available for eDiscovery and recovery (if necessary). The downside of using retention policies for documents is that data held in the Preservation Hold Library is charged against the tenant’s SharePoint storage quota. Normally this isn’t a problem, but it might force the tenant to buy more storage from Microsoft.

Tenants do get compromised and data can be stolen by attackers, but tenants can do an awful lot to help prevent compromise. Making sure that accounts are protected with multi-factor authentication for a start, removing the ability for clients to connect using basic authentication, and deploying conditional access policies are three steps to halt attackers in their steps. Microsoft is helping by removing basic authentication for protocols like POP3, IMAP4, Exchange Web Services, Exchange ActiveSync, and PowerShell by mid-2021, but tenants can do this now without waiting.

Update: The deprecation of basic authentication for the email connection protocols starts in October 2022.

Accidental Deletion

I wonder what kind of technical review the document through. For instance, accidental deletion is the report’s #1 reason why backups are needed. I’d be more inclined to believe that this is a problem if I didn’t see text like “If you delete a user, whether you meant to or not, that deletion is replicated across the network, along with the deletion of their personal SharePoint site and their OneDrive data.” The focus here is on SharePoint Online, but it’s confused. OneDrive for Business is a user’s personal site, and the workflow used to remove accounts allows an administrator to assign access to the deleted user’s OneDrive for Business account as part of the process. If you want to keep someone’s mailbox, put it on hold before deleting the account and Exchange Online will make the mailbox inactive and keep it until the hold expires. In any case, for all account deletions, even if no hold exists, you can recover the account for up to 30 days following the deletion, which is never mentioned. Again, more FUD.

The authors use a splendid turn of phrase when they state, “Office 365 has geo-redundantly deleted the data forever.” I can’t find what geo-redundantly means, but it seems like they’re making a lot of the fact that user data is removed along with their account (subject to the 30-day recovery period for deleted accounts).

Later, discussion turns to the “Recoverable Items mailbox,” which is a folder rather than a mailbox. They forget to tell people that Exchange Online automatically increases the storage quota for Recoverable Items to 100 GB when mailboxes are on hold to ensure that email held by retention policies can be kept online and available.

Retention Policy Gaps and Confusion

Reason #2 is “Retention policy gaps and confusion.” Retention planning and execution can be confusing unless it’s planned, especially when several Office 365 workloads are involved, but let’s investigate further. The report says: “Office 365 has limited backup and retention policies that can only fend off situational data loss.”

Leaving aside the odd phrasing of “fending off situational data loss,” the fact is that SharePoint Online is the only Office 365 workload that takes backups, so they’re right about limited backup. But that’s by a deliberate design decision to rely on the ability of software to construct robust data protection schemes, like Exchange Native Data Protection.

Microsoft’s decision to use Native Data Protection for Exchange Online is rooted in practicality. In general, the amount of data generated by Office 365 applications would create significant challenges and cost if Microsoft were to attempt to take backups. In the case of Exchange Online , consider how long it would take and how much storage is needed to back up the mailboxes of 345 million Office 365 users when the average size of a cloud mailbox is much larger than its on-premises counterpart due to larger mailbox quotas, the recoverable items quota, and expandable archives. Lacking Office 365 backups is only a weakness in the eyes of backup vendors; it can be a valid and defendable choice for tenants who elect to exploit the features incorporated in the software.

The report says: “In the case of a catastrophic issue, a backup solution can provide the ability to roll back to a previous point-in-time prior to this issue and saving the day.” I wonder if this statement is provable. If Office 365 suffers a catastrophic failure, what is the restore target? Will the customer have on-premises servers to restore data to? Or can they move data to another platform? The multiple datacenters within Office 365 regions means that it would take a truly catastrophic incident to remove service from tenants for more than a working day – and the history of Office 365 operations proves this to be the case.

At what point during an incident would a tenant decide that it’s time to restore back to a point in time? And what data can be restored? Teams is cloud-only, as is Planner and Yammer, so what happens for these applications – where their data be restored to in such a way that users can work with the data? Email and documents can be restored to another location, but that creates other problems like client reconfigurations and email and documents protected with sensitivity labels where users might not be able to authenticate to access the content. While micro-level restores (like a single message, document, or mailbox) are eminently possible if Office 365 is operational, the challenge of restoring all mailboxes (including archives) and all sites for a complete tenant is more challenging. In most cases, the best advice for an Office 365 tenant experiencing an outage is to wait and let Microsoft fix the problem and resume normal operations.

I appreciate that the availability of backups could allow granular restores or point in time restores of objects like an Exchange Online mailbox, a SharePoint Online site, or a OneDrive for Business account, and can be valuable in scenarios like a ransomware attack. Outside the base workloads, all bets are off because no backup and restore APIs exist for applications like Teams and Planner, a fact that no ISV cares to mention. To be fair, Planner data is easier to deal with because it’s reasonably limited in quantity and a Planner Graph API exists that can extract and rewrite data if needed.

The Teams Question

Backing up the Teams compliance records created in Exchange Online is not a Teams backup, no matter how loudly a vendor proclaims this to be true. Including these records along with other mailbox data is an imperfect and fundamentally flawed answer; the records are incomplete and can’t be restored into Teams chats or channels.

Some backup vendors, like Code Two, say that they backup Teams data and then clarify that they’re only referring to the SharePoint Online, OneDrive for Business, and Exchange Online (calendar) data. Although this is better than leading customers to believe that Teams chat and channel conversations are backed up, I prefer the clarity of other vendors like Spanning, who concentrate on the well-known and fully understood challenge of backing up Exchange Online, SharePoint Online, and OneDrive for Business.

Update: It’s been pointed out to me that Keepit uses the beta migration API for Teams to extract channel messages for backup and to restore messages back. This is the same API used by tenant to tenant migration products like those created by Quest, AvePoint, and BitTitan to move Teams data from one tenant to another and has the same problems, such as no support for personal and group chats and complete threads being written into channels instead of separate topics and replies. It’s a better solution than depending on Teams compliance records, but it’s not true backup and restore.

Internal Security Threats

Internal security threats is reason #3. It’s true that someone with administrative permissions could attempt to remove or compromise data before they leave an organization. The “rogue admin” scenario is much beloved of backup companies, but the threat is less in the cloud than it is on-premises. Retention policies (including those that can’t be amended by administrators) can ameliorate the potential effect of someone who deletes all around them before they are escorted off the premises and features like Privileged Access Management can moderate the ability of administrators to wreak havoc on mailboxes. And confidential information can be protected against casual browsing by administrators by encrypting them with sensitivity labels.

None of these features is available on-premises, which is why they might be overlooked. Another thing is that isn’t available on-premises is a comprehensive audit log to capture details of what someone does. It exists in the cloud as the Office 365 audit log.

The author’s worry about “an employee strategically deleting incriminating emails or files” is easily addressed by deploying retention policies. If an employee, a group, sites, or teams come within the scope of retention policies, any attempt to remove incriminating evidence will seem successful, but copies of the items will be kept and available for investigators to find.

External Security Threats

The prospect of users downloading infected files or succumbing to a phishing attack is very real. User training helps, as do good mail hygiene defences like Advanced Threat Protection or an equivalent email cleansing service, but threat of infection exists and can have horrible consequences. It’s worth noting here that SharePoint Online and OneDrive for Business both can restore files up to 30 days back and can cure an infection in this manner. Problems have been noted with these restores, but Microsoft has improved how the feature works since. No other Office 365 app has a point in time restore capability.

The report reassures customers that reason #4 for backups will help, saying, ”Regular backups will help ensure a separate copy of your data is uninfected and that you can recover quickly.” This statement holds true if you can restore a backup to a location where the uninfected data can be recovered. I’m happy that this works well for Exchange Online and SharePoint Online; I wonder what will happen with Teams, Planner, Yammer, and so on.

Legal and Compliance Requirements

The report raises the need to be able to retrieve information to satisfy legal or compliance requirements as reason #5. They note: “Microsoft has built in a couple safety nets, (Litigation Hold) but again, these are not a robust backup solution capable of keeping your company out of legal trouble” and trot out the prospect (again) of losing SharePoint data when a user account is deleted.

Litigation hold is an Exchange construct where complete mailboxes are put on hold. The feature works on both on-premises and cloud platforms. Office 365 retention policies and in-place holds are much more powerful and comprehensive than simple litigation holds and cover Exchange Online, SharePoint Online, OneDrive for Business, Teams, Microsoft 365 Groups, and Skype for Business Online. I guess the authors didn’t get the memo about retention policies. Or they didn’t read it.

Managing Hybrid Email Deployments

There’s not much to say about reason #6, which is that it is an advantage to use the same backup tools for on-premises and cloud email platforms, saying: “The right Office 365 backup solution should be able to handle hybrid email deployments, and treat exchange [sic] data the same, making the source location irrelevant.”

The text comingles Exchange with Office 365. Exchange Online is the biggest workload in Office 365 but it’s not Office 365. This problem of assuming that what works for an individual workload applies across a huge suite exhibits a lack of awareness of the integrated nature of the service. On-premises deployments focus on individual applications like Exchange or SharePoint, but Office 365 is more integrated, broader, more complex, and its data is less accessible to ISVs. I understand how people can take their on-premises experience and transpose it to Office 365, but it’s not right. A different attitude, more knowledge, and a deep understanding of how technologies are interconnected in the cloud is needed, and that just isn’t evident in this document.

Confusing Office 365 with a Limited Application Set

It seems that backup vendors often refer to Office 365 when they really mean Exchange Online and SharePoint Online (including OneDrive for Business), which are the workloads they can process. Claims are advanced for Microsoft 365 Groups, which is fine when you look through the narrow lens of being able to process the group mailbox and team site. Things get more problematic for apps like Teams, Yammer, and Planner. Microsoft hasn’t delivered suitable APIs to allow vendors to build backup and restore tools for these apps, so ISVs cannot be blamed for being unable to stream data from these apps to suitable backup locations.

It’s important that vendors tell potential customers exactly what their software can do. Regretfully, a lack of precision and accuracy is often evident in the narrative spun by backup vendors.

Survey Data Not Informative

A survey of customers is cited as justification that backups are essential. But no detail is available about the experience of the 1,000 IT Professionals surveyed. The assertion is that these people had suffered some data loss in the cloud, but we don’t know about what cloud platforms are involved. The implication is that the problems were with Office 365, but without probing the exact circumstances of the loss for each of the individuals surveyed, we don’t know. If the loss was related to Office 365, we don’t know what applications were involved or what licenses the tenants owned (Office 365 E3 is a base requirement for retention policies and E5 brings a lot more protection). The survey is just FUD.

Further solace is sought from a statement taken from an IDC study (May 2019 – possibly funded by the vendor) that six out of ten organizations don’t have any form of Office 365 data protection sounds horrible, but we don’t know if these are tenants operating in the small to medium businesses, education, or enterprise sectors, so we don’t know what functionality is available to these tenants. I’d be more worried if I knew that six of ten Office 365 enterprise tenants with E3 or E5 licenses had no protection, but my experience is that this is not the case. Lack of protection is usually a problem with small tenants, not large ones.

Saying that organizations don’t have “any form of protection” is an inaccurate claim because tenants automatically gain protection for Exchange (Native Data Protection), SharePoint Online (backups) and OneDrive for Business (restore my files), not to mention inactive mailboxes, retention policies, etc. I also note that the IDC study is focused on email and collaboration (aka Exchange and SharePoint) and doesn’t go near the problematic area of other Office 365 applications where backup isn’t possible. Furthermore, leading statements like “Microsoft offers a 90-day retention policy” don’t offer any evidence for such a conclusion (what data, what app, under what conditions?) and undermine the credibility of the report.

Poor, Badly Argued, Incomplete

I am underimpressed at the quality of the arguments advanced in the report. Poor technical awareness and understanding of the functionality available to Office 365 enterprise tenants is evident in the attempt to convince customers that backups are a necessity. That’s not true. Backups are something that you should consider after thoroughly evaluating the threats facing your tenant and assessing how to mitigate threats using Office 365 standard functionality.

Streaming information to a backup location is a well-known science for Exchange Online and SharePoint Online. Restoring data is where backup vendors differentiate their offerings and earn their money. If you decide to use a backup service, ask questions about just what data is covered and how realistic it is to restore data after a catastrophic outage. If the vendor can’t come up with compelling and evidence-based answers, try someone else.

Upgrading to more advanced (and expensive) Office 365 licenses might be a better investment than committing to a third-party backup service, especially when you consider the problems of a) backing up several Office 365 apps and b) the difficulty of restoring data (apart from email and documents) to some other platform should a disaster happen, unlikely as that might be.

Note: AvePoint’s view on the issues raised in this article are available here.


Want more practical tips about the administration of Office 365? Subscribe to the Office 365 for IT Pros eBook.

25 Replies to “ISVs Say Office 365 Backup is Critical – But Is It?”

  1. Vendors are now applying the new API’s made available by Microsoft to backup Teams chat, that is evident in multiple 3rd party O365 backup technologies with restore presently limited to JSON or HTML. Roadmaps are showing changes to this API which allow for restore direct to Team’s. Is this report dated and as such doesn’t take into account the latest technology advances?

    Also is the difficulty in this argument based upon Microsoft’s T&C’s which clearly define the data is the responsibility of the service end user, as such standard DR/BC policies in live production must ensure a backup of data is required even though total loss of platform raise’s the question ‘Restore back to what?’.

  2. I have been always convinced that there are sufficient measures by Microsoft to address backup issues. Thanks. This is an eye-opener for many.

  3. We are using Arcserve Cloud to cloud backup solution. This is a managed service, the only one protected by an EDR solution and has an efficient de-dup mechanism. It protects exchange, OneDrive and SharePoint

    1. I don’t see anything special in ArcServe Cloud. It seems to do what most of the other ISVs can do for EXO, SPO, and OD4B. And they trot out some beautiful marketing lines like “Arcserve provides exceptional solutions to protect the priceless digital assets of organizations in need of full scale,
      comprehensive data protection.”

  4. Hi, Tony. I see you saying here that Microsoft backs up Sharepoint Online. Although I’ve seen people claim this, I don’t see it mentioned anywhere in the documentation or service agreement. Can you point me to such a claim from Microsoft?

    I’m also curious to know how this backup is done. I know that the “Restore OneDrive Folder” feature uses versioning and the Recycle Bin, which I would not consider a backup, since they’re stored in the same system they’re protecting. (This is from this doc: https://support.microsoft.com/en-us/office/restore-your-onedrive-fa231298-759d-41cf-bcd0-25ac53eb8a15). Do you any documentation that shows that SPO backup is different than ODFB?

    1. Hi,

      I don’t have any Microsoft documentation to cite that’s public. I’m not sure that Microsoft wants this capability to be too widely discussed because it’s not as good as it seems (14 day retention, site collection level, overwrites the entire site collection on restore).

      However, while I don’t have a Microsoft link, the topic has been widely discussed within the industry and people have reported their experiences. Here’s some good examples I found:

      https://www.fidelityfactory.com/blog/2017/2/6/sharepoint-online-content-recovery#:~:text=Microsoft%20takes%20a%20backup%20every,Site%20Collection%20with%20the%20backup

      https://www.nakivo.com/blog/how-to-back-up-and-recover-office-365-sharepoint-sites/

      https://www.jasperoosterveld.com/2016/08/sharepoint-online-backup-restore/
      [MVP] – Quote from Microsoft support:
      If for some reason data can’t be recovered through the GUI, we provide backup available on the server. For this you need to log the request up to 14 days after accident occurs. This way we can restore files/folders/libraries/main site collections and sub site collections. Basically most items under a site collection. The restore is made by overwriting the existing data. Any duplicate entries are not lost. Duplicate items are restored with the number 1 in the end and it’s up to you which one you would like to keep. The restore can’t be done on a separated location.

      https://www.avepoint.com/blog/office-365/native-sharepoint-online-backup-restore/

      1. A Microsoft support article says…

        SharePoint Online retains backups of all content for 14 additional days beyond actual deletion. If content can not be restored via the Recycle Bin or Files Restore, an administrator can contact Microsoft Support to request a restore any time inside the 14 day window .

        Note: Restorations from backups can only be completed for site collections or subsites, not for specific files, lists, or libraries.

        https://support.microsoft.com/en-us/office/restore-deleted-items-from-the-site-collection-recycle-bin-5fa924ee-16d7-487b-9a0a-021b9062d14b?ui=en-us&rs=en-us&ad=us

  5. Hi Tony,

    I noticed your article and think that you are looking at all this with quite different “glasses” then a backup vendor. Also you are looking at this from a point of view where everything is done properly/in-depth and customers have vast amounts of knowledge and know-how of all the online used products from Microsoft.

    However, this is quite often not the case (not going in to the discussion whether they should or not). And even if one has everything in place it still might be a very good idea to have a backup for all the “not expected” problems that might arise (might even be deliberate/rogue).

    Also, you are stating that a catastrophic issue with, for instance, Microsoft will (probably) not happen, but what if it does happen? Or what if in a country there are catastrophic issues with multiple ISP’s and customers are not able to connect?

    Having a backup I think is always a good idea (like an important insurance), best even to have it stored with other software/vendor/party on something else (off-site, other media, etc.). There will always be possibilities to restore all, or certain parts, of the data that is mandatory for a customer to work with. Might not be everything but probably will be all the needed “core” data to go on with business.

    Microsoft itself states the value of making your own backups in their Service Agreement in article 6b:

    6. Service Availability.

    a. The Services, Third-Party Apps and Services, or material or products offered through the Services may be unavailable from time to time, may be offered on a limited basis, or may vary depending on your region or device. If you change the location associated with your Microsoft account, you may need to re-acquire the material or applications that were available to you and paid for in your previous region. You agree not to access or use material or Services which are illegal or not licensed for use in the country from which you access or use such material or Services, or to conceal or misrepresent your location or identity in order to access or use such material or Services.

    b. We strive to keep the Services up and running; however, all online services suffer occasional disruptions and outages, and Microsoft is not liable for any disruption or loss you may suffer as a result. In the event of an outage, you may not be able to retrieve Your Content or Data that you’ve stored. We recommend that you regularly backup Your Content and Data that you store on the Services or store using Third-Party Apps and Services.

    We can discuss this endlessly probably but I felt it needed to just give a comment on this 🙂

    with kind regards from an employee working at a backup vendor 🙂

    1. I noticed your article and think that you are looking at all this with quite different “glasses” then a backup vendor. Also you are looking at this from a point of view where everything is done properly/in-depth and customers have vast amounts of knowledge and know-how of all the online used products from Microsoft.

      TR: The context for the article is analysis of claims made by a specific backup vendor. I consider many of these claims to be misleading and FUD. I do not tar the entire backup industry with the same brush. My central point is that people need to be aware of the capabilities of the technology they already pay for (Office 365) before rushing to deploy a potentially expensive additional service that might not deliver what they expect. As to customer knowledge, it’s true that some tenants are managed in a less than spectacular manner. However, I believe in dealing with IT Pros as professionals, so I anticipate the people who read this information will understand what I am saying.

      However, this is quite often not the case (not going in to the discussion whether they should or not). And even if one has everything in place it still might be a very good idea to have a backup for all the “not expected” problems that might arise (might even be deliberate/rogue).

      TR: That’s a call each organization must make in the context of the business, regulatory, and risk environment they function within. Their state of operational maturity and knowledge about Office 365 are extra factors to consider.

      Also, you are stating that a catastrophic issue with, for instance, Microsoft will (probably) not happen, but what if it does happen? Or what if in a country there are catastrophic issues with multiple ISP’s and customers are not able to connect?

      TR: If tenants cannot connect to the Microsoft network via one of the many local network points, they should be able to get to the network using another point – even one in a different country. That is, assuming that the tenant has outbound internet service. If they don’t, all bets are off, including recovery from a cloud-based backup service.

      Having a backup I think is always a good idea (like an important insurance), best even to have it stored with other software/vendor/party on something else (off-site, other media, etc.). There will always be possibilities to restore all, or certain parts, of the data that is mandatory for a customer to work with. Might not be everything but probably will be all the needed “core” data to go on with business.

      TR: Again, this is something that each organization must determine for themselves.

      Microsoft itself states the value of making your own backups in their Service Agreement in article 6b:

      6. Service Availability.

      a. The Services, Third-Party Apps and Services, or material or products offered through the Services may be unavailable from time to time, may be offered on a limited basis, or may vary depending on your region or device. If you change the location associated with your Microsoft account, you may need to re-acquire the material or applications that were available to you and paid for in your previous region. You agree not to access or use material or Services which are illegal or not licensed for use in the country from which you access or use such material or Services, or to conceal or misrepresent your location or identity in order to access or use such material or Services.

      b. We strive to keep the Services up and running; however, all online services suffer occasional disruptions and outages, and Microsoft is not liable for any disruption or loss you may suffer as a result. In the event of an outage, you may not be able to retrieve Your Content or Data that you’ve stored. We recommend that you regularly backup Your Content and Data that you store on the Services or store using Third-Party Apps and Services.

      TR: Lawyers are prone to insert get-out-of-jail clauses to cover the provision of services. The flaw in this argument is that much of the data used inside Microsoft 365 cannot be backed up because of the lack of suitable APIs.

      We can discuss this endlessly probably but I felt it needed to just give a comment on this 🙂

      TR: I welcome any and all comment. The important thing is to have a debate based on fact and not on FUD. Once people have facts, they can make an intelligent decision. With FUD, it’s like lemmings lined up to jump off a cliff.

      with kind regards from an employee working at a backup vendor 🙂
      😉

  6. A relevant article for me who, making the case to a customer for Office 365 backup, realised the reasons given by the providers of these products can be pretty weak.

    The best reason that I could come up with was that having a choice of methods of recovering emails etc. is always a good idea.

    Having used some backup solutions elsewhere, I find them much easier to navigate than submitting an e-discovery request to Microsoft and so would turn to them first. Because the annual licence includes updates, hopefully one day Microsoft Teams chat will be included in what can be backed up.

  7. Even though there are some valid points in the discussion made by Tony, e.g. look at what is naively available in the platform and perform due diligence into the technical details of a backup vendor, it is fundamentally flawed in that it dissects only a single white paper from a single vendor. I get the point you’re trying to make but it’s an extremely scathing review without any reference to the original source material. You’ve masterfully fulfilled your own self prophecy, aka confirmation bias.

    You could have distilled your argument into a far smaller article without needlessly dissecting a marketing document.

    1. I have been making these points for years, as readers of the Office 365 for IT Pros eBook will recognize (also in articles on Petri.com like this one https://petri.com/determining-need-office-365-backups from two years ago). The reason I went after this article is its total lack of knowledge about how Office 365 works. I could review documentation and assertions from other cloud backup vendors and come to the same conclusions. Not all vendors generate such crass marketing material as this example, but I think it’s fair to challenge vendors to justify the claims they make. I illustrated how with another vendor when I debated the need for cloud backup with AvePoint in an online discussion. See https://www.avepoint.com/events/webinar/debate-o365-backup

      I also note that the vendor in question did not attempt to rebut any of the criticisms I made of their document…

  8. This topic has been widely discussed within the industry and people have reported their experiences with it. Here’s some examples I was able to find:
    https://www.jasperoosterveld.com/2016/08/sharepoint-online-backup-restore/
    https://spinbackup.com/blog/office-365-on-premises-vs-cloud-backup-where-to-keep-data/
    These are just a tip of the iceberg. Office backup has been an issue for me personally and I’m still looking for a good solution

    1. Any blog that is more than a year old is questionable in terms of the currency of its advice. The world of Office 365 changes all the time, and any suggestion made in 2016 for SharePoint Online is probably invalid given the way people use SPO today. The apps we use today and the way we use data today is very different to what pertained five years ago.

  9. A rare find in today’s world. The blog’s author adding link to a counter view point. Thank you!

    A small note, The green graphic at the top was a little confusing/ misleading at first. The graphic seems that is was: “for it” . . . while the article is really “questioning” the need to backup. I agree that venders paint a scary picture that they have the perfect solution. Relying on “FUD” (fear, uncertainty, and doubt) to push their nightmare scenario. However, as someone without the in-depth technical knowledge of what office 365 is currently capable of, I was not sure of what questions to even ask. Thus how I came across this great blog.

    It was also helpful seeing the counter point article by John Hodeges that shows linked above (8.26.2020). Hodges also wrote blog posted 10.19.2020 on: “The Great Office 365 Backup Debate” ( https://www.avepoint.com/blog/backup/office-365-backup-debate/ )

    Again, Thanks

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.