Whether or not you want to use the "normal backup algorithm" is irrelevant,
since if you try and start that snapshot Postgresql /*will*/ see the
instance as /*needing*/ to be recovered.
Having said that... our storage team does SAN snapshots of the *single LUN*
where */all/**of the Postgres*
Talking about fsfreeze and blocksize are not relevant in your case at all.
You can't make a backup this way any way. According your mail,
you are playing with database recovery after crash. Is pg crash proof? Yes (
https://www.postgresql.org/docs/current/wal-intro.html).
You can use this solution
On Thu, 12 May 2022 at 14:48, Tom Lane wrote:
> "Zwettler Markus (OIZ)" writes:
> > I don't want to do use the normal backup algorithm where pg_start_backup
> + pg_stop_backup will fix any fractured block and I am required to have all
> archived logfiles, therefore.
> > I want to produce an
"Zwettler Markus (OIZ)" writes:
> I don't want to do use the normal backup algorithm where pg_start_backup +
> pg_stop_backup will fix any fractured block and I am required to have all
> archived logfiles, therefore.
> I want to produce an atomic consistent disk snapshot.
[ shrug... ] You
I don't want to do use the normal backup algorithm where pg_start_backup +
pg_stop_backup will fix any fractured block and I am required to have all
archived logfiles, therefore.
I want to produce an atomic consistent disk snapshot.
I am not sure if freeze/unfreeze will be enough with default
