Управление резервными копиями в Managed Service for PostgreSQL
Вы можете создавать резервные копии и восстанавливать кластеры из имеющихся резервных копий.
Также Managed Service for PostgreSQL ежедневно создает автоматическую резервную копию. Вы можете задать время начала резервного копирования и установить срок хранения для нее.
Восстановить кластер из резервной копии
Технология Point-in-Time Recovery (PITR) позволяет восстановить состояние кластера на любой момент времени в интервале от создания самой старой полной резервной копии до архивации самого свежего журнала опережающей записи (Write Ahead Log, WAL). Подробнее см. в разделе Резервные копии.
Восстанавливая кластер из резервной копии, вы создаете новый кластер с данными из резервной копии. Если в каталоге не хватает ресурсов для создания такого кластера, восстановиться из резервной копии не получится. Средняя скорость восстановления из резервной копии — 10 МБайт/с на каждое ядро БД.
Для нового кластера необходимо задать все параметры, обязательные при его создании.
При восстановлении до состояния на текущий момент времени новый кластер будет отражать состояние:
- существующего кластера на момент восстановления;
- удаленного кластера на момент архивации последнего журнала опережающей записи.
Важно
Для резервных копий, созданных вручную:
- Задание произвольного времени восстановления недоступно.
- Кластер можно восстановить только в состояние на момент завершения создания резервной копии.
Чтобы восстановить из резервной копии существующий кластер:
-
Перейдите на страницу каталога и выберите сервис Managed Service for PostgreSQL.
-
Нажмите на имя нужного кластера и выберите вкладку Резервные копии.
-
Нажмите значок
для нужной резервной копии, затем нажмите Восстановить кластер. -
Задайте настройки нового кластера. В списке Каталог можно выбрать каталог для нового кластера.
-
Чтобы восстановить состояние кластера на требуемый момент времени после создания этой резервной копии, задайте нужное значение настройки Дата и время восстановления (UTC). Значение можно ввести вручную или выбрать из выпадающего календаря.
Если оставить настройку без изменений, кластер будет восстановлен в состояние на момент завершения создания резервной копии.
-
Нажмите кнопку Восстановить кластер.
Чтобы восстановить из резервной копии удаленный ранее кластер:
-
Перейдите на страницу каталога и выберите сервис Managed Service for PostgreSQL.
-
Выберите вкладку Резервные копии.
-
Найдите нужную резервную копию по времени создания и идентификатору кластера. В колонке Идентификатор содержатся идентификаторы в формате
<идентификатор_кластера>:<идентификатор_резервной_копии>
. -
Нажмите значок
для нужной резервной копии, затем нажмите Восстановить кластер. -
Задайте настройки нового кластера. В списке Каталог можно выбрать каталог для нового кластера.
-
Чтобы восстановить состояние кластера на требуемый момент времени после создания этой резервной копии, задайте нужное значение настройки Дата и время восстановления (UTC). Значение можно ввести вручную или выбрать из выпадающего календаря.
Если оставить настройку без изменений, кластер будет восстановлен в состояние на момент завершения создания резервной копии.
-
Нажмите кнопку Восстановить кластер.
Managed Service for PostgreSQL запустит операцию создания кластера из резервной копии.
Если у вас еще нет интерфейса командной строки Yandex Cloud, установите и инициализируйте его.
По умолчанию кластер будет восстановлен в тот же каталог, где находится резервная копия. Чтобы восстановить кластер в другом каталоге, укажите идентификатор этого каталога в параметре --folder-id
.
Чтобы восстановить кластер из резервной копии:
-
Посмотрите описание команды CLI для восстановления кластера PostgreSQL:
yc managed-postgresql cluster restore --help
-
Получите список доступных резервных копий кластеров PostgreSQL:
yc managed-postgresql backup list
+--------------------------+---------------------+----------------------+---------------------+ | ID | CREATED AT | SOURCE CLUSTER ID | STARTED AT | +--------------------------+---------------------+----------------------+---------------------+ | c9qlk4v13uq7********:... | 2020-08-10 12:00:00 | c9qlk4v13uq7******** | 2020-08-10 11:55:17 | | ... | +--------------------------+---------------------+----------------------+---------------------+
Время завершения создания резервной копии указано в столбце
CREATED AT
списка доступных резервных копий в форматеyyyy-mm-dd hh:mm:ss
(2020-08-10 12:00:00
в примере выше). Вы можете восстановить состояние кластера на любой момент времени, начиная от создания резервной копии. -
Запросите создание кластера из резервной копии:
yc managed-postgresql cluster restore \ --backup-id=<идентификатор_резервной_копии> \ --time=<время> \ --name=<имя_кластера> \ --environment=<окружение> \ --network-name=<имя_сети> \ --host zone-id=<зона_доступности>,` `subnet-name=<имя_подсети>,` `assign-public-ip=<публичный_доступ_к_хосту> \ --resource-preset=<класс_хоста> \ --disk-size=<размер_хранилища_ГБ> \ --disk-type=<тип_диска>
Где:
-
--backup-id
— идентификатор резервной копии. -
--time
— момент времени, на который нужно восстановить состояние кластера PostgreSQL, в форматеyyyy-mm-ddThh:mm:ssZ
. -
--name
— имя кластера. -
--environment
— окружение:PRESTABLE
— для тестирования. Prestable-окружение аналогично Production-окружению и на него также распространяется SLA, но при этом на нем раньше появляются новые функциональные возможности, улучшения и исправления ошибок. В Prestable-окружении вы можете протестировать совместимость новых версий с вашим приложением.PRODUCTION
— для стабильных версий ваших приложений.
-
--network-name
— имя сети. -
--host
— параметры хоста:-
zone-id
— зона доступности. -
subnet-name
— имя подсети. Необходимо указывать, если в выбранной зоне доступности создано две или больше подсетей. -
assign-public-ip
— флаг, который указывается, если требуется публичный доступ к хосту:true
илиfalse
.
-
-
--resource-preset
— класс хоста. -
--disk-size
— размер хранилища в гигабайтах. -
--disk-type
— тип диска:network-hdd
;network-ssd
;local-ssd
;network-ssd-nonreplicated
.
-
Используйте Terraform для восстановления:
- Существующего кластера из резервной копии.
- Кластера, созданного и удаленного через Консоль управления, CLI или API.
Примечание
Кластер будет восстановлен в каталог, идентификатор которого указан в настройках провайдераfolder_id
.
Для восстановления потребуется идентификатор резервной копии. Получите список доступных резервных копий кластеров PostgreSQL с помощью CLI:
yc managed-postgresql backup list
+--------------------------+---------------------+----------------------+---------------------+
| ID | CREATED AT | SOURCE CLUSTER ID | STARTED AT |
+--------------------------+---------------------+----------------------+---------------------+
| c9qlk4v13uq7********:... | 2020-08-10 12:00:00 | c9qlk4v13uq7******** | 2020-08-10 11:55:17 |
| ... |
+--------------------------+---------------------+----------------------+---------------------+
Ограничения по времени
Провайдер Terraform ограничивает время на выполнение операций с кластером Managed Service for PostgreSQL:
- создание, в том числе путем восстановления из резервной копии, — 30 минут;
- изменение — 60 минут;
- удаление — 15 минут.
Операции, длящиеся дольше указанного времени, прерываются.
Добавьте к описанию кластера блок timeouts
, например:
resource "yandex_mdb_postgresql_cluster" "<имя_кластера>" {
...
timeouts {
create = "1h30m" # Полтора часа
update = "2h" # 2 часа
delete = "30m" # 30 минут
}
}
Чтобы восстановить из резервной копии существующий кластер:
-
Создайте конфигурационный файл Terraform для нового кластера.
При этом не используйте ресурсы баз данных (
yandex_mdb_postgresql_database
) и пользователей (yandex_mdb_postgresql_user
) — они будут восстановлены из резервной копии. -
Добавьте в конфигурационный файл блок
restore
:resource "yandex_mdb_postgresql_cluster" "<имя_кластера>" { ... restore { backup_id = "<идентификатор_резервной_копии>" time = "<время>" } }
Где:
backup_id
— идентификатор резервной копии.time
— момент времени, на который нужно восстановить состояние кластера PostgreSQL, начиная со времени создания выбранной резервной копии. Формат:yyyy-mm-ddThh:mm:ss
.
Примечание
Если параметр
time
не указан, кластер будет восстановлен на момент завершения создания резервной копии. -
Проверьте корректность настроек.
-
В командной строке перейдите в каталог, в котором расположены актуальные конфигурационные файлы Terraform с планом инфраструктуры.
-
Выполните команду:
terraform validate
Если в файлах конфигурации есть ошибки, Terraform на них укажет.
-
-
Подтвердите изменение ресурсов.
-
Выполните команду для просмотра планируемых изменений:
terraform plan
Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.
-
Если вас устраивают планируемые изменения, внесите их:
-
Выполните команду:
terraform apply
-
Подтвердите изменение ресурсов.
-
Дождитесь завершения операции.
-
-
Terraform создаст копию существующего кластера. Базы данных и пользователи будут развернуты из выбранной резервной копии.
Чтобы восстановить из резервной копии удаленный ранее кластер:
-
Создайте конфигурационный файл Terraform для нового кластера.
При этом не используйте ресурсы баз данных (
yandex_mdb_postgresql_database
) и пользователей (yandex_mdb_postgresql_user
) — они будут восстановлены из резервной копии. -
Добавьте в этот конфигурационный файл блок
restore
с именем резервной копии, из которой нужно восстановиться:resource "yandex_mdb_postgresql_cluster" "<имя_кластера>" { ... restore { backup_id = "<идентификатор_резервной_копии>" } }
Где
backup-id
— идентификатор резервной копии удаленного кластера. -
Проверьте корректность настроек.
-
В командной строке перейдите в каталог, в котором расположены актуальные конфигурационные файлы Terraform с планом инфраструктуры.
-
Выполните команду:
terraform validate
Если в файлах конфигурации есть ошибки, Terraform на них укажет.
-
-
Подтвердите изменение ресурсов.
-
Выполните команду для просмотра планируемых изменений:
terraform plan
Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.
-
Если вас устраивают планируемые изменения, внесите их:
-
Выполните команду:
terraform apply
-
Подтвердите изменение ресурсов.
-
Дождитесь завершения операции.
-
-
Terraform создаст новый кластер. Базы данных и пользователи будут развернуты из резервной копии.
Чтобы восстановить кластер из резервной копии, воспользуйтесь методом REST API restore для ресурса Cluster или вызовом gRPC API ClusterService/Restore и передайте в запросе:
- Идентификатор требуемой резервной копии в параметре
backupId
. Чтобы узнать идентификатор, получите список резервных копий в кластере. - Момент времени, на который должен быть восстановлен кластер, в параметре
time
. - Имя нового кластера, который будет содержать восстановленные из резервной копии данные, в параметре
name
. Имя кластера должно быть уникальным в рамках каталога.
По умолчанию кластер будет восстановлен в тот же каталог, где находится резервная копия. Чтобы восстановить кластер в другом каталоге, укажите идентификатор этого каталога в параметре folderId
.
Создать резервную копию
- Перейдите на страницу каталога и выберите сервис Managed Service for PostgreSQL.
- Нажмите на имя нужного кластера и выберите вкладку Резервные копии.
- Нажмите кнопку
Создать резервную копию.
Сервис начнет создавать резервную копию без дополнительного подтверждения.
Если у вас еще нет интерфейса командной строки Yandex Cloud, установите и инициализируйте его.
По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра --folder-name
или --folder-id
.
Чтобы создать резервную копию кластера:
-
Посмотрите описание команды CLI для создания резервной копии PostgreSQL:
yc managed-postgresql cluster backup --help
-
Запросите создание резервной копии, указав имя или идентификатор кластера:
yc managed-postgresql cluster backup my-pg-cluster
Имя и идентификатор кластера можно получить со списком кластеров.
Чтобы создать резервную копию кластера, воспользуйтесь методом REST API backup для ресурса Cluster или вызовом gRPC API ClusterService/Backup и передайте в запросе идентификатор кластера в параметре clusterId
.
Идентификатор кластера можно получить со списком кластеров в каталоге.
Важно
Во время создания резервной копии производительность кластера может снижаться.
Получить список резервных копий
Чтобы получить список резервных копий кластера:
- Перейдите на страницу каталога и выберите сервис Managed Service for PostgreSQL.
- Нажмите на имя нужного кластера и выберите вкладку Резервные копии.
Чтобы получить список всех резервных копий в каталоге:
- Перейдите на страницу каталога и выберите сервис Managed Service for PostgreSQL.
- Выберите вкладку Резервные копии.
Если у вас еще нет интерфейса командной строки Yandex Cloud, установите и инициализируйте его.
По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра --folder-name
или --folder-id
.
Чтобы получить список резервных копий кластеров PostgreSQL, доступных в каталоге по умолчанию, выполните команду:
yc managed-postgresql backup list
+--------------------------+---------------------+----------------------+---------------------+
| ID | CREATED AT | SOURCE CLUSTER ID | STARTED AT |
+--------------------------+---------------------+----------------------+---------------------+
| c9qlk4v13uq7********:... | 2020-08-10 12:00:00 | c9qlk4v13uq7******** | 2020-08-10 11:55:17 |
| c9qpm90p3pcg********:... | 2020-08-09 22:01:04 | c9qpm90p3pcg******** | 2020-08-09 21:30:00 |
+--------------------------+---------------------+----------------------+---------------------+
Чтобы получить список резервных копий кластера, воспользуйтесь методом REST API listBackups для ресурса Cluster или вызовом gRPC API ClusterService/ListBackups и передайте в запросе идентификатор кластера в параметре clusterId
.
Чтобы получить список резервных копий всех кластеров Managed Service for PostgreSQL в каталоге, воспользуйтесь методом REST API list для ресурса Backup или вызовом gRPC API BackupService/List и передайте в запросе идентификатор каталога в параметре folderId
.
Идентификатор кластера можно получить со списком кластеров в каталоге.
Получить информацию о резервной копии
Чтобы получить информацию о резервной копии существующего кластера:
- Перейдите на страницу каталога и выберите сервис Managed Service for PostgreSQL.
- Нажмите на имя нужного кластера и выберите вкладку Резервные копии.
Чтобы получить информацию о резервной копии удаленного ранее кластера:
- Перейдите на страницу каталога и выберите сервис Managed Service for PostgreSQL.
- Выберите вкладку Резервные копии.
Если у вас еще нет интерфейса командной строки Yandex Cloud, установите и инициализируйте его.
По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра --folder-name
или --folder-id
.
Чтобы получить данные о резервной копии кластера PostgreSQL, выполните команду:
yc managed-postgresql backup get <идентификатор_резервной_копии>
Идентификатор резервной копии можно получить со списком резервных копий.
Чтобы получить данные о резервной копии кластера, воспользуйтесь методом REST API get для ресурса Backup или вызовом gRPC API BackupService/Get и передайте в запросе идентификатор резервной копии в параметре backupId
.
Идентификатор резервной копии можно получить со списком резервных копий.
Задать время начала резервного копирования
В консоли управления задать время начала резервного копирования можно при создании или изменении кластера.
Чтобы задать время начала резервного копирования, используйте флаг --backup-window-start
. Время задается в формате ЧЧ:ММ:СС
.
yc managed-postgresql cluster create \
--cluster-name <имя_кластера> \
--environment <окружение> \
--network-name <имя_сети> \
--host zone-id=<зона_доступности>,subnet-id=<идентификатор_подсети> \
--resource-preset <класс_хоста> \
--user name=<имя_пользователя>,password=<пароль_пользователя> \
--database name=<имя_БД>,owner=<имя_владельца_БД> \
--disk-size <размер_хранилища_ГБ>
--backup-window-start 10:00:00
Где environment
— окружение: prestable
или production
.
Изменить время начала резервного копирования в существующем кластере можно с помощью команды update
:
yc managed-postgresql cluster update \
--cluster-name <имя_кластера> \
--backup-window-start 11:25:00
-
Откройте актуальный конфигурационный файл Terraform с планом инфраструктуры.
О том, как создать такой файл, см. в разделе Создание кластера.
Полный список доступных для изменения полей конфигурации кластера Managed Service for PostgreSQL см. в документации провайдера Terraform
. -
Добавьте к описанию кластера Managed Service for PostgreSQL блок
backup_window_start
в секцииconfig
:resource "yandex_mdb_postgresql_cluster" "<имя_кластера>" { ... config { ... backup_window_start { hours = <час> minutes = <минута> } ... } ...
Где:
hours
— час начала резервного копирования (UTC).minutes
— минута начала резервного копирования (UTC).
-
Проверьте корректность настроек.
-
В командной строке перейдите в каталог, в котором расположены актуальные конфигурационные файлы Terraform с планом инфраструктуры.
-
Выполните команду:
terraform validate
Если в файлах конфигурации есть ошибки, Terraform на них укажет.
-
-
Подтвердите изменение ресурсов.
-
Выполните команду для просмотра планируемых изменений:
terraform plan
Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.
-
Если вас устраивают планируемые изменения, внесите их:
-
Выполните команду:
terraform apply
-
Подтвердите изменение ресурсов.
-
Дождитесь завершения операции.
-
Ограничения по времени
Провайдер Terraform ограничивает время на выполнение операций с кластером Managed Service for PostgreSQL:
- создание, в том числе путем восстановления из резервной копии, — 30 минут;
- изменение — 60 минут;
- удаление — 15 минут.
Операции, длящиеся дольше указанного времени, прерываются.
Как изменить эти ограничения?Добавьте к описанию кластера блок
timeouts
, например:resource "yandex_mdb_postgresql_cluster" "<имя_кластера>" { ... timeouts { create = "1h30m" # Полтора часа update = "2h" # 2 часа delete = "30m" # 30 минут } }
-
Чтобы задать время начала резервного копирования, воспользуйтесь методом REST API update для ресурса Cluster или вызовом gRPC API ClusterService/Update и передайте в запросе:
- Идентификатор кластера в параметре
clusterId
. Его можно получить со списком кластеров в каталоге. - Новое время начала резервного копирования в параметре
configSpec.backupWindowStart
. - Список полей конфигурации кластера, подлежащих изменению (в данном случае —
configSpec.backupWindowStart
), в параметреupdateMask
.
Важно
Этот метод API переопределит все параметры изменяемого объекта, которые не были явно переданы в запросе, на значения по умолчанию. Чтобы избежать этого, перечислите настройки, которые вы хотите изменить, в параметре updateMask
(одной строкой через запятую).
Удалить резервную копию
Вы можете удалить только те резервные копии, которые были созданы вручную.
- Перейдите на страницу каталога и выберите сервис Managed Service for PostgreSQL.
- Выберите кластер Managed Service for PostgreSQL, резервную копию которого нужно удалить.
- На левой панели выберите раздел Резервные копии.
- Нажмите на значок
справа в строке резервной копии, которую вы хотите удалить. - Выберите пункт Удалить резервную копию.
- Подтвердите удаление и нажмите кнопку Удалить.
Если у вас еще нет интерфейса командной строки Yandex Cloud, установите и инициализируйте его.
По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра --folder-name
или --folder-id
.
Чтобы удалить резервную копию:
-
Посмотрите описание команды CLI для удаления резервной копии PostgreSQL:
yc managed-postgresql backup delete --help
-
Запросите удаление резервной копии, указав ее идентификатор:
yc managed-postgresql backup delete <идентификатор_резервной_копии>
Идентификатор резервной копии можно получить со списком резервных копий.
Чтобы удалить резервную копию, воспользуйтесь методом REST API delete для ресурса Backup или вызовом gRPC API BackupService/Delete и передайте в запросе идентификатор резервной копии в параметре backupId
.
Идентификатор резервной копии можно получить со списком резервных копий.