Standby Server and Barman Backup on production system

From: Sebastian Fiedler - Nexst4 GmbH <sebastian(dot)fiedler(at)nexst4(dot)de>
To: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Standby Server and Barman Backup on production system
Date: 2014-07-10 09:23:16
Message-ID: 53BE5B84.8040000@nexst4.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hello,
I had followed this discuss
(http://www.postgresql.org/message-id/CABRT9RAXzUa=_zT_M4Z1vyDuFkpgNCZLUnRTUO5gvK2kKkNu=A@mail.gmail.com).

I have a similar problem now:

I use one Postgres Server as Master an an other one as Standby (WAL
archives).
I do also a daily backup of the Master Server using pg_dump.
Now there is a situation where a possible restore via "cat dumpfile |
psql ...." takes to long and the server load is too high.

So my idea is to use barman for backup.
Is it possible to use wal replication and barman backupin one config file?
Is there someone how has experience with this?

The relevant barman (test)config looks like:

wal_level = archive
archive_mode = on
archive_command = 'rsync -a %p /var/lib/barman/btest/incoming/%f'

The relevant wal replication config on production system (master) looks
like:
wal_level = hot_standby
archive_mode = on
archive_command = 'rsync -a %p -e "ssh -i
/var/lib/postgresql/.ssh/id_rsa"
postgres(at)standby(dot)srv:/var/lib/postgresql/9.1/wals/master_main/%f </dev/null'

Can I use a 2'nd rsync command here? How should I do?
What are differences between "wal_level = archive" and "wal_level =
archive" or doesn't matter here?

--
Nexst4 GmbH
Riesaer Straße 7
01129 Dresden

Tel.: +49 (351) 655 76 64
Fax: +49 (351) 655 76 66
Mail: sebastian(dot)fiedler(at)nexst4(dot)de

Geschäftsführer: Matthias Schmidt, Alf Thiele
Sitz der Gesellschaft: Dresden
HRB 27274

Responses

Browse pgsql-general by date

  From Date Subject
Next Message basti 2014-07-10 09:24:03 Standby Server and Barman Backup on production system
Previous Message Chris Hanks 2014-07-10 09:01:31 Joining on a view containing a UNION ALL produces a suboptimal plan on 9.3.4