Резервное копирование и восстановление в Базе данных 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) может составлять до 15 минут.

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

База данных 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. Метрика используемого хранилища резервных копий представляет собой суммарную емкость хранилища, используемую для хранения всех резервных копий баз данных и журналов на основе периода хранения резервных копий, заданного для сервера.

Примечание.

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

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

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

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

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

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

Внимание

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

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

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

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

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

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

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

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

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

Внимание

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

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

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

Внимание

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

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

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

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

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

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

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

Внимание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Долгосрочное хранение (предварительная версия)

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

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

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

  • В предварительной версии восстановление LTR в настоящее время доступно как RestoreasFiles в учетных записях хранения. Функция RestoreasServer будет добавлена в будущем.
  • В предварительной версии можно выполнить резервное копирование LTR для всех баз данных, в будущем будет добавлена поддержка резервного копирования отдельной базы данных.
  • Резервное копирование LTR в настоящее время не поддерживается для серверов с поддержкой CMK. Эта возможность будет добавлена в будущем.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    База данных 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 гибкий сервер в настоящее время не поддерживает восстановление серверов в общедоступном и частном доступе.

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

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

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