A customer of an Irish scheduling platform imports the wrong spreadsheet and overwrites a year of appointment notes. They contact support with a simple request: put our account back to how it looked this morning.
The platform has backups. Unfortunately, hundreds of other customers have made legitimate changes since morning. Restoring the shared database in place would repair one account by deleting everyone else's working day.
This is why a SaaS backup policy and a customer recovery feature are different deliverables. The first preserves data. The second decides how to reconstruct a coherent piece of a live business without damaging the rest of it.
Understand the recovery unit your infrastructure provides
PostgreSQL's continuous-archiving documentation explains that physical point-in-time recovery restores an entire database cluster rather than a subset. A shared application's tenant boundary does not automatically become a physical backup boundary. PostgreSQL point-in-time recovery
Logical tools offer other forms of selection, but still require understanding the application. PostgreSQL's dump documentation describes database snapshots and selective schema or table handling. A tenant whose rows span shared tables needs more than choosing a table name. PostgreSQL SQL dump guidance
Before promising an account-level restore, ask the development team to identify the actual recovery unit, the source of historical data and the application work required to reconstruct a tenant safely.
Map what belongs to a customer
An account may own appointments, notes, attachments, team memberships, preferences and audit records. Some objects are shared across accounts. Others reference global catalogues or external systems. A tenant identifier on the main table does not prove that every related row can be selected safely.
Document ownership and relationship rules. Include records created by background jobs, object-storage keys and search indexes. If two customers can share a user identity, restoring one customer's profile must not overwrite the user's access elsewhere.
This mapping is also a product design opportunity. Ambiguous ownership often makes exports, offboarding and support harder. Solving it for recovery can clarify those other features, provided each has its own permission and retention rules.
Recover into a separate environment first
One possible design reconstructs the historical database in an isolated recovery environment, then extracts the approved tenant scope. That environment needs its own access controls and should not send mail, process payments or connect to live business integrations merely because it contains production-like configuration.
The recovered application may need a historical schema or a carefully managed conversion to the current one. Record which version interprets the data. A row that made sense before a product migration may require transformation before it can re-enter today's application.
Treat the recovery workspace as sensitive. Limit who can access it, record the investigation and remove temporary copies according to the agreed procedure. The convenience of troubleshooting must not create a forgotten clone of all customer data.
Decide whether the customer wants rewind, repair or comparison
The original request may sound like a full rewind, but the customer often wants only the damaged notes restored. They may have created valid appointments after the mistake that should remain. Clarify the desired business result before changing live data.
A comparison view can show missing, changed and conflicting records. Let an authorised operator or customer representative review the proposed scope. Preserve the request, the chosen recovery point and the approval so the team can later explain why particular records changed.
For recurring mistakes, a targeted undo or import-version feature may be a better product investment than repeated manual recovery. The architecture should reflect how customers actually make errors rather than treating every incident as total destruction.
Keep external effects in the present
Restoring yesterday's appointment record does not unsend today's confirmation email. It does not cancel a payment or revoke a document already delivered to an external partner. Recovered data and external reality can disagree unless the workflow explicitly reconciles them.
Identify which identifiers and statuses must remain authoritative. An external payment reference, for example, may need to survive even when the associated description is repaired. Do not automatically replay all recovered jobs: that can repeat notifications or other business actions.
Use a recovery mode that suppresses unintended effects and produces a review list for genuine follow-up work. The person approving that list needs to understand the business consequence, not only the database operation.
Make the verification tenant-aware
Check referential consistency, file availability and important business totals for the recovered customer. Then prove that other tenants did not change. A restore script reporting success is not sufficient evidence of either outcome.
Test access permissions after recovery. An old snapshot may contain memberships that have since been revoked. Reintroducing those permissions can turn a data repair into an access-control incident. Separate historical content from current authorisation where the product requires it.
Our article on SaaS tenant isolation explains the boundary this work depends on. The practical disaster-recovery guide covers wider operational preparation.
Price the service you can actually deliver
Recovery time includes approval, historical reconstruction, comparison, import and verification. It is not simply the time required to download a backup. Measure the full process with a representative tenant and record how data volume affects it.
Agree the supported retention window, maximum scope, required customer authorisation and cases needing specialist review. If a recovery is a paid service, explain those terms clearly. If it is part of a premium plan, ensure support has the tooling and training to fulfil the promise.
A useful engineering pilot restores one deliberately damaged tenant while another continues normal work. Include attachments, later valid changes, a revoked user and a record linked to an external action. The handover should contain the evidence and the operator procedure.
TuniCyberLabs can build that capability into your custom SaaS platform. Discuss tenant-level recovery with your current tenancy model and the most common customer mistake. A credible recovery promise starts with proving that one account can be repaired independently.