Резервное копирование и восстановление в Базе данных Azure для PostgreSQL — гибкий сервер

Область применения: гибкий сервер Базы данных Azure для PostgreSQL

Резервные копии — это важная составляющая любой стратегии обеспечения непрерывности бизнес-процессов. Они помогают защитить данные от случайного повреждения или удаления.

Гибкий сервер Базы данных Azure для PostgreSQL автоматически выполняет регулярное резервное копирование сервера. Затем можно выполнить восстановление на определенный момент времени (PITR) в пределах указанного срока хранения. Общее время восстановления обычно зависит от размера данных и количества операций восстановления, которые необходимо выполнить.

Обзор службы Azure Backup

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

Срок хранения резервных копий по умолчанию составляет 7 дней, но период можно продлить до 35 дней. Все резервные копии шифруются с использованием 256-битного шифрования AES для неактивных данных.

Эти файлы резервных копий нельзя экспортировать или использовать для создания серверов за пределами гибкого сервера Базы данных Azure для PostgreSQL. Для этой цели можно использовать средства PostgreSQL pg_dump и pg_restore/psql.

Частота резервного копирования

Резервные копии на гибких серверах основаны на моментальных снимках. Создание первой резервной копии моментального снимка планируется сразу же после создания сервера. В настоящее время резервные копии моментального снимка создаются раз в день.

Резервное копирование журнала транзакций происходит с разной периодичностью, в зависимости от рабочей нагрузки и времени заполнения файла WAL и его готовности к архивированию. Как правило, задержка (целевая точка восстановления или RPO) может составлять до 15 минут.

Типы избыточности для резервного копирования

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

Гибкий сервер предлагает три варианта:

  • Хранилище резервных копий, избыточное между зонами: этот параметр автоматически выбирается для регионов, поддерживающих зоны доступности. Если резервные копии хранятся в хранилище резервных копий, избыточном между зонами, то несколько копий хранятся не только в зоне доступности, в которой размещен сервер, но и в другой зоне доступности в том же регионе.

    Этот параметр обеспечивает доступность данных резервного копирования в зонах доступности и ограничивает репликацию данных страной или регионом для удовлетворения требований местонахождение данных. Это также обеспечивает устойчивость объектов резервного копирования как минимум на 99,9999999999 % (12 девяток) в течение заданного года.

  • Локально избыточное хранилище резервных копий. Этот параметр автоматически выбирается для регионов, которые еще не поддерживают зоны доступности. Если резервные копии хранятся в локально избыточном хранилище резервных копий, то несколько копий резервных копий хранятся в одном и том же центре обработки данных.

    Этот вариант помогает защитить ваши данные от сбоев в серверных стойках и на дисках. Это также обеспечивает устойчивость объектов резервного копирования как минимум на 99,999999999 % (11 девяток) в течение заданного года.

    По умолчанию хранилище резервных копий для серверов с высоким уровнем доступности в одной зоне (HA) или без конфигурации высокого уровня доступности имеет значение локально избыточного.

  • Геоизбыточное хранилище резервных копий. Этот параметр можно выбрать во время создания сервера. Когда резервные копии хранятся в геоизбыточном хранилище резервных копий, дополнительно к трем копиям данных, которые хранятся в регионе, где размещен сервер, данные также реплицируются в геопарный регион.

    Благодаря этому параметру сервер можно восстановить в другом регионе в случае аварии. Это также обеспечивает устойчивость объектов резервного копирования как минимум на 99,99999999999999 % (16 девяток) в течение заданного года.

    Геоизбыточность поддерживается для серверов, размещенных в любом из пар регионов Azure.

Переход от других вариантов хранилища резервных копий к геоизбыточному хранилищу резервных копий

Геоизбыточное хранилище можно настроить для резервного копирования только во время создания сервера. После подготовки сервера изменить параметр избыточности для хранилища резервных копий нельзя.

Хранение архивных копий

Резервные копии сохраняются на основе заданного на сервере периода хранения резервной копии. Можно выбрать диапазон хранения от 7 (по умолчанию) до 35 дней. Вы можете задать период хранения при создании сервера или изменить его позже. Резервные копии сохраняются даже для остановленных серверов.

Срок хранения резервных копий определяет, насколько раннюю точку во времени можно задать для PITR, так как это зависит от наличия соответствующих резервных копий. Период хранения резервной копии также можно рассматривать как окно восстановления.

