Deployment Manual4 min readReviewed 2026-05-15

Storage, Backup, and Disaster Recovery

DeskDox recoverability depends on coordinated backup of the database, document storage, generated artifacts, index data, licensing state, and operational configuration.

Storage Classes

Storage class	Examples / paths	Recovery importance
Database	PostgreSQL data directory or database dump	Critical system of record for metadata, users, roles, workflows, audit, settings, and jobs.
Uploaded documents	`/app/files`, Linux `/srv/edms/volumes/uploads`, Windows `DATA_ROOT/uploads`	Critical document repository.
Previews	`/app/data/previews`	Operational continuity; may be regenerable but can be expensive to rebuild.
OCR/index data	`/app/data/faiss`	Search, Emii, and retrieval performance; may be rebuildable but reprocessing time must be considered.
Backups	`/var/lib/deskdox/backups`, Windows `BACKUP_ROOT`	Must be protected and copied off-host or off-site.
Logs	Docker logs, host logs, reverse proxy logs	Required for operations, support, and audit investigation depending on policy.
Temporary processing	Converter, OCR, and backup temporary paths	Usually not retained; ensure sufficient capacity and endpoint security compatibility.
Licensing	`/var/lib/deskdox/licensing`	Required to preserve activation and licensing state.

Backup Scope

Production backup planning should include:

PostgreSQL database backup or dump.
Uploaded document binaries.
Preview artifacts where included in the continuity plan.
FAISS/search/index artifacts where included in the continuity plan.
Licensing directory.
Environment/configuration record sufficient to rebuild the deployment.
Backup metadata, timestamp, release tag, and restore notes.

The Windows deploy-kit backup.ps1 script creates a database.sql dump and copies uploads, faiss, and previews from DATA_ROOT into a timestamped backup directory. Restore through restore.ps1 recreates the target database and restores those file directories. This procedure is destructive and must be tested carefully.

Backup and Restore Flow

flowchart LR
    DB[("PostgreSQL")] --> Dump["Database dump"]
    Uploads[("Uploaded documents")] --> Package["Backup package"]
    Previews[("Preview artifacts")] --> Package
    Index[("FAISS and index data")] --> Package
    License[("Licensing state")] --> Package
    Dump --> Package
    Package --> OffHost["Off-host or off-site copy"]
    OffHost --> Target["Restore target"]
    Target --> RestoredDB[("Restored PostgreSQL")]
    Target --> RestoredFiles[("Restored files and artifacts")]
    RestoredDB --> Smoke["Application smoke tests"]
    RestoredFiles --> Smoke

Backup Retention

Retention must be defined by the customer. The application configuration includes daily, weekly, and monthly retention settings, but the final retention policy must also account for storage cost, legal/regulatory retention, off-host copy, and restore testing.

Off-Host and Off-Site Copy

Backups stored only on the application host do not provide sufficient disaster recovery protection against host failure, ransomware, storage corruption, or site loss. Production deployments should copy backups to customer-approved off-host or off-site storage.

The off-host copy mechanism may be a customer backup platform, storage replication, object storage, network share, or enterprise backup agent. The customer owns the durability and access controls of that backup destination unless covered by a separate managed service arrangement.

Restore Testing

Restore testing must validate:

Database restore.
Document file restore.
Preview/index artifact restore or accepted regeneration path.
Licensing state.
Application startup after restore.
Login, upload, preview, search, workflow, email, and audit smoke tests.

Production deployments should include a restore validation exercise before go-live. If restore testing is deferred, the decision should be recorded in the deployment handover notes with the reason, owner, target validation date, and interim recovery approach.

DR Server Assumptions

A disaster recovery server is not automatically created by the current compose package. If the customer requires a standby environment, it must be designed separately and must include:

Compatible DeskDox release/image tag.
Compatible environment configuration.
Restorable database target.
Restorable document and artifact paths.
DNS cutover or alternate access plan.
License/activation handling.
Backup access permissions.
Defined RPO/RTO.

RPO/RTO Planning

Objective	Planning impact
RPO	Determines backup frequency, replication needs, and acceptable data loss.
RTO	Determines restore automation, standby readiness, database size limits, and staffing.
Retention	Determines backup storage capacity, off-site copy volume, and archive lifecycle.
Restore confidence	Requires scheduled restore validation and documented recovery procedures.

Backup and DR Readiness Checks

Before go-live:

Backup location and retention are documented.
Initial backup completes successfully.
Backup includes required data classes.
Backup encryption key handling is documented.
Off-host/off-site copy is configured or the deferral is recorded in handover notes.
Restore validation is completed or a follow-up validation plan is recorded.
RPO/RTO are documented with operational owners.