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 1vkSvp-00Fhza-05 for pgsql-general@arkaria.postgresql.org; Mon, 26 Jan 2026 20:11:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vkSvo-00AaQV-0E for pgsql-general@arkaria.postgresql.org; Mon, 26 Jan 2026 20:11:28 +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 1vkSvn-00AaQN-2N for pgsql-general@lists.postgresql.org; Mon, 26 Jan 2026 20:11:28 +0000 Received: from smtp98.iad3a.emailsrvr.com ([173.203.187.98]) by magus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vkSvl-00000000auX-38oX for pgsql-general@lists.postgresql.org; Mon, 26 Jan 2026 20:11:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=g001.emailsrvr.com; s=feedback; t=1769458284; bh=rvphRow4W9b432Kc3WTgZIsp4smCBgI05MYeenAzgME=; h=Subject:From:Date:To:From; b=EAIa2R/fO79xMLFAnn6Ldx83gEdt2OUdCmVn4f9XJnKeSUmyg0bA83KT1hLtPpVY3 R91z8ItFZ2Uog862rswc44roj05uiFiP5LGzTjn+HaoxRyxkEu8/rUYzuSJRF/X1Ts eVAADDdXENh8mhylr7DuhfId5zH3CGOiz+AOAQTE= X-Auth-ID: xof@thebuild.com Received: by smtp37.relay.iad3a.emailsrvr.com (Authenticated sender: xof-AT-thebuild.com) with ESMTPSA id C78696557; Mon, 26 Jan 2026 15:11:23 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.8\)) Subject: Re: About backups From: Christophe Pettus In-Reply-To: <1244937982.4358855.1769455485523@mail.yahoo.com> Date: Mon, 26 Jan 2026 12:11:22 -0800 Cc: pgsql-general@lists.postgresql.org Content-Transfer-Encoding: quoted-printable Message-Id: <8C907CFF-EF9A-4BD8-A9B9-47DCC8D1A65E@thebuild.com> References: <1730736265.4259921.1769443263077.ref@mail.yahoo.com> <1730736265.4259921.1769443263077@mail.yahoo.com> <868938296.4311067.1769449951678@mail.yahoo.com> <2022327491.4341234.1769452625380@mail.yahoo.com> <32C440DF-84C3-48D3-AF25-C0D977359F56@thebuild.com> <1244937982.4358855.1769455485523@mail.yahoo.com> To: felix.quintgz@yahoo.com X-Mailer: Apple Mail (2.3776.700.51.11.8) X-Classification-ID: 8198389e-af44-429b-8f15-d2b6eae36527-1-1 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > On Jan 26, 2026, at 11:24, felix.quintgz@yahoo.com wrote: >=20 > A full database backup is the requirement. A database restore is = optional, but that's negotiable; the backup is not.=20 > All of this must be done without access to the server or the database = itself, solely through the application, and the user must have the = necessary permissions within the application. In that case, running pg_dump on the application server is probably the = way to go. pg_dump can produce a single file that can be used to do a = full restore, and it's smaller than an equivalent bindary backup (since = it includes index definitions, but not the contents of the index = itself). Of course, if it's a 100GB database, you'll end up with a huge = file no matter what, but nothing to do about that.=