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

Вы можете быстро восстановить приложение в целевом 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.