Backup and Disaster Recovery for Berlin SMBs: What You Actually Need
Backups are the one part of IT that every business thinks is sorted — until it isn’t.
The pattern is consistent: a ransomware attack hits, or a critical file gets deleted, or a server fails — and then the real conversation starts. Was the last backup from yesterday, or three weeks ago? Has anyone actually tested a restore? Does the backup include Microsoft 365, or just the file server?
This guide covers what a working backup and disaster recovery setup looks like for a Berlin SMB in 2025 — not in theory, but operationally.
The problem with “we have backups”
Having a backup process running is not the same as having a recovery capability. The difference only becomes visible under pressure, which is exactly the wrong time to find out.
Common gaps in SMB backup setups:
- Microsoft 365 is not backed up. Microsoft’s shared responsibility model explicitly states that data protection is the customer’s responsibility. Exchange Online, SharePoint, OneDrive, and Teams data can be deleted — accidentally or maliciously — and Microsoft’s recycle bin retention is limited. A third-party Microsoft 365 backup is not optional for any business that runs critical operations through M365.
- Backups are not tested. A backup job completing without errors does not mean the data is recoverable. Backup files can be corrupt, incomplete, or stored in a format that requires specific software to restore. If you have not performed a test restore in the last 90 days, you do not have a verified backup.
- Backups are on the same network as production. Ransomware routinely targets backup systems. If your NAS is network-connected and accessible from workstations, it will be encrypted alongside everything else. Air-gapped or immutable backup copies are a requirement, not a nice-to-have.
- RTO and RPO are undefined. Recovery Time Objective (how long the business can be down) and Recovery Point Objective (how much data loss is acceptable) are the two parameters that determine what backup infrastructure you actually need. Without them, you are building backup without knowing what you are protecting against.
The 3-2-1 rule — and why it is still the baseline
The 3-2-1 rule remains the minimum viable standard for SMB backup:
- 3 copies of your data
- 2 different storage media or systems
- 1 copy offsite or in the cloud
In practice for a Berlin SMB using Microsoft 365 and an on-premises or hosted file server, this typically means: local backup (fast restore), cloud backup (offsite), and Microsoft 365 backup via a third-party tool like Veeam, Acronis, or Backupify.
In 2025, an updated version of this rule adds a fourth consideration: one copy should be immutable — meaning it cannot be deleted or modified by ransomware or a compromised admin account. Azure Blob Storage with immutability policies, or object-locked S3-compatible storage, satisfies this requirement without significant cost overhead.
What to actually back up
For most Berlin SMBs, the critical data landscape looks like this:
| Data source | Backup requirement | Common gap |
|---|---|---|
| Exchange Online / Outlook | Third-party M365 backup | No backup at all |
| SharePoint / OneDrive / Teams | Third-party M365 backup | Assumed covered by Microsoft |
| File server / NAS | Local + cloud, immutable copy | Network-attached backup (ransomware risk) |
| Line-of-business applications | Application-consistent backup or vendor-managed | Database not included in file backup |
| Endpoints (laptops / workstations) | OneDrive sync or endpoint backup agent | Desktop and Downloads folders excluded |
Disaster recovery vs. backup — the difference matters
Backup is a copy of your data. Disaster recovery is a plan to restore your business operations to an acceptable state within a defined timeframe. They are related but not the same.
A disaster recovery plan (DRP) for an SMB does not need to be a 200-page document. It does need to answer:
- What are the systems and processes that, if unavailable, would stop the business operating?
- For each: what is the maximum acceptable downtime (RTO)?
- For each: what is the maximum acceptable data loss in hours (RPO)?
- Who is responsible for initiating recovery, and what exactly do they do?
- Where are the recovery credentials and documentation stored (not on the systems that might be down)?
RTO and RPO drive your infrastructure requirements. A business that can tolerate four hours of downtime and two hours of data loss has very different backup needs from one that needs to be back online in 30 minutes with no data loss.
Testing: the step nobody does
A backup you have not tested is a hypothesis, not a capability. Quarterly restore tests are the minimum — and they need to test the full recovery path, not just “can we see the files.”
A meaningful restore test for an SMB includes:
- Restoring a specific file or folder from a backup taken at least 7 days ago
- Restoring a mailbox or calendar item from Microsoft 365 backup
- Confirming a restored database opens and applications connect to it
- Documenting how long the restore actually took against the RTO target
Test results should be recorded, even in a simple spreadsheet. This documentation is increasingly required for NIS2 compliance and GDPR incident response readiness.
Ransomware-specific considerations
Ransomware has fundamentally changed the backup threat model. The key considerations for 2025:
- Immutable storage is non-negotiable. Backup targets should support object lock or write-once policies. Azure Blob, Wasabi, and Backblaze B2 all support this at low cost.
- Backup admin credentials must be isolated. The account that manages your backup system should not be the same account used for day-to-day admin. Ideally, backup system access is not accessible from regular workstations at all.
- Air-gap or offline copies. A rotated external drive kept offsite — even just at a director’s home — provides a recovery path that is completely independent of your network.
- Detection, not just protection. Backup alone does not detect ransomware. Endpoint detection and response (EDR) and Microsoft 365 anomaly alerts are the early warning system. The later you detect an infection, the more data you lose even with good backups.
What a realistic SMB backup stack looks like
For a Berlin business with 10–80 employees on Microsoft 365 with a mix of on-premises and cloud workloads:
- Microsoft 365 backup: Veeam Backup for Microsoft 365, Acronis Cyber Protect Cloud, or Dropsuite — daily backups, 1-year retention, geo-redundant storage
- File server / NAS: Veeam or Acronis agent → local backup repository + Azure Blob with immutability policy — daily incremental, weekly full
- Endpoints: OneDrive Known Folder Move (KFM) configured via Intune for Documents/Desktop/Pictures — simple, automatic, included in M365 licensing
- Offsite copy: Encrypted external drive rotated weekly or monthly to an offsite location (or cloud-only if RTO allows)
- Backup monitoring: Email or Teams alerts on backup job failure — someone must own reviewing these daily
Rough monthly cost for this stack: €80–200 depending on data volume and tooling choices. It is one of the highest-ROI IT investments a small business can make.
GDPR and NIS2 implications
GDPR requires technical and organisational measures to ensure data availability and resilience. In practice, this means documented backup procedures, tested restore capability, and — critically — an incident response plan that includes how you handle data breaches. A ransomware attack that encrypts personal data is a reportable GDPR breach within 72 hours.
NIS2, which applies to a broader set of businesses than its predecessor, explicitly requires backup and recovery controls as part of basic cybersecurity hygiene. Berlin SMBs in sectors like transport, digital infrastructure, food distribution, or professional services may fall under NIS2 scope.
Free for Berlin SMBs
Find Out Where Your IT Actually Stands
We review your security posture, Microsoft 365 setup, network resilience, and compliance gaps — and give you a written report at no cost.
Book Your Free IT Assessment →
No obligation. Written report included. ~45 minutes of your time.
Summary
The gap between “we have backups” and “we can recover” is where most SMB data loss happens. The fundamentals are not technically complex: 3-2-1 rule, immutable offsite copy, tested restores, and a written recovery plan with defined RTO and RPO.
If your backup setup has not been reviewed in the last 12 months, there is a meaningful probability that something in it has drifted — a job that stopped running, a retention window that shortened, an admin password that changed and was never updated in the backup software.
A systematic review of backup and recovery is part of our free IT assessment for Berlin SMBs — alongside security posture, Microsoft 365 configuration, and compliance readiness. The written report tells you exactly where you stand.
Related Reading
Also on this topic
