Re: Recovery target 'immediate'

On 26.04.2013 14:54, Magnus Hagander wrote:
> On Fri, Apr 26, 2013 at 1:47 PM, Simon Riggs<simon(at)2ndquadrant(dot)com> wrote:
>> On 26 April 2013 11:29, Heikki Linnakangas<hlinnakangas(at)vmware(dot)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