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 1vTIbE-00GNlK-2Z for pgsql-general@arkaria.postgresql.org; Wed, 10 Dec 2025 11:43:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vTIbD-00AzLa-11 for pgsql-general@arkaria.postgresql.org; Wed, 10 Dec 2025 11:43:15 +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.96) (envelope-from ) id 1vTIbD-00AzLS-00 for pgsql-general@lists.postgresql.org; Wed, 10 Dec 2025 11:43:15 +0000 Received: from mail-pg1-x532.google.com ([2607:f8b0:4864:20::532]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vTIbB-0047kx-1d for pgsql-general@lists.postgresql.org; Wed, 10 Dec 2025 11:43:14 +0000 Received: by mail-pg1-x532.google.com with SMTP id 41be03b00d2f7-bd1b0e2c1eeso5264084a12.0 for ; Wed, 10 Dec 2025 03:43:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765366992; x=1765971792; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=aH88z6esXpA2mS/quWAjytoqA1AW/wnmlriA0V/UTTI=; b=l5CLG9hYZwfoCXr+8D2R9j7eYMmzU/+1vYhF9EZdd7b3V4ryn568SKdnSYs+HW3HeQ syaPd1Eivy0GNS1vo9LVmUi9uy/R1kpjTx2qGM9l3GCoGrOWItCvCAMUCuhIjSR3zidK uWVQf5wQPMcKumpMxd+Fw43OfZvjeEgFRg6/w20Zaka2uGAPD5gFoLnHc1HW2Rd4YfSo nDjQsPeXSUHstc1YwU+SoXnJkOYoAyJZj+7B/7dstCSoWA4Ux/6TSc2be5nWUnCOHBIn 0lpK1pmXUl8j/jv29TastCDJVUIIUigSLFEE+i4Ii8cohMyGehpArXIxq0ji9HXE2h0c NmYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765366992; x=1765971792; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=aH88z6esXpA2mS/quWAjytoqA1AW/wnmlriA0V/UTTI=; b=bl/ISid1lpREaxWzWGSL4yPMuPy93zgFu+s+XNQt8yDmTdtN0r0Yjj6z7l1EMwDmrM 0CDxLFNGWaKo3g3vscZ2aG7pFGrPbVBWO4CjdZa7w5cKgN7L9u/ZnZyxgAECNcA/Fjnh irdx1vQWhqyfYlf40Os+3Fo5wU+WnmztWlIw5wOtMixAzww+LlstAqVEJMGRmNJc9mvO xR6CVnORgVOWLKaFhPcuCDlKVVAhvb8RjC9CPxNK77bEQx6yKhCmBViqFMZ3PLKZlOXu gaE6mW/Bi3g2zsv5/dxYRH/23eeci5G/Lbvk/+i3ZNScXU+obA2RNhhj4ve9IjHuRfet HJHA== X-Gm-Message-State: AOJu0Yxlw/eZbOSnSoqEIfG3SdXwf+27AO3yKUeen7/hE+ZYmZ8aaqQJ FvqimvQthyv/Ul89XYPCGpMmtwxFK4VBp0yAFeHUU5CzJu79c63Fw2z+rspV7a53tgmOE7Kv7/q ne2ezcsy/NS7E9dtg/DiY/6IQi/zI9Aa9S+W6 X-Gm-Gg: ASbGncsSl8OUvmZ2l1kZGBALvNJPrOWzMU2o6eoCH6OO8nmmUfiqbWSUH/OQovSUPUH Bx3ec/5xy1Ysu3V0nt8PHDf6gKtDLX/q+Zle/2qzB+DdxvXduY6GOuCzN3N+PnKNyPC6CXjcLi7 rN3xPLUK2AiaSY6dU0sRksZYnkp74Q6m4Y25Dtg+iSQ7eewvmNKqXCdkQTgFzlklvrSCmgE6LEk 8fRgJujD1t7xWL9+5/xhaMuVcfvU9sTmn5q5bnUg39OsngBLqoUuuteCKl1b0yEeM7OptDRslaN bcMoiLYE+vBGsoc548WNpJYDJnZnM1cR/joeV7suQmWd7S5li+eFRrSkm837L66q8ICaurIOWV5 BHQHLMxF0FWGsp2oS/6/O6cECq8TWIm6vH7DL X-Google-Smtp-Source: AGHT+IFGdfx5k3XvAp2+MpEz9fANZcPrlWJxBzEyfLN144tiVYzSjuropJr/pZewbTAIxRKPtiQMvPR5D+m+lHJI4ec= X-Received: by 2002:a05:7022:e994:b0:11a:2ec0:dd02 with SMTP id a92af1059eb24-11f2969ebaemr1671786c88.33.1765366992213; Wed, 10 Dec 2025 03:43:12 -0800 (PST) MIME-Version: 1.0 From: "Colin 't Hart" Date: Wed, 10 Dec 2025 12:43:01 +0100 X-Gm-Features: AQt7F2rOIepNVtpvwevfwztbz1K6KLp5tMSzLCv36-ssyP2O9reljFeLr3DRvEc Message-ID: Subject: pgBackrest and newer timelines To: PostgreSQL General Content-Type: multipart/alternative; boundary="000000000000781bc50645978856" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000781bc50645978856 Content-Type: text/plain; charset="UTF-8" Hi, Before a migration we tested a database restore on the new server -- which was configured to archive its WAL, and has archived WAL on a new timeline to our central backup server. We tested this twice. Now we have done the migration, which due to the size of the database we achieved by detaching the disks from the old server and attaching them to the new (this was the easiest way to achieve an OS upgrade from Ubuntu 20.04 to Debian 12). ((Yes we reindexed the text columns.)) So now our new server is still on the original timeline, but our backup server contains WAL from two new timelines. What should we do? Can we safely remove that WAL from the backup server? How? Thanks, Colin --000000000000781bc50645978856 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Before a migration we te= sted a database restore on the new server -- which was configured to archiv= e its WAL, and has archived WAL on a new timeline to our central backup ser= ver. We tested this twice.

Now we have done the mi= gration, which due to the size of the database we achieved by detaching the= disks from the old server and attaching them to the new (this was the easi= est way to achieve an OS upgrade from Ubuntu 20.04 to Debian 12). ((Yes we = reindexed the text columns.))

So now our new serve= r is still on the original timeline, but our backup server contains WAL fro= m two new timelines.

What should we do? Can we saf= ely remove that WAL=C2=A0from the backup server? How?

<= div>Thanks,

Colin
--000000000000781bc50645978856--