On 03/15/11 12:30 AM, Alban Hertroys wrote:
> On 15 Mar 2011, at 7:46, Alban Hertroys wrote:
>
>> On 15 Mar 2011, at 3:06, Rajesh Kumar Mallah wrote:
>>
>>> Dear Friends,
>>>
>>> While taking online basebackup we ignore tar exit codes of 1 .
>>> However under certain circumstances tar exits we code '2' which
>>> stands for 'Fatal Errors' . Eg in case of "Cannot stat: No such file or directory"
>>> encountered while taking backup of the pgdatadir . My question is
>>> can we ignore such errors of "vanishing files" ? is it normal ?
>>> I think the situation is arising because some table which were created
>>> before start of backup were dropped during the backup. But that is
>>> quite normal also.
>>
>> You should probably exclude the PG data directories from your file-system backups, there isn't much point in backing
themup anyway.
>
> I should refine that a bit...
>
> A file-system level backup backs up the files in a sequential order, while the database writes it's transactions in
themin a pattern that's much closer to random order. As a result of that, your file-system backup is likely to contain
thedatabase files in an inconsistent state.
> If you subsequently try to recover from that backup, you rely on the ability of the database to recover from that
inconsistentstate. Postgres is pretty good at recovering, but there's no guarantee it will succeed. It's probably a bad
ideato rely on that for your backups.
>
> Instead, for backing up your database, use one of the strategies outlined in the fine manual. Those are reliable.
um, I assumed from the original post that he was talking about taking a
base backup in preparation for setting up WAL replication, presumably
preceded by a call to pg_start_backup(), etc...
