A preview demonstrates a candidate
A preview lets a reviewer inspect a specific release with controlled data and external effects. It may be intentionally incomplete as a copy of production, because real payment and messaging connections should not run casually during review. A beautiful preview is evidence about that environment. It is not proof that the latest production database or uploaded files can be recovered.
A backup must support restoration
A backup is useful when the necessary code, data and configuration can be restored into a usable system. List what is included, the capture time and who can access it. Keep credentials and customer data protected. A backup task reporting success does not establish that the restore procedure works; a controlled restoration exercise answers a different and more valuable question.
A rollback must account for consequences
Reverting code may be simple while reversing data changes is not. A new schema, a sent message or an external payment cannot be assumed to disappear with an older application release. Define the rollback boundary before deployment and choose reversible steps where possible. If an action cannot be reversed automatically, name the manual process and the responsible decision-maker.
Test the right promise
For a hosting choice, ask which copies are kept, for how long, and what restore work is included. For a deployment, ask which release is approved and how new writes are handled. For a preview, ask whether the scenario matches the requirement. Forge keeps these concerns in one lifecycle without pretending that one screenshot or one archive proves all three.
A working copy is for change; a backup is for recovery
A preview contains a particular application version and an intentionally chosen dataset. It may omit recent production records, files or secrets. A backup policy has a different job: provide recoverable data within a defined scope and time window. Calling a preview a backup hides those differences.
For a hosted portal, identify the database, uploaded documents, configuration and any external storage. Decide how often they are copied, how long versions are retained and what restore procedure is available. Recovery must be tested in isolation; the presence of an archive alone does not prove that the application can start from it.
| Decision | Useful requirement | Evidence |
|---|---|---|
| Preview | Inspect an intended change. | Version and selected test data. |
| Backup | Retain a recoverable point in time. | Scope, timestamp and integrity record. |
| Restore | Prove a recovery procedure works. | Isolated application and data checks. |
Where this goes wrong
A restore may invalidate newer activity if applied without a reconciliation plan. Keep recovery authority separate from a routine preview review, and never send restored test messages to real customers as a side effect.
Ask what can be restored and what can be reversed; they are different questions.
Turn it into a working checklist
- Define the purpose of each environment.
- Record backup scope and time.
- Test restoration separately.
- Write a consequence-aware rollback plan.
A concrete next step
Write a recovery scope card listing included data, retention, responsible operator and tested procedure. Link it to the hosting service without claiming an unverified recovery-time guarantee.
Watch a related case
The video could not be loaded. Try again later.