Hi,
Thanks for the quick reply. To your questions:
> What do you mean exactly by "file-system replication"?
RAID1 setup (specifically, between two disks or EBS volumes [on AWS]), using LVM.
The two disks are synchronized, so AFAIK each should be an exact copy of the data.
> Not as long as you capture the currently-active WAL files along with the database contents.
I am not that familiar with Postgresql internals, but if we have a snapshot of the file system at the time of the crash (using RAID), is there a scenario where previous WAL segments will be needed to restore the database?
Regards,
Tom
On Thu, Dec 30, 2021 at 12:20 PM Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
Tom Korach <tom@xxxxxxxxxxxx> writes:
> We have a Postgresql instance (0.5-4TB in size) used for development and
> on-line reporting.
> We do not need high-availability, but we do need:
> 1. Quick disaster recovery (<1 hour) is important.
> 2. Recovery from corruption of the server or mistakes.
> Will file-system replication be enough to achieve this goal?
What do you mean exactly by "file-system replication"? Something
equivalent to rsync will absolutely not work against a running
Postgres server, because it won't capture a consistent state of
all the files. If you have (and trust) a filesystem with snapshot
capabilities, it might work to take a filesystem snapshot and hold
onto it long enough to rsync from the snapshot. I'm not sure about
the reliability or performance implications of such a setup, though.
See
https://www.postgresql.org/docs/current/backup-file.html
> Do we also need WAL file archiving?
Not as long as you capture the currently-active WAL files along
with the database contents.
regards, tom lane
