Headless recovery and rollback

Stop before restore

Obsidian Headless does not document history, exact-version read, or restore commands. Recovery depends on a recoverable backup plus documented desktop/Sync recovery or a separately verified provider workflow.

Before any risky change

• Back up the source before setup, config changes, continuous mode, unlink, or destructive mode.
• Record source and destination status, file inventories, hashes, conflict records, and deletion records.
• Name the rollback owner and exact restore scope.

Sync incident

1. Stop the supervised continuous process.
2. Preserve status, inventories, logs, conflicts, deletions, and unexpected files.
3. Do not keep retrying an unchanged failing configuration.
4. If mirror-remote reverted local edits or pull-only ignored a writer's changes, restore from the approved backup only after exact scope approval.
5. Route exact-version recovery through desktop sync:history, sync:read, sync:restore, local File Recovery, or a separately verified provider workflow.
6. Repeat source/destination status and second-device exact content/hash readback.

Publish incident

1. Stop further publication and preserve the dry-run, source commit/hash, prior public URL, and release receipt.
2. Restore the prior approved source state.
3. Perform a new reviewed dry-run.
4. Republish or remove content only under exact approval.
5. Verify the public URL and expected content/hashes.

Unlink or account incident

ob sync-unlink, ob publish-unlink, and ob logout mutate stored linkage or credentials. Stop and obtain exact approval before using them. Preserve the approved account alias, mapping, path, and rollback owner without recording credential values.

Database rule

Never copy a live writable SQLite database between devices. A quiesced database backup requires a separately approved workflow; routine projection uses supported sync, exports, immutable receipts, or Git objects.

Sources: Desktop CLI, Headless Sync, and Headless Publish, retrieved 2026-08-29 EDT.