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 1ulSMZ-000s4o-Oq for pgsql-general@arkaria.postgresql.org; Mon, 11 Aug 2025 13:14:55 +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 1ulSLZ-000oLi-V6 for pgsql-general@arkaria.postgresql.org; Mon, 11 Aug 2025 13:13:54 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ulSLZ-000oLa-Ij for pgsql-general@lists.postgresql.org; Mon, 11 Aug 2025 13:13:53 +0000 Received: from mail-oo1-xc35.google.com ([2607:f8b0:4864:20::c35]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1ulSLX-0001Oc-1D for pgsql-general@lists.postgresql.org; Mon, 11 Aug 2025 13:13:52 +0000 Received: by mail-oo1-xc35.google.com with SMTP id 006d021491bc7-61997c8e2a1so2552124eaf.1 for ; Mon, 11 Aug 2025 06:13:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1754918031; x=1755522831; darn=lists.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=cpupGNOIoxYH448xT2A5Q3bvTmfgbcygLdNr5Fp/u28=; b=D/J/acX+Y/QGTOGy/n8db05Cu9C9oD3DPScWGzL9Bj/6n3x4mIZ7U2NQKptG+S5Yb3 NQbXzIDz0uWFtJz1NF0FNVj+4uk7ozGFx3LvRwPudT9sbVBKBjNNlUr7LFFnqbFskOdz LonqncDRq7OvRoHEQF5MHmC+JwsOaQwZSk95QrpyWImBGjc0pgQ9mSw1AHI+/iCrxFpD Qzpa6b8CfhHqu1XFu/9OsjwBiLN4unOhd0d/NdtyPVEkofjBpWzwJ8bWEQC8W3AC5zC4 uqJOuzN1U2nUYfkrVj/Vg24VSO+2DEpKMgpNZA8fFzl5JIzfi8ZVmyduYj7fk1Gjvem2 8PLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754918031; x=1755522831; 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=cpupGNOIoxYH448xT2A5Q3bvTmfgbcygLdNr5Fp/u28=; b=VwTWDMWusH8pVKj8Ewm5TNNk2MsgLFvNKCa8GQvqkqUzqHiV/dqvLnY9/kRZQ8UM+k +hnWuEyKhoSdX9Q2iSrgdxvNLnO+j2OiMlpUDjpt71s0fKmhtl9zMQgpaDm6n33I3a7n ecQ1wym9lT+iTAYg7+ttII9GOUNobySmQfiUhiFsAobXUrJW2UJI6BlXTRJFbQQzKt/2 43gXgEPRmLdhL9W2CiMuin5CYKYJRWJJGgwpnO4NyDyDjaaAgCIzqPvWk1KrE71gjJYU 7tv56vTHIwK/4QDrr+IA1vVLwlzDehSPBr/MTzXi8YiuyDm3ylNeym2lyNfxYzT4lO9t Cbfw== X-Gm-Message-State: AOJu0YxH1HTesl7iyVoFWXgNjBbKL7jf+A482T6n34+4oEhguBHD3iih DGlVDjSxKX+XmSLxZEk4T9bSJwABbS1+gCuWTg96cyJILe2xWiVpFyWihPdaESl3zFed4StJOH5 5A7XEeGEsintNVcXc/7176jtlm0PXpYIt/7W+ X-Gm-Gg: ASbGncu/NUMJ4yrB2gcjf/S6sSj5INYin6bJBJ3AuprNRw1G3SLHXbBNFUXXnuOxPGd 2tnlf71mPrfulkg9SbEoYUE6p9DLXwZn6zejxtQxmvGU5mZQAdYPFINXJ2X6aD/rxIsM8S1kHcl 1sSs6PA16+GUtaR2KQEwUMlzxAioiiXz6XgVbA1/Sni4uEVUwX9s/d6x0xtc1/zmmNlE8ET6mvR oNPU+Xk X-Google-Smtp-Source: AGHT+IHh9G6y4tLutp3BM6xYmTaUPGGkRnZ3ajNHbrBbTu7YlWZmS4R28CCC/0nQH7FchlHtZqYAiudbZp/GiAo/EaE= X-Received: by 2002:a05:6820:811:b0:61b:756d:967d with SMTP id 006d021491bc7-61b7c4ebc18mr6948602eaf.0.1754918031015; Mon, 11 Aug 2025 06:13:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ron Johnson Date: Mon, 11 Aug 2025 09:13:38 -0400 X-Gm-Features: Ac12FXys7VGzkLqiGve6mCJV6FMW4g3Tlke0R_7UonZh01zA8X8Jo8L1VKdCHeI Message-ID: Subject: Re: Backups with filesystem snapshots To: PostgreSQL General Content-Type: multipart/alternative; boundary="000000000000d94511063c16b1ad" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000d94511063c16b1ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 11, 2025 at 9:01=E2=80=AFAM Nick Cleaton wro= te: > If I take an instantaneous filesystem-level snapshot of the postgres > data directory underneath a running postgres server, is that a safe > backup without doing any pg_start_backup/pg_stop_backup ? > > It seems like it should be, so long as I get an atomic snapshot that > includes both data and wal, because starting up from that snapshot > should look the same as recovering from an unclean postgres shutdown > due to a kernel panic. > We once restored a whole-system VMware snapshot to a new VM (new IP address and everything). When I logged in, PG started up without a hiccup; it took a couple of minutes while WALs rolled forward, but that's to be expected. Postgresql didn't (and doesn't) know anything about when snapshots are taken. --=20 Death to , and butter sauce. Don't boil me, I'm still alive. lobster! --000000000000d94511063c16b1ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Aug 11, 2025 at 9:01=E2=80=AFAM N= ick Cleaton <nick@cleaton.net>= ; wrote:
If I take an instantaneous filesystem= -level snapshot of the postgres
data directory underneath a running postgres server, is that a safe
backup without doing any pg_start_backup/pg_stop_backup ?

It seems like it should be, so long as I get an atomic snapshot that
includes both data and wal, because starting up from that snapshot
should look the same as recovering from an unclean postgres shutdown
due to a kernel panic.

We once restored a who= le-system VMware snapshot to a new=C2=A0VM (new IP address and everything).= When I logged in, PG started up without a hiccup; it took=C2=A0a=C2=A0coup= le of minutes while=C2=A0WALs rolled forward,=C2=A0but that's to be exp= ected.

Postgresql didn't (and doesn't) kno= w anything about when snapshots are taken.

--
Death to <Redacted>, and butter sauce.Don't boil me, I'm still alive.
<Redacted> lobs= ter!
--000000000000d94511063c16b1ad--