From: | Vince McMahon <sippingonesandzeros(at)gmail(dot)com> |
---|---|
To: | "adrian(dot)klaver(at)aklaver(dot)com" <adrian(dot)klaver(at)aklaver(dot)com> |
Cc: | "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: How to validate restore of backup? |
Date: | 2024-08-22 21:31:41 |
Message-ID: | CAKS+vVaBQu12o==EUS9XsnNMAMU6Rh+xn_Vxpa79dU0oVN+RgA@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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 <adrian(dot)klaver(at)aklaver(dot)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 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(dot)klaver(at)aklaver(dot)com
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | John the Scott | 2024-08-22 22:02:32 | Re: Planet Postgres and the curse of AI |
Previous Message | Robert Treat | 2024-08-22 21:13:17 | Re: Planet Postgres and the curse of AI |