Всем привет! Подскажите пожалуйста кто знает по восстановлению PointInTime: бэкап

снимается целиком виртуальной машины, wal файлы копируются через archive_command. При этом не выполняется pg_backup_start/pg_backup_stop. Можно ли восстановить такой бэкап с помощью wal файлов? Положил файл recovery.signal, удалил файлы в pg_wal - сервер не стартует

> удалил файлы в pg_wal - сервер не стартует И с чего бы он стартовал? Его состояние вообще не соответствует никакому snapshot в принципе. > Можно ли восстановить такой бэкап с помощью wal файлов? По идее, да (если есть все нужные) — restore_command (+ конфигурация restore point, если нужно) и вперёд.

ой зря вы это сделали)

я на кошке тренируюсь ) в доке по восстановлению сказано: удалить файлы в pg_wal )

если у вас лежат все нужны wal-файлы с момента снятия бэкапа (делается принудительный чекпоинт обычно) до того момента, до которого вы хотите восстановить, все должно сработать возможно вы в конфигурации что-то недонастроили и что значит сервер не стартует? что пишет в логах?

видимо дело именно в командах pg_backup_start, пишет: could not locate a valid checkpoint record

Доя начала — а зачем вы удалили файлы из pg_wal ?

https://www.postgresql.org/docs/current/continuous-archiving.html пп.26.3.4

восстановил снапшот, сделал то же самое (создал recovery.signal; прописал restore_command, убрал archive_command, выключил archive_mode - чтобы на то же место не писало wal файлы в архив) без удаления wal файлов, так же не стартует, в лог пишет: 2023-08-01 11:21:18 MSK [1859-1] LOG: database system was shut down at 2023-08-01 10:08:30 MSK cp: cannot stat '/backup/00000002.history': No such file or directory 2023-08-01 11:21:18 MSK [1859-2] LOG: starting archive recovery cp: cannot stat '/backup/0000000100000910000000DE': No such file or directory 2023-08-01 11:21:18 MSK [1859-3] LOG: invalid record length at 910/DE0000A0: wanted 24, got 0 2023-08-01 11:21:18 MSK [1859-4] LOG: redo is not required cp: cannot stat '/backup/0000000100000910000000DE': No such file or directory 2023-08-01 11:21:18 MSK [1859-5] FATAL: WAL ends before end of online backup 2023-08-01 11:21:18 MSK [1859-6] HINT: Online backup started with pg_start_backup() must be ended with pg_stop_backup(), and all WAL up to that point must be available at recovery.

у вас нет wal-логов которые ему нужны с чекпоинта в последнем логе все четко и кратко написано либо restore command написан неправильно

grep -r _command /etc/postgresql/12/main/postgresql.conf #archive_command = 'test ! -f /backup/%f && cp %p /backup/%f' restore_command = 'cp /backup/%f %p'

> убрал archive_command, выключил archive_mode - чтобы на то же место не писало wal файлы в архив Хмм... как-то это не очень надёжно, нет (лучше как-то иначе это "разводить", IMHO)? > restore_command = 'cp /backup/%f %p' Это именно там, где пытаетесь выполнять восстановление? Если да, то вот же проблема: cp: cannot stat '/backup/00000002.history': No such file or directory 2023-08-01 11:21:18 MSK [1859-2] LOG: starting archive recovery cp: cannot stat '/backup/0000000100000910000000DE': No such file or directory

моя ошибка, бэкап шара не была подключена

> Хмм... как-то это не очень надёжно, нет (лучше как-то иначе это "разводить", IMHO)? в archive_command уже встроена проверка, пожалуй мог и не трогать это

Добрый совет: Вы, когда "наиграетесь" (разберётесь в принципах работы [backup] recovery, что DBA необходимо знать, IMHO) — выбросите всё это (кустарные скрипты и т.п.) в окно и возьмите нормальную, взрослую систему для DR (они тут, кстати, обсуждались как бы ни вчера).

я не DBA, я сисадмин - т.е "кто везде тот нигде"

не совсем понятно при чём тут взрослая система для DR (что конечно хорошо, спору нет). wal файлы есть, чекпоинт (какой-то, любой) тоже должен быть.. получается, без команды pg_backup_start - ничего не получится?

