Re: Experience and feedback on pg_restore --data-only

From: Ron Johnson <ronljohnsonjr(at)gmail(dot)com>
To: "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Experience and feedback on pg_restore --data-only
Date: 2025-03-21 19:00:57
Message-ID: CANzqJaD_ef+jyX8=r+TLYyQ0Wzc2dQiPpcPC5nMx+ixGvaNzyw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, Mar 21, 2025 at 2:36 PM Dimitrios Apostolou <jimis(at)gmx(dot)net> wrote:

> On Thu, 20 Mar 2025, Dimitrios Apostolou wrote:
>
> > Rationale:
> >
> > When restoring a backup in an emergency situation, it's fine to run
> > pg_restore as superuser and get an exact replica of the dumped db.
>

How often do you have emergencies requiring database restore???? In my
seven years managing PG systems, I've had TWO.

> > AFAICT pg_restore (without --data-only) is optimised for such case.
>
[snip]

> > Any feedback for improving my process?

Yes: don't use a logical backup tool like pg_dump to backup production
databases.

PgBackRest (the tool I have experience with; there are others, though) has
mandatory features like PITR, incremental and differential backups, delta
restores and encryption. Use that instead.

To get rid of the cruft in your database, go through the schema and
manually drop unused tables.

--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Michael Paquier 2025-03-21 22:45:51 Re: query_id: jumble names of temp tables for better pg_stat_statement UX
Previous Message Tom Lane 2025-03-21 18:56:12 Re: After upgrading libpq, the same function(PQftype) call returns a different OID