Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\))
Subject: Re: PgBackRest and WAL archive expiry
From: Christophe Pettus <xof@thebuild.com>
In-Reply-To: <CAKgGyB_TfVHh+mg-6JpPLscGO0h8_9F=km_EmQHxb69BEmsiiA@mail.gmail.com>
Date: Thu, 19 Sep 2024 22:52:32 -0700
Cc: pgsql-general <pgsql-general@postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <267A05E2-4506-4012-870E-124DEF255C41@thebuild.com>
References: <CAKgGyB_TfVHh+mg-6JpPLscGO0h8_9F=km_EmQHxb69BEmsiiA@mail.gmail.com>
To: KK CHN <kkchn.in@gmail.com>
Archived-At: <https://www.postgresql.org/message-id/267A05E2-4506-4012-870E-124DEF255C41%40thebuild.com>
Precedence: bulk


> On Sep 19, 2024, at 22:46, KK CHN <kkchn.in@gmail.com> wrote:
>=20
> 1. In the  EPAS server    I have   postgres.conf with=20
> archive_command =3D 'pgbackrest --stanza=3DEMI_Repo archive-push %p && =
cp %p  /data/archive/%f'
>=20
> The problem is that the   /data/archive  folder is growing  within a =
few days to 850GB  of 2 TB  partition.

The /data/archive directory is entirely under your control.  pgbackrest =
and PostgreSQL don't manage them in any way.  It will just keep growing =
indefinitely unless you take action to delete the WAL segments out of =
it.

There's no real benefit in maintaining that separate /data/archive =
directory; pgbackrest archives and manages the lifecycle of the WAL =
segments in its repository.  I wouldn't bother with that separate =
archive, and just use pgbackrest.=