Все резервные копии, необходимые для выполнения PITR в течение периода хранения резервной копии, сохраняются в хранилище резервных копий. Например, если период хранения резервной копии равен 7 дням, окном восстановления будут последние 7 дней. В этом сценарии сохраняются все данные и журналы, необходимые для восстановления сервера, за последние семь дней.

Стоимость хранилищ резервных копий

Гибкий сервер бесплатно предоставляет хранилище резервных копий размером до 100 % объема подготовленного хранилища сервера. За дополнительный используемый объем хранилища резервных копий взимается плата (за ГБ в месяц).

Например, если вы подготовили сервер с хранилищем объемом 250 ГиБ, вам будут бесплатно предоставлены 250 ГиБ хранилища резервных копий. Если ежедневно на резервное копирование уходит 25 ГиБ, вы можете бесплатно использовать хранилище резервных копий в течение 10 дней. Плата за объем хранилища резервных копий, превышающий 250 Гиб, будет взиматься, как определено в модели ценообразования.

Если вы настроили сервер с геоизбыточным резервным копированием, данные резервного копирования также копируются в парный регион Azure. Таким образом, размер резервной копии будет вдвое больше локальной резервной копии. Счет выставляется как ((2 x локальный объем резервной копии) — подготовленный объем хранилища) x цена @ гигабайт в месяц.

Для отслеживания потребляемого сервером пространства в хранилище резервных копий, можно использовать метрику Используемое хранилище резервных копий на портале Azure. Метрика используемого хранилища резервных копий представляет собой суммарную емкость хранилища, используемую для хранения всех резервных копий баз данных и журналов на основе периода хранения резервных копий, заданного для сервера.

Примечание

Независимо от размера базы данных, интенсивное транзакционное действие на сервере создает больше файлов WAL. Увеличение числа файлов в свою очередь увеличивает объем хранилища резервных копий.

Восстановление на определенный момент времени

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

Файлы физической базы данных сначала восстанавливаются из резервных копий моментальных снимков в расположение данных сервера. Соответствующая резервная копия, созданная раньше требуемой точки во времени, выбирается и восстанавливается автоматически. Затем начинается процесс восстановления с помощью файлов WAL, чтобы перевести базу данных в согласованное состояние.

Например, предположим, что резервные копии выполняются ежедневно в 23:00. Если точка восстановления — 15 августа в 10:00, то восстанавливается ежедневная резервная копия от 14 августа. База данных будет восстановлена до 10:00 15 августа с помощью резервной копии журнала транзакций от 23:00 14 августа до 10:00 15 августа.

Для восстановления сервера базы данных см. эти действия.

Важно!

Операция восстановления в гибком сервере всегда создает новый сервер базы данных с предоставленным именем. Она не перезаписывает существующую базу данных.

PITR полезно в таких случаях:

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

Благодаря непрерывному резервному копированию журналов транзакций можно выполнить восстановление до последней транзакции. Можно выбрать один из следующих вариантов восстановления:

  • Последняя точка восстановления (сейчас). Это вариант по умолчанию. Он позволяет восстановить сервер до последней точки во времени.

  • Пользовательская точка восстановления. Этот вариант позволяет выбрать любой момент времени в течение периода хранения, определенного для этого гибкого сервера. По умолчанию автоматически выбирается последнее время в формате UTC. Автоматический выбор полезен, если требуется восстановить последнюю зафиксированную транзакцию в целях тестирования. При необходимости можно выбрать другие дни и время.

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

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

Если сервер настроен в виртуальной сети, можно выполнить восстановление в ту же виртуальную сеть или в другую. Тем не менее выполнить восстановление для общего доступа не удастся. Аналогично, если сервер настроен с общим доступом, выполнить восстановление для частного доступа виртуальной сети не удастся.

Важно!

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

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

Геоизбыточное резервное копирование и восстановление

Сведения о включении геоизбыточного резервного копирования на панели Вычисление и хранение на портале Azure см. в руководстве по быстрому запуску.

Важно!

Геоизбыточное резервное копирование можно настроить только во время создания сервера.

После настройки сервера с геоизбыточным резервным копированием его можно восстановить в геопарный регион. Дополнительные сведения см. в разделе Поддерживаемые регионы для геоизбыточного резервного копирования.

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

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

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

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

Дополнительные сведения о выполнении геовосстановления см. в разделе Руководство.

Важно!

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

С помощью основного региона по-прежнему можно выполнить геовосстановление исходного сервера в геопарный регион. Отключите параметр геоизбыточности в параметрах Вычисление и служба хранилища>Настройка сервера на портале и выполните восстановление как локально избыточного сервера, чтобы обеспечить непрерывность бизнес-процессов.

