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

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

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

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

Обзор резервного копирования

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

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

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

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

Резервные копии для экземпляров гибкого сервера Azure Database for 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, см. в статье "Создание гибкого сервера Базы данных Azure для PostgreSQL".

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

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

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

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

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

Дополнительные сведения см. в разделе "Восстановление в парный регион" (геовосстановление).

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

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

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

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

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

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

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

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

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

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

• Значения всех параметров сервера на исходном сервере не применяются автоматически к новому серверу. Убедитесь, что все параметры сервера на новом сервере перенастроятся в соответствии с требованиями нового сервера.

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

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

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

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

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

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

Резервные копии по запросу

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

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

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

Ограничения

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

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

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

Долгосрочное хранение теперь общедоступно в Восточной Азии, Центральной Индии, Юго-Восточной Азии, южной и западной частях Великобритании, с поддержкой дополнительных регионов, ожидаемой в ближайшие несколько недель.

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

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

• Настоятельно рекомендуется протестировать резервное копирование и восстановление LTR сразу после настройки, чтобы убедиться, что они соответствуют вашим бизнес-требованиям.
• В настоящее время восстановление LTR доступно только в виде "восстановления в виде файлов" в учетных записях хранения, с планируемой в будущем возможностью восстановления в виде сервера.
• LTR выполняет резервное копирование всех баз данных в экземплярах гибкого сервера, а отдельные базы данных не могут быть выбраны для настройки LTR.
• Резервное копирование LTR не поддерживается на репликах, его можно выполнять на первичных серверах.
• Максимальный поддерживаемый размер базы данных для резервных копий долгосрочного хранения (LTR) составляет 1 ТиБ.
• Резервные копии LTR можно запланировать еженедельно, ежемесячно или ежегодно. Ежедневное расписание резервного копирования в настоящее время не поддерживается.
• Резервные копии LTR не поддерживают таблицы, содержащие строку с длиной BYTEA, превышающей 500 МБ.
• При восстановлении ролей для пользователей Microsoft Entra убедитесь, что проверка подлинности Microsoft Entra включена, и вы вошли в систему в качестве администратора Microsoft Entra для создания дополнительных пользователей. Попытка создания ролей Entra в качестве обычного пользователя приведет к ошибкам.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Доступен ли мой сервер во время выполнения резервной копии?

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

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

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

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

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

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

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

Связанный контент

• Восстановление до последней точки восстановления.
• Восстановление до пользовательской точки восстановления.
• Восстановление до полного резервного копирования (быстрое восстановление)
• Восстановление в парном регионе (геовосстановление).