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 1rzYoF-004sYC-Cc for pgsql-general@arkaria.postgresql.org; Wed, 24 Apr 2024 09:20:59 +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 1rzYoE-00DQjI-3Q for pgsql-general@arkaria.postgresql.org; Wed, 24 Apr 2024 09:20:58 +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 1rzYoD-00DQfz-OT for pgsql-general@lists.postgresql.org; Wed, 24 Apr 2024 09:20:57 +0000 Received: from mail-ed1-x542.google.com ([2a00:1450:4864:20::542]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rzYoB-002gCK-HT for pgsql-general@postgresql.org; Wed, 24 Apr 2024 09:20:57 +0000 Received: by mail-ed1-x542.google.com with SMTP id 4fb4d7f45d1cf-571be483ccaso7846571a12.2 for ; Wed, 24 Apr 2024 02:20:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713950453; x=1714555253; 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=3SVN1D9WJeMIhfzeBURN9ch3G+R1pINQdw/8p3e5AfE=; b=Fp4W80CLKQl9BLHQcAi8xSuT3OsZEIxBBp4PBs63lAewxF3TD3tsoTywTRto3+/rxc Sj43aES93M5UInmVHcDKLPanTiNCwQ/4jbCkPD95cAi4/vNpp+D6aZqsZl4OpLcucFsn yOaSq52PBR1zn9/sqY+0h5nZuWS8NhTD9nRHjsvQFxfxLiaZ+vdIyOHxk6MmPsiSY7yg mB9xi1xsIu+++zisTUTmWO3iPI3XEwNaBpSuNV7RFP+Yb0vwBY6dFsd0gR4UpOGLNdU8 Y68T4ILwgl7jvDK6SE9actRPfwHEVBzrxCb041GiJJgCPJqjlHYcuiRZzXIR82gzkZmz mpzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713950453; x=1714555253; h=cc: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=3SVN1D9WJeMIhfzeBURN9ch3G+R1pINQdw/8p3e5AfE=; b=pNSKpeAfSVOMhEm/pebV3I2ci3vkbmgdNvsZuSDXJPT0rJPUTALwS+ScPWalQlKuKM Xcs83blEt5SL8zB/ulW89olVmvj+WHu3q1JI1d3ryOUFk0vsXxMrG93v0pNfK/k0KkLC 7d/Jfw4QYwKb0OPL82qK7ktinflhYVbJu/h9Lz8FW2eZhhOQJblJDmlZDBhIuXSk7wuE GAFrf9VNK7FAvVCYGrEquJyKi1wmHj1Kz/WMxlEIJDkkR5VEdqTQywHqghVvY+oC8hxj 9kM1tazjvAh+QwwoI/7G4tAeZUrLutY/v0XhQS1ZYspy7oT+D5HyelM0KGWGZzP/mV65 1w3g== X-Gm-Message-State: AOJu0YwPpKIpN09PSh/0BPRwLb1OMmK19lytKbiug1/Jn4miQnlStHcR 8qlh+n424WCaJat6b55MnMXTvw3cpQIuKV88Qc+Rre9UENbdVvbhE+GtKTE9mBfJLrOGYidH2Um OIUp9c0rqFSwGoVaS+vkB4BPj/uc= X-Google-Smtp-Source: AGHT+IH0LHBLG1j5+MMmQr4BnYgXIurbX9ldVaC/aNPLaCTJ3Rfzq6kSgDVD3C78Sra9xofPE6wvGxA0Z9+HpJvlPP0= X-Received: by 2002:a17:906:f28f:b0:a56:8e7c:9eb8 with SMTP id gu15-20020a170906f28f00b00a568e7c9eb8mr1222729ejb.9.1713950452493; Wed, 24 Apr 2024 02:20:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Vijaykumar Jain Date: Wed, 24 Apr 2024 14:50:41 +0530 Message-ID: Subject: Re: Backup_Long Running To: jaya kumar Cc: pgsql-general Content-Type: multipart/alternative; boundary="000000000000e237260616d42f30" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000e237260616d42f30 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Apr 24, 2024, 12:33=E2=80=AFPM jaya kumar wr= ote: > 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 work 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 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 backups. there are other tools too, I used only these two. > > --000000000000e237260616d42f30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Apr 24, 2024, 12:33=E2=80=AFPM jaya kumar = <kumardba27@gmail.com> wr= ote:

= 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.


--000000000000e237260616d42f30--