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 1nKIQB-0004om-Ls for pgsql-admin@arkaria.postgresql.org; Wed, 16 Feb 2022 11:24:31 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nKIQA-0007e9-Hf for pgsql-admin@arkaria.postgresql.org; Wed, 16 Feb 2022 11:24:30 +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 1nKIQA-0007e0-5q for pgsql-admin@lists.postgresql.org; Wed, 16 Feb 2022 11:24:30 +0000 Received: from evariste01.clarocloud.co.za ([196.13.181.165] helo=evaristesys.com) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nKIQ7-0006Fm-Ak for pgsql-admin@lists.postgresql.org; Wed, 16 Feb 2022 11:24:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=evaristesys.com; s=defaultdkim; h=Sender:To:Date:Message-Id:Subject: Mime-Version:Content-Transfer-Encoding:Content-Type:From:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=exe5Bci2pU0OJRqZo3dX8U2AFi/eEMwYEJE8K45TXgI=; b=HbMQISOW7oOneSGtQc0oBQltt cQDd1lKMXxeGfYKPHhQhFpAuaYODbWmU44idRne2PwMLG8G2AXEZZsV66pmxkKhfzxAY8sIWRGsIM +lrymB2tVPZW01iI/qBlCH2VZBbizOXrj6gjIVd07I4rVZJJy9AAlk75GycQLIyTcRxgQ=; Received: from 071-090-217-141.res.spectrum.com ([71.90.217.141] helo=smtpclient.apple) by evaristesys.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nKIQ1-0001Zt-IP for pgsql-admin@lists.postgresql.org; Wed, 16 Feb 2022 13:24:21 +0200 From: Alex Balashov Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) Subject: Differential backup in database migration Message-Id: Date: Wed, 16 Feb 2022 06:24:17 -0500 To: pgsql-admin@lists.postgresql.org X-Mailer: Apple Mail (2.3693.40.0.1.81) Sender: sasha@evaristesys.com List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, I sincerely apologise if this is a stupid question, in that it has been = answered enough times to enter an FAQ canon: I=E2=80=99m faced with the daunting prospect of upgrading a PG 9.6 = installation to 14, in the process migrating a ~400 GB database. Due to = the large jump in major versions, the on-disk block storage of course = will not be in the slightest bit binary-compatible, so I will have to = dump out the DB & import it into the target DB, live via a network pipe. This process is time-consuming, and can=E2=80=99t afford the downtime on = the old 9.6 DB. The issue, of course, is that the 9.6 DB will change = during the time this snapshot is being dumped out and imported. = Ultimately, the target database will need to be brought into consistency = with the incumbent database (more or less) at the point of a cut-over. I suppose the most intuitive solution to me would be to import the = snapshot to the target DB, then take another, smaller differential = backup of some kind, and in turn import that. But perhaps there=E2=80=99s = another solution altogether, i.e. a much faster backup & restore? I see = that pgBackRest makes this argument to the prospective user. I have no experience with pgBackRest or any such tool, so would = appreciate any advice on how to best go about this!=20 Thank you in advance, and apologies again if the question is asked = routinely. =E2=80=94 Alex --=20 Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/