Skip to main content

Backup and restore

A Jiandu backup is complete only when it can restore the database and every referenced original to a coherent point in time.

What to protect​

  • the SQLite database or a consistent PostgreSQL backup;
  • the local blob root, S3 bucket/namespace, or WebDAV collection;
  • the effective secret-free configuration;
  • protected secret files through your normal secret backup process;
  • the owner recovery token, stored separately as break-glass material;
  • the Jiandu version or source revision needed to understand the backup.

Do not place the only recovery token inside the only Jiandu backup.

A dependable routine​

  1. Quiesce changes or use the database/storage consistency method documented for your deployment.
  2. Create a new backup rather than overwriting the last known-good copy.
  3. Record the Jiandu version and time.
  4. Verify checksums and archive readability.
  5. Restore into a new, empty and unpublished destination.
  6. Start it on an isolated origin.
  7. Sign in, search, and open representative originals, including a restricted document.
  8. Record the result and keep the tested restore until the next successful drill.

Restore safety​

Jiandu refuses to restore over an ambiguous live target. The destination must be an explicit path that does not exist, or an empty unpublished database as required by the selected operation. If a restored database remains explicitly unpublished, use a new empty target for another attempt.

If archive integrity verification fails, keep the damaged archive unchanged for investigation and restore the previous verified backup.