Here's a du -sh *
output of a typical PostgreSQL 9.3 data directory:
4.0K PG_VERSION
59G base
47M global
20M pg_clog
28K pg_multixact
80K pg_notify
4.0K pg_serial
4.0K pg_snapshots
4.0K pg_stat
368K pg_stat_tmp
168K pg_subtrans
4.0K pg_tblspc
4.0K pg_twophase
1.1G pg_xlog
4.0K postmaster.opts
4.0K postmaster.pid
Notice that there's no backup
directory: a PG instance does not need or create such a directory. It had to be created by a person or a script that is not part of PostgreSQL itself.
Since you mention pg_xlog
, if the files in this directory follow the naming convention of WAL files (24 numbers in hexadecimal in a 3x8 layout) found in pg_xlog
, it's plausible that they're WAL files copied for continuous archiving. Check the archive_command
in postgresql.conf
.
In this case, the name backup
for the target directory make sense, but its location doesn't. Such backups are useful for disaster recovery when the data directory has disappeared, so obviously the data directory itself is the last place where you want such backups.
You're expected to ensure that /path/to/archive
is a shared volume, like an NFS fileshare, that both servers can read. Or you're expected to use an appropriate command to copy the files to/from a shared storage location.
I think this might need to be made more obvious in the documentation.
Re your comment:
Why it is necessary to create a archive directory and the copy doesn't execute directly into pg_xlog?
the reason is that the master's pg_xlog
is generally on a different server to the replica(s). The replicas cannot access it. You really don't want to put pg_xlog
on shared storage because it's performance critical.
It also does you no good to have a backup that requires access to the master server's pg_xlog
when the master server just melted in a fire.
By archiving WALs, PostgreSQL can also reduce filesystem fragmentation. It recycles WAL archives once they're no longer required, renaming them and using them as if they were new files. This is a significant performance improvement that would not be possible if it had to keep all the old WAL files around.
Finally, it creates a logical separation between "transaction logs the master server still needs to operate" and "transaction logs that are now only required for backup/archival".
Best Answer
PostgreSQL 10+
In PostgreSQL 10 the WAL directory was renamed from
pg_xlog
to the easier to rememberpg_wal
.