Восстановление и работа в сети

Восстановление на определенный момент времени

Если на исходном сервере настроена сеть общего доступа, можно выполнить восстановление только для общего доступа.

Если на исходном сервере настроена виртуальная сеть с частным доступом, можно выполнить восстановление в ту же виртуальную сеть или в другую. Нельзя выполнять PITR между общим и частным доступом.

Геовосстановление

Если на исходном сервере настроена сеть общего доступа, можно выполнить восстановление только для общего доступа. Кроме того, после завершения операции восстановления необходимо применить правила брандмауэра.

Если на исходном сервере настроена виртуальная сеть с частным доступом, восстановление можно выполнить только в ту же виртуальную сеть, поскольку виртуальные сети не охватывают регионы. Нельзя выполнить геовосстановление между общим и частным доступом.

Действия, выполняемые после восстановления

После восстановления базы данных можно выполнить следующие задачи, чтобы сделать данные и приложения доступными.

  • Если сервер-источник будет заменен на новый сервер, перенаправьте на него клиенты и клиентские приложения. Измените имя сервера строки подключения, чтобы она указывала на новый сервер.

  • Убедитесь, что для пользовательских подключений заданы соответствующие правила брандмауэра уровня сервера и виртуальной сети. Эти правила не копируются с исходного сервера.

  • Увеличьте или уменьшите масштаб для восстановленных вычислений сервера по мере необходимости.

  • Убедитесь, что заданы соответствующие данные для входа и разрешения уровня базы данных.

  • Настройте оповещения соответствующим образом.

  • Если вы восстановили базу данных, для которой настроена высокая доступность, и хотите настроить для восстановленного сервера высокий уровень доступности, можно выполнить следующие действия.

