A backup of a shared SaaS database protects the whole service, but a customer may need only its own data restored after an accidental deletion. Restoring the entire database could overwrite other tenants' newer work. Tenant-specific recovery therefore needs a plan for extracting, validating, and reintegrating one customer's records while preserving relationships and current production activity. The procedure should be tested before the first urgent request.
Define the recovery promise
Clarify which events are covered: accidental deletion, corruption, a faulty import, or full infrastructure failure. State the recovery point and expected time the business can support. A daily backup cannot promise restoration to the minute. Decide whether the tenant receives a full rollback, selected records, or an export for manual review. These options have different risks. Include uploaded files, search indexes, and settings in the definition; restoring database documents alone may leave a visibly broken product.
Map tenant-owned data
List collections, storage paths, caches, search records, and cross-part copies that contain the tenant's information. Some global records may be referenced by tenant data, and some users may belong to more than one tenant. The restore must not duplicate or overwrite shared identities blindly. Use centralized IDs and ownership fields to identify records, and validate that every selected record truly belongs to the tenant. Keep a dependency map for related records so a restored order does not point to a missing invoice or vice versa.
Restore into a safe workspace first
Extract the tenant's data from a backup into an isolated environment. Compare record counts, dates, and key relationships with the request. Let an authorized operator or customer representative review a sample before production import. If the cause was a bad migration or import, correct that root cause first or the restored data may be damaged again. Avoid running an unreviewed script directly against production under time pressure. A staged workspace also reveals whether the backup format can be read and whether older schema shapes need migration.
Merge carefully with current state
Production may have new writes after the backup. Choose whether to replace selected records, merge missing items, or create a separate recovery copy for review. Each choice needs conflict rules. Use idempotent import operations and record what changed. Pause relevant writes if a consistent cutover requires it, but avoid stopping other tenants. Update embedded cross-part data through supported operations where possible. Rebuild derived search and cache entries after restoring source records. Keep an audit log of the recovery so later questions can be answered.
Test the procedure
Run drills with a test tenant containing posts, files, users, and background jobs. Simulate a deletion, restore from a backup, and verify the product through the API and site. Measure duration and note manual steps. Test access controls so a support operator cannot restore another tenant without authorization. If the architecture uses separate databases for some customers, rehearse both shared and dedicated paths. A backup is only useful when the team can perform the promised recovery reliably.
Improve from real incidents
After a restore, review why the data was lost and whether validation, undo, or better permissions could prevent recurrence. Update the runbook with commands, owners, and checks that worked. For an SMB-focused service, a modest documented process may be enough, but it must be honest about recovery limits. Tenant-specific restore is a valuable capability when it preserves other customers' work, keeps auditability, and lets the affected customer return to a trustworthy state. Record the backup source, extraction time, validation results, and final approval for every real recovery. These details help explain exactly what was restored and support a later audit. Test the procedure again after significant schema or storage changes; an old successful drill does not prove that a new data model can still be recovered.