Feedback about hybrid SAN snap and rsync'd approach for large systemcloning - Mailing list pgsql-general

From Jerry Sievers
Subject Feedback about hybrid SAN snap and rsync'd approach for large systemcloning
Date
Msg-id CB47B6F6-2619-4D79-97F2-412C840F2F32@comcast.net
Whole thread Raw
Responses Re: Feedback about hybrid SAN snap and rsync'd approach for large systemcloning  (Laurenz Albe <laurenz.albe@cybertec.at>)
Re: Feedback about hybrid SAN snap and rsync'd approach for large systemcloning  (Stephen Frost <sfrost@snowman.net>)
List pgsql-general
Suppose we have a DB cluster with an additional tablespace and we are
able to make an atomic SAN snapshot of *only* the main cluster
volume...

The additional tablespace contains only UNLOGGED relations.

We cannot snap that volume so we use rsync as follows...

1. pg_start_backup('foo');
make SAN snapshot
rsync the add'l tablespace
pg_stop_backup()

Now provision a new cluster around the snapshot and rsync'd volume,
rejigger the pg_tblspc link if necessary... and start it up maybe or
not having it remain as a streaming replica.

It's been my experience that possibly bulky data in the additional
tablespace does *not* need be rsync'd if we capture only the *_init
files.

Id' be curious to here feedback re the sanity of this approach.

And would also like to know if perhaps *only* the directories under
the rsync'd tablespace actually must be present for a successful
recovery.

The above approach has worked mumerous times even with origin systems
having large, churny contents in the dedicated unlogged tablespace
(which is on a much faster local NVME volume than the main SAN
volume.)

Thanks!



pgsql-general by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: alter function/procedure depends on extension
Next
From: Adrian Ho
Date:
Subject: Re: OpenSSL@1.1 not getting linked with Homebrew - trying to install postgresql