MIME-Version: 1.0
References: <CAKgGyB8JbhNJr4Y13CS-zu5Nk=4eZy6HeNwW0y0rW4j9XGpL4Q@mail.gmail.com>
In-Reply-To: <CAKgGyB8JbhNJr4Y13CS-zu5Nk=4eZy6HeNwW0y0rW4j9XGpL4Q@mail.gmail.com>
From: Greg Sabino Mullane <htamfids@gmail.com>
Date: Fri, 30 Aug 2024 08:45:56 -0400
Message-ID: <CAKAnmmJ7ESPd7N_3ve7GsBuRXUBvWhOSg2Kt3OifSG07QkDsLA@mail.gmail.com>
Subject: Re: PgBackRest full backup first time : Verification
To: KK CHN <kkchn.in@gmail.com>
Cc: pgsql-general <pgsql-general@postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000001e0b3b0620e5fbfd"
Archived-At: <https://www.postgresql.org/message-id/CAKAnmmJ7ESPd7N_3ve7GsBuRXUBvWhOSg2Kt3OifSG07QkDsLA%40mail.gmail.com>
Precedence: bulk

--0000000000001e0b3b0620e5fbfd
Content-Type: text/plain; charset="UTF-8"

>
> database size: 146.9GB, database backup size: 146.9GB
> repo1: backup size: 20.6GB


It looks to me as though everything is working as expected. You took a full
backup of your system, which was around 147GB - most of which is in a
tablespace. It got compressed down to 20GB. You then took two incremental
backups, which are by definition much smaller and take a short amount of
time to run.

I can't  restore back to the DB server right now to test it as it is a
> production server and down time granting is not immediately possible to
> test it ...
>

You do not have to restore to the same server or the same directory. You
can keep your production system running and do a test restore somewhere
else. Just make sure you specify --archive-mode=off (which prevents the WAL
from being shipped from the restored system to your existing production
repo)

[root@db1 data]# du -h
> returns   537 G
>

This is not relevant, as pgbackrest only cares about the Postgres data
directory (/data/edb/as16/data/)

149G    /data/edb/as16/tablespace/ESS


This is where the rest of your backup size is coming from. Postgres and
pgbackrest consider this part of the data directory.

You really should spin up a test Postgres cluster and get very familiar
with how pgbackrest works, rather than continuing to flounder about on a
production system and rely on mailing lists to answer a bunch of questions
for you. While we can answer these questions, you will learn better from
experimenting and trying things out yourself on a non-prod system.

Cheers,
Greg

--0000000000001e0b3b0620e5fbfd
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">database=
 size: 146.9GB, database backup size: 146.9GB<br>repo1: backup size: 20.6GB=
</blockquote><div><br></div><div>It looks to me as though everything is wor=
king as expected. You took a full backup of your system, which was around 1=
47GB - most of which is in a tablespace. It got compressed down to 20GB. Yo=
u then took two incremental backups, which are by definition much smaller a=
nd take a short amount of time to run.<br></div><div dir=3D"ltr"><br></div>=
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div dir=3D"ltr"><div>I can&#39;t=C2=A0 restore back to the DB server rig=
ht now to test it as it is a production server and down time granting is no=
t immediately possible to test it ...</div></div></blockquote><div><br></di=
v><div>You do not have to restore to the same server or the same directory.=
 You can keep your production system running and do a test restore somewher=
e else. Just make sure you specify --archive-mode=3Doff (which prevents the=
 WAL from being shipped from the restored system to your existing productio=
n repo)</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><div dir=3D"ltr"><div>[root@db1 data]# du -h<br></div><div>returns=C2=A0=
 =C2=A0537 G</div></div></blockquote><div><br></div><div>This is not releva=
nt, as pgbackrest only cares about the Postgres data directory (/data/edb/a=
s16/data/)</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">149G =C2=A0 =C2=A0/data/edb/as16/tablespace/ESS</blockquote><div><br>=
</div><div>This is where the rest of your backup size is coming from. Postg=
res and pgbackrest consider this part of the data directory.</div><div><br>=
</div><div>You really should spin up a test Postgres cluster and get very f=
amiliar with how pgbackrest works, rather than continuing to flounder about=
 on a production system and rely on mailing lists to answer a bunch of ques=
tions for you. While we can answer these questions, you will learn better f=
rom experimenting and trying things out yourself on a non-prod system.</div=
><div><br></div><div>Cheers,</div><div>Greg</div><div><br></div></div></div=
>

--0000000000001e0b3b0620e5fbfd--