Skip to main content

Backup Retention and Restore

What Dralvia keeps locally by default​

Dralvia keeps a short local window of database backups on the host for fast recovery. The default local retention policy is:

  • keep backups no older than 3 days
  • keep only the 1 newest local database dump
  • sanitize scan_job.result_json and scan_result.scan_json in the backup stream so scan-history backups keep durable metadata but not raw scanner payload blobs

This default is intentionally small. Daily database dumps can become large enough to exhaust the root disk if they are kept locally for long periods.

Scan-history backup behavior​

For links and websites scan history, local database backups preserve the durable history rows but do not keep the raw scanner detail payloads in the backup artifact:

  • scan_job.result_json is exported as NULL
  • scan_result.scan_json is exported as NULL

That keeps the backup aligned with the long-term retention model:

  • URL / domain
  • timestamp
  • score
  • risk level
  • flags
  • ownership / public identifiers
  • operational status fields

Recent raw scanner payloads still exist in the live database during the short evidence window, but they are not copied into the local backup dump.

What happens after each backup​

After each backup run, Dralvia rotates old local database dump files in BACKUP_DIR and removes files that are either:

  • older than the configured RETENTION_DAYS value
  • beyond the configured BACKUP_KEEP_COUNT newest local files

Rotation also runs on failed backup days, so a misconfigured encryption or offsite setting does not allow old dumps to accumulate forever.

The recommended daily order is:

  1. run phish-scan retention / raw-payload trimming
  2. run the database backup after the trim window
  3. rotate older local backup artifacts

When to increase retention​

Increase RETENTION_DAYS or BACKUP_KEEP_COUNT only if all of the following are true:

  • Offsite backup sync is configured.
  • Restore drills have been completed successfully.
  • The host has enough free disk for the larger local window.

If those controls are not in place, keep the local retention short and treat the host as a staging point, not the long-term archive.

Offsite backup posture​

Dralvia supports encrypted offsite backup storage. The default local backup window is short so the host does not become the only long-term archive.

For hosted workspaces, Dralvia handles backup operations. Customers do not need to run backup commands or manage backup keys.

For self-hosted deployments, keep encryption enabled before moving backup artifacts off the host. Store the encryption secret outside the host and verify at least once per month that a copied backup can decrypt and pass an integrity check.

Dralvia also supports a monthly encrypted offsite bundle for self-hosted operators. The bundle is intended to act as a server-rebuild kit: application data, identity and documentation data, service volumes, monitoring state, deployment configuration, edge configuration, service schedules, host configuration, package and tool version inventories, rendered service definitions, listening network services, logs, and a manifest. Copy the encrypted bundle to two places, such as a laptop and a separate removable drive, and keep the decryption secret outside the server.

Live Docker volumes can change while they are being archived. For local Docker volumes, the monthly bundler archives Docker's reported volume mountpoint with GNU tar. ClickHouse is handled as a logical backup instead of a live data-volume tar: the bundle includes database/table schema and table data in ClickHouse Native format. Other tar errors still fail the bundle.

The bundle records which owner-held recovery secrets are intentionally excluded, such as the decryption secret and provider control-plane credentials. Store those outside the server, for example in the owner's password manager.

The monthly bundle is not a substitute for a restore drill. Treat it as the material needed to rebuild, then periodically prove the process on a clean machine before making any recovery-time promise.

Emergency cleanup behavior​

Operators can run the DB backup script in rotation-only mode to prune old local dump files without creating a fresh dump first. This is intended for host disk-pressure incidents.

Host disk cleanup automation​

Self-hosted operators can enable a guarded host cleanup timer that ships with the Dralvia self-hosted bundle.

The timer checks the root filesystem each day. When usage is below 70 percent, it exits without deleting files. When usage is 70 percent or higher, it:

  • skips cleanup when a monthly server-rebuild bundle is active
  • removes autonomous threat-feed snapshot folders older than 14 days
  • removes unused Docker images
  • removes unused Docker build cache

The cleanup does not remove Docker volumes. Volumes commonly hold databases and service state, so volume cleanup should stay a manual recovery action with a verified backup.

To enable it, install the bundled dralvia-host-disk-cleanup systemd service and timer, then:

systemctl daemon-reload
systemctl enable --now dralvia-host-disk-cleanup.timer

Run the cleanup manually with --force for a dry run, or --apply --force to remove eligible items.

Operational caveats​

  • Runtime hosts should have an explicit /etc/dralvia/backup.env so backup behavior is intentional rather than relying on script defaults.
  • Longer local retention without offsite sync increases the chance of disk-pressure incidents.
  • Local backups are operational artifacts, not a substitute for validated offsite disaster recovery.
  • Restore readiness matters more than raw backup count. A small number of known-good backups is safer than many unverified host-only dumps.