Комментарии 17
Спасибо за статью.
Подскажите пожалуйста, у pg_probackup v3 будет все таки бесплатная версия или он будет доступен только как часть Enterprise-редакции?
Это станет известно ближе к релизу, потому что вот так звёзды складываются, что прямо сейчас никто вам на этот вопрос точно не ответит.
Если читать доки, что сейчас доступно по версиям:
Можно собрать pg_probackup
https://github.com/postgrespro/pg_probackup
или поставить из реп:
https://postgrespro.github.io/pg_probackup/
но поддержка 17 не заявлена на https://github.com/postgrespro/pg_probackup
как и тут https://repo.postgrespro.ru/pg_probackup/deb/pool/main-noble/p/ нету 17
а для своих продуктов они используют не публичную версию которая в нумерации давно ушла вперед
К сожалению да, я тоже давно заметил, что публичная версия pg_probackup v2 безнадежно отстала от закрытой версии. Только мелкие багфиксы и никакого развития :(
А чего конкретно не хватает в публичной, из того что есть в закрытой?
Встречный вопрос - а что есть в закрытой? Она на то и закрытая, что ченджлог доступен только энтерпрайз пользователям.
В открытой нехватает хранения бэкапов в s3
Но вы так уверенно говорите, что публичная версия пробекапа безнадёжно отстала и там никакого развития, будто у вас есть список того чем обделили.
Список то есть. Посмотрите на количество issue, их 160 штук и кажется что они никогда не будут закрыты. Там и ошибки и предложения нового функционала, например 2 моих предложения раз и два - и вроде бы не сложно и вроде как нужно, но не реализовано и в то же время не отклонены. Или реализовано, но в закрытой версии? Тут я не знаю тк доступа к закрытой версии у меня нет.
Супер, спасибо. Насколько я знаю PM'ы ишуи регулярно смотрят и самое интересное берётся в разработку. В ent версии действительно что-то уже сделано, но, как я говорил выше, надо дождаться выхода тройки, потому что основные усилия разработчиков сейчас там.
Ну, если честно, то первое предложение - прямо классический кейс когда проще дописать и PR прислать, чем просить и ждать.
Я в курсе, что есть разница в версиях pg-probackup:
Инструкция по установке Postgres Pro Standard 16.4.1 не работает.
https://postgrespro.com/products/download
Postgres Pro Std 17 в репах пока нет.
возврат БД postgres на произвольно выбранный момент времени путем накатывания реду логов на бекап начнет работать без боли когда - нибудь?
сейчас это делается ПРИМЕРНО так, извините за мой LLM
никогда так не делал ввиду лени
Если у вас несколько баз данных на одном сервере PostgreSQL, и вам нужно восстановить только одну из них, процесс будет немного отличаться. Вот пошаговая инструкция для такого случая:
Создайте новый кластер PostgreSQL для восстановления:
pg_createcluster [version] recoveryНапример:
pg_createcluster 16 recoveryОстановите новый кластер:
pg_ctlcluster [version] recovery stopОчистите каталог данных нового кластера:
sudo rm -rf /var/lib/postgresql/[version]/recovery/*Восстановите базовый бэкап только нужной базы данных в новый кластер:
pg_restore -C -d postgres -U postgres -h localhost -p [port_of_new_cluster] [path_to_backup_file]Флаг
-Cсоздаст базу данных, если она не существует.Создайте файл recovery.signal в каталоге данных нового кластера:
sudo touch /var/lib/postgresql/[version]/recovery/recovery.signalОтредактируйте postgresql.conf нового кластера:
sudo nano /var/lib/postgresql/[version]/recovery/postgresql.confДобавьте следующие строки:
restore_command = 'cp /path/to/archive/%f %p' recovery_target_time = '2024-10-24 14:30:00' recovery_target_action = 'promote'Запустите новый кластер:
pg_ctlcluster [version] recovery startМониторьте процесс восстановления в логах:
sudo tail -f /var/log/postgresql/postgresql-[version]-recovery.logПосле завершения восстановления, проверьте состояние базы данных:
psql -p [port_of_new_cluster] -d [restored_db_name]Если все в порядке, вы можете остановить оригинальный кластер и скопировать восстановленную базу данных обратно:
pg_dumpall -p [port_of_new_cluster] -d [restored_db_name] | psql -p [port_of_original_cluster] -d postgresУдалите временный кластер:
pg_dropcluster [version] recovery
Этот метод позволяет восстановить одну базу данных, не затрагивая остальные базы на сервере. Он создает временный кластер для восстановления, что минимизирует риск повреждения данных в основном кластере.
Важные замечания:
Убедитесь, что у вас достаточно места на диске для создания временного кластера.
Проверьте, что порты нового и оригинального кластеров не конфликтуют.
Всегда делайте резервную копию перед выполнением операций восстановления.
В зависимости от версии PostgreSQL, некоторые команды или файлы конфигурации могут слегка отличаться.
Есть ещё pgBackRest утилитка, хотелось бы почитать сравнение с ней
PostgreSQL 17: уже можно просто делать бекапы и перестать страдать?