Комментарии 17
К сожалению дамп это не бекап, он не содержит учётные записи приложения которое должно подключаться к бд. Даже полный дамп всех бд это не бекап из-за других важных параметров. Есть разница между копией данных и копией сервиса.
Это вольный пересказ доки и материалов курса от PostgresPro или оригинальный контент?
Не заметил каких-то историй из продакшна, кроме пожара (если это ИРЛ был случай).
Забыли еще упомянуть важные опции при dump : -j <кол-во потоков> и -f d (формат директорий, без которого -j не сработает). На террабайтных базах без нескольких потоков у вас бэкап будет идти день. А это плохо, так как бэкап - это, естественно, транзакция, так как только за счет MVCC бэкап ничего не блокирует и, в принципе, может идти нормальная работа базы. Однако пока идет бэкап, вакуум работать фактически будет вхолостую, так как нельзя очищать записи после начала транзакции. Соответственно, таблицы будут разрастаться и замедляться работа.
Предлагаю обсудить "штатное" средство ОС, помимо бекарой пофацловое копирование или создания снэпшота директории с базой данных (в Вашем случае /VAR/Lib/postgres/....).
Монтируем диск к данной директории, например /dev/sdb1, отформатированный в NTFS, чтобы, в случае аварийной ситуации его можно было бы открыть на различных устройствах
Делаем с заданной периодичностью снэпшоты на диск /Dev/sdc1, пусть будет также NTFS, с теми же мыслями
Разворачиваем идентичный сервер с идентичными настройками прода postgres, ставим "на горячую" в ЦОД своего провайдера
Льем туда (и еще куда-то) бекап снэпшотов, дампы баз, физические бекапы.
В случае краха всего, мы можем зацепить а-диск /Dev/sdb1 в сервер у провайдера (примерно час) и ничего не потерять
Пока везем к провайдеру диск (или ленимся это делать), то разворачиваем, начиная с самого свежего полученные снэпшоты или цепляем самый свежий развернутый как базу по пути /VAR/lib/postres/... за 15 минут и получаем базу с потерей времени n в рамках наших нормативных документов отдела/организации (которые, кстати, обязательно согласовываются с руководством, а если не согласовываются, то вообще кому нужен такой бизнес, имхо это живой труп)
Перенастраиваем коннекты к базе на сервер у провайдера и начинаем работать с аварийной ситуацией.
Не думаю, что бюджет такого решения будет выше стоимости ежегодного сопровождения сервера включая зарплату devops-а или стоимость услуг подрядчика-аутсорсера
Вариант провайдера: офис прод, резерв складское помещение и тройное резервирование подачи электроэнергии
P.s. если сгорел офис с серверной, то, скорее всего локалка тоже умерла, и сервер БД восстанавливать не так уж и срочно, но это другая история
Скриншоты консольных команд в статье как изюм в кексе: проделки дьявола.
Как выше написали, pg_dump - это не бэкап. Для бэкапа есть WAL-G: https://github.com/wal-g/wal-g.
Вы ошибаетесь - для бэкапов нужен pg_probackup : https://postgrespro.ru/docs/enterprise/14/app-pgprobackup
А где рецепт взять для такой простой процедуры как восстановление на конкретный момент времени одной базы (не всего кластера)?
https://postgrespro.ru/docs/enterprise/14/app-pgprobackup
Чтобы исключить одну или несколько баз из числа восстанавливаемых, используйте ключ --db-exclude:
pg_probackup restore -B каталог_копий --instance имя_экземпляра --db-exclude=имя_базыКлюч --db-exclude может добавляться многократно. Например, чтобы при восстановлении исключить базы данных db1 и db2, выполните следующую команду:
pg_probackup restore -B каталог_копий --instance имя_экземпляра --db-exclude=db1 --db-exclude=db2Чтобы восстановить только некоторые базы данных, выполните команду restore как минимум со следующими параметрами:
pg_probackup restore -B каталог_копий --instance имя_экземпляра --db-include=имя_базы
Ключ --db-include может добавляться многократно. Например, чтобы восстановить только базы db1 и db2, выполните следующую команду:
pg_probackup restore -B каталог_копий --instance имя_экземпляра --db-include=db1 --db-include=db2Хмм, крутяк, спс!)
Но я так полагаю это уже разработка внутри форка
Будет ли это работать на ванильной посгре?
Ну или реверс-вопрос - есть ли у ванильной постгри аналогичная тулза?
Коллеги вы показываете скрины с PG14 и recovery.conf
Но уже начиная с PG14 recovery.conf влили в postgresql.conf и при наличии этого файла сервер не запуститься.
https://www.postgresql.org/docs/14/recovery-config.html
Опечатка? Или я чего-то невнимательно читал?!
Восстановление на требуемый момент времени возможно только всего кластера, нет возможности раздельного отката разных баз.
Это же какой-то позор©
Резервное копирование и восстановление СУБД PostgreSQL