Backups & recovery
Backups are insurance. Restore drills are the policy payout. DeployDock treats both as first-class workflows: backups you can find in the UI, retention you can explain to finance, and restore paths that do not depend on one engineer’s memory of a cron job.
Backups fail silently until they don’t
The dangerous moment is not when backup jobs stop—it is when nobody notices for weeks. The panel should show last success, next run, and size trends so slow degradation (creeping dataset growth, permission drift, full disks) becomes visible before the holiday freeze.
Conceptual framing: Backups. Operational steps: Backup config and Restore backup.
Scope: what must be in the bundle
A credible backup includes databases, application files that are not reproducible from Git, and configuration the panel manages—TLS material, vhost includes, environment fragments. Be explicit about what is not backed up: ephemeral caches, build artifacts you can regenerate, and secrets that should live in a vault instead of on disk.
Document the gap between “we can rebuild from CI” and “we will lose customer uploads without this directory.” That honesty prevents nasty surprises during audits.
Off-site copies are non-negotiable
RAID is not a backup; snapshots on the same disk are not a backup. Push encrypted copies to another account, another region, or tape if you must. DeployDock’s role is to make exports predictable and schedulable; your org’s policy defines where they land.
Restore drills beat promises
Schedule quarterly restores to a disposable host: prove you can boot the database, replay WAL or binlogs if needed, and reach HTTP 200 on a representative page. Time the exercise. Log gaps. Update runbooks. The troubleshooting matrix is useful when restores fail halfway due to version skew.
Encryption and keys
Encrypt backups at rest and in transit. Separate encryption keys from backup storage where possible. Rotate keys when teams change. If you cannot answer “who can decrypt production backups?” in one sentence, tighten access.
RPO and RTO in plain language
Recovery Point Objective (how much data you may lose) and Recovery Time Objective (how long restore may take) should appear in internal SLAs—even if the numbers are aspirational at first. The panel helps operationalize those targets with scheduling granularity and restore tooling; it cannot invent faster disks or better WAN.
Enterprise and compliance
Regulated customers often need immutability, legal hold, and air-gapped transfer paths. Read Air-gap and Private deployments, then Contact if you need packaging that aligns with your retention regime.
Related features
- Databases for schema and user hygiene alongside backups.
- File manager for inspecting paths before and after restore.
Need guided setup?
If you want a partner to review your backup topology before go-live, reach out via Contact.