It's not a matter of if. It's a matter of when.
Drives fail. Servers crash. People delete things. Ransomware encrypts what nothing was watching. The question isn't "could it happen here" — it's "how fast can we be back?" That's what backup & DR is. Done right, it's the work you hope never matters.
3-2-1 isn't marketing — it's the floor.
3 copies of your data · 2 different kinds of storage · 1 copy off-site
Anything less and you're rolling dice. We design backup posture around that floor, then layer on encryption, versioning, retention policy, and disaster recovery on top.
What we protect
- Servers — full image-based and file-level backups, VM-aware where the hypervisor supports it (quiesced snapshots, application-consistent restores for databases and Exchange/AD). Destination shape depends on the server's role and your preference: on-site storage (NAS or dedicated backup appliance) with cloud replication for the off-site copy; direct-to-cloud where on-site isn't practical; client-provided cloud storage if you want to own the destination; or LSC-managed object storage if you'd rather we handle the whole pipeline end to end. We're at home across the common toolchain — Proxmox Backup Server, Veeam, native hypervisor snapshots, and others matched to the environment — with retention windows and immutable versioning layered on where the destination supports them. Bare-metal vs VM, application-aware vs crash-consistent — we shape the strategy around the server's actual job, not a generic template.
- Workstations — image-based backups (or file-level where image isn't practical) on every main user system we identify as critical. Image-based captures the whole machine: installed applications, OS configuration, file data, drive mappings, printers, user customizations — all of it. For most clients we default to covering all main user systems. The call on what's critical sits with us, not the end user — most people aren't relying on cloud sync as consistently as they think they are.
- Cloud tenants — Microsoft 365 + Google Workspace data (mailboxes, files, calendars, sites) backed up to third-party storage. Native cloud retention is not backup. We add the real layer.
- Websites & databases — pairs with our hosting service
Disaster Recovery as a Service
For clients who can't afford to be down for a day while we restore, we run DRaaS: an off-site replica of your critical servers, ready to spin up if your primary environment is unreachable. Recovery time is measured in hours, not days. Replication runs in the background; you don't notice it until you need it.
A common shape we deploy: redundant AD/DNS controllers running in our datacenter cabinet, reachable from the client site over an IPSec tunnel. When on-prem hardware dies, users keep authenticating against the off-site controller — a quick DNS flip and the workday continues while we deal with the primary. Details on the hosting / co-location page.
Encryption posture
- Encrypted in transit — TLS for backup transmission and management traffic.
- Encrypted payloads — the backup agent applies AES-256 to the data before it leaves the source. This works whether or not the source machine itself has full-disk encryption — the two layers are independent.
- Encrypted at the storage target — the destinations we back up to encrypt blobs at the storage layer. Key custody (provider-managed, LSC-managed, or client-controlled) is specified per engagement.
- Versioning & immutable snapshots — where the target supports it, prior backups within the retention window can't be altered or deleted by ransomware or accidental action.
RTO & RPO
We set recovery time objective (RTO) and recovery point objective (RPO) targets for each client based on what your business can tolerate. Common shapes:
- File-level restore: minutes
- Single-server restore: hours
- DRaaS failover: 1–4 hours depending on environment size
- Cloud data restore: minutes to hours depending on scope
We test the recovery path. A backup that's never been restored isn't a backup — it's a hope.
Common questions
Doesn't RAID count as backup?
No. RAID protects against drive failure. It does not protect against ransomware, fire, theft, file corruption, accidental deletion, or a bad firmware update bricking the array. RAID is part of uptime; backup is something else entirely.
Microsoft 365 / Google Workspace already keep my data, right?
They keep it for a limited retention window with specific recovery semantics. They are explicit in their docs that customers are responsible for backup. We add a real backup layer for every cloud client.
How do you know the restore path actually works?
Because we use it. Real-world restore requests come through regularly — file-level recovery, accidental deletions, machine swaps, the occasional "I overwrote the wrong thing" moment. Those are the most reliable proof that the path works, and we've run plenty of them successfully over the years. We also spot-check restores when the situation calls for it — after a major backup configuration change, when onboarding a new client environment, or when something looks off in the agent logs. The goal isn't a checkbox on a calendar; it's confidence that when you call us with "shit, can you get X back," the answer is yes.