Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sh8rq-00DSoD-UA for pgsql-general@arkaria.postgresql.org; Thu, 22 Aug 2024 14:32:50 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sh8ro-0030EE-JV for pgsql-general@arkaria.postgresql.org; Thu, 22 Aug 2024 14:32:49 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sh8ro-0030E5-8W for pgsql-general@lists.postgresql.org; Thu, 22 Aug 2024 14:32:48 +0000 Received: from mail-oo1-xc2b.google.com ([2607:f8b0:4864:20::c2b]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sh8rl-000xoB-Gw for pgsql-general@lists.postgresql.org; Thu, 22 Aug 2024 14:32:48 +0000 Received: by mail-oo1-xc2b.google.com with SMTP id 006d021491bc7-5d5c7f23f22so575447eaf.0 for ; Thu, 22 Aug 2024 07:32:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724337165; x=1724941965; darn=lists.postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=mJQQ4utEOJQum1c9ntiANllynPOIo/V6Ggwyxohvyt0=; b=aKYjQxbiKiuVfUEMPcjcr36jfHtNCUdxQJhMlDyj+SPW2sEFXuHhWm0/dz70lcXTnp 0h0l7Yl3tC8lH+F3PEf3oAAmNH3bauK69PGFuozD7uSsq5U2a+rQHjYqDfPXqu61voaF wiO1EMKxleaVofGHJNeSCmNKlgiHHhv7M9w0a4Qu80k4QpCY8s7gH4st2YpgneHlTdJa BSle+Fh23JOipjrzNlYxticWqPjic4TmHmGS4pSIbzXODbrFPYJGttH1+C4zwTEi2QOY n9/Wj8X3NX8iyUSpWzzzGkpRd53uoNeU4Xg+/ZeMqoZ57w3u3BoHs2cSfGPhD0FUdS/T RoaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724337165; x=1724941965; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=mJQQ4utEOJQum1c9ntiANllynPOIo/V6Ggwyxohvyt0=; b=qWhr73vbbIrN8K9hamX5ZgBmLrw/H1gg/OHcnJqlcpkc/nErU/Clt9NdW2dBh3ADmj fMHvnfoF0hMoBGXhT+J+zGQznJBC7VYFJHzvP6Y1vmm6cA5EJZEoXP7bcLdiqtpaIlg0 1oCf0xVyPb+CbzaM2o3TdFqK+FlV38+DTaoMoSHPH2DoKMHubojOmbeFPRRhNq/MIrNr vwjIqsTkRLmR8HTuS/NTLZR2mX+rDAPHXfD6UI4vzOK5vW36aIElvn8ZF4MSQ1CgGjjF jfIHO7PVlkbD5jDjd3lnw5ppJX7tAms0BqrNiRoFMqUQlK++iPVlx2t3zG80rjtXcSYG FTKw== X-Gm-Message-State: AOJu0YzVt+WJitgiv51fgnrIT8Q3durPmBXfv+WDFo7cQQnaD8XfzIuD MhM9EO257LhP9z9In510CO/8IeFT5hj3mjMZvVKmyNHY3pPX9rNvTVw4ar+HV3D/VFvqEHmSy6C Klfe987KSNpmj2zlsXj3sLPtNRLsbhQ== X-Google-Smtp-Source: AGHT+IFdbqyfqUqaURspCu69FYUbnZcd8zywillNswiZfKJa8iXXD0K4nrpbY06TqETofaP1Ro/AXJ6GpsFNllCnGos= X-Received: by 2002:a05:6820:2228:b0:5ce:d2e3:b18 with SMTP id 006d021491bc7-5dca069d8b0mr6335574eaf.8.1724337164771; Thu, 22 Aug 2024 07:32:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ron Johnson Date: Thu, 22 Aug 2024 10:32:33 -0400 Message-ID: Subject: Re: How to validate restore of backup? To: "pgsql-generallists.postgresql.org" Content-Type: multipart/alternative; boundary="0000000000002de869062046882d" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000002de869062046882d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Aug 22, 2024 at 10:22=E2=80=AFAM Greg Sabino Mullane wrote: > On Thu, Aug 22, 2024 at 8:49=E2=80=AFAM o1bigtenor = wrote: > >> >> >> On Thu, Aug 22, 2024 at 6:24=E2=80=AFAM Ron Johnson >> wrote: >> >>> That's great on small databases. Not so practical when they're big. >>> >>> So - - - - what is the recommended procedure for 'large' databases? >> > > Use a real backup system like pgBackRest. Stop using pg_dump. > Not useful when you're migrating not only between major versions but glibc levels. Use logical replication!! Maybe. It gets difficult with partitioned tables that regularly have children added and dropped; mistakes can be made. pg_dump/pg_restore is guaranteed to work. --=20 Death to America, and butter sauce. Iraq lobster! --0000000000002de869062046882d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Aug 22, 2024 at 10:22=E2=80=AFAM = Greg Sabino Mullane <htamfids@gmai= l.com> wrote:
On Thu, = Aug 22, 2024 at 8:49=E2=80=AFAM o1bigtenor <o1bigtenor@gmail.com> wrote:
=


On Thu, Aug 22, 2024 at 6:24=E2=80= =AFAM Ron Johnson <ronljohnsonjr@gmail.com> wrote:
That's great on = small databases.=C2=A0 Not so practical when they're big.

So - - - - what is the recommended procedure for 'l= arge' databases?

Use = a real backup system like pgBackRest. Stop using pg_dump.
=
=C2=A0
Not useful when you're migrating not= only between major versions but glibc levels.

Use= logical replication!!=C2=A0 Maybe.=C2=A0 It gets difficult with partitione= d tables that regularly have children added and dropped; mistakes can be ma= de.=C2=A0 pg_dump/pg_restore is guaranteed to work.

--
Death to America, and butter sauce= .
Iraq lobster!
--0000000000002de869062046882d--