Feature Request: Binary Log Backups & Point-in-Time Recovery for MySQL/MariaDB and PostgreSQL

[leuedaniel]

Summary

Add support for continuous binary log / WAL archiving alongside full backups, enabling true Point-in-Time Recovery (PITR) directly from the Databasement UI.

---

Motivation

Currently, Databasement creates logical dumps (mariadb-dump / pg_dump) on a fixed schedule. This means the maximum data loss window equals the backup interval. For production databases, a 15–30 minute loss window is often acceptable — but recovering to an exact point in time (e.g. 2 minutes before an accidental DROP TABLE) is not possible with snapshot-only backups.

Tools like SQLBak already offer this combination: scheduled full backups paired with continuous incremental backups via binary logs, with a UI-driven restore flow that lets you pick any point in time. An open-source equivalent of this capability in Databasement would make it a compelling self-hosted alternative.

---

Proposed Behaviour

MySQL / MariaDB

• Periodically upload binary log files to the configured storage volume (S3, SFTP, local)
• Store the binlog_position / GTID alongside each full backup
• On restore, allow the user to select a target timestamp; Databasement replays the necessary binary log segments after restoring the base snapshot

PostgreSQL

• Archive WAL segments continuously to the configured storage backend
• On restore, configure recovery.signal and restore_command automatically, then let PostgreSQL replay WAL up to the chosen recovery target

---

UI Suggestion

On the snapshot restore dialog, add an optional "Restore to point in time" datetime picker. When selected:

1. Databasement restores the closest preceding full snapshot
2. It then replays binary log / WAL segments up to the chosen timestamp
3. Progress and log output are streamed in real time (as with the current restore flow)

---

Prior Art / Reference Implementations

• SQLBak – commercial tool offering full + binary-log incremental backups with UI-driven PITR
• Databasus – open-source, implements WAL archiving + PITR for PostgreSQL via a sidecar agent
• maria-back-me-up (SAP) – Kubernetes-native tool doing exactly this for MariaDB: full backups + binary log streaming to S3, with a web UI showing the recovery timeline
• MyHoard (Aiven) – open-source MySQL PITR daemon using Percona XtraBackup + binary log archiving

---

Why This Matters

For self-hosters running production workloads, PITR is often the difference between a recoverable incident and significant data loss. Having it integrated into Databasement's existing UI — rather than requiring a separate tool — would make the backup workflow complete without additional infrastructure.

Thank you for building and maintaining Databasement — the Keycloak OIDC integration and cross-server restore are exactly what was missing from the open-source backup landscape.

[ktsouvalis]

Hi @David-Crty , I'm interested in contributing to this but given my current availability I can only realistically tackle a bounded slice.

Would it be valuable to start with MySQL/MariaDB binary log upload (periodically shipping binlog files to the configured storage volume and recording the binlog position alongside each snapshot) without implementing PITR restore yet? That would lay groundwork for the restore flow as a follow-up PR.

Happy to put together a design proposal first before writing any code, if that helps.

[David-Crty]

Hey @ktsouvalis ✋

My knowledge on point-in-time recovery is low; I never really used it in a real production environment.
We can start with a design, yes, I will try to give you accurate feedback