Independent comparison · no paid rankings
Home / Blog / Technical / Granular restore: recover one customer without rewinding everyone

Granular restore: recover one customer without rewinding everyone

Restoring the whole VM for one customer erases everyone's timeline: granular restore requires tenant architecture and semiannual drills.

Hébergeurs.eu Editorial Team 5 min read Updated Jul 19, 2026

A SaaS customer accidentally deletes an entire folder Friday at 5 p.m. Support promises « granular restore ». Ops launches a VM snapshot restore — and rewinds the whole platform to Thursday midnight. Every other customer loses a day of work. Granular SLA existed in the contract, not in architecture.

Restoring one tenant without touching others requires tenant export, DB PITR, or restore to temporary instance then selective merge — not a marketing « restore VM » button.

PITR vs tenant export

PITR (Point In Time Recovery): return to time T — ideal recent corruption on shared DB with logical isolation.

Tenant export: extract customer X data from multi-tenant schema — ideal targeted deletion without global rewind.

ScopeTypical toolGlobal risk
Table / tenantselective pg_restore, export scriptLow if sandbox
VM snapshotHypervisorHigh — all downtime

Multi-tenant architecture

Restore to temporary instance isolated network, validate checksums, selective merge — never overwrite multi-customer prod without isolation.

Application soft delete may beat backup restore for speed — document when each path applies.

Nightly exports for largest customers reduce P1 restore panic.

Drills and RTO matrix

Semiannual minimum: fictional customer deleted folder yesterday, timed restore without other customer downtime. Sandbox mandatory.

RTO matrix: tenant export, table PITR, VM snapshot — tool, target, last real test date. Without date, SLA is fiction.

Support: legal wording « customer workspace restorable » vs « full backup » — legal review.

Promise vs host capability

Many hosts restore full disk image only. Test customer X restore before contractual granular SLA.

Compare backup/restore offers via comparison tool — ask for tenant restore proof, not marketing slide.

Incident communication

« Restore in progress for customer workspace X only » — not « global maintenance » if avoidable. Post-restore: client file sample checksums.

Post-mortem: gap marketing promise / technical matrix — fix contract or architecture before next enterprise sale.

Customer promise audit

Compare marketing SLA words to technical restore capability matrix. Misalignment fixed in contract or architecture before next enterprise sale.

Tenant export nightly for largest customers reduces P1 restore panic — incremental export cheaper than full PITR drill daily.

Restore test includes application login as customer user — DB row present insufficient if app cache stale.

Operational follow-up

Quarterly fictional customer granular restore drill — real RTO metric. Network-isolated sandbox mandatory. Support macros answer granular scope accurately — legal reviewed wording. Document gaps between host marketing and field measurement in the quarterly review.

Quarterly follow-up

Quarterly fictional customer granular restore drill — real RTO metric. Network-isolated sandbox mandatory. Support macros answer granular scope accurately — legal reviewed wording. Document gaps between host marketing and field measurement in the quarterly review.

Application soft delete may beat backup restore for speed — document when each path applies.

Keep a dated runbook, before/after metrics, post-incident review — cumulative discipline beats Friday night panic.

Keep a dated runbook, before/after metrics, post-incident review — cumulative discipline beats Friday night panic.

Keep a dated runbook, before/after metrics, post-incident review — cumulative discipline beats Friday night panic.

Keep a dated runbook, before/after metrics, post-incident review — cumulative discipline beats Friday night panic.

Keep a dated runbook, before/after metrics, post-incident review — cumulative discipline beats Friday night panic.

Keep a dated runbook, before/after metrics, post-incident review — cumulative discipline beats Friday night panic.

Operational follow-through

Keep a dated runbook, quarterly review with business teams, and before/after metrics for each change. Document gaps between host marketing and field measurement: latency, quotas, restore, support. To compare infrastructure and read more field notes, browse our directory, comparison tool, and technical blog guides — a documented decision beats an upgrade bought in Friday night panic.

Quarterly review

Compare field metrics and host product sheet: latency, quotas, restore, support delays. Adjust contract or architecture on evidence, not feeling.

Decide and move forward without blind spots

  1. RTO matrix — tenant export, table PITR, VM snapshot: tool, target, last real test date.
  2. Semiannual exercise — client X deleted folder yesterday, restore without other customer downtime, timed.
  3. Exact command runbook — pg_restore, mysqlbinlog, not theory.
  4. Support script vocabulary — « customer workspace restorable » vs « full backup » legally.
  5. List granular vs full-only — what the host contract actually covers.

Multi-tenant SaaS: comparison tool, directory, continuity guides.

Frequently asked questions

PITR vs tenant export?

PITR restores to time T — ideal for recent corruption. Tenant export isolates one customer without rewinding the whole VM.

Granular promised but VM snapshot only?

Many hosts restore full disk only. Test client X restore before contractual granular SLA.

Avoid overwriting other customers?

Restore to temporary instance, validate checksums, selective merge — never overwrite prod without isolation.

Exercise frequency?

Semiannual minimum per critical scope. Update RTO matrix last test date.


Simulate a fictional customer granular restore this quarter — not on P1 ticket day.

Compare European hosts

Filter by compliance, location and use case — then open the sheets to verify the real scope.

Browse the directory
Blog

Related reading

All articles →