Резервные копии в Managed Service for PostgreSQL
Managed Service for PostgreSQL обеспечивает автоматическое и ручное резервное копирование баз данных.
Для кластеров с неподдерживаемой версией СУБД восстановление из резервных копий недоступно.
Чтобы восстановить кластер из резервной копии, следуйте инструкциям.
Создание резервной копии
Первая и каждая седьмая автоматические резервные копии, а также все резервные копии, созданные вручную, — полные резервные копии всех баз данных. Остальные резервные копии — инкрементные, в них хранится только разница с предыдущей резервной копией, что позволяет экономить место в хранилище.
Как полные, так и инкрементные резервные копии создаются с помощью утилиты wal-g. Для реализации восстановления на любой момент времени (Point-in-Time-Recovery, PITR) используются данные из журналов опережающей записи (Write Ahead Log, WAL). Подробнее в разделе PITR в Managed Service for PostgreSQL.
Чтобы снизить нагрузку на мастер, для создания резервной копии используются данные с реплики.
Важно
В передаваемом на реплики журнале WAL нет изменений таблиц UNLOGGED и TEMP, поэтому данные из них не добавляются в резервную копию. Данные в таблицах UNLOGGED и TEMP сохраняются только до момента ручного переключения мастера или его перезагрузки.
Резервная копия всех данных кластера автоматически создается раз в день. Отключить автоматическое создание резервной копии невозможно. Однако при создании или изменении кластера для таких резервных копий можно задать:
- Срок их хранения.
- Промежуток времени, в течение которого начинается резервное копирование. По умолчанию —
22:00 - 23:00UTC (Coordinated Universal Time).
После создания резервная копия сжимается для дальнейшего хранения. Отображение точного размера резервной копии недоступно.
Резервные копии создаются только на работающих кластерах. Если вы используете кластер Managed Service for PostgreSQL не круглосуточно, проверьте настройки времени начала резервного копирования. Кластер, у которого нет резервных копий, невозможно остановить.
О том, как вручную создать резервную копию, читайте в разделе Управление резервными копиями.
Важно
Если резервная копия создана вручную, то кластер можно восстановить только в состояние на момент завершения создания резервной копии.
Хранение резервной копии
Особенности хранения резервных копий в Managed Service for PostgreSQL:
-
Резервные копии хранятся в объектном хранилище в виде бинарных файлов и шифруются с помощью GPG. У каждого кластера свои ключи шифрования.
-
Общий объем резервной копии определяется как сумма объемов копии данных и журнала WAL. Объем данных журнала WAL зависит от количества вносимых изменений и может превышать объем копии. Оба значения можно получить со списком резервных копий.
-
Срок хранения резервных копий существующего кластера зависит от способа их создания:
-
Автоматические резервные копии по умолчанию хранятся 7 дней. При создании кластера или изменении его настроек можно задать другой срок хранения в диапазоне от 7 до 60 дней.
-
Автоматические резервные копии, созданные с помощью политик резервного копирования, могут храниться от 7 до 1095 дней (до трех лет).
-
Резервные копии, созданные вручную, хранятся бессрочно.
-
-
После удаления кластера все его резервные копии хранятся 7 дней.
-
На хранилище резервных копий не распространяется действие квот и лимитов для хранилища кластера.
-
Резервные копии содержатся в объектном хранилище и не занимают место в хранилище кластера. При этом если в кластере есть N свободных гигабайт места, то хранение первых N гигабайт резервных копий не тарифицируется.
Подробнее в разделе Правила тарификации для Managed Service for PostgreSQL.
Восстановление из резервной копии
Восстанавливая кластер из резервной копии, вы создаете новый кластер. При этом понадобится задать все его параметры, как и при обычном создании кластера. Если в каталоге не хватает ресурсов для создания такого кластера, восстановиться из резервной копии не получится. Средняя скорость восстановления из резервной копии — 10 МБ/с на каждое ядро БД.
Кластер восстанавливается до состояния на выбранный момент времени с использованием PITR. Новый кластер будет отражать состояние:
- существующего кластера на момент архивации самого свежего WAL;
- удаленного кластера на момент архивации последнего WAL.
Из резервной копии кластер восстанавливается целиком со всеми БД. Выбрать желаемые БД нельзя.
Совет
Периодически проверяйте восстановление кластеров продуктивных систем. Убедитесь в целостности данных в восстановленном кластере.
PITR в Managed Service for PostgreSQL
Managed Service for PostgreSQL позволяет восстановить состояние кластера на любой момент времени (Point-in-Time-Recovery, PITR) после создания самой старой полной резервной копии. Это достигается за счет дополнения данных резервной копии, выбранной в качестве начальной точки для восстановления, архивированными записями из журналов WAL.
Например, если операция создания резервной копии завершилась 10.08.2020 в 12:00:00 UTC, текущая дата — 15.08.2020 19:00:00 UTC, а последний журнал опережающей записи был сохранен 15.08.2020 в 18:50:00 UTC, кластер может быть восстановлен в любое свое состояние в промежутке времени с 10.08.2020 12:00:01 UTC до 15.08.2020 18:50:00 UTC включительно.
WAL состоит из файлов размером 16 МБ, которые архивируются в работающем кластере по мере достижения нужного размера или если с момента последней архивации прошло время, заданное настройкой СУБД уровня кластера archive timeout. Затем архив загружается в объектное хранилище.
Важно
На создание и загрузку архива WAL в объектное хранилище требуется некоторое время. Из-за этого состояние кластера, сохраненное в объектном хранилище, может отличаться от реального.
По умолчанию PITR включен.
Подробнее о PITR читайте в документации PostgreSQL.