В комментах к предыдущей статье обещал выложить статью о том, как собрать pg_probackup. Статья не получилась, ибо она выходила размером ровно в один абзац:
В той же папке из предыдущей статьи, делаем так:
# клонируем актуальную ветку git без истории
[idiot@notebook postgresql-17.5]$ git clone --depth 1 https://github.com/postgrespro/pg_probackup contrib/pg_probackup
...
[idiot@notebook postgresql-17.5]$ make -C contrib/pg_probackup
...
[idiot@notebook postgresql-17.5]$ sudo make -C contrib/pg_probackup install
..
[idiot@notebook postgresql-17.5]$ /usr/local/pgsql/bin/pg_probackup --version
pg_probackup 2.5.15 (PostgreSQL 17.5)
Профит, конец статьи, расходимся.
Но в таком виде оно решительно не годится, ибо получается не статья на серьезном ресурсе, а легкомысленный твит в запрещенной соцсети.
Посему требуется налить немного воды про правильные бэкапы...
Кроме спокойного сна, бэкапы должны нам гарантировать защиту от ряда угроз. Конкретная модель угроз выбирается специфично бизнес-задачам, но в общем случае она подразумевает следующие истории
- ошибки железа (умер диск, сбойнул или сгорел контроллер RAID и т.п.)
- ошибки софта (сбой на уровне ОС при записи в ФС, ошибка в коде СУБД etc)
- кривые руки (одмина, погромиста, поставщика конфигурации и проч.)
- стихийное бедствие (пожар, ракета в сервер, кривые руки)
Кроме вышеперечисленных, которые можно отнести к непредумышленным угрозам, есть предумышленные:
- компроментация сервера в общем, и шифровальщики в частности
- инсайдеры - недовольная уборщица с физическим доступом в серверную загружается с livecd, скачивает вашу терабайтную базу на флешку и продает ее конкурентам на рынке "Садовод". Ну или сисадмин ловит сезонное обострение, выполняет sudo rm -rf /, увольняется и отъезжает на Бали. Или индор разработчик перед увольнением закладывает на ДатаВремяУвольнения + 3*84600 регламентное задание, удаляющее все документы с четными номерами.
Устав бороться с уборщицами и админами с сезонными аффективными расстройствами, кто-то из умников придумал правило "3-2-1": должно быть три копии данных, две из которых - локальные, а одна - удаленная. Это минимум миниморе резервного копирования, постараемся запомнить.
Еще один умник сообразил, что сервер не должен управлять собственным бэкапом, ибо если сломали сервер - сломали и бэкапы. Не стоит полагаться на выгрузку в dt на примонтированную самбу или на дамп базы средствами СУБД. В таком раскладе шифровальщик и самбу тоже зашифрует, и созданный дамп превратит в (псевдо)случайный набор бит. Умник назвал такую схему PUSH backup. В противовес PUSH ессно есть PULL: внешние хосты (те самые "2" из "3-2-1") подключаются к серверу, который надо бэкапить, забирают оттуда данные и хранят их где-то у себя внутре, рядом с неонкой. Бэкапируемый сервер может даже не знать, что его бэкапят.
Третий умник сказал, что для спокойного сна недостаточно делать бэкапы, но также необходимо их проверять.
pg_probackup решительно умеет во все угрозы, перечисленные выше. Также он прекрасно умеет в pull, 3-2-1 и проверку бэкапов. Еще он умеет в ssh, поэтому будет крайне безопасно. Умеет снимать бэкап с реплики, чтобы не грузить боевой инстанс. Инкрементальные бэкапы, восстановление на заданный момент в прошлом, проверку целостности и многие-многие другия тоже умеет. Швейцарский нож мира postgres для бэкапов.
Про настройку pg_probackup есть великолепный цикл из трех статей на Хабре. Ну и официальная документация тоже хороша. Ищущий обрящет.
Продолжение следует...
В следующей серии займемся, наконец, безопасностью: на сервере postgres создадим бесправного юзера, включим его в группу postgres, чтобы он мог читать pg_data(ага-ага, тот самый --allow-group-access из первой статьи), создадим конфиг ssh, чтобы этот юзер не мог запускать ничего, кроме как pg_probackup agent.
Вступайте в нашу телеграмм-группу Инфостарт