Database Reference
In-Depth Information
F
Reload all scripts like the following:
psql -f myscriptdump.sql
LOGICAL (from script dump created by
pg_dumpall
):
We need to follow the procedure, which is shown next.
F
Confirm you have the correct backup before you restore. If the following command
returns nothing, then the file is not timestamped, and you'll have to identify it in a
different way:
head myscriptdump.sql | grep Started
F
Find a suitable server, or create a new virtual server.
F
Reload script in full
psql -f myscriptdump.sql
PHYSICAL:
F
If you used the
Standalone
hot
physical
database
backup
recipe then recovery is very
easy. Restore the backup file onto the target server.
F
Extract the backup file into the new data directory.
F
Confirm that you have the correct backup before you restore.
$ cat backup_label
START WAL LOCATION: 0/12000020 (file 000000010000000000000012)
CHECKPOINT LOCATION: 0/12000058
START TIME: 2010-06-03 19:53:23 BST
LABEL: standalone
F
Check all file permissions and ownerships are correct and links are valid. That
should already be the case if you are using the postgres userid everywhere, which
is recommended.
F
Start the server
That procedure is so simple because in the
Standalone
recipe we gift wrapped everything
for you. That also helps us understand that we need both a base backup and the appropriate
WAL files.
If you used other techniques, then we need to step through the tasks to make sure we cover
everything required as follows:
F
Shutdown any server running in the data directory.
F
Restore the backup so that any files in the data directory that have matching names
are replaced with the version from the backup. (The manual says delete all files and
then restore backup—that might be a lot slower than running an rsync between your
backup and the destination without the
--update
option). Remember that this step
can be performed in parallel to speed things up, though it is up to you to script that.
