Блокнот руководителя
Оформите подписку
на рассылку
Заполните форму
Выберите рубрики
Нажимая кнопку, вы даёте согласие на обработку своих персональных данных
Вы всё ещё используете pg_dump?
Пустите в свою жизнь pg_probackup!

Автор
Федотов Алексей
Специалист по информационным системам
Группы компаний "КАМИН"
В настоящее время в нашей стране по различным причинам становится всё больше внедрений, основанных на свободной СУБД PostgreSQL. Не обошла стороной эта тенденция и сферу внедрения решений на базе 1С Предприятия. В частности, наша компания уже давно работает с прикладными решениями 1С на связке Linux+PostgreSQL.

Так как СУБД — это история про данные, а данные надо что? Правильно — беречь! И грамотный администратор первым делом заботится о чём? О резервном копировании данных, находящихся в СУБД.

С чем же предстоит столкнуться администратору, решая задачу резервного копирования, при внедрении у себя СУБД PostgreSQL? С набором консольных утилит! Да, да, консольных, никакой графики «из коробки»!

В комплекте с сервером СУБД идут по сути две утилиты pg_dump и pg_basebackup, которые реализуют различные способы хранения резервной копии (подробнее можно почитать в документации о каждой из них). Но всё же первым и самым «простым» инструментом для создания резервной копии, наверное, для большинства, становится pg_dump. Его очень легко «прикрутить» недолго думая, можно копировать только нужные базы, а не весь сервер PostgreSQL целиком. Да и переместить такую копию между серверами различных версий несколько проще, так как она является независимой от версии сервера (с некоторыми оговорками). В этом плане pg_basebackup выглядит гораздо более сложным инструментом, требующим значительно больших телодвижений для достижения необходимых результатов. Ведь мало сделать резервную копию, её же ещё надо потом успешно восстановить! Многие ли администраторы задумываются об этом? Чаще всего происходит так: настроил выгрузку баз с помощью pg_dump и удаление «устаревших» файлов, и хорошо, ведь время дорого, а разбираться как там всё устроено ой как не хочется! Но нужно бы иногда поглядывать за этим процессом, чтобы место не закончилось или положиться на «авось пронесёт»...
На наш взгляд такой подход несёт ряд существенных рисков для бизнеса, вплоть до полной потери данных, хранимых в СУБД! А выбор pg_dump в качестве инструмента для создания резервных копий, пожалуй не самый удачный! Почему? Давайте разберёмся:

  1. Восстановление из такой резервной копии возможно только на момент начала формирования резервной копии;

  2. При возникновении ошибок в процессе создания резервной копии, с большой долей вероятности вы узнаете об этом только в тот момент когда попытаетесь восстановить такую копию;

  3. Объём дискового пространства, занимаемого резервными копиями, достаточно быстро растёт в зависимости от необходимой «глубины хранения», ведь каждая такая копия будет содержать в большей степени дублирующиеся данные;

  4. Время создания и восстановления резервной копии сильно зависит от объёма ваших данных и производительности сервера и может быть весьма значительным;

  5. У вас нет никакой возможности проверить свои, бережно «сложенные» куда-либо, архивы резервных копий на наличие в них ошибок.
Тем, кому данных доводов мало для того чтобы отказаться от использования pg_dump в качестве основного средства резервного копирования, можно пожелать никогда не столкнуться с ситуацией, когда восстановление из резервной копии потребуется. Ну а тем кто начал задумываться «что же делать?», мы можем посоветовать альтернативу — pg_probackup.

Это утилита, разрабатываемая специалистами российской компании Postgres Proffesional (не путать с pg_basebackup, идущей в комплекте с СУБД), позволяющая настроить процесс резервного копирования СУБД PostgreSQL, так же легко как это делается с помощью pg_dump, однако дающая вам значительные преимущества, например:

  1. Восстановление резервной копии возможно на любой момент времени в рамках заданного временного «окна восстановления»;

  2. Резервные копии проверяются на этапе их создания, поэтому в архив не попадёт «битая» копия данных, которая может создавать у вас иллюзию благополучия;

  3. Объём резервных копий можно сократить за счёт инкрементального копирования, т.е. в архив будут попадать только те данные, которые реально изменились с момента предыдущего резервного копирования;

  4. Время создания инкрементальных копий сильно меньше времени создания полных копий СУБД, а так же выгрузки баз с помощью pg_dump;

  5. Вы можете в любое время проверить состояние ваших резервных копий, например не «побились» ли они после переноса с одного носителя на другой;

  6. Интерфейс управления архивом резервных копий, который позволяет посмотреть информацию как о всех копиях созданных для выбранного сервера, так и подробности по каждой конкретной копии.
В своей работе мы пришли к использованию данного инструмента после долгих экспериментов и поисков вариантов решения трудностей резервного копирования возникающих при эксплуатации крупных проектов, специфика которых требует от нас большой «глубины хранения», но при этом мы сильно ограничены в дисковых ресурсах. Длительный период для управления резервными копиями мы использовали утилиту pg_barman, подбирали стратегии хранения, перемещали резервные копии между файловыми серверами, с целью распределения дисковой нагрузки, но всё равно упирались в ограничения по объёму.

Чтобы наглядно показать разницу в размерах полной резервной копии одного и того же сервера сделанной разными утилитами приведу следующую иллюстрацию
В верхней части, размеры резервных копий, сделанные pg_barman, в нижней части размеры копий сделанные pg_probackup.

Подводя итог, сказанному выше, можно с уверенностью утверждать, что pg_probackup инструмент, подходящий для внедрений любого масштаба, как по простоте его внедрения, так и по получаемой от этого выгоде!

Не откладывайте качественное резервное копирование своих данных на завтра, завтра может быть уже поздно!

Если вы сомневаетесь в своих силах, специалисты нашей компании помогут вам преодолеть возможные трудности при решении такой важной задачи как резервное копирование СУБД PostgreSQL!
Остались вопросы - оставьте заявку.
Мы вам поможем.
Как удобнее с Вами связаться:
"Нажимая на кнопку, Вы даёте согласие на обработку персональных данных и соглашаетесь с политикой конфиденциальности"
kamin@kaluga.ru
(4842) 27-97-22
РУБРИКИ
СВЯЗАТЬСЯ С НАМИ
(4842) 27-97-22,
kamin@kaluga.ru
пер. Теренинский, д. 6а,
г.Калуга
ПОДПИСАТЬСЯ
© 2020