A filesystem snapshot captures a point-in-time image of storage that may later be restored. For PostgreSQL, that apparent safety is conditional: database correctness depends on write-ahead log (WAL) and data files remaining synchronized, not merely on having a copy of the filesystem. section 9.1
The tempting mistake is to treat a disk snapshot like a database backup. RAID mirrors corruption, and a replicated standby can reproduce damaging changes; neither makes a filesystem snapshot a reliable recovery mechanism for corruption, human error, or malicious activity. section 9.1 section 9.7
Snapshot safety depends on how the PostgreSQL files are captured and restored:
- A file-level snapshot is unsafe unless it is guaranteed atomic across the entire filesystem. PostgreSQL spans WAL, buffers, transaction state, and segmented data files. section 9.1
- Restoring an atomic disk snapshot and starting PostgreSQL resembles recovery after a crash: startup crash recovery replays committed WAL transactions. section 9.1
- Never restore a snapshotted filesystem over the data directory of a running instance; likely inconsistencies can corrupt data. section 9.1
- For a safe snapshot, shut PostgreSQL down cleanly first, or quiesce backup activity with pg_backup_start() before and pg_backup_stop() after the capture. section 9.1
Disk restore versus a running server
A storage layer restores yesterday’s filesystem image directly onto a live PostgreSQL data directory. This mixes restored files with files held or changed by the running server and is a corruption risk. Stop PostgreSQL before restoring; after restart, PostgreSQL can perform crash recovery. Even that does not turn the snapshot into a complete recovery strategy. section 9.1 section 9.7
Do not confuse a filesystem snapshot with PostgreSQL’s MVCC snapshot. An MVCC snapshot is a transaction’s consistent visibility view, assembled from transaction activity; it is held while a query or cursor runs. Long-held transaction snapshots can prevent autovacuum from removing dead tuples, contributing to bloat and XID wraparound risk. section 6.4.1 section 6.5.2
Filesystem snapshots can still support operational observation when they record database statistics rather than data files. pg_statviz stores timestamped snapshots of cumulative and dynamic PostgreSQL statistics, enabling trend analysis and visualizations with periodic collection and downsampling. section 7.5
For recoverability, use PostgreSQL-aware backups rather than filesystem snapshots alone. Combine automated backups with continuous archiving and Point-in-Time Recovery, keep a redundant copy elsewhere, and test full restores. section 9.7
