Pull to refresh

Comments 17

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

Это вольный пересказ доки и материалов курса от PostgresPro или оригинальный контент?

Не заметил каких-то историй из продакшна, кроме пожара (если это ИРЛ был случай).

Забыли еще упомянуть важные опции при dump : -j <кол-во потоков> и -f d (формат директорий, без которого -j не сработает). На террабайтных базах без нескольких потоков у вас бэкап будет идти день. А это плохо, так как бэкап - это, естественно, транзакция, так как только за счет MVCC бэкап ничего не блокирует и, в принципе, может идти нормальная работа базы. Однако пока идет бэкап, вакуум работать фактически будет вхолостую, так как нельзя очищать записи после начала транзакции. Соответственно, таблицы будут разрастаться и замедляться работа.

Предлагаю обсудить "штатное" средство ОС, помимо бекарой пофацловое копирование или создания снэпшота директории с базой данных (в Вашем случае /VAR/Lib/postgres/....).

  1. Монтируем диск к данной директории, например /dev/sdb1, отформатированный в NTFS, чтобы, в случае аварийной ситуации его можно было бы открыть на различных устройствах

  2. Делаем с заданной периодичностью снэпшоты на диск /Dev/sdc1, пусть будет также NTFS, с теми же мыслями

  3. Разворачиваем идентичный сервер с идентичными настройками прода postgres, ставим "на горячую" в ЦОД своего провайдера

  4. Льем туда (и еще куда-то) бекап снэпшотов, дампы баз, физические бекапы.

  5. В случае краха всего, мы можем зацепить а-диск /Dev/sdb1 в сервер у провайдера (примерно час) и ничего не потерять

  6. Пока везем к провайдеру диск (или ленимся это делать), то разворачиваем, начиная с самого свежего полученные снэпшоты или цепляем самый свежий развернутый как базу по пути /VAR/lib/postres/... за 15 минут и получаем базу с потерей времени n в рамках наших нормативных документов отдела/организации (которые, кстати, обязательно согласовываются с руководством, а если не согласовываются, то вообще кому нужен такой бизнес, имхо это живой труп)

  7. Перенастраиваем коннекты к базе на сервер у провайдера и начинаем работать с аварийной ситуацией.

  8. Не думаю, что бюджет такого решения будет выше стоимости ежегодного сопровождения сервера включая зарплату devops-а или стоимость услуг подрядчика-аутсорсера

  9. Вариант провайдера: офис прод, резерв складское помещение и тройное резервирование подачи электроэнергии

  10. P.s. если сгорел офис с серверной, то, скорее всего локалка тоже умерла, и сервер БД восстанавливать не так уж и срочно, но это другая история

Вы придумали физическую репликацию?

Скриншоты консольных команд в статье как изюм в кексе: проделки дьявола.

А где рецепт взять для такой простой процедуры как восстановление на конкретный момент времени одной базы (не всего кластера)?

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

Хмм, крутяк, спс!)
Но я так полагаю это уже разработка внутри форка
Будет ли это работать на ванильной посгре?
Ну или реверс-вопрос - есть ли у ванильной постгри аналогичная тулза?

Будет ли это работать на ванильной посгре?

Да, будет.

pg_probackupумеет бэкапить ванильный постгрес (и восстанавливать)

Коллеги вы показываете скрины с PG14 и recovery.conf

Но уже начиная с PG14 recovery.conf влили в postgresql.conf и при наличии этого файла сервер не запуститься.

https://www.postgresql.org/docs/14/recovery-config.html

Опечатка? Или я чего-то невнимательно читал?!

Восстановление на требуемый момент времени возможно только всего кластера, нет возможности раздельного отката разных баз.

Это же какой-то позор©

Sign up to leave a comment.