Quiesce, freeze, and application hooks — the techniques for consistent backups

Achieving application-consistent backups requires coordinating the snapshot with the application. This lesson walks the techniques — quiesce, freeze, fsync — and the application-specific hooks for PostgreSQL, MySQL, MongoDB, and others.

The four techniques

Quiesce (application-level)

The application is told to pause writes for the duration of the snapshot:

# PostgreSQL
psql -c "SELECT pg_start_backup('snapshot-2026-08-16');"
# ... snapshot ...
psql -c "SELECT pg_stop_backup();"

# MySQL (with FLUSH TABLES WITH READ LOCK)
mysql -e "FLUSH TABLES WITH READ LOCK;"
# ... snapshot ...
mysql -e "UNLOCK TABLES;"

The application is in a quiescent state; the snapshot is captured; the application resumes.

Freeze (filesystem-level)

The filesystem is frozen; writes are blocked at the kernel level:

# Linux: fsfreeze
fsfreeze -f /var/lib/postgresql/data
# Filesystem is frozen; new writes are blocked
# ... snapshot ...
fsfreeze -u /var/lib/postgresql/data
# Filesystem is unfrozen; new writes resume

Freeze is filesystem-level; the application does not need to know. The trade-off: writes are blocked, which can cause timeouts if the snapshot takes a long time.

fsync (flush dirty pages)

The application flushes dirty pages from the buffer pool to disk:

# PostgreSQL
psql -c "CHECKPOINT;"

# MySQL
mysql -e "FLUSH LOGS;"

fsync ensures that all in-memory data is on disk before the snapshot. The application continues to accept writes during the snapshot; the snapshot captures the state at the moment of the fsync.

Application hooks

Many databases have built-in hooks for snapshots:

# PostgreSQL: pg_basebackup (preferred)
pg_basebackup -D /var/lib/postgresql/backup -Ft -z -P

# MySQL: mysqldump (logical backup)
mysqldump --all-databases --single-transaction > backup.sql

# MongoDB: mongodump (logical backup)
mongodump --out /backup/

# Cassandra: nodetool snapshot (file-level snapshot)
nodetool snapshot

Application hooks are the most reliable: the application knows its own state and can coordinate the snapshot.

The coordination sequence

A typical application-consistent snapshot procedure:

sequenceDiagram
    participant O as Operator
    participant DB as Database
    participant BE as Backend
    Note over O,DB: Quiesce
    O->>DB: pg_start_backup / FLUSH TABLES WITH READ LOCK
    DB-->>O: backup mode / lock acquired
    Note over O,DB: Flush
    O->>DB: CHECKPOINT / flush logs
    DB-->>O: dirty pages flushed
    Note over O,BE: Snapshot
    O->>BE: create snapshot
    BE-->>O: snapshot created
    Note over O,DB: Resume
    O->>DB: pg_stop_backup / UNLOCK TABLES
    DB-->>O: backup mode / lock released

The sequence:

1. The operator tells the database to enter backup mode (quiesce).
2. The operator tells the database to flush dirty pages (fsync).
3. The operator triggers the snapshot.
4. The snapshot is captured while the database is in backup mode and the pages are flushed.
5. The operator tells the database to exit backup mode.

Per-database hooks

PostgreSQL

# Physical backup (for snapshot-based restore)
psql -c "SELECT pg_start_backup('snapshot-2026-08-16', true);"
psql -c "CHECKPOINT;"
# ... snapshot ...
psql -c "SELECT pg_stop_backup();"

# Logical backup (for SQL restore)
pg_dump -Fc -d mydb > /backup/mydb.dump

The physical backup produces a snapshot of the data directory; the logical backup produces SQL statements.

MySQL

# For InnoDB (transactional)
mysql -e "FLUSH TABLES WITH READ LOCK;"
mysql -e "SHOW MASTER STATUS;"
# ... snapshot ...
mysql -e "UNLOCK TABLES;"

# For mysqldump
mysqldump --all-databases --single-transaction --master-data=2 > /backup/dump.sql

The FLUSH TABLES WITH READ LOCK blocks all writes; the snapshot is captured; the lock is released.

MongoDB

# With WiredTiger (default), MongoDB supports consistent
# snapshots via the filesystem; the database can be running

# For mongodump
mongodump --oplog --out /backup/

# For filesystem snapshot (with the database running)
# MongoDB detects the snapshot and replays the journal

MongoDB’s WiredTiger storage engine has built-in crash recovery; the database can recover from a crash-consistent snapshot by replaying the journal.

Kafka

# Kafka does not have quiesce; instead, rely on
# replication for backup

# Use the mirror maker or partition reassignment
# to create a copy of the data

Kafka’s data is replicated across brokers; backup is typically a separate Kafka cluster that mirrors the primary.

The production pattern

The production pattern:

#!/bin/bash
# backup.sh: Application-consistent snapshot

set -e

# 1. Quiesce the database
psql -h $DB_HOST -U $DB_USER -c "SELECT pg_start_backup('snapshot-$(date +%Y%m%d)', true);"

# 2. CHECKPOINT to flush dirty pages
psql -h $DB_HOST -U $DB_USER -c "CHECKPOINT;"

# 3. Trigger the snapshot
kubectl create -f - <<EOF
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: postgres-snap-$(date +%Y%m%d-%H%M%S)
spec:
  source:
    persistentVolumeClaimName: data-postgres-0
  volumeSnapshotClassName: postgres-snap
EOF

# 4. Wait for the snapshot to complete
kubectl wait --for=jsonpath='{.status.readyToUse}'=true \
  volumesnapshot/postgres-snap-$(date +%Y%m%d-%H%M%S) --timeout=600s

# 5. Resume the database
psql -h $DB_HOST -U $DB_USER -c "SELECT pg_stop_backup();"

The script is the production pattern for application- consistent snapshots.

Quiz

Production discipline

• Application-consistency requires application cooperation. Use quiesce (application hook) + fsync.
• Test the consistency of a snapshot via restore. A snapshot that is never restored is not a backup.
• Use the database’s native hooks. pg_start_backup, FLUSH TABLES WITH READ LOCK, etc.
• Document the procedure. Every backup has a documented procedure; the restore procedure matches.
• Use an Operator. Cloud Native PG, Zalando, Strimzi encode the application knowledge.