При том, что... где Вы взяли этот archive_command, например? Почему Вы уверены, что она надёжна (я просто мельком глянул, если что)? Короче говоря, в "кустарщине" Вы наверняка допустите немало [глупых] ошибок, которых в этих системах просто нет, понимаете? > получается, без команды pg_backup_start - ничего не получится? Ничего подобного я не писал, и должно получаться (прямо сейчас нет времени смотреть на Ваши логи, извините).

из пушки тоже можно воробья убить, но никто так не делает. В любом случае, спасибо всем за участие!

А, ну в таком случае приготовьтесь к таким же (или даже худшим) проблемам в production (а то и к бессонным ночам). Удачи, что тут скажешь. ;)

Невозможно покрыть все случаи дорогими большими системами. Всё что вы описали у меня уже было

Эээ... "дорогими"? Они стоят ровно 0$, если что (их изучение и настройка стоит Вашего времени = денег работодателю, ясное дело). Но они, хотя бы, уже "пробежались" по почти всем тем "граблям", на которые кустарные scripts наступят (или там вообще не было таких ошибок, потому что писали их люди, в этом компетентные).

это не кустарные скрипты, это скрипты из доков постгрес.. и механизмы все - базовые постгрес.. чужие системы решают одни проблемы и создают свои.. ни о чем спор.. нет универсальной таблетки

Ну, у вас жэ не обычный file system-level backup, а снапшот рабочего сервера... Впрочем, да, хужэ от этого быть не должно.

archive_command это алиас

> это не кустарные скрипты, это скрипты из доков постгрес.. ROFL! Из той самой документации: —————— The simplest useful command is something like: archive_command = 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f' # Unix archive_command = 'copy "%p" "C:\\server\\archivedir\\%f"' # Windows which will copy archivable WAL segments to the directory /mnt/server/archivedir. (This is an example, not a recommendation, and might not work on all platforms.) ... It is important that the archive command return zero exit status if and only if it succeeds. Upon getting a zero result, PostgreSQL will assume that the file has been successfully archived, and will remove or recycle it. However, a nonzero status tells PostgreSQL that the file was not archived; it will try again periodically until it succeeds. —————— Так вот показанная в примере команда этого требования и близко не выполняет, если что. > ни о чем спор.. нет универсальной таблетки ORLY?! См. выше. Риторический вопрос: когда люди перестанут самозабвенно "сдирать" примеры (приводимые в документациях для иллюстрации каких-то идей, или для того, чтобы что-то попробовать — например, код, где нет обработки ошибок; scripts для чего-то, написанные по принципу максимальной краткости, а не надёжности и т.д. и т.п.), не читая эту самую документацию?

мастер текстовых переписок)

вы спорите ради спора? Команда archive_command в моем случае копирует wal файлы в архив. Что еще нужно? Возвращает нужный статус. Вы цепляетесь за какую часть фразы "This is an example, not a recommendation, and might not work on all platforms." - да, для платформы windows моя команда не подойдет, и пути у меня другие

вам предлагают проверенные на практике решения по автоматизации и управлению бэкапами. вы настаиваете, что у вас “всё хорошо”. тогда к чему вопросы о том, что у вас что-то не хоршо?

