DEV Community

Cover image for A Green Backup Job Is Not a Recovery Test: Run a Safe Restore Drill with DBAegis
ILOGICSOFT
ILOGICSOFT

Posted on

A Green Backup Job Is Not a Recovery Test: Run a Safe Restore Drill with DBAegis

#database #devops #opensource #selfhosted

Disclosure: I am part of the team building DBAegis.

A backup job that ends in SUCCESS proves that a command completed. It does not prove that the artifact is usable, that the target is ready, or that your team can restore the data when time matters.

That is the operational problem behind DBAegis, a self-hosted database resilience platform that puts connections, schedules, backup history, controlled restores, and recovery evidence in one web interface.

This walkthrough shows a safe first evaluation with DBAegis Community.

What Community includes

DBAegis Community is AGPL-3.0 and requires no license. Version 1.0.0 supports:

  • PostgreSQL, MySQL, and MongoDB
  • logical backup and restore using DBAegis-local storage
  • manual backups, backup history, restore jobs, and basic retention
  • one local administrator
  • up to three active database connections and three schedules

Cloud storage, physical backup and restore, point-in-time recovery, notifications, RBAC, MFA, audit exports, and additional database engines are not part of Community. The edition comparison documents the exact boundaries.

Before touching a database

Use a clean Linux VM, non-production data, and a disposable restore target. Do not make your first restore attempt against production.

You will need:

  • a Linux VM with systemd and sudo
  • outbound HTTPS for dependencies
  • a reachable PostgreSQL, MySQL, or MongoDB test database
  • the matching native database client tools
  • enough local space for the backup artifact and restore working files

Install and verify the release

Download the release archive and checksum from the same GitHub release:

mkdir -p "$HOME/dbaegis-install"
cd "$HOME/dbaegis-install"

VERSION=1.0.0
BASE_URL="https://github.com/ILOGICSOFT/dbaegis-community/releases/download/v${VERSION}"

curl -fLO "${BASE_URL}/dbaegis-community-v${VERSION}.tar.gz"
curl -fLO "${BASE_URL}/SHA256SUMS"
sha256sum --ignore-missing --check SHA256SUMS
Enter fullscreen mode Exit fullscreen mode

Stop if checksum validation fails. Then create the service account and install:

getent passwd dbaegis >/dev/null || \
  sudo useradd --system --create-home --home-dir /var/lib/dbaegis dbaegis

tar -xzf "dbaegis-community-v${VERSION}.tar.gz"
cd "dbaegis-community-v${VERSION}"
sudo DBAEGIS_USER=dbaegis bash bin/install.sh --fresh
Enter fullscreen mode Exit fullscreen mode

Verify the service before signing in:

systemctl status dbaegis --no-pager
curl -fsS http://127.0.0.1:8000/health
curl -fsS http://127.0.0.1:8000/api/version
Enter fullscreen mode Exit fullscreen mode

The web UI is available at http://SERVER_IP:3000. The installer prints the initial login details; change the generated administrator password after signing in.

Run the backup half of the drill

  1. Open Connections and add a non-production PostgreSQL, MySQL, or MongoDB source.
  2. Run Test Connection.
  3. Resolve client-tool, network, authentication, TLS, path, and disk-space errors before continuing.
  4. Start a manual logical backup to DBAegis-local storage.
  5. Open Backup History and confirm that the job completed, the artifact has a non-zero size, and the engine log contains no unexpected warnings.

This is useful evidence, but the drill is only half complete.

Prove the restore path

Create an empty, disposable database or namespace. Keep it clearly separated from the source so a mistaken target selection cannot overwrite the data you just backed up.

Then:

  1. Add the disposable target as a separate DBAegis connection.
  2. Test its connectivity and permissions.
  3. Open Restore and select the successful backup artifact.
  4. Select the disposable target.
  5. Review the create and overwrite options carefully.
  6. Start the restore and inspect the resulting engine log.

Finally, validate the recovered data with checks that matter to the application. A row or document count is a start, but it is not enough by itself. Check representative records, required schemas or collections, constraints and indexes, ownership or permissions, and any extension or feature your application depends on.

Record evidence, not just a green status

For each drill, record:

  • the source and isolated target
  • engine and client-tool versions
  • backup artifact identifier and size
  • backup and restore durations
  • validation queries and observed results
  • warnings, missing tools, and manual steps
  • the person who performed the drill and the date

That record turns “we have backups” into a repeatable recovery procedure your team can inspect and improve.

What DBAegis can—and cannot—prove

DBAegis coordinates the workflow and keeps its operational context visible. Recoverability still depends on the database engine, client tools, backup artifact, target environment, credentials, and the validation procedure you choose.

The goal is not to replace engine knowledge. It is to make the recovery path explicit and repeatable before an incident forces you to discover it under pressure.

You can start with the DBAegis Community repository, follow the quick start, and check the backup and restore support matrix.

I would value candid feedback on installation friction, restore safety, and what evidence your team needs before trusting a backup.

Top comments (1)

Collapse
 
mads_hansen_27b33ebfee4c9 profile image
Mads Hansen •

The disposable target and application-level validation are the parts many backup checks miss. I would measure RTO from “recovery declared” to “application acceptance passed,” not only the restore command duration. DNS/routing, secrets, roles and grants, extensions, collations, time zones, migrations, connection pools, and dependent services can all leave a technically restored database unusable.

For the drill fixture, include invariants that counts cannot prove: foreign-key relationships, unique constraints, a large object or binary value, sequence/identity next values, representative permissions, and a known transaction created while the backup runs. Then start the real application against the isolated target and execute a small read/write acceptance suite under a non-production identity. Record the newest recoverable transaction timestamp so the exercise measures RPO as well as RTO. It is also worth rotating artifacts and targets across engine/client versions; a restore that only works with today's exact toolchain is a compatibility test waiting to fail. The strongest evidence is a timed, repeatable service-recovery runbook, not a successful import.