Re: pg_combinebackup does not detect missing files
От | David Steele |
---|---|
Тема | Re: pg_combinebackup does not detect missing files |
Дата | |
Msg-id | a7aa27e0-8148-4c5a-89c9-87b181fb4748@pgmasters.net обсуждение исходный текст |
Ответ на | Re: pg_combinebackup does not detect missing files (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On 5/21/24 03:09, Robert Haas wrote: > On Fri, May 17, 2024 at 6:14 PM David Steele <david@pgmasters.net> wrote: >> Then intentionally corrupt a file in the incr backup: >> >> $ truncate -s 0 test/backup/incr1/base/5/3764_fsm >> >> In this case pg_verifybackup will error: >> >> $ pg_verifybackup test/backup/incr1 >> pg_verifybackup: error: "base/5/3764_fsm" has size 0 on disk but size >> 24576 in the manifest >> >> But pg_combinebackup does not complain: >> >> $ pg_combinebackup test/backup/full test/backup/incr1 -o test/backup/combine >> $ ls -lah test/backup/combine/base/5/3764_fsm >> -rw------- 1 dev dialout 0 May 17 22:08 test/backup/combine/base/5/3764_fsm >> >> It would be nice if pg_combinebackup would (at least optionally but >> prefferrably by default) complain in this case rather than the user >> needing to separately run pg_verifybackup. > > My first reaction here is that it would be better to have people run > pg_verifybackup for this. If we try to do this in pg_combinebackup, > we're either going to be quite limited in the amount of validation we > can do (which might lure users into a false sense of security) or > we're going to make things quite a bit more complicated and expensive. > > Perhaps there's something here that is worth doing; I haven't thought > about this deeply and can't really do so at present. I do believe in > reasonable error detection, which I hope goes without saying, but I > also believe strongly in orthogonality: a tool should do one job and > do it as well as possible. OK, that seems like a good place to leave this for now. Regards, -David
В списке pgsql-hackers по дате отправления: