Point-in-time recovery

SQLStyle writes full snapshots and incremental history from the application process to your S3-compatible object storage. A snapshot establishes a recovery base; incremental history records the transactions that follow it.

Restore planning combines the recovery state accepted by SQLStyle with the objects in your storage. It selects an exact recovery chain without trusting a stale local database catalog.

Backup and recovery history explains how DBH segments, snapshots, and the controller’s accepted frontier are produced.

How recovery history is accepted

Only the instance with current primary authority may advance the accepted recovery state. If authority moves during failover, fencing prevents a late upload or report from the former primary from extending that state.

The objects remain in storage you control. SQLStyle records which snapshot and incremental history are authoritative, then verifies sizes, checksums, and transaction coverage before materializing a database.

Latest and point-in-time recovery

Latest recovery selects the newest complete chain accepted by SQLStyle. Point-in-time recovery starts from a compatible snapshot and replays history only through the requested commit timestamp.

Both modes use the same inventory and verification commands. Selecting a time does not require the original application instance or its local database files.

Inspect recovery state

export SQLSTYLE_API_KEY='...'
export SQLSTYLE_STORAGE_SECRET_ACCESS_KEY='...'

sqlstyle database app/main recovery status

sqlstyle database app/main recovery inventory

status reports authoritative and recoverable frontiers, recovery-point information, and issues. inventory lists candidate snapshot and DBH objects.

Verify before restore

sqlstyle database app/main recovery verify \
  --mode plan

sqlstyle database app/main recovery verify \
  --mode checksum

--mode accepts plan, checksum, or full and defaults to plan.

Restore the latest accepted state

sqlstyle database app/main restore --latest

Without --output, SQLStyle writes app_main.sqlite in the current directory. It replaces / and \ with _ when that produces a portable filename. Names containing spaces, Unicode, or reserved or hidden components use unpadded URL-safe Base64 instead. SQLStyle never overwrites an existing file.

Choose another destination when needed:

sqlstyle database app/main restore \
  --output ./restored.sqlite

Point-in-time restore

sqlstyle database app/main restore \
  --at <unix-milliseconds> \
  --output ./restored.sqlite

Latest restore can begin from a raw SQLite snapshot or a DBH snapshot. Point-in-time restore requires a DBH snapshot base so replay can stop at the requested commit timestamp.

Progress and automation

Use --progress auto|plain|json|none. Progress is written to standard error; the final table or JSON result remains on standard output.

Use --out json or --json for scripts. Keep the database-scoped API key and object-storage secret out of command history by using environment variables or key files.

Safe deletion

Manual deletion is a preview unless --execute is provided:

sqlstyle database app/main recovery delete \
  --object <object-ref>

Execution rejects the entire requested batch unless every selected object is superseded by a surviving verified recovery plan. There is no force-bypass flag.