Backups you can actually restore.
Most businesses discover their backup strategy doesn't work the day they need it. Ours are tested every month, restored on demand, and immutable to ransomware by design.
A backup that hasn't been restored is a hope, not a backup.
The pattern we inherit, over and over: a 5-year-old NAS in a closet, a Veeam license that lapsed in 2022, a "we should test that someday" line in a 2019 IT review. When ransomware hits — and statistically it will, with the average Canadian SMB paying $48K and 21 days of downtime per Statistics Canada's 2024 cyber report — those backups don't restore.
4UIT designs every backup the same way: 3 copies of the data, on 2 different media types, with 1 off-site and immutable. That's the standard. The implementation varies by what you're protecting.
What we back up
Servers (physical and virtual). Workstations (selectively — usually only knowledge workers' laptops). Microsoft 365 — yes, you need to back up M365, Microsoft does not back it up for you. Google Workspace. Cloud workloads on Azure / AWS. Line-of-business databases (SQL Server, Postgres, MySQL).
How immutability works
Ransomware now actively hunts and deletes backups before encrypting your live data — that's the playbook. Immutable storage is write-once, delete-never (within a retention window), enforced at the storage layer. An attacker with full domain admin still can't delete or overwrite the immutable copy. We use object-lock on cloud targets (Wasabi, Backblaze B2, AWS S3) and hardened repositories on-prem.
The monthly restore drill
Every customer gets a monthly restore test. We pick a random file, a random VM, or a random M365 mailbox, restore it to a sandbox, verify it opens, and log the result. You see the log. If a restore ever fails, we fix the backup chain that week — not when a ransomware actor schedules it for us.
Disaster recovery, not just backup
For customers who can't tolerate hours of downtime, we build full disaster-recovery: warm-spare VMs in a secondary site, RTO/RPO commitments documented and tested twice a year, runbooks written so a junior engineer (or you) could execute the failover at 3 AM. RTOs from 15 minutes; RPOs from minutes.
Common questions.
Doesn't Microsoft back up my M365 data?
No — and Microsoft is explicit about this. The shared-responsibility model says Microsoft handles infrastructure availability; the customer handles data protection. Deleted mail, deleted SharePoint sites, accidentally-emptied Teams channels — once past the 30/93-day retention window, gone forever, unless you have third-party backup.
How often are backups taken?
Servers and M365: hourly incrementals, daily fulls. Workstations: typically once or twice daily. Databases: depending on RPO target, anywhere from continuous log shipping to nightly. We tune to your tolerance for data loss.
What's the difference between backup and disaster recovery?
Backup gets your data back, eventually. DR gets your business running again, fast. Backup is a precondition for DR; DR adds standby infrastructure, runbooks, and tested failover. Most SMBs need backup; mid-market and regulated businesses need DR.
How fast can you restore a ransomware-encrypted server?
Depends on size and target. A 500GB file server restored from immutable cloud to a clean replacement VM: typically 4–8 hours including network, AD rejoin, and verification. With a DR plan in place, the same scenario fails over in 15–60 minutes to a pre-built warm spare.
Where is my data physically stored?
On-site copy: at your office on a hardened repository. Off-site copy: in a Canadian-region cloud target (Wasabi Toronto, Azure Canada Central, or your choice). We never store backup data outside Canada without explicit written consent.
Ready to make your IT boring?
20-minute call. No deck, no pressure. We listen, then propose.
Book a brief →