Before you begin
- An agreed purpose for the service and someone authorized to make operating decisions.
- A list of the applications, accounts and external services you already use or intend to use.
- Access to configuration and backup records, with secrets kept in their approved store.
- A second maintainer who can review the map and identify missing information.
Begin with a member's ordinary task
Our running example is an illustrative workshop notebook: members edit instructions, attach diagrams and keep a private book of organizing notes. The group chooses BookStack for the example; this is a planning choice, not an installed application supplied with a VPS. Use your own application and exact installation records when filling the sheet.
Describe the service as something a person can do: “An authorized member can find the current repair instructions and open their attachments.” Then list what is outside its scope. In this example, the wiki does not hold the group's only copy of its recovery instructions or credential records.
| Field | Workshop notebook entry |
|---|---|
| Purpose | Shared instructions and private organizing notes. |
| Accountable maintainer | Notebook coordinator; a second authorized coordinator covers absence. |
| Service address | notes.example.org, an example hostname to replace. |
| Recovery priority | Restore reading and attachments before allowing edits; reconnect notifications last. |
Give each dependency its own row
Walk through signing in, opening a page, uploading a diagram and receiving a notification. For each action, ask which component stores information or talks to another system. BookStack's backup guide identifies the database, configuration, uploaded images, attachments and any custom themes as recovery ingredients. Record their actual locations rather than assuming the application directory contains everything. BookStack backup requirements.
| Component | Record to keep | Failure question |
|---|---|---|
| Wiki application | Installed version, installation method and configuration reference. | Can the cover maintainer reproduce this version? |
| Database | Engine/version, database name, backup method and access reference. | Can it be restored without contacting the original host? |
| Attachments | Storage paths, backup selection and one harmless witness file. | Does a restored page still open its diagram? |
| DNS and HTTPS | Who controls the domain, how records change and where configuration lives. | Can the group regain the normal address? |
| Outgoing email | Selected relay, authorized account owner and a safe test destination. | Which member actions fail or become silent if delivery stops? |
| Scheduled work | Each configured job, trigger, owner and failure evidence. | Would a restored copy repeat an external action? |
Email and webhooks deserve separate entries. BookStack can process them in the background when configured with a queue worker; a page loading successfully does not establish that those jobs ran. BookStack email and background action documentation.
Mark the information that needs different treatment
“The wiki is private” is too broad to guide a restore or export. In the notebook example, published repair instructions may be shared outside the group, organizing notes remain member-only, and administrative recovery material belongs in restricted storage outside the wiki. Decide which category each collection belongs to before moving it.
- Content: identify who may read, edit, delete and export each collection.
- Member records: record why the service needs them, who reviews them and how departures are handled.
- Operational records: list logs, backup reports and retained exports, including a review or deletion rule.
- Secrets: write a retrieval reference and authorized custodian, never the credential value.
Give backup copies and restore environments an access decision too. A copy of a private book remains private even when it sits in a temporary directory. If one row combines public pages and restricted notes, split it until the distinction is useful.
Write the order of recovery and the acceptable gap
Agree how much recent editing the group could recreate and how long it could work from an offline reference copy. These are requirements to discuss, not recovery times established by this guide. Translate them into a backup schedule, an independent destination and an exercise that can test the proposed method.
- Recover the instructions and authorized access needed to start the work.
- Rebuild a separate environment with the recorded software versions.
- Restore the database, files and configuration as a matching set.
- Check reading, permissions and a witness attachment before permitting changes.
- Reconnect the normal address and external actions only after a controlled return decision.
Keep the current backup selection, its timestamp and the most recent actual drill result beside this order. Where no drill has happened, write “not yet exercised.” An inventory of intended copies cannot establish that those copies are usable.
Copy a blank service record
Keep this worksheet somewhere both authorized maintainers can reach when the VPS is unavailable. Link to detailed instructions instead of turning the record into a second, stale installation manual.
Service / member task:
Primary maintainer / cover maintainer:
Normal address / domain account custodian:
Application and database versions:
Data paths / backup selection:
Public, member-only and restricted collections:
External services / scheduled actions:
Credential store references and authorized custodians:
Acceptable data gap / recovery priority:
Independent backup destination:
Last actual restore result / unresolved action:
Next review trigger / owner:Let another maintainer find the gaps
Ask the cover maintainer to trace one attachment from its page to storage and backup, locate the domain account reference, and explain how email would be disconnected during recovery. Let them mark every place that requires an unwritten assumption. Assign each gap an owner; an unknown backup path is work to finish, not an empty cell to hide.
Review the record after a new integration, changed storage location or maintainer handover. It is a navigation aid, not proof of capacity, security or successful restoration. Turn its recovery section into a restore rehearsal, then use the shared wiki service plan to decide which supporting components are worth operating.
Documentation behind this note
Use the documentation for the version you actually run. These examples are planning material, not a record of a test on a Hoszen VPS.