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.96) (envelope-from ) id 1waXrX-001scr-0y for pgsql-general@arkaria.postgresql.org; Fri, 19 Jun 2026 11:58:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1waXrV-00FmEp-0E for pgsql-general@arkaria.postgresql.org; Fri, 19 Jun 2026 11:58:17 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1waXrU-00FmEh-1w for pgsql-general@lists.postgresql.org; Fri, 19 Jun 2026 11:58:16 +0000 Received: from mail-ed1-x52a.google.com ([2a00:1450:4864:20::52a]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1waXrS-000000018OB-3sMp for pgsql-general@lists.postgresql.org; Fri, 19 Jun 2026 11:58:15 +0000 Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-6976b0c5adbso324804a12.2 for ; Fri, 19 Jun 2026 04:58:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781870291; cv=none; d=google.com; s=arc-20240605; b=NfAlxpx3WrNBoRQ0pLhhe1ifeQRuc65kZ9Fr28UkecCEhRa8xdF1zpWEog39n3/At5 1hFeSnOtZZDkM8pIxV5FloF6GASBw8wDjZwR5CokyPEsVcmPKzA3TRHcwnAxdUdbuLR2 OhXgrv/csWc+hbIApkTomSKiNHo4DmJPlEa19kTaGsbNPR2FRKuTqW0FNXK1ePL5K1Xa OarRTBt54pwasE7KaF7CpGc+XEMBSfgVdtADqCPwOW1ba8ZGt+fSKw1PNhNdyeql6WFd zPJaBJbI9o5UTmbd+PTI2BrIj+HsjB7u+wBhEF2FcvQs2eJJ9VkBBRwsHsebnYo3rRfq stxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=Jxo80PUB4KDPk8orEpWWYvAqqLeI9KdvxaEtZzNOB2Y=; fh=4rCG0PM8n0FOokGy8sSWDJpgPdCgp6yIXcpABJ7tUh0=; b=ccIcqNTiNXacJOxKFLInFR+E6S1HyDQZPLNUD8rPUwKQqSsb1Na6/l89TxjIYV1PFw HnvUWNTrgLdSvyUY8HMRVg96Y5ZHTPzlxnYG5rkbQ04sxhQJkhKd8U/qpL1x6wX6IO+9 n4UyD4KfE0ndbo1ta6H2tm/mKc5KRFnP3z2EhGKVe9JvgtX0Lnw7XpeclmlumuVclenk EC4Kw7tv3w2o2IlnfExBV1wNO5AMIjoNFtFmwO9y/6KFno9cc8MFg8qfAycc6SutDLua mJTeci393W2cwQA87J2Z3f4yzmXpm+s8mQeFXgiyGyjfyZoFU5EigjTpiY/dPfCNTcDh os7A==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781870291; x=1782475091; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=Jxo80PUB4KDPk8orEpWWYvAqqLeI9KdvxaEtZzNOB2Y=; b=NmT37+Md6PP5kTjqnqR8gdBPNLQtglpOwPWXGvocKzd/v6kqmbBIhTMErjrZhexHzv VMIrseKG3P+KLfkpZ4xTxEfU42eGtjEU8WOXTxDD2G2WeTb/oIQj7v3R0CP9SFVwCVXN NGliTqDTUtVQmbMWr3EsRDEKi7D4R3He7NKOf0D/O2jzxtVcW4tW2hJ0Gghg2lFKMhfv v19Oz5GQSsqQsRlKNhHhdRXUQl7qU6MGuIOYRypBlM0jo0dDOTsVRFpQWTKRYQUuB7I2 //xOZi13m1XIt5jIEPRpQ/ROQgQyi8AKR288GtjAi56ZpUH9ORJRZfu663s9V2AxVIkD A+hQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781870291; x=1782475091; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Jxo80PUB4KDPk8orEpWWYvAqqLeI9KdvxaEtZzNOB2Y=; b=AWyZD4aq2K5zlSJ60XlrHUlTh2hhcMKYW7BQlviAuogZzjIVtQm0y/v/PVPuiCHg1+ 4pLQZ0LTXOBpTAfAeEbvAmvdnAYadrWbX04XOBvYieEk2HWph+E2/99kdTMVl2rGsqsv /w581wV30GpbxPktJnQM9hMR+stX83yS6bc6K7t3los5uoR82HHLfljti9q1W4JRVVsN qwQo/Hd9sbE3nxWz5of1gyJ3iboG0caax/Q9sv3cXXlKQsAA9xrtZozYGM0WkuTUgT2L Q5/xmZuzZbTvRq7FpuhYevYdNHjPz5HSMnaV8qQAjN/yhcTh074fPnPVioxBogeXRorq 1ieA== X-Gm-Message-State: AOJu0Yy4bX5JmJ3XW04U1CwSpm2hAuOCqBwEljeUxcCzHl1vpaX9gMwd ALhNI/ZS96s9AWMLHeEZpOXWNnvrhRvdWtc7AZjh0Tlzja547srPixFI1zcL5h6ERf0BuLWLyUZ w3k0cnwGueG3fOpDm9VBvkOxdHBY21p64ZA9m X-Gm-Gg: AfdE7ckhpjjpe3DTMgoMnreH7yUKpSFApA2GzK1DNCJ8UbegFjtd0Nid+v4OCGx6PvE p/akjHXMAu3P8CKGshGPvEcQgDlyBuOILvy1JYoQ2v0D30POCasFaeBEHi6ejymHVTSQQ1yLPmv U3mmD73brncU0IuKRlH47QDMnvInWxJZtcuNa7lMtnyAyJJ0oDoPedYywn0FAucOkg5Af2s82/0 20mJurprDXVjaPqtpG5zW11P3GW5EiQNpdDJ7AEtFVrQBaTxUuYE6S/sZQCNatWCuA73pK0mg== X-Received: by 2002:a05:6402:35cd:b0:697:3bb9:11ae with SMTP id 4fb4d7f45d1cf-69756789074mr931614a12.19.1781870291419; Fri, 19 Jun 2026 04:58:11 -0700 (PDT) MIME-Version: 1.0 From: KK CHN Date: Fri, 19 Jun 2026 17:36:12 +0530 X-Gm-Features: AVVi8CfyCaIxBlKcwMoQhSHh8q61l0lz-AvoXBfQk7HJE007ohe7jtFbLBZ7B50 Message-ID: Subject: Can use NFS mount partition for Pgbackrest Repo -path ? To: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000c1846606549a012c" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000c1846606549a012c Content-Type: text/plain; charset="UTF-8" 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, PG16) which is almost 83 % full now. . Note: */dev/mapper/rhel-data 15T 13T 2.6T 83% /data is almost getting full and it is not possible to extend the local storage partition further. * *To overcome the storage space, my sys admin added an NFS mount point from an external storage as follows.* 10.255.254.113:/Data 51T 384K 50T 1% /datanew this is with 50 TB space. *My Query is :* 1. *Can I use this NFS mount point /datanew as the repo1-path for pgbackrest to overcome the storage space shortage ? * 2. *What are the drawbacks in doing this approach ? * 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 ?) * 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). PS: - Any hints and directions much appreciated to correct myself, If I am doing wrong/direction. Thank you, Krishane. [root@dbbackup ~]# df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 4.0M 0 4.0M 0% /dev tmpfs 16G 0 16G 0% /dev/shm tmpfs 6.3G 655M 5.7G 11% /run /dev/mapper/rhel-root 100G 38G 63G 38% / */dev/mapper/rhel-data 15T 13T 2.6T 83% /data // Getting full*/dev/sda2 960M 265M 696M 28% /boot /dev/sda1 599M 7.1M 592M 2% /boot/efi tmpfs 3.2G 36K 3.2G 1% /run/user/1001 tmpfs 3.2G 60K 3.2G 1% /run/user/0 *10.255.254.113:/Data 51T 384K 50T 1% /datanew // New NFS mount point added 50T*tmpfs 3.2G 52K 3.2G 1% /run/user/42 [root@dbbackup ~]# --000000000000c1846606549a012c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

I am using the rep= o1-path as follows=C2=A0 =C2=A0for the pgbackrest=C2=A0 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-retenti= on-full=3D3
repo1-retention-diff=3D3
repo1-cipher-type=3Daes-256-cbc<= br>repo1-cipher-pass=3Dacbd

The issue here is = The repo1-path =3D=C2=A0 /data/DB_BACKUPS directory is the local file stora= ge of this repo server (A Virtual Machine running RHEL 9.4, pgbackrest 2.25= .1, PG16) which is almost=C2=A0 83 %=C2=A0 full now.=C2=A0
.
Note:=C2=A0 =C2=A0/dev/mapp= er/rhel-data =C2=A0 15T =C2=A0 13T =C2=A02.6T =C2=A083% /data=C2=A0 =C2=A0i= s almost getting full=C2=A0 and it is not possible to extend the local stor= age partition further.=C2=A0

To overcome the storage space,=C2=A0 =C2=A0= my sys admin added an NFS=C2=A0 mount point=C2=A0 from=C2=A0 an external st= orage as follows.

10.255.254.113:/Data =C2=A0 = =C2=A051T =C2=A0384K =C2=A0 50T =C2=A0 1% /datanew=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0this is with 50 TB space.=C2=A0


<= /b>
My Query is=C2=A0 :

=C2=A01.= =C2=A0Can I use this NFS mo= unt 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
=C2=A0
2. What are the drawbacks=C2=A0 = in doing this approach ?=C2=A0=C2=A0

=C2=A03. What command line tool=C2=A0 to use=C2=A0 e= ither=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 bac= kup folders of the currently running backups of the six different productio= n=C2=A0 Database clusters=C2=A0 to the new NFS mount point=C2=A0 /datanew= =C2=A0 by minimal downtime (If=C2=A0 the NFS mount point for repo1-path is= =C2=A0 possible/advisable ?)=C2=A0

4.=C2=A0 Also=C2=A0 sett= ing permissions=C2=A0 for the repo server user ( in my case it is pgbackres= t itself)=C2=A0 for the NFS mount point is straight forward or do I need to= set permissions differently=C2=A0 in the NFS server side and client VM sid= e also ? ( sorry for ignorance).=C2=A0


PS: -=C2=A0 Any hints and directions much appreciated to correct my= self, If I am doing wrong/direction.=C2=A0=C2=A0

<= br>
Thank you,
Krishane.=C2=A0



[root@dbbackup ~]# df -h
Filesystem =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Size =C2=A0Used Avail Use% Mounted on
de= vtmpfs =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 4.0M =C2=A0 =C2=A0 = 0 =C2=A04.0M =C2=A0 0% /dev
tmpfs =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 16G =C2=A0 =C2=A0 0 =C2=A0 16G =C2=A0 0% /dev/shm<= br>tmpfs =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A06.3G= =C2=A0655M =C2=A05.7G =C2=A011% /run
/dev/mapper/rhel-root =C2=A0100G = =C2=A0 38G =C2=A0 63G =C2=A038% /
/dev/mapper/rhel-data =C2=A0 15T = =C2=A0 13T =C2=A02.6T =C2=A083% /data=C2=A0 =C2=A0// Getting full
/d= ev/sda2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0960M =C2=A0265M =C2= =A0696M =C2=A028% /boot
/dev/sda1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0599M =C2=A07.1M =C2=A0592M =C2=A0 2% /boot/efi
tmpfs =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03.2G =C2=A0 36K =C2= =A03.2G =C2=A0 1% /run/user/1001
tmpfs =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03.2G =C2=A0 60K =C2=A03.2G =C2=A0 1% /run/us= er/0
10.255.254.113:/Data =C2=A0 =C2=A051T =C2=A0384K =C2=A0 50T =C2= =A0 1% /datanew=C2=A0 =C2=A0// New NFS mount point added 50T
tmpfs = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03.2G =C2=A0 5= 2K =C2=A03.2G =C2=A0 1% /run/user/42
[root@dbbackup ~]#=C2=A0

--000000000000c1846606549a012c--