---
title: Back up and restore your deployment
label: Backup and restore
description: Protect the database, identity keys, and both content volumes, then rehearse recovery.
layout: docs
order: 143
---

## Define the recovery set

A complete recovery set includes the released image reference and digest, database and managed identity archive, `/received`, `/outbound`, and any externally configured certificates and deployment secrets.

The System page's scheduled and manual archives contain the SQLite database and VOTPort-managed identity files: cookie secret, receipt signer, native-push issuer, and generated push certificate/key. The database includes any access keys, session tokens, and peer receive-link credentials saved through **Storage**; protect both full archives and database-only snapshots accordingly. They exclude content volumes, staging data, existing backup archives, and externally configured certificate files.

Back up `/received` and `/outbound` separately, including named tenant subdirectories. Keep the database and file backups consistent with one another.

## Configure scheduled archives

In **System**, select a local destination, an S3-compatible destination, or both. A blank local path uses `/data/backups`. A custom path is inside the service's filesystem: mount the host directory there first and make it writable by the container user. Its ancestors must satisfy the private-path safety checks.

VOTPort prunes the archives it created under those destinations, not unrelated objects. Set retention to your recovery requirements and inspect the reported backup status. Optional secrets left blank remain unchanged; the UI reports whether a credential or passphrase is configured without returning its value.

Keep an independent recovery copy of the encryption passphrase. Encrypted archives cannot be recovered without it.

## Database replication

The separate **Download snapshot** action produces a consistent database-only copy. It does not include identity keys or content files and is not a complete disaster-recovery archive.

For a smaller database recovery-point interval, an operator can run Litestream or another qualified WAL replication mechanism. Mount the database at the path used by that tool and restore it before starting VOTPort. Database replication still does not protect the content volumes or identity files.

## Restore an archive

1. Stop admitting transfers and record the current image reference.
2. Preserve a recovery copy of the existing deployment.
3. Select and validate the archive using **System / Restore**. VOTPort stages the archive and requests a supervised restart.
4. Restore the corresponding received and outbound file backups using your storage tooling.
5. Start the matching released image. Without a service supervisor, stop and start the process manually to apply the staged restore.
6. Verify `/healthz`, sign in again, and exercise known Receive and Deliver links. Compare a restored file with its receipt.
7. Re-enter and enable backup destinations after accepting the restored deployment.

The installer retains a private rollback directory under `/data` while replacing managed files. Later initialization can still fail; keep that directory until the restored service is accepted. Do not unpack archive members over a live database or copy a live `-wal` file over the restored database.

Restoration rotates the administrator cookie key and signs out existing sessions. Restored backup destinations are cleared and automatic backups are disabled so historical destinations do not receive new data unexpectedly.

## Rehearse recovery

Periodically restore into an isolated instance using the complete recovery set. Measure how much data can be lost between backups and how long recovery takes. Include identity pinning, file availability, permissions, and a real transfer in the rehearsal.