Backing up a database properly
Copying the data files of a running database gives you a backup that may not restore. Databases need to be backed up on their own terms.
Why a plain file copy is not enough
A live database is writing while you copy, so a naive file-level snapshot can capture a half-written state that will not come back cleanly. You need either a consistent dump taken through the database, or a filesystem snapshot coordinated with the engine's flush-and-lock.
Dumps and point-in-time recovery
A logical dump is portable and easy to inspect but slow to restore at size. Physical backups plus the write-ahead log give point-in-time recovery — you can roll forward to the second before a bad query. For the engine specifics see PostgreSQL and MariaDB replication; a replica is availability, not a backup.
Prove the restore
An untested database backup is a hope. Restore it into a scratch machine on a schedule, run a few sanity queries, and record how long it took — that number is your real RPO and RTO for disaster recovery. Keep at least one copy offline so ransomware cannot reach it.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base