Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nzQjJ-00070Z-Vz for pgsql-admin@arkaria.postgresql.org; Thu, 09 Jun 2022 22:34:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nzQjI-0008Qg-Ec for pgsql-admin@arkaria.postgresql.org; Thu, 09 Jun 2022 22:34:16 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nzQjI-0008QX-3x for pgsql-admin@lists.postgresql.org; Thu, 09 Jun 2022 22:34:16 +0000 Received: from mail.thelabyrinth.net ([45.56.70.56]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nzQjF-0003gs-Dp for pgsql-admin@postgresql.org; Thu, 09 Jun 2022 22:34:15 +0000 Received: from [10.69.210.216] (c-73-39-102-148.hsd1.md.comcast.net [73.39.102.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: dsteele) by mail.thelabyrinth.net (Postfix) with ESMTPSA id 4CC255468E; Thu, 9 Jun 2022 22:34:12 +0000 (UTC) Message-ID: <477f38d6-df05-60a2-2266-e54a4f232ac6@pgmasters.net> Date: Thu, 9 Jun 2022 18:34:11 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: pg_basebackup and pg_receivewal timing, missing WAL files Content-Language: en-US To: Stephen Frost , Tim Cc: posgres support References: <20220609183641.GN9030@tamriel.snowman.net> <20220609212409.GR9030@tamriel.snowman.net> From: David Steele In-Reply-To: <20220609212409.GR9030@tamriel.snowman.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 6/9/22 5:24 PM, Stephen Frost wrote: > > * Tim (timfosho@gmail.com) wrote: >> We currently use pgbackrest as our primary backup tool actually, and it >> works great! The issue I ran into with trying to set it up that way with >> pgbackrest, is when configuring the second repo, pgbackrest will have to >> archive all WAL files to it, going back to the oldest backup. And we have > > Eh? Why is that? I think there's some confusion here regarding how > pgbackrest multi-repo works. We won't archive back to the 'oldest > backup' when you add a second repo, we'll just archive *new* WAL to it > after it's been configured. By default pgbackrest will keep all WAL since the start of the oldest backup in a repo. Each repo can have its own retention settings so this might be a *different* oldest WAL per repo. However, you can use repo-retention-archive and repo-retention-archive-type to change this behavior, see https://pgbackrest.org/configuration.html#section-repository/option-repo-retention-archive. Basically, if you need to keep a number of full backups for compliance you can set repo-retention-archive-type=full and repo-retention-archive-type=1 in that repo and WAL in between the backups will only be kept after the last backup. WAL required to make backups consistent is always kept until the backup expires. We've had requests for repo-retention-archive-type=0, i.e. only archive WAL during a backup, but we have not had time to implement that. Some users have implemented a work-around based on checking the backup lock. There is an issue that describes the method but I was not able to find it after a brief search. This is safer than it sounds because pgbackrest will check that all WAL required to make the backup consistent reached the archive. So, if the wrapper is broken you'll get errors. Regards, -- -David david@pgmasters.net