From: Jerry Sievers <gsievers19@comcast.net>
To: John Scalia <jayknowsunix@gmail.com>
Cc: Matheus de Oliveira <matioli.matheus@gmail.com>,
 "pgsql-admin\@postgresql.org" <pgsql-admin@postgresql.org>
Subject: Re: Hourly backup using pg_basebackup
References: <54D50D9B.1090905@gmail.com>
 <CAJghg4+JXVs1_k12M=Ozu_pzma0eBPQO++hA5b7C2vhXAh2-tg@mail.gmail.com>
 <54D51B08.5050901@gmail.com>
Date: Fri, 06 Feb 2015 15:12:28 -0600
In-Reply-To: <54D51B08.5050901@gmail.com> (John Scalia's message of "Fri, 06
 Feb 2015 14:50:32 -0500")
Message-ID: <86egq2hhhf.fsf@jerry.enova.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Precedence: bulk
Sender: pgsql-admin-owner@postgresql.org

John Scalia <jayknowsunix@gmail.com> writes:

> On 2/6/2015 2:25 PM, Matheus de Oliveira wrote:
>
>     On Fri, Feb 6, 2015 at 4:53 PM, John Scalia <jayknowsunix@gmail.com> wrote:
>    
>         We have a python script called by cron on an hourly basis to back up our production database. Currently, the script invokes pg_dump and takes more than hour to
>         complete. Hence the script looks to see if it's already running and exits if so. I want to change the script so it uses pg_basebackup instead since that's so
>         much faster.
>
>     Have you considered using incremental backup (continuous archiving) instead of a such small backup window?
>    
>     See [1]
>
>         My problem is, however, that while I'd like to just have it build a tarball, maybe compressed,  I can't use a "-X s" option for the wal segments. I think I
>         understand why I can't use the streaming option with a "-Ft" specified. I'm just concerned about the docs saying that the backup may have problems with fetch as
>         a wal segment may have expired. Manually testing is showing that the Db needs about 11 minutes to backup with pg_basebackup, and our wal_keep_segments setting
>         is 6.  This said, an hour's worth of wal segments should be available, but the six that were there at the beginning of the backup are not the same six there at
>         the end. I don't think this is really a problem, but I'd like to get it confirmed. Wouldn't the backup actually have to take more than hour for this to be an
>         issue?
>
>     If you use archiving [1], you don't need to worry about saving the segments withing the backup, just let it be done through archive_command. Isn't that an option
>     for you? If don't, why?
>
> Oh, yes, I did fail to mention that the system where I'm trying this is the primary in a streaming replication cluster with (2) hot standby servers. I've mentioned
> without much traction, that we don't really even need a backup with 3 servers ready to do the work without delays. Like I said in the last post, it's all political.

Er, yes you do.

Suppose someone/thing drops a table erroneously?

Do that and all dozens of your streamers are trash.


>
>     [1] http://www.postgresql.org/docs/current/static/continuous-archiving.html
>    
>     Best regards,
>     --
>     Matheus de Oliveira
>     Analista de Banco de Dados
>     Dextra Sistemas - MPS.Br nível F!
>     www.dextra.com.br/postgres
>

-- 
Jerry Sievers
Postgres DBA/Development Consulting
e: postgres.consulting@comcast.net
p: 312.241.7800


-- 
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin