Выполнение задачи восстановления приложения#

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

• Kubernetes-ресурсы были случайно удалены и требуют восстановления.

• Необходимо мигрировать данные приложения в другие namespace в том же кластере.

• Требуется миграция ресурсов приложения в namespace других кластеров на платформе.

• Kubernetes-ресурсы, сохранённые в резервной копии в продуктивном кластере, нужно восстановить в кластере аварийного восстановления.

#Предварительные требования

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

• Если у PersistentVolume установлена политика reclaimPolicy со значением Retain, перед восстановлением данных в связанный PVC удалите spec.claimRef.uid и spec.claimRef.resourceVersion на соответствующем PersistentVolume (PV).

• Для восстановления между кластерами (миграции данных) убедитесь, что целевой кластер и кластер, где хранится файл резервной копии, могут читать один и тот же файл резервной копии. Это можно обеспечить двумя способами:

  • Целевой кластер и кластер с файлом резервной копии подключены к одному и тому же объектному хранилищу.

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

• Если при резервном копировании приложения был выбран тип ресурсов Backup Kubernetes resources and persistent volume claims, убедитесь, что имя StorageClass целевого кластера совпадает с именем StorageClass исходного кластера. В противном случае настройте сопоставление между исходным и целевым StorageClass в разделе Advanced Recovery Target Settings.

#Процедура

1. В левой навигационной панели нажмите Clusters > Backup and Recovery.

2. Перейдите на вкладку Recovery Management.

3. Нажмите Execute Application Recovery Task.

4. Настройте параметры следующим образом.

   Параметр	Описание
   Backup Repository	Выберите репозиторий, прошедший проверку подключения, или нажмите Create Backup Repository. Совет: После создания репозитория нажмите OK and Create Application Backup для возврата и продолжения, либо нажмите Create для возврата к списку репозиториев.
   Recovery File Configuration	Выберите файл резервной копии, в котором хранится резервная копия данных. Совет: Префикс имени файла — это имя политики резервного копирования; можно выбрать только успешно сохранённые файлы.
   Recovery Target Configuration	Namespaces: namespace, в котором выполняется восстановление данных, и исходный namespace резервных данных. Допустимый диапазон — namespace, заданные в политике резервного копирования. Система восстанавливает резервные данные в тот же namespace в соответствии с вашим выбором. Совет: Чтобы восстановить в другие namespace в кластере, настройте параметры в Advanced Recovery Target Settings.
   Advanced Recovery Target Settings	Восстановить резервные данные, изначально предназначенные для исходного namespace, в любой namespace кластера (существующий или новый). Source Namespace: выбранный namespace. Target Namespace: namespace, в котором выполняется восстановление данных; может быть существующим или новым, созданным путём ввода несуществующего имени. Совет: Если при резервном копировании приложения был выбран тип ресурсов Backup Kubernetes Resources and Persistent Volume Claims, убедитесь, что имя StorageClass целевого кластера совпадает с исходным. В противном случае настройте имена исходного и целевого StorageClass в расширенных настройках; платформа сохранит данные с использованием нового StorageClass.

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

   Внимание: По умолчанию файл резервной копии сравнивается с ресурсами в целевом namespace. Восстанавливаются только данные, которые есть в файле резервной копии, но отсутствуют в namespace. Ресурсы с тем же именем или инкрементальные ресурсы (существующие в namespace, но отсутствующие в файле резервной копии) не перезаписываются.

   Чтобы перезаписать ресурсы с тем же именем, уже существующие в namespace:

   1. Нажмите YAML в правом верхнем углу для переключения в режим редактирования YAML.

   2. Добавьте existingResourcePolicy: update под .spec, а также добавьте pods в excludedResources следующим образом: excludedResources: ["pods"].

   Совет: Этот способ не может перезаписать данные приложения в persistent volume, связанных с PVC.

6. Нажмите Start.

#Что дальше

1. Импорт namespace: После миграции между кластерами или платформами вручную импортируйте namespace в соответствующий проект в Project Management. В противном случае восстановленное приложение может не отображаться в интерфейсе платформы.

2. Перенастройка фиксированного IP: После миграции между кластерами или платформами фиксированные IP-адреса контейнеров в вычислительных компонентах изменяются. При необходимости вручную обновите параметр Static IP Address группы контейнеров для deployments, daemon sets и stateful sets.

#Соответствующие операции

#Повторить попытку

Если задача восстановления завершилась неудачей, повторите задачу.

#Процедура

1. В левой навигационной панели нажмите Clusters > Backup and Recovery.

2. Перейдите на вкладку Recovery Management.

3. Справа от записи о неудачном восстановлении нажмите Retry и подтвердите.

#Скачать журнал задачи восстановления приложения

При каждом выполнении задачи восстановления создаётся запись восстановления. Просматривайте статус выполнения и детали (YAML) через запись восстановления, а также вручную скачивайте журнал операций задачи восстановления приложения.

#Процедура

1. В левой навигационной панели нажмите Clusters > Backup and Recovery.

2. Перейдите на вкладку Recovery Management.

3. Справа от записи восстановления нажмите Export Log.