Backup, Restore and Disaster Recovery Cluster Services
Recovery tiers with a measured RTO, an off-site copy that cannot be encrypted by ransomware, and a restore drill the board can read.
What this usually looks like
Backups report success every night. The question nobody has answered with a stopwatch is how long it takes to come back, and whether the copies are actually readable.
- Job success is treated as proof of recoverability, and no restore has been timed in years.
- Backup storage sits on the same array and the same credentials as production.
- The DR plan is a document whose RTO was written before the last three architecture changes.
- Kubernetes workloads have no backup beyond "the manifests are in Git" — which is not a data backup.
Three ways to buy this
Audit if you want to know how bad it is. Build if you have the team and want the capability. Managed if you don't want to own the pager. Most engagements start with the audit and decide afterwards.
Audit
A fixed-price health check — the cheapest way in
- Estate tiering against an explicit recovery requirement per system
- Backup job coverage and gap analysis against the inventory
- First timed restore of a representative sample, with a report
- Blast-radius review: what a compromised credential could delete
Build
One-off delivery: design, code, hardening, handover
- Recovery tiers with defined RTO and RPO, agreed with the business
- Backup jobs built per tier instead of one nightly schedule for everything
- Off-site immutable repository, with credentials separate from production
- Database-consistent backup for PostgreSQL, MySQL, MongoDB and object stores
- Velero or Kasten for Kubernetes, with a tested cross-cluster restore
Managed
Build plus 7×24 on-call, SLA and quarterly drills
- Backup success, coverage and repository integrity monitored daily
- Restore drills on a quarterly cycle, rotating the scope so every tier is proven yearly
- Retention and immutability policy maintained and evidenced
- DR runbook kept current with every architecture change, not after it
- Ransomware-recovery readiness reviewed annually
What we actually deploy
Specific tooling, not categories. If a version matters to your decision, ask — we will tell you which one we would pick and why, including when the answer is the older one.
Host & VM backup
- Proxmox Backup Server (+ sync jobs)
- Proxmox VE backup
- Bacula / Bareos
- Amanda
- Restic / Borg (file tier)
Kubernetes
- Velero (+ CSI snapshots)
- Kasten K10
- application-consistent hooks
- cross-cluster restore
Databases
- pgBackRest (PITR)
- XtraBackup
- mongodump / mongorestore
- object-store snapshot policies
Off-site & immutability
- S3-compatible immutable repository
- Object Lock / WORM
- encrypted transport
- air-gapped vault
- 3-2-1-1-0 discipline
Orchestration & DR
- scripted failover runbooks
- DNS cutover
- replication policy
- RTO/RPO tier register
Verification
- automated restore tests
- checksum verification
- backup freshness reporting
- drill reports to management
What we will be measured on
These are the numbers we put in the delivery report. If we cannot measure it, we do not promise it.
- Every system belongs to a named recovery tier with an agreed RTO and RPO.
- Each tier has been restored and timed within the last quarter — with a written report.
- The off-site copy is immutable and reachable without production credentials.
- A Kubernetes namespace has been restored to a different cluster, end to end.
- Backup coverage gaps are reported automatically rather than discovered during an incident.
What we would build, and where the weak point is
The backup server in the same rack is a deliberate speed layer, not a recovery strategy — which is why the off-site vault uses separate credentials and immutability. If one compromised account can delete both copies, you have one copy with a longer cable.
marks a single point of failure we would raise with you rather than hide. Every architecture has one; the question is whether you know where it is.
What we don't do
Every vendor says yes to everything. Here is where our answer is no, or where someone else needs to be in the room. If this list looks wrong for your situation, tell us — we would rather argue about scope before the contract than after.
- Requires partner
Tape library operation and off-site media rotation
We integrate a tape tier if you run one and will design around it, but we do not operate physical media rotation.
- Out of scope
Forensic data recovery from failed media
Clean-room recovery is a specialist industry. We design so you fail over instead of paying for it.
- Out of scope
Legal retention interpretation and e-discovery
We implement the retention you specify and prove it is enforced. Deciding what the law requires is your counsel’s call.
- Requires partner
Backup of SaaS and third-party cloud tenants
We will include it in the design where the vendor exposes an API; several do not, and we will say so rather than pretend.
What it looked like last time
A logistics group with nightly backups that had never been restored in three years: estate tiered into four recovery classes, backup rebuilt per tier, an immutable off-site repository separated from production credentials, and a first drill that recovered fourteen critical systems with a measured time per tier — replacing a policy number with an evidence-backed one.
Anonymised under NDA. No client names, no logos, no invented metrics. Full case library on the work page.
Talk to the data protection engineer about your backup & disaster recovery
Send us the architecture, or just describe what broke most recently. You'll get an engineer's answer, not a discovery questionnaire.
Talk to a data protection engineer: botonwa@gmail.com · +86 130 5181 3099