Backup Procedure

Velnode Browser  ·  a product of Dignity New Zealand Limited

_{Operations  |  Version 1.0  |  Last updated 2026-05-28}

Backup Procedure

Document type: Operations Owner: Dignity New Zealand Limited Applies to: Velnode Browser v1.10 and later Last updated: 2026-05-28 Document version: 1.0 Status: Approved

Purpose

This document is the canonical procedure for backing up the development tree, the user state, and the release artefacts of Velnode Browser, a product of Dignity New Zealand Limited. Two audiences read it: the maintainer at Dignity New Zealand Limited before risky changes, and any end user who wants a portable snapshot of their Velnode state.

Scope

Three backup surfaces are in scope:

1. The maintainer development tree, including all source code, design documents, the canon manifest, and the roadmap.
2. The end-user local state, the data/ folder on a user's device.
3. Release artefacts, the signed installers for each shipped semver.

1. Backup principles

• Backups are explicit. Velnode does not silently upload anything to a backup service.
• Backups are local to begin with. A snapshot starts as a folder on the same device, then can be copied off.
• Backups are numbered, not timestamped. A numbered series is easier to reason about ("restore Backup-12") than a timestamp series.
• Backups are immutable. Once a backup is taken, do not edit inside it. Take a new backup instead.

2. Maintainer development backup

The repository carries a velorabrowser_stable_backup/ folder with numbered subfolders Backup-0, Backup-1, … each containing a snapshot of the working tree at the time of capture.

When to take one

• Before any change that touches main.js, preload.js, the canon manifest, or the AI / voice / permissions path.
• Immediately before sealing a MINOR or MAJOR release per the Release Procedure §3 step 4.
• Before running a refactor that crosses multiple canon files.

How to take one

Use the project's /velora-backup skill or follow the manual sequence:

1. Confirm the working tree is clean (git status).
2. Determine the next snapshot number (next available Backup-N folder name).
3. Copy the working tree, excluding node_modules/, velorabrowser_stable_backup/, and .git/ into the new snapshot folder.
4. Append an entry to backup_info.txt with the snapshot number, the commit SHA, the timestamp, and a one-line reason.
5. Commit nothing during the backup; the snapshot is content, not history.

How to restore one

1. Confirm the working tree is clean.
2. Copy the snapshot back over the working tree.
3. Re-run the canon hash audit and confirm MATCH.
4. Run npm test to confirm the restored state is functional.
5. Append a restore entry to backup_info.txt.

3. End-user local-state backup

A Velnode user can back up their state by copying the data/ folder out of the Velnode install directory to a safe location.

What to copy

The full data/ folder. Specifically: timeline.json, semantic-memory.json, bookmarks.json, notes.json, settings.json, command-pins.json, mindmap.json, and plugins-enabled.json. See Data Handling for the inventory.

When to back up

• Before reinstalling Velnode.
• Before moving Velnode to a new device.
• Before deleting timeline.json to start fresh.
• On a personal cadence that matches the value of the data — weekly is reasonable for active users.

How to back up

1. Quit Velnode.
2. Open the install directory in your OS file manager.
3. Copy the entire data/ folder to a backup location — an external drive, a cloud sync folder you trust, an encrypted USB stick.
4. Note the date in whatever way you remember things.

How to restore

1. Quit Velnode.
2. Replace the existing data/ folder with the backup copy.
3. Relaunch Velnode.

There is no risk in this restore: the files are plain JSON, the schema is stable, and Velnode will simply load what is there.

Cross-device export (planned)

Phase 9 introduces a verified export-bundle format and a verified import on a new device. Until that ships, the manual data/ copy described above is the supported path.

4. Release artefact backup

For each shipped semver, the following artefacts are retained:

• The signed installer for each platform.
• The release notes.
• The canon manifest at the moment of sealing.
• The engineering-history entry for the release.

Retention is for the life of the project. Artefacts are stored alongside the project repository under a releases/ path; the directory is not committed to main if it carries large binary blobs but is mirrored in the build pipeline's artefact store.

5. Roles

6. Restore drill

A backup is not real until it has been restored. Twice a year, perform a restore drill:

1. Choose a recent Backup-NN snapshot.
2. Restore it in a scratch directory.
3. Run npm test.
4. Run the canon hash audit.
5. Note the result in backup_info.txt.

A drill that fails is a Critical issue and feeds into the Incident Response procedure.

7. Records

backup_info.txt at the repository root records every backup and every restore. Each entry is:

Backup-N | <SHA> | <timestamp> | <reason>
Restore-N→working | <SHA> | <timestamp> | <reason>

The file is append-only by convention.

8. Review cadence

This document is reviewed every Velnode major release and after each restore drill.

9. Contact

Dignity New Zealand Limited Email: [email protected]

Document maintained by Dignity New Zealand Limited. Questions: [email protected].