On Fri, Jun 19, 2026 at 7:58 AM KK CHN <[email protected]> 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=/data/DB_BACKUPS > repo1-block=y > repo1-bundle=y > repo1-retention-full=3 > repo1-retention-diff=3 > repo1-cipher-type=aes-256-cbc > repo1-cipher-pass=acbd > > The issue here is The repo1-path = /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. -- Death to <Redacted>, and butter sauce. Don't boil me, I'm still alive. <Redacted> lobster!
