Why Microsoft 365 still needs a backup
Microsoft keeps your service running. It does not promise to get your data back. Under Microsoft’s shared responsibility model, the tenant is theirs to keep online and the contents are yours to protect. A mailbox deleted by an offboarding mistake, a SharePoint library encrypted by ransomware that synced from one laptop, a Teams channel purged by a departing employee: Microsoft’s built-in retention gives you a window, and after that the data is gone. Our Microsoft 365 backup takes independent copies of mail, OneDrive, SharePoint, and Teams on a schedule, held outside your tenant, so a deletion inside the tenant cannot reach them.
The three kinds of copy
Cloud. Microsoft 365 data is backed up to independent storage on a daily schedule with point-in-time restore, so you can recover a mailbox, a file, or an entire site as it was on a specific day.
On-prem. Servers and file shares still running in your office get image-based backup: the whole machine, not just the files, so a dead server can be brought back as a virtual machine rather than rebuilt from scratch. Copies go to local storage for fast restores and to the cloud for the day the office is not available.
Endpoints. Laptops and desktops are backed up too, because the spreadsheet that runs the business is frequently on someone’s desktop and nowhere else.
Immutable means the attacker cannot delete it
Ransomware groups look for backups first. They know that a business with a clean restore will not pay. So the copies that matter are stored immutably: once written, they cannot be modified or deleted by anyone, including us, until the retention period ends. Stolen admin credentials, a compromised backup console, a disgruntled insider: none of them can reach the immutable copy. It is the single control that decides whether a ransomware incident is a bad week or a closed business.
Quarterly restore tests, with results you can read
A backup that has never been restored is a hope, not a plan. Every quarter we run a real restore against test infrastructure: a mailbox, a file share, a full server image. We time it, confirm the data opens, and write up what happened, including anything that failed and what we fixed. Those results go into your quarterly business review. When your insurer or auditor asks whether backups are tested, you hand them the dated report.
The recovery runbook
The runbook exists from day one, not the day of. It names who declares an incident, who gets called in what order, which systems come back first (usually identity and email, then the line-of-business application, then file shares), and how long each step should take based on the restore tests. Recovery time and recovery point targets are set with you during onboarding, based on what a day without a given system would cost your business, and the backup schedule is built to meet them.
For a New York office that loses its building, whether to a flood, a fire, or a landlord dispute, the runbook also covers working from anywhere. Because Microsoft 365 is the primary workspace and on-prem systems can be restored to the cloud, your staff can work from home or a co-working space while the office is sorted out.
Where this fits in the plans
Backup and Disaster Recovery is included in the Professional and Enterprise tiers and available as an add-on to Foundation at $25 per user per month. If you have on-prem servers, we scope those separately and quote a flat fee. Scope is documented before anything starts, so there is never a question afterward about whether a system was covered. Backup is the last line in the cybersecurity stack, and the one that gets used when everything in front of it has failed.