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 1wepNE-00539b-0U for pgsql-general@arkaria.postgresql.org; Wed, 01 Jul 2026 07:28:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wepND-00COH6-0C for pgsql-general@arkaria.postgresql.org; Wed, 01 Jul 2026 07:28:43 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wepNC-00COGu-1t for pgsql-general@lists.postgresql.org; Wed, 01 Jul 2026 07:28:42 +0000 Received: from mail-vk1-xa34.google.com ([2607:f8b0:4864:20::a34]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wepN9-000000019jn-4AZK for pgsql-general@postgresql.org; Wed, 01 Jul 2026 07:28:41 +0000 Received: by mail-vk1-xa34.google.com with SMTP id 71dfb90a1353d-5bdbd631a6aso205083e0c.1 for ; Wed, 01 Jul 2026 00:28:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1782890917; cv=none; d=google.com; s=arc-20260327; b=sz8MpHnucMqHotPMYYvyPeIVe/O3HiganNOxod4KWO/1KqF+rlIlplW2RaxoXr/vJg iUK2Padp+FzLYVvllPufZl+sO+iX6zZTGZAiL8xQlH0/pl++XbDiN14xVK3X3VD560Wf SNcePRPHqzD2FJK3apFCfAVEjJ52bVePCYRv6tu0v6qhq0Q46SDs65FPL93jm0G6FfI6 CwwNOV6jhWPCWRyBml42z696/q0uoUENwitwbd+YM3vRbp7EnQy2DTObTnWijqJAoXOz 4D7kOaoDZYCkRnMmYvqyEpxFYR4FjtetJWllVvHFEGzCBvrYt/f6/6pa9YwHWWoVzPFR 2Pbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=IbMouImnqdf8hVaSi7iO2JFPvqSQMCwKVCrKAFo0ioI=; fh=uChVshp755b/V7QQr1ppagbmkl/2dxRB/45qV0dyigo=; b=doK7SyAoIhG7QVoOoxIq+EJe1DeBjV6VIR7vretYSxTiF3dKW4+iDl3TooL1Q/Oq64 csh2Pt1JA5RTkFIa9q03LBv5ZxexjJifU67ous0eTnY6QFtV5AHT/zMH4oKqW0XHUduZ y35dwA6AfNvbdDS02lbyKnKnFV/vJyHuWpp9Q7CqoIqbwZdA6Ozl9K/+AhY2hu+MdNbh v76dxX/Sc7C0HLa9o1cttk5hGT50ulIwu+i05vjcSdUch8EC+So7ZFETqL+rsytkaPjE 4jIrX9QxGQwZDAof0+SXhbKTQTocNeh2L0z5UXRG9pi9DVJxeiQRpj2f58Yk5A3HDi/l FxBQ==; darn=postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=opensource-db.com; s=google; t=1782890917; x=1783495717; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=IbMouImnqdf8hVaSi7iO2JFPvqSQMCwKVCrKAFo0ioI=; b=akbwGrTCdUgRI8Pb4cN/dDJBpUM2yPvjcpcYxL+NGMrpLoSt2mnwtSIc6hbyobh6wY Qo4MOVcMfZDASynjZGui5f612tBs1MIeCeYu6lwziDGBrTdF6+lVd1JivMc289+h+V0o +V1V/QRVIbBa352LzQNAsLAJYjHDkL9M5mAY6JlQI0b41pWy6D3DxlGL2hVVLwNR0Oha fUw7oegeS8vdRA7N5xjnZXj8heZrCVRYyHG1G5U6Ud4pu1YVTp1up31SphTOY9HG4aUC LUvIbkuRQ5y/B7XqaG06FE6wS0FmUCoGUPiQcoMMbBjjx1XYtPPn6Sa+6eTlP94IM7Nm n+uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782890917; x=1783495717; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=IbMouImnqdf8hVaSi7iO2JFPvqSQMCwKVCrKAFo0ioI=; b=fSpXBVw8MJARppNC+l+dDWVYcR6tfwARJubfleLRbaZvJadVyj90sMqKSfqHKYfczl 6xz9M+QTq9Iep8iaxxIVF4upKlzR1jUxmRohUR8c7suo1HwzS9oy/IgzlJsGX2TACYJp JkRHovPxLhQi5ZRpphvFCH59VODzZ8MuUhxW0/18Ai5mKWYZ7TGV6YggUwzrkEPFFglF sUWVnJndSZUjUU3ze2Qn7nmd0yEGzWLKTEWoRPadpu9qYQ5ISh2tOjqL4iS8QO92oX/W Jt8e7cs8gdWwLJ9KRNu9INnZE0S1Lk/qmNOzxPRyi72QPPZKAdX8PV3u1QaOCUwt3Ln2 5ZYQ== X-Gm-Message-State: AOJu0YzDD4ZdloSl4Ex3hb+SpQxFBtDltp+YbQaolYYYbqOCpMNOAFeM GJrHq8n5+W8pse/xOhWZJEdXUXcHgTpZWmlKgmim1h8qnWIPsbaAF8sFYIuJBgritK9QKoOngLY yKR1OLFAvEv8rhH3yD6QBsCgBiQClk02/Jj48KdFwJw== X-Gm-Gg: AfdE7ckr9XQKOIRlyjFZ/gaMdMFLJD83Qrkgss3KkhSM51hf+fCz7BAlDka0vQEp5hO A2CmxKuZ6yFReCcn0V8oxrIWMZoFxeBXT3bMHG5YSo6NW7XiCkeDrM1n8wjMsrGGKaCXuZp2c5M EXR2dK0sQ8+VEkrJrno0m1kQdaO/FglA45z4DAT0izSO9J2xc3D0XJEGtkHC6xBkMRBbzF9ZyYT ezKWlurqn321ZIzvVasgVouPtOBl//ek+LYU58/ugGAnqZUPwqJn1FM/tzjSfdsQUuDTdDltOua DGjOkw== X-Received: by 2002:a05:6122:4b8e:b0:5a1:b296:78fc with SMTP id 71dfb90a1353d-5bdde653405mr154427e0c.1.1782890917158; Wed, 01 Jul 2026 00:28:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Venkat Akhil Pavuluri Date: Wed, 1 Jul 2026 12:58:24 +0530 X-Gm-Features: AVVi8Cdz28bEd8-GH3o6YSqWC-DjhtSRrSNqHvqOuLr2vE0tLaaKpfZNIzsmawI Message-ID: Subject: Re: Postgresql Wal archive and Barman setup To: sa sa Cc: pgsql-general@postgresql.org Content-Type: multipart/alternative; boundary="000000000000ca74c9065587a398" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000ca74c9065587a398 Content-Type: text/plain; charset="UTF-8" Hi sa sa, As per the best practices, maintain different mount points for the data directory and the archive location. In your case, data_directory is `/srv/data` and the archive location is `/srv/archive`, meaning both reside on the `/srv/` mount point. If your archive location is on a different mount point, your archives will fail (which will have its own repercussions) but your cluster will remain operational. And also having alert system to send mails will help you as Masheed said. Thanks and Regards Venkat Akhil P OpenSource DB Your Trusted Data Partner On Wed, 1 Jul 2026 at 02:06, sa sa wrote: > Hello All, > > I have a scenario, where I need some suggestions and improvements if > applicable. > > Our setup in brief > 1) Primary --> standby > using archive_command = rsync to primary local location and standby > local location > 2) Primary --> Barman > Using streaming. Barman backup location is /nfs/DD9 > 3) Archive cleanup on primary is setup via crontab to every 14 days. > > Here is my scenario, If my barman nfs is down for 5 days and my local > archive location is filled up during this time. what will happen. > > if my /srv/archive (location archive wal location) on primary and standby > is 100% full during this time. > my /srv/data is going to be 100% full , causing my cluster to go down. > > So what are the suggestions to avoid this situation. > > Thanks, > Sa > --000000000000ca74c9065587a398 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi sa sa,

As per the best practices, maintain = different mount points for the data directory and the archive location. In = your case, data_directory is `/srv/data` and the archive location is `/srv/= archive`, meaning both reside on the `/srv/` mount point. If your archive l= ocation is on a different mount point, your archives will fail (which will = have its own repercussions) but your cluster will remain operational.=C2=A0=

And also having alert system to send mails will help you as Masheed= said.

Thanks and Regards
Venkat A= khil P
OpenSource DB
Your Trusted Data Partner

<= /div>
On Wed, 1 Jul 2026 at 02:06, sa sa <ssmaugust@gmail.com> wrote:
Hello All,
=
=C2=A0I have a scenario, where I need some suggestions and i= mprovements if applicable.

Our setup in brief
1) Primary --> standby
=C2=A0 =C2=A0 using archive_comma= nd =3D rsync to primary local location and standby local location
2) Primary --> Barman
=C2=A0 =C2=A0 Using streaming. Barman b= ackup location is /nfs/DD9
3) Archive cleanup on primary is setup= via crontab to every 14 days.

Here is my scenario, If my barman nfs is dow= n for 5 days and my local archive location is filled up during this time. w= hat will happen.

if my= /srv/archive (location archive wal location) on primary and standby is 100= % full during this time.=C2=A0
my /srv/data is going to be 100% full , causing my cluster to go do= wn.

So what are the suggestions to avoid = this situation.

Thanks,
= Sa
--000000000000ca74c9065587a398--