Re: BUG #15636: PostgreSQL 11.1 pg_basebackup backup to a CIFS destination throws fsync error at end of backup

From: John Klann <jk7255(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #15636: PostgreSQL 11.1 pg_basebackup backup to a CIFS destination throws fsync error at end of backup
Date: 2019-02-19 20:21:25
Message-ID: CAHyX5+VGCkWb_81_v_JsqJKzOEbBqDzjX8JmNWA5ogJTXmXgWw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Thanks Stephen for pointing this out.

John

On Mon, Feb 18, 2019 at 11:26 AM Stephen Frost <sfrost(at)snowman(dot)net> wrote:

> Greetings,
>
> * PG Bug reporting form (noreply(at)postgresql(dot)org) wrote:
> > archive_mode = 'on'
> > archive_command = 'test ! -f
> /pgxlog1/data1/%f || cp /pgxlog1/data1/%f
> > /cifs/backups/<backupDirectoryName>/dmp/archive/%f'
>
> I realize you were complaining about pg_basebackup here, but since you
> shared your config, I wanted to point out that the above is an
> absolutely *terrible* archive_command, *especially* when you've got a
> network filesystem involved.
>
> There's no guarantee with that archive command that the WAL makes it to
> the backup server or that it's completely written out on the backup
> server before the PG server removes the WAL- if something happened (a
> network hiccup, the CIFS server being rebooted, or the PG server
> restarting) there's a real possibility that you'd lose some portion of
> your WAL, which could make a backup invalid, or could make it so you
> can't do PITR.
>
> Please don't roll your own backup solution like this.
>
> Thanks!
>
> Stephen
>

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Julien Rouhaud 2019-02-19 20:21:42 Re: BUG #15572: Misleading message reported by "Drop function operation" on DB with functions having same name
Previous Message David Rowley 2019-02-19 20:03:50 Re: BUG #15572: Misleading message reported by "Drop function operation" on DB with functions having same name