Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье описывается, как восстановить сервер Azure PostgreSQL-Flexible из файлов, резервных копий, сделанных через портал Azure.
Предварительные условия
Прежде чем восстанавливать данные из резервных копий в гибком сервере базы данных Azure для PostgreSQL, ознакомьтесь со следующими требованиями:
Убедитесь, что у вас есть необходимые разрешения для операции восстановления.
Данные резервного копирования хранятся в хранилище резервных копий в виде блоба в учетной записи Майкрософт. Во время операции восстановления данные резервного копирования копируются из одной учетной записи хранения в другую между клиентами. Убедитесь, что целевая учетная запись хранения для восстановления имеет свойство AllowCrossTenantReplication с значением true.
Убедитесь, что целевая учетная запись хранения для восстановления резервного копирования в виде файла доступна через общедоступную сеть. Если учетная запись хранения использует частную конечную точку, обновите параметры доступа к общедоступной сети перед выполнением операции восстановления.
Восстановление Azure PostgreSQL — гибкие резервные копии сервера в виде файлов
Замечание
Операция восстановления — это два этапа:
- Восстановите резервную копию из хранилища резервных данных в контейнер для хранения.
- Восстановите файлы резервной копии из контейнера хранилища на новый или существующий гибкий сервер.
Чтобы восстановить базу данных Azure PostgreSQL-Flexible, выполните следующие действия.
Перейдите к хранилищу резервных копий>экземплярам резервного копирования. Выберите гибкий сервер PostgreSQL для восстановления и выберите "Восстановить".
Кроме того, перейдите в центр резервного копирования и выберите " Восстановить".
Выберите момент времени, который вы хотите восстановить, используя точку восстановления. Измените диапазон дат, выбрав период времени.
Выберите целевую учетную запись хранения и контейнер на вкладке "Параметры восстановления". Нажмите кнопку "Проверить", чтобы проверить разрешения параметров восстановления перед окончательным просмотром и восстановлением.
После успешной проверки нажмите кнопку "Проверить и восстановить".
После окончательной проверки параметров выберите "Восстановить ", чтобы восстановить выбранную резервную копию сервера PostgreSQL — гибкое резервное копирование сервера в целевой учетной записи хранения.
Отправьте операцию восстановления и отслеживайте инициируемое задание в области Задания резервного копирования.
После успешного завершения задания восстановления перейдите в контейнер учетной записи хранения, чтобы просмотреть восстановленные базы данных в виде файлов (.sql
файлов) с гибкого сервера PostgreSQL. Azure Backup также создает следующие файлы резервного копирования:
Database.sql file
по базе данных: содержит данные и информацию о схеме для конкретной базы данных.Roles.sql files
для всего экземпляра: содержит всю информацию о ролях, доступную на уровне сервера.Tablespace.sql file
: файл пространства таблиц.Schema.sql file
: содержит сведения о схеме для всех баз данных на сервере.Замечание
Рекомендуется не запускать этот скрипт на гибком сервере PostgreSQL, так как схема уже является частью скрипта
database.sql
.
Восстановление файлов резервной копии из контейнера хранилища на новый или существующий сервер PostgreSQL — гибкий сервер
Чтобы восстановить файлы резервной копии из контейнера хранилища на новый или существующий сервер PostgreSQL — гибкий сервер, выполните следующие действия.
Убедитесь, что на новом целевом гибком сервере включены все необходимые расширения .
Сопоставлять значения параметров сервера из исходной базы данных PostgreSQL с базой данных Azure для PostgreSQL, используя раздел параметров сервера на портале Azure и вручную обновив значения соответствующим образом. Сохраните изменения параметров, а затем перезапустите базу данных Azure для PostgreSQL — гибкий сервер, чтобы применить новую конфигурацию.
Если на новом сервере требуется проверка подлинности Microsoft Entra, включите её и создайте соответствующих администраторов Microsoft Entra.
Создайте новую базу данных для восстановления.
Замечание
Перед восстановлением базы данных необходимо создать новую пустую базу данных. Убедитесь, что у вашего аккаунта есть разрешение
CREATEDB
.Чтобы создать базу данных, используйте команду
CREATE DATABASE Database_name
.Восстановите базу данных с помощью
database.sql file
в качестве целевого администратора пользователя. 1.После создания целевой базы данных восстановите данные в этой базе данных (из файла дампа) из учетной записи хранения Azure, выполнив следующую команду:az storage blob download --container-name <container-name> --name <blob-name> --account-name <storage-account-name> --account-key <storage-account-key> --file - | pg_restore -h <postgres-server-url> -p <port> -U <username> -d <database-name> --no-owner -v –
-
--account-name
: имя целевой учетной записи хранения. -
--container-name
: имя контейнера объектов BLOB. -
--blob-name
: имя большого двоичного объекта. -
--account-key
: ключ учетной записи облачного хранилища. -
-Fd
: формат каталога. -
-j
: количество работ. -
-C
: Начните выполнение команд для создания базы данных, потом подключитесь к ней снова.
Кроме того, можно скачать файл резервной копии и запустить восстановление напрямую.
-
Восстановите только необходимые роли и привилегии и игнорируйте распространенные ошибки. Пропустите этот шаг, если вы выполняете восстановление для соблюдения требований и извлечения данных как локальный администратор.
Восстановление ролей и пользователей для восстановленных баз данных
Архивные резервные копии в основном восстанавливаются для нужд соблюдения требований, таких как тестирование и аудит. Вы можете войти в систему как локальный администратор и восстановить его с помощью database.sql
файла. Для получения данных другие роли не требуются.
Для других использования, таких как случайная защита от удаления или аварийное восстановление, убедитесь, что необходимые роли создаются в соответствии с потребностями организации. Избегайте дублирования между roles.sql
и database.sql
.
- Восстановление того же гибкого сервера: восстановление ролей может не потребоваться.
-
Восстановление на другом гибком сервере: используйте
roles.sql
файл для повторного создания необходимых ролей.
При восстановлении из roles.sql
некоторые роли или атрибуты могут оказаться недопустимыми для нового целевого сервера.
Для сред с доступом суперпользователя (локальные или виртуальные машины) можно легко выполнять все команды.
Основные рекомендации по сценарию гибкого сервера
Ниже приведены основные аспекты.
-
Удалите атрибуты Superuser-Only: на гибком сервере нет привилегий суперпользователя. Таким образом, удалите атрибуты, такие как
NOSUPERUSER
иNOBYPASSRLS
, из дампа ролей. -
Исключить Service-Specific пользователей: Исключить пользователей, относящихся к службам гибкого сервера (
azure_su
,azure_pg_admin
,replication
,localadmin
,Entra Admin
). Данные роли службы автоматически воссоздаются при добавлении администраторов на новый гибкий сервер.
Перед восстановлением объектов базы данных убедитесь, что вы правильно дамп и очищаете роли. Чтобы выполнить это действие, скачайте roles.sql
скрипт из контейнера хранилища и создайте все необходимые имена входа.
- Создание ролей, не связанных с Entra: используйте учетную запись локального администратора для запуска скриптов создания ролей.
- Создание ролей Microsoft Entra. Если необходимо создать роли для пользователей Microsoft Entra, используйте учетную запись администратора Microsoft Entra для запуска необходимых сценариев.
Скрипт ролей можно скачать из аккаунта хранилища, как показано на следующем скриншоте.
При переносе выходного файла roles.sql
могут включать определенные роли и атрибуты, которые не применимы в новой среде. Необходимо учитывать следующее:
- Удаление атрибутов, которые могут быть заданы только суперпользователями: если вы переходите в среду, где у вас нет привилегий суперпользователя, удалите такие атрибуты, как NOSUPERUSER и NOBYPASSRLS из дампа ролей.
-
Исключение пользователей, относящихся к специфической службе: Исключите пользователей службы одного сервера, например
azure_superuser
илиazure_pg_admin
. Они специфичны для службы и создаются автоматически в новой рабочей среде.
Используйте следующую команду sed для очистки дампа ролей:
sed -i '/azure_superuser/d; /azure_pg_admin/d; /azuresu/d; /^CREATE ROLE replication/d; /^ALTER ROLE replication/d; /^ALTER ROLE/ {s/NOSUPERUSER//; s/NOBYPASSRLS//;}' roles.sql
Эта команда удаляет строки, содержащие azure_superuser
azure_pg_admin
azuresu
, строки, начиная с репликации CREATE ROLE и репликации ALTER ROLE, и удаляет атрибуты NOSUPERUSER и NOBYPASSRLS из инструкций ALTER ROLE.
Следующие шаги
Управление резервным копированием Azure PostgreSQL — гибкий сервер с помощью портала Azure.