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 1vxgBP-00H23K-1u for pgsql-general@arkaria.postgresql.org; Wed, 04 Mar 2026 06:58:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vxgBO-00ArBP-0B for pgsql-general@arkaria.postgresql.org; Wed, 04 Mar 2026 06:58:10 +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 1vxgBN-00ArB0-1y for pgsql-general@lists.postgresql.org; Wed, 04 Mar 2026 06:58:10 +0000 Received: from mail-oi1-x234.google.com ([2607:f8b0:4864:20::234]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vxgBM-00000000KW9-0QjZ for pgsql-general@postgresql.org; Wed, 04 Mar 2026 06:58:09 +0000 Received: by mail-oi1-x234.google.com with SMTP id 5614622812f47-45f18e8f2f5so4239451b6e.3 for ; Tue, 03 Mar 2026 22:58:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1772607486; cv=none; d=google.com; s=arc-20240605; b=XtuBJPxz0CZmDeOVSznMqI45WVGK2aEr6AcuhO9zVzMiDtthJ5qEwm4ICGtRWTje3r S0p4dEBOOZEfhVXl5ahbHLV7FwIPH0I79ShoitHvYfiHFs1gyebjU6hZNgh/GBw1Pnus b0AsNdJiE2idimGxQU5WZJ6TBEyuJqMnPcWO+dX/2d77H8EVU/56Ai59xt2u3QRLXvhT 9o3l2QBImhXS18YuaWRqRoW4Vxr6rpbVKeUWiVUNtSCAb3GjHcsYddCCAcS2VnryKtax fQWoR2zTADMEJvI3jOFJll9QLCv2h2Pmd7U/dunl7oQGq27X2FT1MlBa3ulDRTFk2lDH eisw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=WC174V6QK9VGhGffZ/HYRqIUcp+drGA8ofa7lRYpE9M=; fh=KNSq+t9BltSXFnT3Yof/aKGBtqxeA+bTALiYdvTslaY=; b=IDihplOxxyFZ0kCKVDJ9fMQE/cwmupNy7zhS6uHO14HUfYGyv6Y7/dqEUaHZtndgXv cyYHauVF6b7qzEEsUCafhNUqENFgaITZWy8h/XNu5RrWZ6D2YPAZqOaambq0umuNfrhE c13nUfq+jziKCBqFX4fveQs5+3y41UqOvdzsCgyQrta+SrSdKTLRj3GaFUo3YE8lhQA7 UlPlMcskmEZSMsVIO6a4kccWZv0kbE1Z37EzlPbC6TRn5MkHZrWc7vTJD2oNlvKBfiF4 LAABBaNHQHbk6KUtCL4JPYGK/6oF1fVTFj5UmR1CF0d7hje/Y5qzApUJ4CHdTW4aDADb RCkQ==; darn=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=20230601; t=1772607486; x=1773212286; darn=postgresql.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=WC174V6QK9VGhGffZ/HYRqIUcp+drGA8ofa7lRYpE9M=; b=U5umre5XrVVcxL8yr2RnV0UunvW/M4pz096bXzsSTU3nGY4l7V5DwsZqc7wo7dQQij 6TLtqc1uvmf6cxsAqdgWolqsnhbQMgZeCRwhh1w02SF/KMr8oA7xs3HmFDqs10SNfoXk DVV9lW5kISHm9pkoQqYipQzqNzZJItn+GW/ut8wPwMBdNNOvYrHBOOpWV/nd7VLZfZF7 vk4jsxqpT/jR3VsbwuPMjeorsdBLHWnTElAO7bXeWiYpFMf7ulg/2b60dEuMY3mwGILe nO01N8DXms8LBT4NlxfRttcMSPoTA+y0yJp/I7qbPPqx4ugciYkCd3HXBVHqBbmah5o4 V1qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772607486; x=1773212286; h=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=WC174V6QK9VGhGffZ/HYRqIUcp+drGA8ofa7lRYpE9M=; b=dMAuLhTjVypiQN7mC4DwsyILjdQVZ9IHSy9mTVLufcptKk/cQCuquSRn5DOnlXOayn uu5hC+bVZ1NE7TvXfgb/8tyqgW6cvf56homFmgp0z8aXQhqLFQgrgg1jTUNrws6J2W7K O0VPCZw54EGm/VxWz1GHfIa5qj2I6ImgiJ6flzaKhblptgE0/dJaMSZl7Fb021EDywk7 qnpk6SlmwscSR0rbDZttGCCzDn3a4QLgGlE8SFEGh6wQKo6FqYYkX0lUWUPquFbJPzSL wLhaIW/KPXdTH3xIzYlxms6h1gOIcx+W9d64BcPDycDJjIFJ3AJyIe5NJwqV3jBN3V1H paFQ== X-Gm-Message-State: AOJu0YyyIw/obz8h+qawI9dTG/hjW0AK2iu7d9hhmHdy5HXXCVVGcGVY ou17tBEgYlYYHicop4UTFe4sI6gHnAdBXzUhuQjoXoc0USb6EmpSmTNEcziTz9Kg8cu5ZHp6MVt p0XLdUvNa5xVgoe9bds3POXXJhKIlPNtoDqd5 X-Gm-Gg: ATEYQzwjggDUQlpLDx7JBg4sxxHYCllFZuzUxNwGyuTdbKSRa0RqiwKPfINO/Vxehv+ I0qPJl+Y4dk1kdSwsmqCegHG8fRLWNlDiKbAeqaGSoqVEaufo9FYORiaulGzpbtB0/de3+welV8 x2XwyVQO3izb7CewCC+/BPt4rKL+OQaQ/kGX1qWhEJUPQ8iy+Ud96k2pyAe8PVZKBMkBAwq8VZo DtoIuEEzFMkWjLEmiaLJ4620sG7JDB8rGoUhAugpt9ZwH5V0qJxdyENsRttILoZdwl1vizn22Pr EoM2lxBn X-Received: by 2002:a05:6808:4f62:b0:45a:8d42:646f with SMTP id 5614622812f47-4651adce717mr497781b6e.62.1772607486674; Tue, 03 Mar 2026 22:58:06 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ron Johnson Date: Wed, 4 Mar 2026 01:57:55 -0500 X-Gm-Features: AaiRm50pUbDFZ-UDm8bZPCLQreEP5pXrLmFQQMnk_5ZYVeqpP8jBhwwG_N-JPWk Message-ID: Subject: =?UTF-8?Q?Re=3A_PostgreSQL_Archive_Log_Partition_Reaching_95=25_?= =?UTF-8?Q?=E2=80=93_Need_Automated_Cleanup?= To: pgsql-general Content-Type: multipart/alternative; boundary="00000000000091cccd064c2d57eb" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000091cccd064c2d57eb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Mar 3, 2026 at 9:19=E2=80=AFAM loganathan P w= rote: > Dear Team, > > We have PostgreSQL 15 and PostgreSQL 17 databases running in separate > environments on different servers. Each database is approximately 1.5 TB = in > size and highly active, generating around 500 GB of archive logs per day. > How many days (or weeks) of PITR backups do you need to retain. > We have VM SRM replication configured. > That's probably not wise, given the size and volume. Physical replication via pg_basebackup is quite easy to set up. This is the command I use: pg_basebackup \ --pgdata=3D$PGDATA \ --dbname=3Dservice=3Dbasebackup \ --verbose --progress \ --checkpoint=3Dfast \ --write-recovery-conf \ --wal-method=3Dstream \ --create-slot --slot=3D$SlotName \ --compress=3Dserver-lz4 > The archive log partition reaches 95=E2=80=93100% utilization before back= ups are > taken. After the backups are completed, we must manually remove the > archived log files to free up space. > > Could you please advise whether PostgreSQL has any built-in parameters or > mechanisms to automatically delete archived log files > Lauren Albe is right: pgbackrest is probably the tool for you. Besides doing regular database backups, it manages WAL archives, encryption, compression and can be configured to automatically purge the oldest saveset (a full backup and its associated incremental backups plus archived WAL files) after a certain number of days. For example, I've got multiple 3-4TB databases and use pgbackrest to retain 28-35 days of PITR backups. After the full backup on that 35th day, pgbackrest automatically "expires" the oldest saveset and then we're back down to 28 days of PITR backups. It really is a wonderful do-everything tool. > once they have been successfully backed up? > Where do you back them up to? --=20 Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --00000000000091cccd064c2d57eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Mar 3, 2026 at 9:19=E2=80=AFAM lo= ganathan P <plogandba@gmail.com> wrote:
Dear Team,=

We have PostgreSQL 15 and PostgreSQL 17 databases= running in separate environments on different servers. Each database is ap= proximately 1.5 TB in size and highly active, generating around 500 GB of a= rchive logs per day.

How many d= ays (or weeks) of PITR backups do you need to retain.
=C2=A0
W= e have VM SRM replication configured.

=
That's probably not wise, given the size and volume.=C2=A0 P= hysical replication via pg_basebackup is quite easy to set up.
Th= is is the command I use:
pg_basebackup \=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --pgdata=3D$PGDATA \
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --dbname=3Dservice=3Dbasebackup \=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --verbose --progress \
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --checkpoint=3Dfast \
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 --write-recovery-conf \
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 --wal-method=3Dstream \
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 --create-slot --slot=3D$SlotName \
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 --compress=3Dserver-lz4
=C2=A0
= The archive log partition reaches 95=E2=80=93100% utilization before backup= s are taken. After the backups are completed, we must manually remove the a= rchived log files to free up space.

Could you please advise whether = PostgreSQL has any built-in parameters or mechanisms to automatically delet= e archived log files

Lauren Albe is right: pgbackrest is probably the tool= for you.=C2=A0 Besides doing regular database backups, it manages WAL arch= ives, encryption, compression and can be configured to=C2=A0automatically p= urge the oldest saveset (a full backup and its associated incremental backu= ps plus archived WAL files) after a certain number of days.

<= /div>
For example, I've got multiple 3-4TB databases and use pgback= rest to retain 28-35 days of PITR backups.=C2=A0 After the full backup on t= hat 35th day, pgbackrest automatically "expires" the oldest saves= et and then we're back down to 28 days of PITR backups.

<= /div>
It really is a wonderful do-everything tool.
=C2=A0
o= nce they have been successfully backed up?

Where do you back them up to?=C2=A0

--
Death to <Redacted>, and but= ter sauce.
Don't boil me, I'm still alive.
<Red= acted> lobster!
--00000000000091cccd064c2d57eb--