Да ничего подобного, обожемой! Вы понимаете, почему именно она ненадёжна (задумывались над этим), или Вам разжевать? ;( Кстати, показанная Вами ошибка вполне может быть из-за этого... > Что еще нужно? Чтобы она работала. Именно так, как требует документация.

я, со всем уважением, искал тут не менеджеров по продажам, а знатоков postgres

она и работает, у меня недельный архив WAL файлов

"разжевать" "обожаемой".. извините, давайте не будем продолжать.. я задел ваше самолюбие похоже, извините

Так Вы их нашли, но советов Вы не слушаете. :( > она и работает, у меня недельный архив WAL файлов Cool story. Только вот [хотя бы] один из них почти наверняка "битый" — как же так вышло-то, а?

Извините, но Вы явно из тех, кто: "I did not come here to learn, I came here to be right, and I need your help." ©

Ярослав какбы намекает, что эта команда не очень надёжна. Что правда. Особенно в случае сетевых шар (но и без них тожэ).

вы не можете быть уверены в том, что бэкап рабочий просто по наличию файлов. вам надо как минимум восстановиться из этих “файлов”. если вы не можете — нет у вас бэкапа.

верно, можно было бы встроить проверку целостности. но в данном случае проблема явно не в этом, т.к ошибка возникает на первом же файле.. все файлы wal в архиве имеют 16777216 байт

тут несколько вариантов, один из них - не выполнение команды pg_backup_start, который записывает чекпоинт, о чём и был вопрос мой - это обязательный шаг или нет

Это, конечно, хорошо, что у вас записаны файлы правильного размера. Но почему-то ведь в нём есть некорректная запись?

не совем понимаю, в логах об этом ничего не сказано, говорится что чекпоинта не находит 2023-08-01 11:51:45 MSK [2364-1] LOG: database system was interrupted while in recovery at log time 2023-08-01 10:08:30 MSK 2023-08-01 11:51:45 MSK [2364-2] HINT: If this has occurred more than once some data might be corrupted and you might need to choose an earlier recovery target. cp: cannot stat '/backup/00000002.history': No such file or directory 2023-08-01 11:51:45 MSK [2364-3] LOG: starting archive recovery 2023-08-01 11:51:46 MSK [2364-4] LOG: restored log file "0000000100000910000000DE" from archive 2023-08-01 11:51:46 MSK [2364-5] LOG: invalid resource manager ID in primary checkpoint record 2023-08-01 11:51:46 MSK [2364-6] PANIC: could not locate a valid checkpoint record 2023-08-01 11:51:46 MSK [2361-6] LOG: startup process (PID 2364) was terminated by signal 6: Aborted 2023-08-01 11:51:46 MSK [2361-7] LOG: aborting startup due to startup process failure 2023-08-01 11:51:46 MSK [2361-8] LOG: database system is shut down

veeam backup

проверил через pg_waldump этот файл - нет ошибок

У вас в логах вот это: LOG:  invalid resource manager ID in primary checkpoint record Какбы битый файл — это прямо первое предподожэние.

wal файлы накатываются к чекпоинту, выполнение команды pg_backup_start выполняет эту функцию - создает именнованную запись, чекпоинт, обнуляет архивный файл.. у меня в процедуре бэкапа этого нет, в связи с чем похоже возникает эта ошибка.. я хотел убедиться, спросить совета у знатоков - есть ли может обходные пути, т.к какой-то чекпоинт всё равно должен быть

А вы сравните результат pg_controldata на data directory сервера, который пытаетесь запустить, с данными из этого pg_waldump (может, это вообще файл не от того сервера). Кстати, pg_waldump почти наверняка должен был выдать хоть какое-то предупреждение (если нет, это как-то странно).

нет никаких ошибок в wal файлах, проблема не в этом, проблема в отсутствии чекпоинта с команды pg_backup_start, насколько я понимаю

Нет, не должно там быть никакого checkpoint — иначе бы обычное recovery не работало (и это Вам уже писали, вроде?). Т.е. это рабочий метод, в принципе.

я тоже думал "в принципе"

я проверил через pg_waldump несколько файлов wal, всё ок

Ну так получается, что либо где-то в этом вашем методе есть недочёт, либо Вы нашли bug в PostgreSQL, разве нет? Я бы смело поставил на первое. ;)

Нужно не "проверил", а https://t.me/pgsql/488394

А этот... veeamsnap.ko у вас при этом работает? Да, впрочем, без разницы. Поскольку для снапшотов у вас левая подозрительная фигня — начинайте с pg_start_backup() и всем таким.

veeam backup это левая подозрительная фигня? О.о вы не бот-продажник? какую систему рекламируете? сколько стоит?

Впрочем, поглядел на доку... Он (veeam) там ещё какой-то мутной активностью занимается, если обнаружыт постгрес. Вполне можэт быть, что дело в этом.

Конечно, левая. К правой хоть документацыя не на отвали была бы.

сервер заведомо тот.. посмотрел, увидел подсказку в чём дело