Часто задаваемые вопросы

  • Каким образом Azure выполняет резервное копирование моего сервера?

    По умолчанию База данных Azure для PostgreSQL включает автоматическое резервное копирование всего сервера (охватывающее все созданные базы данных). По умолчанию используется период хранения в 7 дней. Автоматические резервные копии включают ежедневное добавочное создание моментального снимка базы данных. Система непрерывно архивирует файлы журналов (WAL) в хранилище BLOB-объектов Azure.

  • Можно ли настроить автоматическое резервное копирование для долгосрочного хранения данных?

    Нет. В настоящее время гибкий сервер поддерживает не более 35 дней хранения. Можно создавать резервные копии вручную и использовать их для долгосрочного хранения.

  • Как создать резервную копию вручную для серверов PostgreSQL

    Создать резервную копию вручную можно с помощью имеющегося в PostgreSQL средства pg_dump. Примеры см. в Перенос базы данных PostgreSQL с помощью дампа и ее восстановление.

    Если нужно создать резервную копию Базы данных Azure для PostgreSQL в Хранилище BLOB-объектов, см. соответствующую статью в блоге нашего технического сообщества.

  • Что собой представляют окна резервного копирования для сервера? Можно ли настраивать их?

    Окнами резервного копирования управляет Azure, настраивать их нельзя. Первая полная резервная копия моментального снимка планируется сразу же после создания сервера. Последующие резервные копии моментальных снимков являются добавочными и создаются раз в день.

  • Резервные копии зашифрованы?

    Да. Все данные Базы данных Azure для PostgreSQL, резервные копии и временные файлы, созданные во время выполнения запросов, зашифрованы с помощью 256-битного шифрования AES. Шифрование хранилища всегда включено, и его нельзя отключить.

  • Можно ли восстановить отдельную базу данных или несколько баз данных на сервере?

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

  • Будет ли доступен мой сервер, пока выполняется резервное копирование?

    Да. Резервные копии — это онлайн-операции с использованием моментальных снимков. Операция создания моментального снимка выполняется всего несколько секунд и не мешает рабочим нагрузкам рабочей среды, помогая гарантировать высокий уровень доступности сервера.

  • Нужно ли учитывать период резервного копирования при настройке периода обслуживания для сервера?

    Нет. Создание резервных копий запускается внутри системы в рамках управляемой службы и не влияет на период управляемого обслуживания.

  • Где хранятся автоматически созданные резервные копии и как управлять их хранением?

    База данных Azure для PostgreSQL автоматически создает резервные копии сервера и хранит их в:

    • Хранилище, избыточное между зонами, в регионах, где поддерживается несколько зон.
    • Локально избыточное хранилище в регионах, которые еще не поддерживают несколько зон.
    • Парный регион, если вы настроили геоизбыточное резервное копирование.

    Экспортировать эти файлы резервных копий невозможно.

    Резервные копии можно использовать только для восстановления сервера до состояния на определенный момент времени. По умолчанию срок хранения резервных копий составляет 7 дней. При необходимости можно настроить хранение резервных копий на срок до 35 дней.

  • Как часто копируется в парный регион при геоизбыточном резервном копировании?

    Если на сервере настроено геоизбыточное резервное копирование, то данные резервного копирования хранятся в его учетной записи хранения. Учетная запись хранения копирует файлы данных в парный регион, когда выполняется ежедневное резервное копирование на главном сервере. Создание резервной копии файлов WAL происходит, когда они готовы к архивации.

    Резервные копии данных асинхронно копируются непрерывно в парный регион. При получении данных резервного копирования может возникнуть задержка до одного часа.

  • Можно ли выполнить PITR в удаленном регионе?

    Нет. Данные восстанавливаются до последней доступной резервной копии в удаленном регионе.

  • Как выполняется резервное копирование на серверах с высоким уровнем доступности?

    Резервное копирование томов данных гибкого сервера выполняется с помощью добавочных моментальных снимков управляемых дисков с главного сервера. Резервное копирование WAL выполняют либо с главного сервера, либо с резервного сервера.

  • Как убедиться, что на сервере создаются резервные копии?

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

  • Где можно просмотреть сведения об использовании резервных копий?

    На портале Azure, в меню Мониторинг выберите Метрики. В метрике использования резервного копирования можно отслеживать общее его использование.

  • Что произойдет с соответствующими резервными копиями, если удалить сервер?

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

  • Как хранятся резервные копии для остановленных серверов?

    Для остановленных серверов не создаются новые резервные копии. Все старые резервные копии (в пределах периода хранения) на момент остановки сервера сохраняются до его перезапуска. После этого срок хранения резервной копии активного сервера регулируется периодом хранения.

  • Каким образом взимается плата и выставляются счета за резервные копии?

    Гибкий сервер бесплатно предоставляет хранилище резервных копий размером до 100 % объема подготовленного хранилища сервера. За дополнительный используемый объем хранилища резервных копий взимается плата (за ГБ в месяц), как определено в модели ценообразования.

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

  • Как будет взиматься плата за остановленный сервер?

    Пока экземпляр сервера остановлен, новые резервные копии не создаются. Вы платите за выделенное хранилище и хранилище резервных копий (за резервные копии, хранящиеся в пределах указанного периода хранения).

    Бесплатное хранилище резервных копий ограничено размером подготовленной базы данных. Плата за все лишние данные резервных копий будет начисляться в соответствии с ценой резервного копирования.

  • Сервер настроен с высоким уровнем доступности с избыточностью между зонами. Считается ли это за две резервных копии и будет ли взиматься двойная оплата?

    Нет. Независимо от типа сервера — с высоким уровнем доступности или без него — поддерживается только один набор резервных копий. Плата будет начислена только один раз.

  • Как восстановить мой сервер?

    Azure поддерживает PITR для всех серверов. Пользователи могут выполнить восстановление до последней точки восстановления или до пользовательской точки восстановления с помощью портала Azure, Azure CLI и API.

    Чтобы восстановить сервер из резервной копии, созданной вручную, например с помощью средства pg_dump, можно сначала создать гибкий сервер, а потом восстановить базы данных на этом сервере с помощью средства pg_restore.

  • Можно ли выполнить восстановление в другой зоне доступности в том же регионе?

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

  • Сколько времени займет PITR? Почему восстановление занимает так много времени?

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

  • Если я восстанавливаю сервер с высоким уровнем доступности, будет ли для восстановленного сервера автоматически настроен высокий уровень доступности?

    Нет. Система восстановит сервер как гибкий сервер с одним экземпляром. После завершения восстановления можно дополнительно настроить высокий уровень доступности для сервера.

  • Сервер настроен в виртуальной сети. Могу ли я восстановить его в другой виртуальной сети?

    Да. В процессе восстановления выберите другую виртуальную сеть, в которой необходимо выполнить восстановление.

  • Можно ли восстановить сервер с общим доступом в виртуальной сети или наоборот?

    Нет. На данный момент гибкий сервер не поддерживает восстановление серверов с изменением типа доступа (с общего на частный и наоборот).

  • Как отслеживать операцию восстановления?

    На данный момент не существует способа отслеживать операции восстановления. Вы можете отслеживать журнал действий, чтобы узнать, выполняется ли операция либо она завершена.

Дальнейшие действия