Database Reference
In-Depth Information
The server log records each WAL file restored from the archive, so you can check progress and
rate of recovery. You can query the archive to find out the name of the latest archived WAL file
to allow you to calculate how many files to go.
The
restore_command
should return 0 if a file has been restored and non-zero for failure
cases. Recovery will proceed until there is no next WAL file, so there will eventually be an error
recorded in the logs.
If you have lost some of the WAL files, or they are damaged, then recovery will stop at that
point. No further changes after that will be applied, and you will likely lose those changes; that
would be the time to call your support vendor.
There's more...
You can start and stop the server once recovery has started without any problem. It will not
interfere with the recovery.
You can connect to the database server while it is recovering and run queries, if that is useful.
That is known as Hot Standby mode, and is discussed in a later chapter.
See also
Once recovery reaches the stop address you can stop the recovery at any point, as discussed
in
Recovery
to
a
point
in
time
.
Recovery to a point in time
If your database suffers a problem at 15:22 p.m. and yet your backup was taken at 04:00
a.m. you're probably hoping there is a way to recover the changes made between those two
times. What you need is known as "point-in-time recovery".
Regrettably, if you've made a backup with
pg_dump
at 04:00 a.m. then you won't be able to
recover to any other time than 04:00. As a result, the term point-in-time recovery (PITR) has
become synonymous with the physical backup and restore technique in PostgreSQL.
Getting ready
If you have a backup made with
pg_dump
, then give up all hope of using that as a starting point
for a point in time recovery. It's a frequently asked question, but the answer is still "no"; the
reason it gets asked is
exactly
why I'm pleading with you to plan your backups ahead of time.
First, you need to decide what the point of time is that to which you would like to recover.
If the answer is "as late as possible", then you don't need to do a PITR at all, just recover
until end of logs.
