Secure backup
Backups are not “a copy on a USB stick when someone remembers”: they are a recovery strategy you can trust under pressure. We design and operate 3‑2‑1 style architectures with a clear triple‑location layout: three independent backup streams or generations you can rely on, two local targets (different systems or rooms so a single failure does not erase history), and one remote/off‑site tier so ransomware, fire, theft or datacenter loss does not become a data‑loss event.
We focus on what matters in the real world: verified restores, retention that matches compliance and common sense, encryption in transit and at rest, and monitoring that surfaces silent failures before you need the backup.
3‑2‑1 and triple location (in practice)
The 3‑2‑1 rule is a simple guardrail: keep three copies of important data (including production), on two different media/types (so correlated failures are less likely), with one copy off‑site (different building, provider, or region; depending on risk). Our “triple location” implementations usually map to: primary backups on fast local storage for quick VM/file restores, a second local target (another NAS/appliance, or a separate shelf/array) for redundancy and rotation, and a remote leg (replication, object storage, colocation, or a second office) for true disaster recovery.
What we implement & run
- Policy: RPO/RTO targets, retention tiers, legal hold where needed.
- Jobs & schedules: application‑consistent protection for VMs; throttling and windows that fit production.
- Integrity checks: periodic test restores and checksum/scrub routines where supported.
- Alerting: failed jobs, low free space, broken replication, TLS/cert issues on cloud targets.
- Runbooks: who does what during restore, escalation paths, and vendor coordination.
Virtual servers: Proxmox & VMware
For Proxmox VE environments we typically combine guest‑level strategies (scheduled backups of VMs/CTs, tuned retention, exclude lists where safe) with export/replication to a second node or dedicated backup appliance, then fan‑out to an off‑site copy. For VMware vSphere estates we align backup windows with storage snapshots (where appropriate), ensure application‑consistent quiescing when databases run inside guests, and separate “operational restore” targets from “disaster copies” so you do not trade speed for safety by accident.
- Cluster realities: quorum, storage layout, and backup traffic isolated from production VLANs where possible.
- Restore drills: partial file restore, full VM restore, and “restore to alternate cluster” scenarios.
- Change control: upgrades to hypervisor, drivers, and backup agents tracked with rollback plans.
Microsoft 365: tenant backup to appliances you control
Microsoft 365 is durable, but not a substitute for an organisation‑owned backup when you need point‑in‑time recovery, long retention, legal discovery workflows, or protection against operator mistakes and malicious insiders. We implement Microsoft 365 backups onto Synology and QNAP platforms customers already run (or want to standardise on), including mailboxes, SharePoint/OneDrive content, Teams where the product supports it, and calendars/contacts as applicable. Typical stacks include Synology Active Backup for Microsoft 365 and QNAP HDP for SaaS (Microsoft 365), with Hybrid Backup Sync (or equivalent) often used for replication to a second NAS or cloud tier, chosen per tenant size and compliance constraints.
Synology & QNAP
We use Synology and QNAP as first‑class backup platforms: BTRFS/ZFS snapshots where available, encrypted shares, role‑separated admin accounts, UPS integration, SMART tests, and replication to a second device or cloud bucket. We size for growth + retention, not “just enough for last night”.