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 1wJq4z-000LXT-3B for pgsql-performance@arkaria.postgresql.org; Mon, 04 May 2026 09:59:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wJq4y-006cPg-2h for pgsql-performance@arkaria.postgresql.org; Mon, 04 May 2026 09:59:08 +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 1wJq4y-006cPY-1P for pgsql-performance@lists.postgresql.org; Mon, 04 May 2026 09:59:08 +0000 Received: from mail-lf1-x12b.google.com ([2a00:1450:4864:20::12b]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wJq4w-00000000Qhn-0j1N for pgsql-performance@lists.postgresql.org; Mon, 04 May 2026 09:59:08 +0000 Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-5a74ac8b40aso4252606e87.1 for ; Mon, 04 May 2026 02:59:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1777888745; cv=none; d=google.com; s=arc-20240605; b=PfxVOIhqHODcPwsM1vM3xFs6Sehk0+HcIl5CeOodIm2THMozpQlC4QX0SQar9loiMr tshkjsohGagtSTfEDoqVz+BI1grtVXGMSfqocfevOriHSS1p3gibGrjXhI0pCJ9RNy+o 9p9vLZr92T8l428x0eKP+UOaCtBSeFONqD1//XJ0JjPvjLgPu6U4zNySzk6Nd42lAoKP iEIWUWafSEV9+EISRcgSxEhaVNvKsRUq4zrp5pLYJMnuSmI86fMfBMZgMYinNa/UT9eB Ff7GsEMIgR1LOE05r4pKiVbPr8DC8kyRxedb96+Lv08xTs8ves3HV13vmEceKRdp2fD8 R8UA== 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=rkhnK3rQgRkVvc6DwkOFHABqt1SqSYCwPCbRhGP16E0=; fh=zZjPY5CkRvZJUm83a74J0D9nST3mX2tKAPAgrgBo1fg=; b=kB9JugNM7ZhRPCqrzGhgV+i05Hf4sXh2tmNtzDFZFg52nkErPZtS79pN9TwJM5nH20 A85VWp9+gp+5Y8ow+/S94VOj+nJx6iqyf0ro+8bGGcJ4wvDKrNTRoiGVOTYGZ4OQGyRm 5PDTQ5e+J6VQ8aZLo7Xnpr1OexON5hlnMsedrg0JunPF1xNAXL6u9tWHiCirqH4GKQH+ Hf72D2/dZvxZJ8Ce5b//zXWEozALPE924TUhp4H4H/Yv7FfbUAeO9+K8lxgS7B334sNQ w3uPVH13nBmibl1rdNl0OFQTq02wXu11HthbdnRGLmnrRK0gyvl0/bAmGQ4HtAhnPz/l HUoA==; 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=1777888745; x=1778493545; darn=lists.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=rkhnK3rQgRkVvc6DwkOFHABqt1SqSYCwPCbRhGP16E0=; b=CXHyVv590NbvDmESRdtgQ2QdTgx5VD6Z+k+lSXudaE/BqqEHnDXB4u7qI819pL2rnS z3AqPPNRMkpjKnE3xwHFsyLctU7bLTBxQlST/PuVawPydORYowKgat6w7DNwTSc4E1YY zNUe8vxBS4mYKHq76UxZDqBqRXsxDiBRI1rYeKuAr2EUpgIGGLcEEJO4Oo3DMmM42LJa +nf5+DjfpUdV6oLbGHoDyFhG4uvJ7lobuFB/zaHpvLHbgUQ35KgdALF+Xh4xBmwlwNvZ dOhVmqlQ7oMF19u3qH42q7S7lK6IXJLlNixcLQX/wt39eQLQ2OgMHQUXpI3yUQnALIkl 232Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777888745; x=1778493545; 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=rkhnK3rQgRkVvc6DwkOFHABqt1SqSYCwPCbRhGP16E0=; b=orJIPcYhX7GL/8gdivfHJbtR630YoZdiVK3V8ErDBN+kGik/Zr51RAQkXGJth1QpDU F0xf45OLZ59eZpSdsbUEm8cpDds1ndiRqfydVFt7K7m/hrOeA7aiLjG1Y14z9+V6K9Pn gXd436CeKVvHJijUODsu9rquyNuzZA9Z8IuKvEOZgbxxZo8pwn91G5/lhsgsTGYexGl9 23IAPXEk3vVyU7O+LfyFM+/tsJispkS21qhmGI/xfxCP2Mlscr+tTTEcXvYI6L+Kh4PX T1GouhcrSA2qQEJrGwY9RFo3bDZ5i9mHxoOw1HLCFE9y4fl1aMKTUeyUcwMWz/nXiKs4 PCiQ== X-Forwarded-Encrypted: i=1; AFNElJ/Z42qYGAUPc3ond8Jd8L4D9JXLMEbZCBRoOztW8xk8vPD5JFuzE/24hc3SMxZfUe+rqSojfnVCex5pZFzGuSA/ng==@lists.postgresql.org X-Gm-Message-State: AOJu0YzCk+l9u2KytNiKqqziZw9Yy4oKK/ZJ/zxFb6Hb3LEbFgH2fUjQ ErptDQK8Sns8OjExoKYZ7MzKASi1wJzoYevLUsMW6ZQRjCqw+UueiEygfKp38E5hdW3ietYbqcK NVyi068TviwQd+zQqU+8/9jw2yErYlAyV8pYzgB8= X-Gm-Gg: AeBDieu/eDEFz/tyyU75fTsxf21hBo/qRt34JNIzfZcBPZ0bLITrp/rUgM5hCqjMCln DmrCIeobWhOUnZN/SznZrFrxrl4iSPASwNONUDLOPvFr8umk3k0phGXfPk2gzc8VMpsrHORurve HfknInBrvQ2wvUb4v7uJCaGxqO6/kY3P5Pm9hqOT1zvlVoZJRrc6tWxeDkWKFJz/ye753kGALxn 4BA+G8YzXQuG0AhgKTj5lWypUPuSksx5qRZwA+cIjcTj58d/2wjlbigx7jO9UNu0sfIy3ZpKvJD NDHPFJMhld0FPA4j10l312jQeOnxjsbgS31ji5L3T2iyuOcPvDmc9zpYPCD6CYo5cbt/k+dRpV7 XXaYCNQ== X-Received: by 2002:a05:6512:3d18:b0:5a2:be43:c57d with SMTP id 2adb3069b0e04-5a862ec5508mr2903933e87.12.1777888744617; Mon, 04 May 2026 02:59:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: masheed ullah Date: Mon, 4 May 2026 12:58:54 +0300 X-Gm-Features: AVHnY4KLeraKUNiDkseGJOHB0xufIgpvDLM-z-NeH8P-t-Eo6LOxKhGVMSCDATw Message-ID: Subject: Re: Postgres DB backup is taking too much time To: Ilya Anfimov , pgsql-performance@lists.postgresql.org Content-Type: multipart/alternative; boundary="00000000000012bb340650fafb22" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000012bb340650fafb22 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you every one for your output. Although pgBeckRest has no more support. Should I suggest starting testing backup and restore with pgBectRest? I did not find any 3rd Party tool. On Mon, May 4, 2026 at 12:29=E2=80=AFPM Ilya Anfimov = wrote: > On Sun, May 03, 2026 at 12:42:21PM +0300, masheed ullah wrote: > > Hi, > > We have a database of 20TB, and it's taking almost 24 hours to > complete. > > While full restore takes 28 hours. Although we have HA enabled with > > primary and multiple replica's. > > So we need a solution/tool to reduce the RTO, incase of disk failure= / > > Human error for data/tables deletion. > > > > We are using Barman for backup. > > First, you'd need engineers to measure -- what's going on. > Who is the slowest part? The network (most probable)? The post- > gres replication process? The disk that postgres reads? The bar- > man itself? Receiver disks/S3 daemon/etc? TLS of one of the > above? > Measures is the key. Then the solutions may be searched. > > btw, a modern postgres can definitely supply 1GB/s to barman on a > modern system. This is not a much, and probably could be im- > proved by special tricks like rsync or manual prefetch or incre- > mental copies -- however, it's less than 6 hours estimate and > therefore is fine for you. > > > My question is "Are there any tools like ZDLRA appliances for Oracle= " > to > > reduce the RTO to less than 10 hours". > > Best Regards, > > Khattak > > > --00000000000012bb340650fafb22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you every one=C2=A0for your output.=

Although pgBeckRest has no more support.=C2=A0
Should I suggest= starting testing backup and restore with=C2=A0pgBectRest?
I did not fin= d any 3rd Party tool.

On Mon, May 4, 2026 at 12:= 29=E2=80=AFPM Ilya Anfimov <ilan@= tzirechnoy.com> wrote:
On Sun, May 03, 2026 at 12:42:21PM +0300, masheed ullah wrote= :
>=C2=A0 =C2=A0 Hi,
>=C2=A0 =C2=A0 We have a database of 20TB, and it's taking almost 24= hours to complete.
>=C2=A0 =C2=A0 While full restore takes 28 hours. Although we have HA en= abled with
>=C2=A0 =C2=A0 primary and multiple replica's.
>=C2=A0 =C2=A0 So we need a solution/tool to reduce the RTO, incase of d= isk failure/
>=C2=A0 =C2=A0 Human error for data/tables deletion.
>
>=C2=A0 =C2=A0 We are using Barman for backup.

=C2=A0First, you'd need engineers to measure -- what's going on. =C2=A0Who=C2=A0 is the slowest part? The network (most probable)? The post-=
gres replication process? The disk that postgres reads? The=C2=A0 bar-
man=C2=A0 itself?=C2=A0 Receiver=C2=A0 disks/S3=C2=A0 daemon/etc?=C2=A0 TLS= =C2=A0 of one of the
above?
=C2=A0Measures is the key. Then the solutions may be searched.

btw, a modern postgres can definitely supply 1GB/s to barman on a
modern=C2=A0 system.=C2=A0 =C2=A0This=C2=A0 is=C2=A0 not a much, and probab= ly could be im-
proved by special tricks like rsync or manual prefetch or=C2=A0 incre-
mental=C2=A0 copies=C2=A0 --=C2=A0 however,=C2=A0 it's less than 6 hour= s estimate and
therefore is fine for you.

>=C2=A0 =C2=A0 My question is "Are there any tools like ZDLRA appli= ances for Oracle" to
>=C2=A0 =C2=A0 reduce the RTO to less than 10 hours".
>=C2=A0 =C2=A0 Best Regards,
>=C2=A0 =C2=A0 Khattak






--00000000000012bb340650fafb22--