Make application-consistent backups

Copying files while an application writes them can capture related data from different moments.

Picture a backup that walks /var/lib/mysql file by file while the database commits transactions. The first file is copied at 02:00, the last at 02:40, and no single instant of the database’s life looks like what landed in the backup. The copy completes with exit code 0. It may still be unrestorable.

Application consistency means the backup represents one moment the application itself could have been stopped at.

Three ways to get a consistent boundary

Use database-native dumps or backup APIs, filesystem snapshots with quiescing, or a documented stop window.

The database dump is the everyday choice. The engine produces a consistent export while staying online:

sudo -u postgres pg_dump --format=custom shopdb > /srv/backups/shopdb-2026-08-03.dump

The dump is consistent by construction: it sees one transaction-level view of the database no matter how long it takes.

A filesystem snapshot works when the data isn’t in a database, or is too big to dump. The catch is quiescing: telling writers to flush and pause so the frozen view is clean, not a crash image.

The stop window is the honest fallback. Stop the service, copy, start it. Downtime, but perfect consistency, and for a small internal tool that’s often the simplest correct answer.

Databases are more than data

Preserve schema, roles, extensions, and external objects required by the application. A pg_dump of one database does not include the cluster’s roles — capture them separately:

sudo -u postgres pg_dumpall --globals-only > /srv/backups/pg-globals-2026-08-03.sql

Skip this and the restore fails with “role does not exist” errors at the worst possible time.

The cross-boundary problem

Now the hard part: an application with a database and uploaded files. Dump the database, then copy the uploads, and a file uploaded in between exists on disk with no database row — or the reverse, depending on order.

Decide which inconsistency your application tolerates, and order the backup so you get that one. An orphaned file on disk is usually harmless; a database row pointing at a missing file is a broken page. So dump the database first, then copy files. If neither direction is tolerable, you need a brief pause of writers around the boundary.

Design a backup sequence for an application with a database and uploaded files. State how you create one consistent boundary across both.