# AtoCore Backup Strategy

## Purpose

This document describes the current backup baseline for the Dalidou-hosted
AtoCore machine store.

The immediate goal is not full disaster-proof automation yet. The goal is to
have one safe, repeatable way to snapshot the most important writable state.

## Current Backup Baseline

Today, the safest hot-backup target is:

- SQLite machine database
- project registry JSON
- backup metadata describing what was captured

This is now supported by:

- `python -m atocore.ops.backup`

## What The Script Captures

The backup command creates a timestamped snapshot under:

- `ATOCORE_BACKUP_DIR/snapshots/<timestamp>/`

It currently writes:

- `db/atocore.db`
  - created with SQLite's backup API
- `config/project-registry.json`
  - copied if it exists
- `backup-metadata.json`
  - timestamp, paths, and backup notes

## What It Does Not Yet Capture

The current script does not hot-backup Chroma.

That is intentional.

For now, Chroma should be treated as one of:

- rebuildable derived state
- or something that needs a deliberate cold snapshot/export workflow

Until that workflow exists, do not rely on ad hoc live file copies of the
vector store while the service is actively writing.

## Dalidou Use

On Dalidou, the canonical machine paths are:

- DB:
  - `/srv/storage/atocore/data/db/atocore.db`
- registry:
  - `/srv/storage/atocore/config/project-registry.json`
- backups:
  - `/srv/storage/atocore/backups`

So a normal backup run should happen on Dalidou itself, not from another
machine.

## Next Backup Improvements

1. decide Chroma policy clearly
   - rebuild vs cold snapshot vs export
2. add a simple scheduled backup routine on Dalidou
3. add retention policy for old snapshots
4. optionally add a restore validation check

## Healthy Rule

Do not design around syncing the live machine DB/vector store between machines.

Back up the canonical Dalidou state.
Restore from Dalidou state.
Keep OpenClaw as a client of AtoCore, not a storage peer.