PostgreSQL Continuous Recovery vs. Synapse Media Volume Backups

By 4FreeForums Editors · Published October 30, 2026 · Sources linked below

Operating an independent chat network or community homeserver requires balancing database state against unstructured user uploads. When managing a Synapse server, administrators must maintain dependable backups to guard against hardware failure, software bugs, and administrator mistakes. The server architecture splits state across two distinct layers: structured event records inside PostgreSQL and uploaded files stored across disk directories. Understanding how PostgreSQL continuous point-in-time recovery archives compare against raw media volume snapshots ensures your platform can recover cleanly without desynchronizing community records.

Point-in-Time Recovery and Data Granularity

PostgreSQL continuous archiving operates by combining a base filesystem backup with the stream of write-ahead log (WAL) files collected from the cluster data directory inside pg_wal/. Because the log records every single change made to database files, administrators can perform point-in-time recovery by stopping log replay at any chosen moment. This mechanism establishes a consistent historical state while automatically reconciling any internal inconsistencies present in the starting base backup.

In contrast, raw media store snapshots have no transaction log or replay engine. Synapse maintains uploaded files directly on local disk storage. If media files are missing when restoring a volume snapshot, no automated system can replay their creation. As noted in the Synapse backup documentation, losing this local disk data causes community members to encounter persistent errors whenever they attempt to view room avatars, user avatars, or message attachments.

Federation Caching Versus Irreplaceable Local Files

A fundamental difference between database archives and media volume backups is how each layer interacts with the wider federation. PostgreSQL continuous archiving requires capturing the entire database cluster, creating a bulky base backup accompanied by continuous WAL generation. Media storage, however, does not demand an all-or-nothing approach because the Synapse media directory isolates content by source and function:

• local_content: Contains media uploaded directly by local users. This folder must be backed up because it often represents the only copy of those assets across the entire federation.
• local_thumbnails: Stores generated previews of local uploads. If the server operates with dynamic_thumbnails enabled, Synapse automatically regenerates missing previews upon request. When dynamic_thumbnails is not enabled (the default setting), there is no tooling to rebuild them from local_content, making regular snapshots advisable.
• remote_content: Caches media received from external servers across the federation. If these files are excluded from a snapshot or lost, Synapse simply attempts to fetch them again from the remote server.
• remote_thumbnails: Holds previews of images uploaded to other servers, meaning administrators do not need to preserve them.
• url_cache and url_cache_thumbnails: Store temporary data generated by the URL previews feature, which can be discarded entirely during backup routines.

Recognizing these directory roles allows administrators who properly back up your forum infrastructure to trim media volume footprints without risking permanent loss of community data.

Database Cleansing and Cryptographic Keys

Restoring a database backup introduces specific cryptographic requirements that do not apply to raw media snapshots. According to the Synapse administration guidelines for backups, restoring database records to an older state can cause previously used one-time keys to be re-issued to clients. This scenario leads to subsequent message decryption errors across encrypted rooms.

To avoid message decryption failures, administrators must exclude the e2e_one_time_keys_json table during database backups, or execute a TRUNCATE command on e2e_one_time_keys_json after restoring database tables before starting the homeserver process. Clearing this table prompts client applications to generate and upload fresh one-time keys.

Furthermore, database recovery demands extreme caution regarding preexisting schemas. Administrators must never restore a database backup over an existing database with tables present, as doing so leads to immediate errors or subtle inconsistencies. Media volumes, by comparison, carry no cryptographic state machine; restoring an older media folder simply restores older files without corrupting client encryption sessions.

Storage Footprints and Archival Overhead

The resource demands of these two backup strategies diverge significantly. In PostgreSQL continuous archiving, the engine divides write-ahead logs into segment files that are normally 16MB apiece. On an active community platform, database writes generate many megabytes of WAL traffic that must be transferred to archival storage before the database server recycles those segments for reuse.

Media volume snapshots avoid segment sequencing but present disk capacity challenges over time. Because remote media and URL caches can be excluded, admins can isolate local_content to conserve snapshot space. In addition, logical database dumps created via pg_dump using the custom dump format (-Fc) cannot participate in continuous WAL archiving, underlining the architectural gap between logical dumps, physical cluster archiving, and raw volume imaging.

Comparing Recovery Dynamics

When evaluating these recovery methods side by side, distinct operational traits become clear:

• Granularity: PostgreSQL archiving supports precise point-in-time recovery to an exact timestamp, whereas media snapshots only recover the filesystem state captured when the disk volume was copied.
• Federation Rebuilding: Database records cannot reconstruct themselves over the network, while Synapse remote media automatically downloads again from federation partners if wiped.
• Post-Restore Tasks: Restoring a database snapshot requires truncating e2e_one_time_keys_json to prevent decryption errors, whereas media restores require no post-operation database queries.
• Operational Focus: WAL archiving requires monitoring segment completion commands to avoid recycling uncopied files, while media backups focus on selective retention of local assets.

Reviewing these mechanisms alongside our guide to the Synapse Matrix homeserver architecture ensures your community infrastructure remains protected against unexpected server failures.

Sources

Backups - Synapse
PostgreSQL: Documentation: 18: 25.3. Continuous Archiving and Point-in-Time Recovery (PITR)

Published October 30, 2026. No affiliate links on this page. Facts come from the sources linked above; check them for updates.