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 1l9EHg-0008IY-Nu for pgsql-admin@arkaria.postgresql.org; Mon, 08 Feb 2021 21:41:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1l9EHf-0003fp-Fk for pgsql-admin@arkaria.postgresql.org; Mon, 08 Feb 2021 21:41:27 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l9EHf-0003fi-66 for pgsql-admin@lists.postgresql.org; Mon, 08 Feb 2021 21:41:27 +0000 Received: from mail-oi1-x22c.google.com ([2607:f8b0:4864:20::22c]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1l9EHc-0008Ax-5K for pgsql-admin@lists.postgresql.org; Mon, 08 Feb 2021 21:41:26 +0000 Received: by mail-oi1-x22c.google.com with SMTP id i3so6361720oif.1 for ; Mon, 08 Feb 2021 13:41:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=9Gn00Vmxb68rsOcKUtaHMhqk47ZJ5uiWyq2DxT0Sib4=; b=fgbuJ+y80bUcsLpsxm3Co5rg0g+VJaS22p3Rr5EquD5i19+t84gkvr7vcvh7kFO8Ob FDIW267C/KmR9JU0mSPIUX26BTOc0BG3P8GWA/Bz1ND8SRsv9LUl5uWBOsYjVwquDDYM AJqvFMyXxKSNLVyDwZoXHh/bJfj/oGoSjPXsPWxhUh5YPfQffAmAHSN8dLbgA3Fp0XBq jAOxelXZEfC7kCqsKB6L9fNBRWm9/n4uH1GydGMXhMoi6aUHUbQmvLmmzJ5tO2MwaPVZ UJqTNFzWIF39LOAdPyUqYMSxA5p/FrSu2nezSgNcCzG+meJBTt5YQO9eB1F3UuU21ZWt arKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=9Gn00Vmxb68rsOcKUtaHMhqk47ZJ5uiWyq2DxT0Sib4=; b=GvDD3plQoaifAwfmOMdJnBOP2A+utg4qRdi2EfDILbif9EYt/TkP963IozwtGpni81 mqWQMzUQ0Nndxr7NArWeIVl80IW2+WCPfnTsKzNdLE+2UlPV8sNizLNsytI1maF8J3vy gsX398zoJC/ZcrO20ZzAScdJ4Dx2UnzywIVa4/kJaJDZ3kqIa4Ns1tmCt5l6WXVMP2JB HYLytbKG5/A/K/TfTuSwMPCmvqWi885zybJKZEC177k0hG7pSDW5IZVBi/h3qjjExPA/ N5RaZ3Bi4EUj8NIqHI5C5YdQD+LDE0Ywpve7nDySWqlHUjzJtbzucNSxKUdtKTsxiaES Drsg== X-Gm-Message-State: AOAM533wGazja8tawGpXqdbfvl5UFch5vUfwyD2x78cH5aCjnnys0Z1v TvE9yieA3CpDnm7jcV50+xXsTAoEEgUw9A== X-Google-Smtp-Source: ABdhPJzYS3Zdc6Kg9rOcCPBE5jdK4QV8mOtT6z1vxvIU/na7lMuOoQyQACTi2QJlS8XmOhnmhaVqTQ== X-Received: by 2002:aca:dc56:: with SMTP id t83mr510587oig.75.1612820481820; Mon, 08 Feb 2021 13:41:21 -0800 (PST) Received: from [192.168.88.10] (ip174-67-141-204.no.no.cox.net. [174.67.141.204]) by smtp.googlemail.com with ESMTPSA id y5sm1468247oti.59.2021.02.08.13.41.20 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Feb 2021 13:41:21 -0800 (PST) Subject: Re: wal-g (https://github.com/wal-g/wal-g) reliability To: pgsql-admin@lists.postgresql.org References: <20210208212840.GW27507@tamriel.snowman.net> From: Ron Message-ID: Date: Mon, 8 Feb 2021 15:41:20 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20210208212840.GW27507@tamriel.snowman.net> Content-Type: multipart/alternative; boundary="------------59D1A1A380D74C94B52B8590" Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk This is a multi-part message in MIME format. --------------59D1A1A380D74C94B52B8590 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 2/8/21 3:28 PM, Stephen Frost wrote: [snip] > Interesting that you ask this! I say that because it's actually a case > that pgbackrest contemplated and explicitly added support for- > specifically, if you set --archive-copy (or archive-copy=true) and > disable compression (or decompress everything before you start PG), then > you can just start PG from the backup and it'll perform the necessary > recovery from the WAL and start up. We considered this an interesting > use-case and used it extensively and have maintained support for it. > > All that said, of course, this limits the ability to do typical PITR, > but at least it gives you a consistent backup which you can start PG > from. In the SQL Server world, that's a COPY_ONLY backup. -- Angular momentum makes the world go 'round. --------------59D1A1A380D74C94B52B8590 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On 2/8/21 3:28 PM, Stephen Frost wrote:
[snip]
Interesting that you ask this!  I say that because it's actually a case
that pgbackrest contemplated and explicitly added support for-
specifically, if you set --archive-copy (or archive-copy=true) and
disable compression (or decompress everything before you start PG), then
you can just start PG from the backup and it'll perform the necessary
recovery from the WAL and start up.  We considered this an interesting
use-case and used it extensively and have maintained support for it.

All that said, of course, this limits the ability to do typical PITR,
but at least it gives you a consistent backup which you can start PG
from.

In the SQL Server world, that's a COPY_ONLY backup.

--
Angular momentum makes the world go 'round.
--------------59D1A1A380D74C94B52B8590--