Перейти к основному содержимому

Как управлять цепочками резервных копий

Когда использовать​

Когда кластер работает хранителем резервных копий: на нём нужно завести место под копии конкретной ВМ, открыть приём потока, а позже почистить историю или убрать цепочку целиком. Инструкция описывает все операции хранителя, кроме выдачи истории обратно — она разобрана в «Как отдать точку восстановления из цепочки».

Экранов для цепочек в веб-интерфейсе кластера нет: операциями управляет вызывающая сторона — GI или собственный планировщик резервного копирования. Поэтому шаги ниже описаны действиями над объектами, без привязки к экранам. Модель подсистемы — в «Резервное копирование кластер-кластер».

Предусловия​

  • привилегия 14002 (управление цепочками резервных копий) — область действия уровня кластера, роль администратора ВЦОД (виртуального центра обработки данных) такие запросы не проходит;
  • feature.backup в cluster.options кластера-хранителя равна 1; при 0 любая операция подсистемы отвечает -25420;
  • версия vStack Center — 3.0.5;
  • в кластере есть хотя бы один потребляющий пул с живым узлом-владельцем и свободным местом под копию;
  • все операции адресуются кластеру-хранителю: цепочки живут только на нём.

Шаги​

Шаг 1. Создайте цепочку​

Создайте на кластере-хранителе цепочку резервных копий. Укажите только листовое имя — без пула и без префикса .backup. Длина от 1 до 128 символов, состав — латинские буквы, цифры и знаки _, ., -. Пробел, кириллицу, слеш и @ кластер отклоняет кодом -25430. Пул кластер выберет сам. Если полный размер копии известен заранее, передайте оценку размера. Кластер прибавит к ней 20 % запаса на рост цепочки и отбросит пулы, где свободного места меньше этой суммы. Оценка 0 фильтр отключает.

В ответ кластер сообщает полный путь цепочки вида <pool>/.backup/<leaf>, а вместе с ним выбранный пул и адрес узла-владельца этого пула.

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

Шаг 2. Откройте приём потока​

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

Ответ приходит сразу и содержит координаты приёмника — адрес узла-владельца пула и номер выделенного порта. Это то, куда подключается отправляющая сторона: кластер-источник со своей ВМ или другой хранитель, отдающий точку восстановления. Передайте координаты отправителю и уложитесь в таймаут: после его истечения порт закрывается, и приём нужно открывать заново.

Шаг 3. Удалите устаревшую точку восстановления​

Ротация идёт по одной точке. Укажите путь цепочки и короткое имя снимка — суффикс после @, без пути цепочки.

Удаление идемпотентно: повторный запрос на уже удалённой точке отвечает так же. Отдельного признака «точка была и удалена» в ответе нет, поэтому проверять существование снимка заранее не нужно.

Шаг 4. Удалите цепочку целиком​

Удаление цепочки уносит её вместе со всеми точками восстановления, восстановить их после этого нельзя.

Оно тоже идемпотентно. После удаления уберите сохранённый путь цепочки из своего реестра: кластер о цепочке больше ничего не знает.

Проверка результата​

Проверяйте по ответу, но читайте его по операции. У создания цепочки и у обоих удалений успешный ответ — подтверждение выполненной на узле работы: путь цепочки у создания, подтверждение у удалений.

Приём потока живёт по другому правилу. Кластер выделяет порт, ретранслирует команду storage-агенту узла-владельца пула и сразу отдаёт координаты. Поэтому успешный ответ подтверждает ретрансляцию и выданные координаты — непустой адрес узла и номер порта, — а не то, что поток уже принят. Фактический приём данных происходит после подключения отправителя на эти координаты.

Отдельной операции-читателя для сверки нет. Косвенная проверка удалённой цепочки — открыть приём на её путь: ответ -25432 подтверждает, что цепочки действительно больше нет.

Если не получилось​

-25420, подсистема резервного копирования выключена. У кластера feature.backup в cluster.options равна 0. Выключатель действует на кластер целиком и проверяется до всякой работы с пулом, поэтому код приходит на любую из пяти операций. Обход — включить подсистему на этом кластере; обходить её через другую операцию бессмысленно.

-25431 на создании, нет пула с достаточным свободным местом. Кластер не нашёл ни одного потребляющего пула с живым узлом-владельцем, где свободного места хватает на оценку размера с 20 % запаса. Пул, куда копия влезает впритык, под это условие не подходит и тоже отбрасывается. Причина бывает и в оценке, и в состоянии кластера. Обход — уточнить оценку или не передавать её вовсе, освободить место в пуле, проверить, что узлы-владельцы пулов живы.

-25430, недопустимый путь цепочки или имя снимка. Указан путь не вида <pool>/.backup/<leaf> либо имя цепочки или точки восстановления содержит символы вне набора «латинские буквы, цифры, _, ., -». Проверка стоит намеренно: на узлы ретранслируются только пути внутри .backup, иначе операции цепочек добрались бы до датасетов ВМ. Обход — подставлять путь целиком таким, каким его вернуло создание, не собирая его руками.

-25432, цепочка не найдена. Путь корректный, но такой цепочки на кластере нет — чаще всего её уже удалили или создавали на другом кластере. Обход — сверить путь со своим реестром и кластер, которому адресована операция.

-25434, пул цепочки недоступен. Цепочка есть, но узел-владелец её пула не отвечает. Данные не потеряны: операция станет возможной, когда узел вернётся. Обход — разобраться с узлом; переложить цепочку в другой пул средствами подсистемы нельзя.

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

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

См. также​

Методы API​

Операции этой страницы в API: backup-dataset-create, backup-dataset-receive, backup-snapshot-remove, backup-dataset-remove — см. Справочник API.