на шару несколько часов - готово
беру разархивирую на другом хосте и постгрес работает, но я смотрю, что он применяет WAL не с начала бекапа, а за последние несколько минут, хотя логично предполагать, что нам нужен последний коммит с момента последнего чекпоинта до начала бекапа.
можно ли как-то явно открыть "побитую" копию базы и проиграть ещё раз ВАЛы с нужно момента?
Понимаю, что можно как-то зафиксировать перед началом бекапа номер изменения, но в каком файле оно хранится, чтобы восстановление началось с нужного WAL?
Можно просто воспользоваться pg_basebackup.
И да, в докумегиацыи по бэкапу это всё хорошо описано. Хотите сложный путь — идите туда.
Пользуйтесь нормальными средствами для backup (pgBackRest, barman, pg_probackup ... pg_basebackup, наконец), не занимайтесь ерундой. > можно ли как-то явно открыть "побитую" копию базы и проиграть ещё раз ВАЛы с нужно момента? Теоретически — можно, но см. выше.
Можете, конечно, почитать https://www.postgresql.org/docs/current/continuous-archiving.html#BACKUP-LOWLEVEL-BASE-BACKUP , если любопытно... но пользоваться этим не нужно (всё уже написано за нас).
спасибо за совет, но к сожалению специфика приложения в том, что есть колоссальное количество файлов для бекапа, и перечисленные тулзы не дают нужного перфоманса, из того что работало хорошо - был WAL-G но условия изменились так, что теперь только локально бекапим, те же бекапы barman или pg_probackup в виду указанной особенности процессятся непозволительно долго - больше суток или двух, в то время когда обычный pigz PGDATы бежит за пару часов полностью понимаю ваш совет, и несколько лет назад как раз начал работать с менеджерами бекапов, но в данный момент, нахожусь в том месте, где постоянные изменения инфраструктуры компании скорее заставляют изучить lowlevelbackup и использовать его, нежели снова уходить в изучение и реализацию очередной тулзы, выглядит как инвестиция и экономия времени в будущем
А если probackup запараллелить?
если не секрет, что не так с wal-g?
rh8 не могу собрать его нет доступа к интернету (спс секьюрити) то есть как в тулзе для клауд бекапа - надобность пропала но перфоманс выполнения бекапа мне очень нравится (учитывая что это всё в интернет улетает, просто в восторге)
> и перечисленные тулзы не дают нужного перфоманса Это крайне странно. Как раз всё, что можно "наивно" сделать руками, обычно сильно проигрывает pgBackRest, например. > выглядит как инвестиция и экономия времени в будущем Отсюда это выглядит как много "битых" backups в будущем. ;(
а если развернуть локальный s3 сервер и в него отправлять бэкапы через wal-g?
проблема в том, что есть каталог например в 5 миллионов файлов с 0 размером, и архивирование каждого файла стоит времени в контексте пг_пробекапа - время на создание файла на шаре, что довольно много, в общем основная часть времени (80% от времени бекапа) это была создание архивов этих файлов с 0 размером но помню, что разработчик pg_pro был очень оперативен и отзывчив и помогал решить многие проблемы, возможно и эта уже решена, и это снова уходит к тому, что смотрим а что может эта тулза, может уже и барман что-то научился и так по кругу... в то время как знание на более низком уровне смогло бы освободить от этой кабалы =)
пытался реализовать что-то подобное через какие-то прокси для NFS-шары, но видимо я не туда зашёл, нужно было идти от простого "setup local s3 bucket" :)
насколько я понимаю, включенный checksum - не гарантирует проверку на консистентности бекапа, но покажет целостность блока?
Конечно не гарантирует. > но покажет целостность блока? В его окончательном состоянии — да.
Обсуждают сегодня