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 1shFPW-00FBNj-Qv for pgsql-general@arkaria.postgresql.org; Thu, 22 Aug 2024 21:32:02 +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 1shFPU-005iFL-O4 for pgsql-general@arkaria.postgresql.org; Thu, 22 Aug 2024 21:32:01 +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 1shFPU-005iFD-Dc for pgsql-general@lists.postgresql.org; Thu, 22 Aug 2024 21:32:00 +0000 Received: from mail-yb1-xb36.google.com ([2607:f8b0:4864:20::b36]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1shFPN-0010jE-BD for pgsql-general@lists.postgresql.org; Thu, 22 Aug 2024 21:32:00 +0000 Received: by mail-yb1-xb36.google.com with SMTP id 3f1490d57ef6-e116b591e15so1343915276.3 for ; Thu, 22 Aug 2024 14:31:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724362313; x=1724967113; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=E5BiDIE4+f/mmvKyQHUqY8VvvxhXMmckNBvG8tJYjh0=; b=iZ3hZ2ayuDKEp0EaCyf99UjjMqywifaeOQEOSMAqsDu1Az+z57TGiyKJMeqW8YiEm1 sy9B/LXXEpwyvgvGQfM/HksnJHHtTO+PbMXWurinkx6cZEduE+FrR/Q7nYj452k37Ifu bANfsuTrOD8RwIFRrp3a3RrC6k0ptjtZkvuUraWxzpR7cPbv9OePNbWNZo4bnQYKP7Cj 1NLxH+6juv4fwM1DbBaRoDQy2P4g7yWuMJavRsF4If97Nio2tPEKO6onSSYZAbdzIeO6 IrwmWCwRFBAG+IJCvJ/JeMibkQNbKBXuLUznUUBPIJg14joxsgtMFRAEpfX9kHnDVQgc fHZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724362313; x=1724967113; h=cc: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=E5BiDIE4+f/mmvKyQHUqY8VvvxhXMmckNBvG8tJYjh0=; b=QqNl4PmlOTZTWj6EE/rKKX814h8STAyjjrvyEAYtgSVr6blPCL48KUGgq1F1KmEUxa ac7+N086VIlpG8fUgPQXiX1nWAWjsayNWWSX7pqvEytdz0HJf7wuUwD6pvQ+MR9ZskAp OubGdQ1kliQUQA22tbNGkHc5dQfwk522M4xQj772+mdgu9qncjT7DD/Jz+R9KPQH6C3c exwwY/2h4eP9De93LcX/7GDpx/4/N/pJ7YtFgQj09W+u3SkeqFgMBZ/xtZHYoniqCT/T tPGqC+rhySKqAp3Nmie/h4oJ34ScGrPePG2jbdJNvyal6iCuKiKOvNhkmavmTAeVeHQ0 0ySA== X-Gm-Message-State: AOJu0Ywmi7hNRgf+153NaaxBhBbso2dFQ6EHq5K7PuQR9bcgaJUmIq/3 AVOy9/UOB7e85Kf/J/aqkqgLh+nU6CoJlxT2wYY3rwdTy5Vi821zrgL0MaVsoBldRKlWFVzrxHd DGhMRQqRHPhMUcVcr6oKdUuSxokM= X-Google-Smtp-Source: AGHT+IFWUZr/rHBJPpE5DZdVSEo7BsHj52aguyOw/bP63Q3/WYknddJ1ReSKjmKyCEAD9laupHUUg34KH741ERgfWKQ= X-Received: by 2002:a05:6902:1688:b0:e13:cb58:dd15 with SMTP id 3f1490d57ef6-e17a88be25dmr349978276.8.1724362312697; Thu, 22 Aug 2024 14:31:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Vince McMahon Date: Thu, 22 Aug 2024 17:31:41 -0400 Message-ID: Subject: Re: How to validate restore of backup? To: "adrian.klaver@aklaver.com" Cc: "pgsql-generallists.postgresql.org" Content-Type: multipart/alternative; boundary="0000000000001ccdf406204c6331" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000001ccdf406204c6331 Content-Type: text/plain; charset="UTF-8" Hi, Adrian. The largest one is 8 GB after compression. I have a window of 8 hours to handle 30 GB total of backup at various sizes. On Thu, Aug 22, 2024, 11:36 AM Adrian Klaver wrote: > On 8/22/24 04:06, Vince McMahon wrote: > > Hi, > > > > I have some questions When doing pg_restore of backup of a database to a > > NEW server. > > How large a backup? > > > > > Is there a way to ensure the data integrity is in tact, and user ID and > > access works liked how it was in the old server? > > As to user access, write tests that cover that and run on the new cluster. > > Data is trickier and if that is possible to a degree of certainty is > going to depend on answer to the first question above. > > > > > How to properly handle the materialized views when backing up and > restoring? > > create materialized view prj_mv(p_item_no, year) as select p_item_no, > year from projection with data; > > pg_dump -d production -U postgres -h localhost -t projection -t prj_mv > -f prj.sql > > In prj.sql: > > CREATE MATERIALIZED VIEW public.prj_mv AS > SELECT p_item_no, > year > FROM public.projection > WITH NO DATA; > > COPY public.projection ( ... > > > [...] > > REFRESH MATERIALIZED VIEW public.prj_mv; > > It is done for you. > > > > > Thanks. > > -- > Adrian Klaver > adrian.klaver@aklaver.com > > --0000000000001ccdf406204c6331 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Adrian.

=
The largest one is 8 GB after compression.

I have a window of 8 hours to ha= ndle 30 GB total of backup at various sizes.
<= div dir=3D"auto">


On Thu, Aug 22, 2024, 11:3= 6 AM Adrian Klaver <adrian.klaver@aklaver.com> wrote:
=
On 8/22/24 04:06, Vince McMahon wrote:=
> Hi,
>
> I have some questions When doing pg_restore of backup of a database to= a
> NEW server.

How large a backup?

>
> Is there a way to ensure the data integrity is in tact, and user ID an= d
> access works liked how it was in the old server?

As to user access, write tests that cover that and run on the new cluster.<= br>
Data is trickier and if that is possible to a degree of certainty is
going to depend on answer to the first question above.

>
> How to properly handle the materialized views when backing up and rest= oring?

create materialized view prj_mv(p_item_no, year) as select p_item_no,
year from projection with data;

pg_dump -d production -U postgres -h localhost -t projection -t prj_mv
-f prj.sql

In prj.sql:

CREATE MATERIALIZED VIEW public.prj_mv AS
=C2=A0 SELECT p_item_no,
=C2=A0 =C2=A0 =C2=A0year
=C2=A0 =C2=A0 FROM public.projection
=C2=A0 =C2=A0WITH NO DATA;

COPY public.projection ( ...


[...]

REFRESH MATERIALIZED VIEW public.prj_mv;

It is done for you.

>
> Thanks.

--
Adrian Klaver
adrian.klaver@aklaver.com

--0000000000001ccdf406204c6331--