The short answer
A useful backup is a copy you can restore into a working, inspectable knowledge system.
Identify the files that matter, separate source knowledge from rebuildable indexes, and run an isolated restore drill before relying on a backup.Know what you need to recover
Which parts of your knowledge system could you replace if you lost the working copy? Source files, authored notes, graph data, configuration and indexes have different recovery needs. Some records are irreplaceable. Others can be rebuilt, provided you still have the inputs and compatible tools.
Begin by asking what you would need after losing the working machine. Include the installed release and the instructions required to restore it, while handling credentials through your established secret-management process rather than placing them in a public archive.
List what you would need to restore
| Material | Recovery question |
|---|---|
| Approved source files | Are original attachments and media included? |
| Authored knowledge and relationships | Which records cannot be recreated automatically? |
| Configuration and release version | Can the same workflow be installed again? |
| Derived indexes | Can these be rebuilt from the retained inputs? |
| Restore instructions | Can someone follow them without the lost machine? |
Check excluded files and storage outside the obvious project directory. A script that says "backup complete" may only report that it copied the paths it was given.
Do not equate Git history with a complete backup
A repository can preserve tracked text and history, but it does not automatically contain ignored files, untracked attachments or every external object. Git's bundle documentation describes packaging repository objects and references. A Git bundle covers those repository objects and references. It does not back up your entire machine or workspace.
If you use Git, list what is tracked and what is stored elsewhere. Treat remote synchronization as a separate question: a deletion or damaged file can propagate to a synchronized destination. Choose retention and recovery behavior deliberately.
Run an isolated restoration drill
- Make a dated backup using your supported process and record its scope.
- Restore into a separate directory or test environment; do not overwrite the active workspace.
- Install the recorded compatible tools and restore configuration without exposing secrets.
- Rebuild derived indexes through the supported workflow where required.
- Ask several known-answer questions and inspect their source links.
- Check a changed fact and a missing-evidence question, then record the result.
This is a proposed test procedure. A successful file-count comparison is useful, but a retrieval check can reveal missing source paths or configuration that counts alone miss.
Record the age of the backup and time to restore
Record how old the most recent restorable copy is and how long the drill takes. These observations help you choose backup frequency and determine whether the process fits your work. Do not set a recovery promise from an untested estimate.
Revisit the drill after moving storage, changing the graph format or upgrading the retrieval tools. A previously valid backup can require different restoration steps after the surrounding environment changes.
Account for maintenance when comparing products
Local knowledge gives you practical control over files and copies, along with responsibility for preserving them. Gigabrain's operating-model guide explains that tradeoff. Package updates do not replace a backup policy.
Download the restore checklist. Read the setup requirements before comparing packages. Gigabrain includes the knowledge system and retrieval tools. You look after the local files and backups.
