On 26.04.2013 14:54, Magnus Hagander wrote:
On Fri, Apr 26, 2013 at 1:47 PM, Simon Riggs<si...@2ndquadrant.com> wrote:
On 26 April 2013 11:29, Heikki Linnakangas<hlinnakan...@vmware.com> wrote:
But there is also an operation to simply "restore a backup".
Just because a tool supports an imprecise definition of a restore,
doesn't mean Postgres should encourage and support that.
"Restore a backup" is more suited to filesystems where most files
don't change much. And its also a common user complaint: "I restored
my back but now I've lost my changes. Can you help?". That's not
something that's been heard around here because we don't encourage
foot-guns.
I think it makes perfect sense to have this. Since we do guarantee it
to still be consistent even if things *are* changing around. The lack
of an easy way to do this is probably the most common reason I've seen
for people using pg_dump instead of physical backups in the past.
pg_basebackup fixed it for the backup side of things, with the -x
option. This appears to be a suggestion to do that kind of restore
even if you have a log archive style backups.
That said, maybe the easier choice for a *system* (such as v-thingy)
would be to simply to the full backup using pg_basebackup -x (or
similar), therefor not needing the log archive at all when restoring.
Even if you have all the required WAL files included in the backup,
you'll still want to use a restore_command that can restore timeline
history files from the archive (I found this out the hard way).
Otherwise Postgres won't see the existing timeline history files, and
can choose a timeline ID that's already in use. That will cause
confusion after recovery when files generated on the new timeline start
to be archived; they will clash with files from the "other" timeline
with the same TLI. You can work around that by with a restore_command
that returns false for regular WAL files, but restores timeline history
files normally. But that's inconvenient again; it's not trivial to
formulate such a restore_command.
Also, pg_basebackup is a lot less efficient than working straight with
the filesystem. It's a very convenient stand-alone backup tool, but if
you're writing a backup handling system, you'll want to use something
more efficient. (Data Director uses disk snapshots, as it happens)
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
