---
title: "Point-in-time recovery"
description: "Build recovery history in your object storage, verify it, and restore SQLite to the latest accepted state or an earlier point in time."
section: "Guides"
source_url: "https://sqlstyle.com/docs/restore-and-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](/docs/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

```sh
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

```sh
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

```sh
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:

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

## Point-in-time restore

```sh
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:

```sh
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.