From: Stephen Frost <sfrost@snowman.net>
To: Alvaro Aguayo Garcia-Rada <aaguayo@opensysperu.com>
Cc: pgsql-admin@postgresql.org, Luis Marin <luismarinaray@gmail.com>
Subject: Re: PostgreSQL Backup Strategies
Date: Thu, 22 Feb 2018 06:59:40 -0500
Message-ID: <20180222115940.GE2416@tamriel.snowman.net> (raw)
In-Reply-To: <aqm0ckut7fsf67hqeupu7k74.1519268886459@email.android.com>
References: <CAEp6HQVHATX7yjYtdbVcOf0_03ZAxmEVKo=E1WG+y5rkok76jA@mail.gmail.com>
<aqm0ckut7fsf67hqeupu7k74.1519268886459@email.android.com>
Greetings,
* Alvaro Aguayo Garcia-Rada (aaguayo@opensysperu.com) wrote:
> Sorry I have no book to recommend, but my recommendation will always pass through pg_basebackup, which will perform a full backup of you running database without needing to stop anything, and will also(with adequate args) add all transactiins committed zuring the backup to the backup itself.
Note that you *must* ensure that the write-ahead-log / xlog is captured
for the duration of the backup, regardless of how you do the backup.
The above seems to imply that you only need to if you want the
transactions committed during the backup- that is *not* the case, you
need the WAL to have a *consistent* backup. Without the WAL, the backup
isn't consistent and isn't valid and therefore can't be used.
> I do myself use pg_basebackup and a simple shellscript to do automated backups of a production system.
pg_basebackup with the --xlog or --wal option is a good way to get a
snapshot of a running database. You can also use archive_command or
pg_receivexlog / pg_receivewal to collect the WAL but then you have to
verify that you have all of the WAL generated during the backup.
> I've also heard about pgbarman, but have no knowledge on it.
For doing file-based backups of PG, you should definitely be using an
existing well maintained PG backup implementation, such as pgBackRest,
barman, or perhaps WAL-E/WAL-G. These have, literally, years of
development resources put into them to make sure that the backups taken
are consistent and valid (though you should also, always, be testing
your backups). Unless you're planning to invest serious time
understanding all of the details involved in taking a backup of PG, I'd
strongly recommend you use an existing solution.
If you're looking for logical backups, there's also pg_dump, of course,
but you can't do point-in-time-recovery with pg_dump in the same way you
can with a file-based backup, and restore time is longer as indexes have
to be rebuilt and constraints re-checked with pg_dump.
Thanks!
Stephen
Attachments:
signature.asc (application/pgp-signature, 818B) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-admin@postgresql.org
Cc: sfrost@snowman.net, aaguayo@opensysperu.com, luismarinaray@gmail.com
Subject: Re: PostgreSQL Backup Strategies
In-Reply-To: <20180222115940.GE2416@tamriel.snowman.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox