Database Backup on Netdata

Database Backup - Types, Process and Benefits

Mon, 28 Apr 2025 00:00:00 +0000

Data is often called the lifeblood of modern organizations. From customer details and financial records to application configurations and operational logs, databases store the critical information that powers business operations. But what happens if that data is lost due to hardware failure, accidental deletion, software corruption, or a cyberattack? Without a safety net, the consequences can be catastrophic, leading to costly downtime, reputational damage, and potentially irreparable business harm. This is where database backup becomes indispensable.

CockroachDB Backup Job Failures: How To Fix Them

Mon, 01 Jan 0001 00:00:00 +0000

CockroachDB scheduled backups run through the internal jobs system, visible via crdb_internal.jobs (backed by system.jobs). When a scheduled backup fails silently, stalls indefinitely, or grows so slowly that it cannot complete within its interval, your recovery point objective (RPO) is at risk. The failure is insidious: backups often appear healthy until you realize the last successful completion was 36 hours ago.

The severity distinction is sharp. A single backup failure with a recent prior success is a TICKET. The retry will probably succeed. But when no successful backup exists within your RPO window (for example, last success over 24 hours ago with a 24-hour RPO), you are in PAGE territory.

MySQL FLUSH TABLES WITH READ LOCK stall: backups that freeze the server

Mon, 01 Jan 0001 00:00:00 +0000

Your application suddenly cannot write. Threads_connected climbs toward max_connections, but Questions flatlines. The last change was a backup job that started ten minutes ago. The culprit is almost always FLUSH TABLES WITH READ LOCK (FTWRL), and the damage is caused not by the lock itself but by what happens while the server waits to acquire it.

FTWRL is triggered by mysqldump --master-data, mysqldump --lock-tables, and similar tools that need a consistent logical backup. It attempts to close all open tables and acquire a global read lock. While it waits for a long-running query to finish, new writes are already blocked. The result is a whole-server freeze: the query rate drops to zero, connections pile up, and the application sees cascading timeouts.

PostgreSQL backup strategy: pg_dump, pg_basebackup, and pgBackRest compared

Mon, 01 Jan 0001 00:00:00 +0000

Your backup tool determines your RPO, RTO, and whether you can restore to a point in time or only to the backup moment. This guide compares logical dumps via pg_dump, built-in physical copies via pg_basebackup, and the third-party tool pgBackRest. PostgreSQL 17 introduced native incremental physical backups. Operators must decide whether built-in capabilities are sufficient or whether to adopt alternatives such as Barman or WAL-G.

pg_dump and pg_dumpall: logical portability

pg_dump and pg_dumpall use an MVCC snapshot to produce a logically consistent SQL archive without blocking reads. Use --table or --schema for selective extraction. Parallel dumps use --jobs with directory format (-Fd) or custom format (-Fc):

SQL Server backup freshness: the recovery point you only discover you lack during an incident

Mon, 01 Jan 0001 00:00:00 +0000

The recovery point you actually have is the recovery point you can restore to, not the one your schedule promises. Backup freshness is the gap between those two, measured as the time since the last successful full, differential, and transaction log backup per database. When that gap is wrong, you find out during restore: either an analyst files a ticket for missing data, or an incident forces point-in-time recovery and the chain breaks.