Краткий гайд по утилитам PostgreSQL для резервного копирования
База данных — один из ключевых активов компании, а сбой в ее работе может привести к ущербу. Не исключены такие ситуации и с PostgreSQL. Поэтому резервное копирование — одна из основных задач при администрировании базы данных.
Рассказываем, почему нужно резервное копирование, как реализовать защиту данных в PostgreSQL и работать с инструментами для создания дампов.
Зачем делать резервные копии БД
Данные — ключевой актив почти любого бизнеса. До 60% небольших компаний закрываются после потери критически важных данных, а для крупного бизнеса ущерб может измеряться десятками тысяч долларов.
В целом ущерб можно разделить на три категории.
- Остановка бизнес-процессов. Из-за потери данных могут нарушиться бизнес-процессы, а в случае с промышленным предприятием — даже производственные цепочки. Чем больше процессов завязано на данных, тем выше риски. Особенно это актуально для data-driven-компаний, в которых все решения принимают на основе данных.
- Финансовые потери. Восстанавливать БД без резервных копий — сложно, долго и дорого. Плюс во время простоя БД компания теряет потенциальную прибыль.
- Репутационные потери. Последствия, связанные с недоступностью БД, могут негативно отразиться на репутации компании среди клиентов и партнеров.
Поэтому резервное копирование баз данных — важная практика. Она помогает свести к минимуму потерю данных и быстро восстановить работу в случае системного сбоя, атаки злоумышленников, ошибки пользователей. Бэкапы БД создают 91% организаций.
Варианты резервного копирования в PostgreSQL
В PostgreSQL обеспечить сохранность данных на случай сбоя можно несколькими способами.
- SQL-копии. Метод подразумевает использование SQL-команд для экспорта и импорта. SQL-копии содержат структуру БД и данные, которые были в ней на момент создания копии. Метод удобен, но из-за низкой скорости не подходит для работы с большими БД.
- Репликация. При использовании метода данные постоянно реплицируются на резервную и независимую инсталляцию PostgreSQL, размещенную на другом сервере.
Но у репликации есть три недостатка. Во-первых, нужно разворачивать и поддерживать несколько серверов и инсталляций PostgreSQL. Во-вторых, постоянное реплицирование повышает вычислительную нагрузку, что критично при ограниченных мощностях. В-третьих, репликация не подразумевает предварительную проверку файлов — если ошибка попадает в основную БД, она автоматически попадет и в реплику.
- Файловые дампы. Дамп — файл с содержимым базы данных, позволяющий восстановить БД с нуля. В отличие от стандартного бэкапа, который хранит данные в виде бинарных файлов, он хранит данные и структуру в виде текстового файла с инструкциями SQL. Для работы с резервными копиями в PostgreSQL реализована поддержка утилит pg_dump, pg_restore и wal-g.
Перечисленные методы применяются в разных сценариях и имеет свои достоинства. Но когда важна скорость создания бэкапов, нет платформы для развертывания резервной инсталляции PostgreSQL и недопустимо даже потенциальное попадание ошибок в реплику, лучше использовать дампы.
Выбор в пользу дампов оправдан еще по нескольким причинам.
- Дампы сохраняют данные в формате, который легко восстановить. Это обеспечивает простоту восстановления после аварии или сбоя.
- Файловые дампы можно переносить между разными серверами и инсталляциями PostgreSQL, что позволяет развернуть рабочую версию СУБД там, где нужно.
- Дампы позволяют создавать резервные копии и восстанавливать БД с помощью простых команд с логичным и понятным синтаксисом.
Инструменты для работы с дампами в PostgreSQL
PostgreSQL поддерживает несколько утилит для создания дампов и восстановления данных из них. Среди таких — pg_dump, pg_restore и wal-g. Рассмотрим каждую подробнее.
pg_dump
pg_dump — утилита командной строки, с помощью которой можно создавать бэкапы PostgreSQL. Подходит как для полного, так и для выборочного резервного копирования. Позволяет гибко настраивать процесс создания дампа — от выбора формата выходного файла (например, текстовый файл или каталог с отдельными файлами) до уровня параллелизма при создании копии.
При этом pg_dump подходит для создания дампов только одного экземпляра БД. Создавать дампы сразу нескольких БД нельзя.
Утилита pg_dump имеет синтаксис следующего вида:
имя_БД — название БД, бэкап которой нужно сделать.
pg_dump позволяет задавать разные параметры подключения к БД. Например:
- -h (HOSTNAME) — имя хоста, на котором расположена БД;
- -p (PORT) — номер порта, на котором работает сервер БД;
- -U (USERNAME) — имя пользователя, который инициирует запуск создания дампа;
- -W (password) — проверка пароля перед подключением к БД.
Также в опциях можно задать параметры создания дампа.
- -F (FORMAT) — формат файла дампа: plain (p), custom (c), directory (d) (обычный, пользовательский, каталог);
- -f (FILENAME) — название файла резервной копии;
- -c (clean) — включает DROP DATABASE перед восстановлением;
- -C (create) — запуск команды CREATE DATABASE перед восстановлением данных из дампа.
Например, у команды для подключения к локальной базе данных с названием DB от пользователя user1 с запросом пароля и сохранением файла дампа в формате directory под именем db_backup.dump будет следующий вид:
Важно понимать, что у pg_dump есть ограничения. Например, для создания резервных копий больших БД требуется много времени и свободного места на диске. Также с помощью pg_dump нельзя создавать непрерывные резервные копии, необходимые для систем с высокой доступностью.
pg_restore
pg_restore — утилита для восстановления данных из дампов PostgreSQL, созданных с помощью pg_dump. Подходит для восстановления частичных и полных копий. Позволяет гибко настраивать алгоритм восстановления — например, выбирать схемы и таблицы для восстановления, настраивать параллелизм при аварийном восстановлении бэкапа.
У утилиты pg_restore синтаксис следующего вида:
имя_файла_дампа — название файла дампа, из которого нужно восстановить данные.
pg_restore позволяет задавать разные параметры подключения к БД, аналогичные параметрам pg_dump: -h (HOSTNAME), -p (PORT), -U (USERNAME), -W (password).
Параметры утилиты для восстановления данных в pg_restore несколько отличаются. Так, наравне с -f (FILENAME) и -c (clean), есть два дополнительных:
- -d (DBNAME) — имя БД, в которую нужно восстановить данные из дампа;
- -j (jobs) — количество параллельных процессов для восстановления.
Например, команда для подключения к локальной базе данных с названием DB от пользователя user1 с запросом пароля и восстановлением данных из дампа с именем db_backup.dump будет иметь следующий вид:
Еще одна особенность pg_restore — восстановление с применением утилиты потребляет много вычислительных мощностей и в случае больших БД занимает немало времени. К тому же pg_restore не подходит для восстановления WAL-файлов (непрерывных архивных журналов), которые, как правило, применяют в системах, где важна высокая доступность и нулевая потеря данных.
wal-g
wal-g — утилита для PostgreSQL, с помощью которой можно создавать резервные копии WAL-файлов (непрерывных архивных журналов) и восстанавливать их. Также утилита позволяет автоматически управлять хранением и очисткой устаревших WAL.
Достоинство wal-g — в поддержке непрерывного резервного копирования и восстановления данных. Благодаря этому инструмент можно применять в системах, для которых важна высокая доступность и целостность данных.
Синтаксис wal-g следующий:
где:
- command — команда, которую надо выполнить;
- опции — параметры выполнения команды.
Вариантов команд несколько — backup, backup-list, backup-fetch, backup-push, backup-delete, backup-mark, delete, fetch, etc.
Параметры подключения к БД у утилиты wal-g аналогичны параметрам для pg_dump и pg_restore: -h (HOSTNAME), -p (PORT), -U (USERNAME), -W (PASSWORD).
Для создания дампов в wal-g предусмотрено несколько основных команд:
- backup-push — создание и отправка нового бэкапа в удаленное хранилище;
- backup-list — вывод списка доступных бэкапов.
Для восстановления данных из дампа предусмотрены:
- backup-fetch — загрузка бэкапа с удаленного хранилища;
- backup-mark — назначение бэкапа точкой восстановления;
- backup-delete — удаление бэкапа из удаленного хранилища.
Так, команда для создания нового дампа БД и отправки его на удаленное хранилище будет иметь следующий вид:
Команда для восстановления данных до указанной точки в WAL-журнале (LSN) из дампа с удаленного хранилища:
При работе с wal-g важно учитывать, что для корректной работы утилита может требовать дополнительного конфигурирования и глубокой настройки. Более того, надо быть готовым к тому, что создание резервных копий WAL-файлов больших БД — долгий и ресурсоемкий процесс.
Возможные ошибки
Иногда при работе с дампами могут возникать ошибки. Чтобы создание дампов PostgreSQL и восстановление данных из них не превратилось в мучительное испытание, нужно знать, какие ошибки могут возникнуть и как на них реагировать.
- Input file appears to be a text format dump, please use psql. Показывает, что применять утилиту pg_restore нельзя, поскольку у дампа текстовый формат. В таком случае следует использовать команду. Другой вариант — выполняем SQL-запрос, копируем содержимое файла, вставляем данные из буфера в SQL-редактор.
- Too many command-line arguments. Указывает, что при введении команды допущены лишние пробелы. Поскольку для утилиты pg_dump это критично, то от лишних пробелов нужно избавиться.
- Aborting because of server version mismatch. Возникает, когда pg_dump и сервер несовместимы на уровне версий. Например, после обновления консоли или восстановления дампа с удаленной консоли. Решить проблему можно, откатив утилиту до нужной версии или установив ее заново в изолированном пространстве.
- No password supplied. Ошибка характерна для ситуаций, когда переменная PGPASSWORD остается пустой или вообще отсутствует. Обойти проблему можно двумя способами. Настроить сервер в файле pg_hba.conf на получение доступа без пароля или выполнить экспорт переменной PGPASSWORD с помощью команд set (или export) PGPASSWORD.
- No matching tables were found. Ошибка возникает, если не удается найти таблицу, для которой создается дамп. Такое случается, если название таблицы указано неправильно — есть лишние пробелы, нарушен порядок ключей или установлен неверный регистр. В таком случае надо проверить правильность написания названия.
- Некорректная работа команды \. Возникает, если при восстановлении данных возникает ошибка, которую СУБД «из коробки» не отображает. Есть способ исключить такие ситуации — запустить восстановление с опцией -v ON_ERROR_STOP=1. Обнаружив ошибку, система остановит восстановление и выведет на экран соответствующее уведомление.
Главное по теме
Создание резервных копий — обязательная практика при работе с БД. В случае с PostgreSQL защитить данные от рисков и обеспечить их быстрое восстановление можно несколькими способами, в том числе с помощью дампов.
Для работы с дампами в PostgreSQL есть несколько утилит, которые охватывают основные сценарии работы с резервными копиями и позволяют выполнять все операции с помощью простых команд.
Вместе с тем работу с PostgreSQL можно упростить, если разворачивать СУБД в облаке — например, PostgreSQL as a Service есть в облаке VK Cloud. В в облаке можно пользоваться преимуществами геораспределенной инфраструктуры и быстро разворачивать инструменты для резервного копирования и восстановления, что кратко уменьшает риски и пул задач по администрированию.