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

ОБЛАСТЬ ПРИМЕНЕНИЯ: База данных Azure для PostgreSQL — гибкий сервер

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

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

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

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

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

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

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

Резервные копии на База данных Azure для PostgreSQL гибких экземплярах сервера основаны на моментальном снимке. Создание первой резервной копии моментального снимка планируется сразу же после создания сервера. В настоящее время резервные копии моментального снимка создаются раз в день. Если дальнейшие изменения не вносятся в базы данных на сервере после последнего резервного копирования моментальных снимков, резервные копии моментальных снимков временно приостановлены. Как только любая база данных на сервере изменяется, новый моментальный снимок немедленно принимается для записи последних изменений. Первый моментальный снимок — это полная резервная копия и последовательные моментальные снимки — разностные резервные копии.

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

географическое и локальное

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

База данных Azure для PostgreSQL гибкий сервер предоставляет до 100 процентов подготовленного хранилища сервера в качестве хранилища резервных копий без дополнительных затрат. Любое дополнительное хранилище резервных копий, которое вы используете, взимается в гигабайтах в месяц.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Убедитесь, что для подключений пользователей применяются соответствующие брандмауэры уровня сервера, частные конечные точки и правила виртуальной сети. В сети общедоступного доступа правила копируются с исходного сервера, но они могут не быть обязательными в восстановленной среде. Таким образом, настройте их в соответствии с вашими требованиями. Частные конечные точки не переносятся. Создайте все частные конечные точки, которые могут потребоваться на восстановленном сервере. В виртуальной сети частного доступа восстановление не копирует артефакты сетевой инфраструктуры из источника в восстановленные серверные сети. Все, что связано с конфигурацией виртуальной сети (виртуальная сеть), подсетями или группами безопасности сети, необходимо заботиться о задаче после восстановления.

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

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

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

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

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

Резервные копии по запросу (предварительная версия)

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

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

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

Длительное хранение

Azure Backup и База данных Azure для PostgreSQL гибкие серверные службы создали долгосрочное решение для резервного копирования корпоративного класса для База данных Azure для PostgreSQL гибких экземпляров сервера, которые хранят резервные копии до 10 лет. Вы можете использовать долгосрочное хранение (LTR) независимо или в дополнение к решению автоматического резервного копирования, предлагаемому База данных Azure для PostgreSQL гибким сервером, который предлагает хранение до 35 дней. Автоматическое резервное копирование — это создание физических резервных копий, подходящих для операций восстановления, особенно при необходимости восстановления из последних резервных копий. Долгосрочные резервные копии помогают вам с учетом потребностей в соответствии с требованиями, более детализированы и используются в качестве логических резервных копий с помощью собственных pg_dump. Помимо долгосрочного хранения, решение предлагает следующие возможности:

• Плановое резервное копирование по запросу, управляемое клиентом, на уровне отдельной базы данных.
• Централизованный мониторинг всех операций и заданий.
• Резервные копии хранятся на отдельных доменах безопасности и сбоя. Если исходный сервер или подписка скомпрометированы, резервные копии остаются в хранилище Azure Backup (в управляемых учетных записях хранилища Azure Backup).
• Использование pg_dump обеспечивает большую гибкость при восстановлении данных в разных версиях базы данных.
• Хранилища резервных копий Azure поддерживают неизменяемость и обратимое удаление (предварительная версия) функций, защищая данные.
• Поддержка резервного копирования LTR для серверов с поддержкой CMK

Рекомендации и ограничения

• Восстановление LTR в настоящее время доступно только как "Восстановление как файлы" в учетных записях хранения с возможностью восстановления как сервера, запланированной в будущем.
• LTR резервное копирование всех баз данных в гибких экземплярах сервера, а отдельные базы данных не могут быть выбраны для конфигурации LTR.
• Резервное копирование LTR не поддерживается в георепликах, но его можно выполнять с первичных серверов.
• Максимальный поддерживаемый размер базы данных для резервного копирования LTR составляет 4 ТиБ.
• Резервные копии LTR можно запланировать еженедельно, ежемесячно или ежегодно. Ежедневное расписание резервного копирования в настоящее время не поддерживается.

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

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

Вопросы, связанные с резервным копированием

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

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

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

  № В настоящее время База данных Azure для PostgreSQL гибкий сервер поддерживает не более 35 дней хранения. Резервные копии можно использовать вручную для долгосрочного хранения с помощью Azure Backup.

• Разделы справки вручную резервное копирование экземпляров гибкого сервера База данных Azure для PostgreSQL?

  Вы можете вручную создать физический моментальный снимок с помощью функции резервного копирования по запросу, вы также можете создавать логические резервные копии с помощью средства PostgreSQL pg_dump. Примеры см. в статье "Миграция База данных Azure для PostgreSQL гибкой базы данных сервера с помощью дампа и восстановления".

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вопросы, связанные с восстановлением

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

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

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

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

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

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

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

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

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

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

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

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

  № База данных Azure для PostgreSQL гибкий сервер в настоящее время не поддерживает восстановление серверов в общедоступном и частном доступе.

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

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

Следующие шаги

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