MIME-Version: 1.0
References: 
 <CAKgGyB_TX8hNQFFpjFohFJnT=L78ACPoznrsLq9Wg6h3+Cnhmg@mail.gmail.com>
In-Reply-To: 
 <CAKgGyB_TX8hNQFFpjFohFJnT=L78ACPoznrsLq9Wg6h3+Cnhmg@mail.gmail.com>
From: Ron Johnson <ronljohnsonjr@gmail.com>
Date: Fri, 19 Jun 2026 08:48:31 -0400
Message-ID: 
 <CANzqJaC_oK8z+1vz_3FsZw-5j1xSUeQcdD0A6kFheMTOGAYESQ@mail.gmail.com>
Subject: Re: Can use NFS mount partition for Pgbackrest Repo -path ?
To: "pgsql-generallists.postgresql.org" <pgsql-general@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="00000000000077403f06549ab699"
Archived-At: 
 <https://www.postgresql.org/message-id/CANzqJaC_oK8z%2B1vz_3FsZw-5j1xSUeQcdD0A6kFheMTOGAYESQ%40mail.gmail.com>
Precedence: bulk

--00000000000077403f06549ab699
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 19, 2026 at 7:58=E2=80=AFAM KK CHN <kkchn.in@gmail.com> wrote:

> Hi folks,
>
> I am using the repo1-path as follows   for the pgbackrest  backup of more
> than 6 DB clusters in a single remote repo server as follows.
>
> ON MY REPO SERVER
>
> [global]
> repo1-path=3D/data/DB_BACKUPS
> repo1-block=3Dy
> repo1-bundle=3Dy
> repo1-retention-full=3D3
> repo1-retention-diff=3D3
> repo1-cipher-type=3Daes-256-cbc
> repo1-cipher-pass=3Dacbd
>
> The issue here is The repo1-path =3D  /data/DB_BACKUPS directory is the
> local file storage of this repo server (A Virtual Machine running RHEL 9.=
4,
> pgbackrest 2.25.1
>

Those are pretty old.  Lots of security bugs have been patched since 9.4
was released.  And really useful features added to pgbackrest after 2.25.1.


>  1. *Can I use this NFS mount point  /datanew  as the repo1-path for
> pgbackrest  to overcome the storage space shortage ?   *
>

Yes.


>  2. *What are the drawbacks  in doing this approach ?  *
>

You might occasionally have to stop pgbackrest and then restart the nfs
client daemon.


>  3. *What command line tool  to use  either   mv  or tar  command which
> is advisable and fast for copying all the existing /data/DB_BACKUPS
> archive and backup folders of the currently running backups of the six
> different production  Database clusters  to the new NFS mount point
> /datanew  by minimal downtime (If  the NFS mount point for repo1-path is
> possible/advisable ?) *
>

rsync.  That's always the solution.

Run it once (or twice or thrice) to move most of the data, then stop PG and
run it again to move the final bits of data and update pgbackrest.conf/


> 4.  *Also  setting permissions  for the repo server user ( in my case it
> is pgbackrest itself)  for the NFS mount point is straight forward or do =
I
> need to set permissions differently  in the NFS server side and client VM
> side also ?* ( sorry for ignorance).
>

You'll see soon enough, if the rsync fails with a "permission denied" error=
.

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

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

<div dir=3D"ltr"><div dir=3D"ltr"><span style=3D"background-color:transpare=
nt">On Fri, Jun 19, 2026 at 7:58=E2=80=AFAM KK CHN &lt;<a href=3D"mailto:kk=
chn.in@gmail.com">kkchn.in@gmail.com</a>&gt; wrote:</span></div><div class=
=3D"gmail_quote gmail_quote_container"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><div dir=3D"ltr"><div>Hi folks,</div><div><br></div><div>I am=
 using the repo1-path as follows=C2=A0 =C2=A0for the pgbackrest=C2=A0 backu=
p of more than 6 DB clusters in a single remote repo server as follows.</di=
v><div><br></div><div>ON MY REPO SERVER</div><div><br></div><div>[global]<b=
r>repo1-path=3D/data/DB_BACKUPS<br>repo1-block=3Dy<br>repo1-bundle=3Dy<br>r=
epo1-retention-full=3D3<br>repo1-retention-diff=3D3<br>repo1-cipher-type=3D=
aes-256-cbc<br>repo1-cipher-pass=3Dacbd<br></div><div><br></div><div>The is=
sue here is The repo1-path =3D=C2=A0 /data/DB_BACKUPS directory is the loca=
l file storage of this repo server (A Virtual Machine running RHEL 9.4, pgb=
ackrest 2.25.1</div></div></blockquote><div><br></div><div>Those are pretty=
 old.=C2=A0 Lots of security bugs have been patched since 9.4 was released.=
=C2=A0 And really useful features added to pgbackrest after 2.25.1.</div><d=
iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div>=C2=A01.=C2=A0<span style=3D"background-color:transparent"><b=
>Can I use this NFS mount point=C2=A0 /datanew=C2=A0 as the repo1-path for=
=C2=A0 pgbackrest=C2=A0 to overcome the storage space shortage ?=C2=A0 =C2=
=A0</b></span></div></div></blockquote><div><br></div><div>Yes.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr"><div><span style=3D"background-color:transparent">=C2=A0</span><span st=
yle=3D"background-color:transparent">2. </span><b style=3D"background-color=
:transparent">What are the drawbacks=C2=A0 in doing this approach ?=C2=A0=
=C2=A0</b></div></div></blockquote><div><br></div><div>You might occasional=
ly have to stop pgbackrest and then restart the nfs client daemon.</div><di=
v>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D=
"ltr"><div><span style=3D"background-color:transparent">=C2=A03. </span><b =
style=3D"background-color:transparent">What command line tool=C2=A0 to use=
=C2=A0 either=C2=A0 =C2=A0mv=C2=A0 or tar=C2=A0 command which is advisable =
and fast for copying all the existing /data/DB_BACKUPS=C2=A0 =C2=A0 archive=
 and backup folders of the currently running backups of the six different p=
roduction=C2=A0 Database clusters=C2=A0 to the new NFS mount point=C2=A0 /d=
atanew=C2=A0 by minimal downtime (If=C2=A0 the NFS mount point for repo1-pa=
th is=C2=A0 possible/advisable ?)=C2=A0</b></div></div></blockquote><div><b=
r></div><div>rsync.=C2=A0 That&#39;s always the solution.</div><div><br></d=
iv><div>Run it once (or twice or thrice) to move most of the data, then sto=
p PG and run it again to move the final bits of data and update pgbackrest.=
conf/</div><div>=C2=A0</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><span style=3D"background-color:transparent">4.=C2=
=A0 </span><b style=3D"background-color:transparent">Also=C2=A0 setting per=
missions=C2=A0 for the repo server user ( in my case it is pgbackrest itsel=
f)=C2=A0 for the NFS mount point is straight forward or do I need to set pe=
rmissions differently=C2=A0 in the NFS server side and client VM side also =
?</b><span style=3D"background-color:transparent"> ( sorry for ignorance).=
=C2=A0</span></div></div></blockquote><div><br></div><div>You&#39;ll see so=
on enough, if the rsync fails=C2=A0with a &quot;permission denied&quot; err=
or.</div><div>=C2=A0</div></div><span class=3D"gmail_signature_prefix">-- <=
/span><br><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr">Death=
 to &lt;Redacted&gt;, and butter sauce.<div>Don&#39;t boil me, I&#39;m stil=
l alive.<br><div><div>&lt;Redacted&gt; lobster!</div></div></div></div></di=
v></div>

--00000000000077403f06549ab699--