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.94.2) (envelope-from ) id 1rzbnk-005HDW-Oo for pgsql-general@arkaria.postgresql.org; Wed, 24 Apr 2024 12:32:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rzbnj-00EtLR-8r for pgsql-general@arkaria.postgresql.org; Wed, 24 Apr 2024 12:32:39 +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.94.2) (envelope-from ) id 1rzbni-00EtLF-TN for pgsql-general@lists.postgresql.org; Wed, 24 Apr 2024 12:32:38 +0000 Received: from mail-oa1-x2b.google.com ([2001:4860:4864:20::2b]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rzbng-002hi2-My for pgsql-general@postgresql.org; Wed, 24 Apr 2024 12:32:38 +0000 Received: by mail-oa1-x2b.google.com with SMTP id 586e51a60fabf-23333dddd8aso3806606fac.1 for ; Wed, 24 Apr 2024 05:32:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713961955; x=1714566755; 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=jWkK8D6SqC9KyPVBYTpcqyroMMgXvRqEYx3Onp2D5hI=; b=l3aiAvrIaPFkS4i6LJHjHOzpQ8olZInxlPgYZUCMUFgOOBaDH0JmW0K/Lr9drTP4RG y/y+9pUWdAdUJPzg9iyY1d3DLLOGndVJhfn0gwG8xh+ml5MnVde/pzEkPGBFiSvo82gD LBPpZ9sJhKlEAQ01QxoWWgWjzq6mfl5juA0DjHCy7M96YRuuxywTOMm3FDfwL3sSLDw2 9aUJGGxFtV91C836uSfzcsUhFr3bFj6FaXZQpXmBTI9l2xdA1tEv2DIVsJQ2YtJ3EHMv /3AEgNWOkjWz0MGzygwpeyKuGutrMgYnCXjgMvZh99eADb19AM6sZC4zp26zVQUzTg9Z OR1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713961955; x=1714566755; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jWkK8D6SqC9KyPVBYTpcqyroMMgXvRqEYx3Onp2D5hI=; b=cF0keFRvvccs/m9arab4eXBP1muAK4CmbQ4UdhIJLepPHoZo0U1KsLp45sTeR6EPe3 atXshxdewjU2a4X0bcPZ+MdWRZqDr+VrGkibPw5nFedZkql0n2WjrLVcqDuLWygSa3sf iCryRIOuCyvbJ93wMteZJLTVyfsoOC2E0qXDR05zysrNs2SJq1mnDmCySd4g8Fr4wYwX 25kwFVosyUUB/UIOQeqNVtgfkNsFENWO1vem/A0UK3yBP/9B/+JpqV0Q0mDcWFoBTnta z3BF1bebeDRF+En0QaGKd/M9YfPihgIGKDP46TdvI8wD6Y1bXVeW3YH9oSORR2fshQ4U I0Ww== X-Gm-Message-State: AOJu0Yw9//nGpeXFaO+EV+ov8mV5JlfGbk27myctrd7g+CnXVi4s47u2 btX077YsNcsmdLSzRDo8/kG9AprukAVRrTi4MWqCBrjkwm4TUj6iYkyOg1d/wr5HiUZaJUnCB45 l6MUQ0FY4PtE+z6L4nmvuNb5j4WpfDw== X-Google-Smtp-Source: AGHT+IHwQzyXrlm0QI24foTqYpY0uC7YN5nlsaLwZIWvdBBsZLZtX2wj4kkVTLnRVQlXDIWVtVeV4l+JTAvVMApcT7M= X-Received: by 2002:a05:6871:6181:b0:239:61f7:51a7 with SMTP id rb1-20020a056871618100b0023961f751a7mr2358135oab.13.1713961954742; Wed, 24 Apr 2024 05:32:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ron Johnson Date: Wed, 24 Apr 2024 08:32:23 -0400 Message-ID: Subject: Re: Backup_Long Running To: pgsql-general Content-Type: multipart/alternative; boundary="000000000000789a3d0616d6dd42" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000789a3d0616d6dd42 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable PgBackRest is in the PGDG repositories (RHEL & Debian). The documentation is thorough, and discoverable via Google, On Wed, Apr 24, 2024 at 8:30=E2=80=AFAM jaya kumar w= rote: > Thanks for your update. Can you have any link or document to configure L0 > & L1 backup using pgbackrest tool. Also share the pgbackrest installation > method. > > On Wed, Apr 24, 2024 at 2:50=E2=80=AFPM Vijaykumar Jain < > vijaykumarjain.github@gmail.com> wrote: > >> >> On Wed, Apr 24, 2024, 12:33=E2=80=AFPM jaya kumar = wrote: >> >>> Hi Team, >>> >>> >>> >>> Production database Backup is running very long hours. Any option to >>> reduce backup time? Kindly advise me. >>> >>> >>> >>> DB size: 793 GB >>> >>> >>> >>> We are taking pg_basebackup backup. >>> >>> >> do you see network saturation, io saturation ? >> generally faster hardware i.e striped and or nvme disks along with a >> robust network link and capacity should help get the backup done quickly= . >> where are you taking the backup from? is the server busy doing other wor= k >> or it is a dedicated machine for backups ? >> basically monitor for resource saturation, if all looks good, we could >> take basebackup of a 10tb db in 8 hours, and in another case on a slow >> remote storage, backup of 2tb took 1 day. >> >> now, pgbackrest can speedup backup processes by spawning more workers fo= r >> archiving and stuff. we have taken backup on nvme disks striped of 28tb = in >> 3 hours, bare metals servers with powerful cpu. >> >> so , it's hardware .... else switch to pgbackrest which can take >> incremental/differential/full backups. >> there are other tools too, I used only these two. >> >>> >>> > > -- > Thanks & Regards, > Jayakumar.S > +91-9840864439. > --000000000000789a3d0616d6dd42 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
PgBackRest is in the PGDG repositories (RHEL & De= bian).

The documentation is thorough, and discover= able via Google,

On Wed, Apr 24, 2024 = at 8:30=E2=80=AFAM jaya kumar <k= umardba27@gmail.com> wrote:
Thanks for your update. Ca= n you have any link or document to configure L0 & L1 backup using pgbackrest<= /span> tool. Also share the pgbackrest installation method.=C2=A0 =C2=A0=C2=A0
=

= On Wed, Apr 24, 2024 at 2:50=E2=80=AFPM Vijaykumar Jain <vijaykumarjain.github= @gmail.com> wrote:

On Wed, Apr 24, 2024, 12:33=E2=80=AFPM = jaya kumar <ku= mardba27@gmail.com> wrote:

Hi Team,

=C2=A0

Production database Backup is running very long hours. Any opt= ion to reduce backup time? Kindly advise me.

=C2=A0

DB size: 793 GB

=C2=A0

We are taking pg_basebackup backup.


do you see network saturation, io saturation ?
generally faster hardware i.e striped and or nvme disks along wit= h a robust network link and capacity should help get the backup done quickl= y.
where are you taking the backup from? is the serv= er busy doing other work or it is a dedicated machine for backups ?
basically monitor for resource saturation, if all looks goo= d, we could take basebackup of a 10tb db in 8 hours, and in another case on= a slow remote storage, backup of 2tb took 1 day.
now, pgbackrest can speedup backup processes by s= pawning more workers for archiving and stuff. we have taken backup on nvme = disks striped of 28tb in 3 hours, bare metals servers with powerful cpu.

so , it's hardware ...= . else switch to pgbackrest which can take incremental/differential/full ba= ckups.
there are other tools too, I used only these = two.




--
Thanks & Regards,
Ja= yakumar.S
+91-9840864439.
--000000000000789a3d0616d6dd42--