Correct doc and help sentences that are false about the code (closes #233)
check / check (push) Waiting to run

A blob is written in full to a temporary file in $TMPDIR and uploaded
once finished, not streamed to storage; the README and
config.example.yml now say a backup needs about blob_size_limit of free
space there. Also corrected: the snapshot ID format, what restore reads
and how incomplete snapshots are removed in docs/DATAMODEL.md, what
source_path is for, the index_path default, the config search order in
the snapshot create help, what snapshot remove cleans up in the prune
help, how the release installs Go, and the script/release and
script/fmt-check comments.

The source_path claim is also corrected in models.go, scanner.go and
001.sql, which the issue did not list.

Model: opus-5-5
This commit is contained in:
2026-10-07 12:35:07 +00:00
parent 8b22ae8d42
commit adfa7ac6ff
13 changed files with 59 additions and 41 deletions
+5 -6
View File
@@ -111,7 +111,7 @@ Maps chunks to the blobs that contain them.
Tracks backup snapshots.
**Columns:**
- `id` (TEXT PRIMARY KEY) - Snapshot ID (format: hostname-YYYYMMDD-HHMMSSZ)
- `id` (TEXT PRIMARY KEY) - Snapshot ID (format: `hostname_name_timestamp`, e.g. `server1_home_2025-06-01T12:00:00Z`: the hostname up to its first `.`, the snapshot name, and an RFC 3339 UTC timestamp)
- `hostname` (TEXT) - Hostname where backup was created
- `vaultik_version` (TEXT) - Version of Vaultik used
- `vaultik_git_revision` (TEXT) - Git revision of Vaultik used
@@ -218,8 +218,8 @@ The `{remote-key}` directory name is a one-way hash of the human snapshot ID, so
### 4. Restore Process
The restore process doesn't use the local database. Instead:
1. Downloads snapshot metadata from S3
2. Downloads required blobs based on manifest
1. Downloads and decrypts the snapshot's metadata database (`db.zst.age`) from S3
2. Downloads the blobs holding the chunks of the files being restored, found through that database's `blob_chunks` table; the manifest is not read
3. Reconstructs files from decrypted and decompressed chunks
### 5. Pruning
@@ -232,9 +232,8 @@ The restore process doesn't use the local database. Instead:
Before each backup:
1. Query incomplete snapshots (where `completed_at IS NULL`)
2. Check if metadata exists in S3
3. If no metadata, delete snapshot and all associations
4. Clean up orphaned files, chunks, and blobs
2. Delete each one and all its associations, without checking S3 for its metadata
3. Clean up orphaned files, chunks, and blobs
## Repository Pattern