A successful database export answers a narrow question: can the database be copied? It does not answer whether the application can be recovered after the original machine disappears.
For a small self-hosted business application, the missing pieces are often mundane: the encryption key, the exact application release, the database roles, or a background worker that resumes sending messages as soon as the restored system starts.
This article proposes a recovery drill that treats those dependencies as part of the application. Rechvix, a public Go/PostgreSQL business-software project, provides the concrete starting point. The drill below is a proposed operator checklist, not a report of a disaster-recovery test performed for this article.
Start with the dependency you cannot regenerate
Rechvix's public README tells CasaOS operators to preserve both its PostgreSQL data and its secrets directory. Its deployment document identifies an application encryption key used for encrypted stored values and encrypted backup archives. A fresh key may let a new application start; it does not decrypt data written with the old one.
That distinction changes how a recovery plan should be written. “Generate secrets on first boot” is useful installation behavior. “Generate replacement secrets during recovery” can be the wrong operation.
For each persistent component, record the dependency and two recovery facts:
| Component | What must survive? | What proves recovery? |
|---|---|---|
| Database | A consistent backup and its recovery instructions | Known records and relationships can be read |
| Encryption material | The original key, held in a protected recovery location | Previously encrypted application data remains usable |
| Release configuration | Version, schema expectations and non-secret settings | The restored release starts against the intended schema |
| Background work | Queue state and delivery configuration | Pending work is understood before external delivery resumes |
Keep secret values out of the manifest itself. The manifest can say where an authorized operator retrieves a key without becoming another unprotected copy of that key.
Define success before opening the backup
A login screen is a weak recovery test. It can appear while important business relationships remain broken.
Choose a small set of reference records in a dedicated test installation. For an invoice-and-inventory system, a useful fixture is one finalized invoice, its accounting entries, its stock movements and a customer payment. Record identifiers and expected totals before taking the backup.
After restoring, verify the same relationships. Can the invoice still be rendered? Does the payment allocation still point to the expected document? Do the recorded stock movements explain the balance? Are posted amounts unchanged?
This is not a substitute for full integrity testing. It is a compact way to distinguish “the server responds” from “a representative business workflow survived.” Use synthetic records for an article or public demonstration; production customer data does not belong in screenshots or published recovery logs.
Restore somewhere that cannot act as production
A recovery copy can accidentally become a second production sender. The danger is especially easy to miss when scheduled reminders, webhooks or payment integrations share the same database.
Start the exercise in a separate environment with outbound delivery blocked or routed to test services. Do not assume that changing the public hostname disables background delivery. List every component capable of sending externally, including workers.
Restore there first. Keep the original installation intact. The point of the drill is to learn what recovery needs without turning the exercise into an outage.
Avoid copying a destructive restore command from a generic blog post. The exact steps depend on the backup format, release and deployment method. In particular, an application's whole-instance restore may replace records for more than one organisation. Check scope before running it.
Check the database identity as well as the data
Rechvix's deployment guidance separates the schema-owning migration role from the ordinary runtime role. Its README also warns that connecting as a table owner can bypass row-level security.
That makes role restoration a functional and security concern. If an operator fixes a restored application's permissions by giving it the migration owner's connection string, the UI may work while its isolation assumptions have changed.
A useful acceptance check has two sides: the runtime account can perform expected operations, and it cannot read another tenant's records. Run that check through the real application context or a documented test harness, rather than assuming a successful administrative database query proves isolation.
Measure a usable recovery, not just import time
Record the age of the recovered backup and the time until the reference workflow is usable. Those are different measurements.
A ten-minute import can still leave hours of work to recover the key, locate the matching release, rebuild roles and reconcile queued deliveries. Conversely, a quick recovery from an old backup may lose more recent work than the business can accept.
Keep a short drill log:
- Backup timestamp and application version.
- Restore start and completion times.
- Time the reference workflow passed.
- Encryption and tenant-isolation checks: pass, fail or not tested.
- External delivery state and remaining manual steps.
A field marked “not tested” is useful information. It identifies the next exercise instead of hiding an assumption inside a green status.
Treat documentation conflicts as findings
The Rechvix deployment page includes older stage-specific descriptions alongside newer backup and configuration sections. The current README describes a broader shipped application. That is a reason to verify instructions against the exact release, not to merge every statement into one confident installation guide.
Save the documentation revision used for the drill. When instructions disagree with the release, record the mismatch and resolve it before applying them to production.
The deliverable from a recovery exercise is more than a restored database. It is a repeatable path from a known backup to a usable, correctly isolated application, with the remaining gaps written down.
Sources and scope: Rechvix README and deployment and recovery documentation, reviewed on October 24, 2026. No recovery timing, compliance certification or production restore result is claimed here.
About the project: I maintain Rechvix through NodeDR. The drill above is a proposed checklist, not a report of a completed recovery test.
Top comments (0)