A modified version of shared hardware functionality is file system replication, where all changes to a file system are mirrored to a file system residing on another computer. The only restriction is that the mirroring must be done in a way that ensures the standby server has a consistent copy of the file system — specifically, writes to the standby must be done in the same order as those on the primary. DRBD is a popular file system replication solution for Linux.
DRBD seems to work similar to RAID but over network, but I might be wrong.
> An alternative file-system backup approach is to make a “consistent snapshot” of the data directory, if the file system supports that functionality (and you are willing to trust that it is implemented correctly).
> The typical procedure is to make a “frozen snapshot” of the volume containing the database
So could the following backup architecture make sense?
1. Periodic snapshots using EBS mechanism (to get consistent snapshots).
2. Periodic pg_basebackup + WAL file archiving ( to allow reverting to a previous step if we e.g. mistakenly drop a table).
Thanks,
Tom
On Thu, Dec 30, 2021 at 12:52 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Tom Korach <tom@safekeep.com> writes: >> What do you mean exactly by "file-system replication"?
> RAID1 setup (specifically, between two disks or EBS volumes [on AWS]), > using LVM.
Maybe I'm missing something, but AFAIK plain old RAID will not protect you against any scenario except failure of a single disk. It certainly won't do anything to help you revert to a prior database state.
The docs page I pointed you to is part of a chapter that lays out all the backup methods the PG community considers reliable. I strongly suggest sticking to one of those and not trying to take shortcuts. (The following chapter on high-availability setups is relevant reading as well.)