docs: fix drift in Backup & Recovery

[jack-arturo]

Routine docs-accuracy audit. First review of this page — no prior review state existed for operations/backup.

Claim	Current state	Fix	Evidence
--cleanup --keep 7 "deletes backups older than 7 days"	--keep is a count of files, not an age. cleanup_old_backup_files() sorts each store's *.json.gz by mtime and unlinks everything past index keep	Comment rewritten to "keeps the 7 most recent backup files per store"	automem@42ba8b6:automem/backup.py#L331-L342, scripts/backup_automem.py#L237-L243
"The --cleanup --keep N flag removes backups older than N days based on filename timestamp parsing"	Same function again: ranking is by p.stat().st_mtime; the filename timestamp is never parsed for retention	Sentence rewritten to describe the real behaviour (N most recent per store, by mtime) and note the default of 7	automem@42ba8b6:automem/backup.py#L334-L339
Env table marks FALKORDB_PORT and FALKORDB_PASSWORD as Required: Yes (while also giving FALKORDB_PORT a default)	Both are plain os.getenv reads with no requirement check — port defaults to 6379, password defaults to None. AUTOMEM_BACKUP_DIR is read by the script but absent from the table	Both rows set to Required: No (password annotated as needed only for password-protected instances); AUTOMEM_BACKUP_DIR row added	automem@42ba8b6:scripts/backup_automem.py#L56-L64
"The FalkorDB export captures the entire Redis keyspace including … Metadata and indices"	export_falkordb_artifact() runs paged MATCH (n) / MATCH (a)-[r]->(b) Cypher queries and gzips a JSON object {timestamp, graph_name, nodes, relationships, stats}. No Redis keys and no index definitions are captured	Replaced with the actual object shape and an explicit note that indices are not exported	automem@42ba8b6:automem/backup.py#L117-L169
"Each Qdrant backup contains an array of point objects"; integrity check zcat … | jq 'length'	export_qdrant_artifact() writes an object {timestamp, collection_name, points, stats}. jq 'length' on that returns 4 (the key count), not the memory count	Described as an object with a points array; the jq example now reads .stats.points_count and .points | length	automem@42ba8b6:automem/backup.py#L231-L246

Verified against: verygoodplugins/automem@42ba8b6

Checked and found accurate, left unchanged: every backup_automem.py and restore_from_backup.py flag shown on the page (--backup-dir, --s3-bucket, --cleanup, --keep, --backup-timestamp, --qdrant-only); the falkordb_<ts>.json.gz / qdrant_<ts>.json.gz naming and backups/<store>/ layout; the S3 key prefix automem-backups/<store>/<file>; health_monitor.py --auto-recover being a CLI flag with no env-var equivalent; recover_from_qdrant.py's restore_memory_to_graph_only() and the exact RESERVED_FIELDS set; scripts/cleanup_memory_types.py; the backup workflow's 6-hour cron and its full secret list.

Questions

• The GitHub Actions sequence diagram names the S3 bucket my-automem-backups, but backup.yml runs --s3-bucket automem-backups. Read as a placeholder it is fine, read as a diagram of that workflow it is wrong. Not changed — the bucket is user-chosen and the rest of the page uses the same placeholder consistently.
• The same workflow runs --cleanup --keep 14, which the page never states. The Layer 3 diagram says "Last 7-14 backups", which is compatible but vague. Left alone rather than guessing at intent.

Unverified

None — every code-anchored claim on this page resolved to current source.

Follow-ups

• The restoration sequence diagram still says "Parse JSON array json.load()", the same array-vs-object error fixed in prose above. Left to keep this PR at the 5-fix cap.
• The page's source-note permalinks are pinned to automem@57264a9; they still resolve, and no link on the page was touched by this PR.

---

Generated by Claude Code

[cloudflare-workers-and-pages]

Deploying automem-website with    Cloudflare Pages

Latest commit:	a214484
Status:	✅  Deploy successful!
Preview URL:	https://d5a7bf70.automem-website.pages.dev
Branch Preview URL:	https://docs-audit-operations-backup-nd44.automem-website.pages.dev

View logs