Есть по меньшей мере 4 способа резервного копирования базы данных на Postgres: SQL дамп, снапшоты файловой системы, непрерывное архивирование и использование сторонних инструментов. Для каждого есть целевая точка восстановления ( RPO - критерий актуальности данных вашего приложения или бизнес-потребностей) и целевое время восстановления (RTO - показатель того, как быстро должно завершиться восстановление после начала сбоя). Вам необходимо соотнести эти показатели с требованиями, которые бизнес предъявляет к данным.

Лучшим способом достижения RTO является использование высокодоступного решения в дополнении к резервным копиям.  Допустим, сбой не реплицируется, тогда процесс отработки отказа даст больше времени для расширенного восстановления.

SQL дамп

Инструмент Postgres pg_dump выполняет SQL дамп. Главное его преимущество заключается в доступности для любой версии Postgres (даже для более старых версий) и для любого пользователя, у которого есть доступ к базе данных. Этот дамп может быть запущен удаленно.

Но для большинства данных производственного масштаба потребуется больше времени для сброса и восстановления, а также большой объем пространства для дампа базы данных ( хотя дамп может быть передан через gzip).  В случае, если дамп запускается удаленно используется высокая пропускная способность сети.

Восстановления производятся с помощью собственного инструмента pg_restore с потенциально высокими RPO и RTO, так как процесс выполнения и восстановления может занять некоторое время.

Снапшоты файловой системы.

Снапшот гораздо быстрее, чем дамп. Однако, есть некоторые моменты, на которые стоит обратить внимание.

Типичная производственная база PostgreSQL постоянно меняется. Также, не все данные записываются в файловую систему в определённый момент времени. Например, есть журналы событий, которые используются для аварийного восстановления. Любой снапшот должен это учитывать, как и файловая система учитывает постоянные снапшоты (такие как ZFS). Но для получения актуальной резервной копии базу данных необходимо остановить. В любом случае, WAL-файлы должны быть включены в каждый снапшот, чтобы быть уверенным в том, что все изменения применены и восстановлены.

Также стоит обратить внимание, что для облачных установок PostgreSQL снапшоты файловых систем легко выполняются через консольные функции. В отношении файлов восстановления применяются стандартные рекомендации, приведенные выше.

Предположим, что снапшот является текущим (что верно для многих облачных провайдеров) либо, что первоначальная rsync завершена, тогда показатель PRO может быть достаточно недавним. RTO может быть расширен в зависимости от того, насколько хорошо определен и реализован процесс восстановления, а также в зависимости от сетевого времени.

Копия файловой системы

На уровне файловой системы доступны такие методы как rsync. Технология rsync синхронизирует файлы на основе их временных меток. Это осуществимо, пока база данных находится онлайн. При использовании для резервного копирования базы данных, в которой многие файлы остаются неизменными, но при этом некоторые постоянно обновляются, вы можете выполнить первоначальную процедуру rsync для захвата основной части данных (это займет больше времени), а затем вторую, более быструю rsync для захвата любых измененных файлов.

Непрерывное архивирование

Непрерывное архивирование — это не обязательно отдельный метод. Это скорее комбинация вышеперечисленных способов в единый процесс. Резервная копия и WAL-файлы используются для восстановления базы данных. Из-за того, что воспроизведение WAL-файлов может быть остановлено в любой временной метке, одним из преимуществ этого процесса является удобное восстановление баз данных в любой доступный момент времени. Абсолютно любое количество WAL-файлов может быть воспроизведено, предполагая, что они возвращаются назад до начала последней резервной копии.

Ключевым моментом в использовании WAL-файлов для восстановления в любом временном моменте является их потоковая передача на сервер базы данных. PostgreSQL перемещается по файлам, перезаписывая их по мере настройки использования пространства. Потоковая передача позволяет Вам избегать перезаписи копии файлов. Она включена в конфигурацию PostgreSQL для запуска WAL -архивирования и определения команды, используемой для копирования файлов в другое место. Заметьте, что PostgreSQL хранит WAL-файлы до тех пор, пока они не будут успешно скопированы. Поэтому, убедитесь в том, что мониторинг подключен во избежание остановки работы из-за недостаточного количества свободного места на диске, сбоев сети и т.д.

В этом процессе для получения исходного файла резервной копии используется собственный инструмент PostgreSQL  pg_basebackup.  Наряду с этой командой используется файл данных сопровождения для записи временных точек начала/окончания резервного копирования и журналов предзаписи (WAL).

Среди собственных методов архивирования (после первоначальной настройки) предлагается лучший RPO, так как архивирование WAL позволяет восстанавливать данные в определенный момент времени. Вы можете расширить RTO, в зависимости от того, насколько хорошо выполнили и внедрили процесс восстановления (на основе сетевого времени).

Сторонние инструменты

Конечно, есть и сторонние инструменты, которые объединяют в себе вышеизложенные методы. Они упрощают резервное копирование в широких топологиях и обладают удобными для пользователя функциями мониторинга и автоматизации. Например, EnterpriseDB предлагает инструмент резервного копирования и восстановления данных.

Одним из таких инструментов с открытым исходным кодом является Barman, который использует как метод rsync, так и непрерывное архивирование. Метод непрерывного архивирования предпочтителен для более современных версий PostgreSQL. В более поздних версиях Barman, WAL- файлы остаются более актуальными благодаря специальным командам, тем самым предоставляя преимущество для RPO. Barman обладает возможностью дублировать себя в различных географических регионах. Это обеспечивает более высокую доступность в случае, если произойдет сбой в единственном дата-центре  или регионе.

Преимущество использования такого инструмента как Barman состоит в том, что он хорошо протестирован во многих средах. У него также есть встроенный набор вспомогательных команд для управления резервными копиями как глобально, так и отдельно на каждом сервере. Например, Вы можете использовать команду barman check-backup <server_name> <backup_id> для проверки согласованности резервной копии и WAL-файлов для полного восстановления. Команды Barman позволяют регистрировать резервные копии, удалять их, осуществлять настройку  репликации Barman, запускать восстановление и т.д. Функции включают возможность осуществления параллельных процессов, сжатия файлов для сокращения пропускной способности сети и удаленного резервного копирования/восстановления.

Как правило, либо непрерывное архивирование, либо Barman поддерживает резервные копии с достаточным количеством RPO и RTO. Внедрение решения для резервного копирования, поддерживающего аварийное восстановление путем хранения резервных копий в дата-центрах или облачных регионах, дает дополнительные преимущества.

No Comments