Another option is to perform a continuous archiving base backup ( Section 26.3.2) because such backups are immune to file system changes during the backup. If simultaneous snapshots are not possible, one option is to shut down the database server long enough to establish all the frozen snapshots. Read your file system documentation very carefully before trusting the consistent-snapshot technique in such situations. For example, if your data files and WAL log are on different disks, or if tablespaces are on different file systems, it might not be possible to use snapshot backup because the snapshots must be simultaneous. If your database is spread across multiple file systems, there might not be any way to obtain exactly-simultaneous frozen snapshots of all the volumes. You can perform a CHECKPOINT before taking the snapshot to reduce recovery time. This is not a problem just be aware of it (and be sure to include the WAL files in your backup).
However, a backup created in this way saves the database files in a state as if the database server was not properly shut down therefore, when you start the database server on the backed-up data, it will think the previous server instance crashed and will replay the WAL log. This will work even while the database server is running. The typical procedure is to make a “ frozen snapshot” of the volume containing the database, then copy the whole data directory (not just parts, see above) from the snapshot to a backup device, then release the frozen snapshot. So file system backups only work for complete backup and restoration of an entire database cluster.Īn alternative file-system backup approach is to make a “ consistent snapshot” of the data directory, if the file system supports that functionality (and you are willing to trust that it is implemented correctly). Of course it is also impossible to restore only a table and the associated pg_xact data because that would render all other tables in the database cluster useless. A table file is only usable with this information. This will not work because the information contained in these files is not usable without the commit log files, pg_xact/*, which contain the commit status of all transactions.
If you have dug into the details of the file system layout of the database, you might be tempted to try to back up or restore only certain individual tables or databases from their respective files or directories. Needless to say, you also need to shut down the server before restoring the data. Information about stopping the server can be found in Section 19.5. Half-way measures such as disallowing all connections will not work (in part because tar and similar tools do not take an atomic snapshot of the state of the file system, but also because of internal buffering within the server). The database server must be shut down in order to get a usable backup.
0 kommentar(er)
