Бэкап конфигурации и модели: что снимать перед изменениями

1. Что считается конфигурацией

Модель — не «настройки в файле», а база документов: machine, network, location, environment, column, disk, networkswitch, configrule, supportedstoragepolicy, task, taskschedule, event. Продукт читает её по mTLS на порт 8443 и рендерит конфиги плейбуками. Поэтому правка «одного поля» — это изменение источника истины, а не косметика.

Отдельно стоят метаданные DSS: конфиги /opt/ampli/cfg/arakoon/{arakoonkeeper,dsskeeper}/*.cfg и базы /mnt/meta4/arakoon_*/db. Их снимают перед работами по DSS и ленте, но это тяжёлый и отдельный класс бэкапа — не «конфиг на каждый чих».

2. Когда бэкапить

• Перед любым PUT/POST в модель: сеть, маршрут, статус NIC, политика, rackunit.
• Перед сменой политики DSS или правкой supportedstoragepolicy.
• Перед апгрейдом ОС/ПО: и модель, и очередь, и group_vars.
• Перед повторным прогоном install-ng и перед любой правкой очереди.
• Перед decommission диска/кассеты и перед работами по ёмкости.
• Перед применением вендорского патча и перед снятием обходов.
• Перед вайпом/переустановкой — снимок того, что ещё живо, чтобы было с чем сверять.

Правило простое: если после действия нельзя быстро ответить «каким было значение до», бэкап не сделан.

3. Три способа снять снимок

3.1. Model API (mTLS). Сертификаты продукта root-only, поэтому с ноды — под sudo -n:

for c in machine network location environment column disk networkswitch \
         configrule supportedstoragepolicy task taskschedule event; do
  sudo -n curl -sk \
    --cert /opt/ampli/cfg/marvin/ssl/machine.cert \
    --key  /opt/ampli/cfg/marvin/ssl/machine.key \
    "https://127.0.0.1:8443/model/$c/" > "<BACKUP_DIR>/$c.json"
done

Ожидается 200 и JSON с ключом коллекции. Без клиентского сертификата модель отвечает 400 мгновенно — это норма mTLS, а не отказ API.

3.2. mongodump. Полный снимок базы, включая документы, которые API отдаёт с пагинацией:

mongodump --ssl --sslCAFile /opt/ampli/cfg/ssl/.ca.crt \
  --sslPEMKeyFile <MANAGEMENT_MODEL_PEM> \
  --host 127.0.0.1:27017 --db modeldb \
  --out "<BACKUP_DIR>/modeldb_$(date +%s)/"

Ожидается каталог с .bson-файлами коллекций, размер — не нулевой. Пути к PEM в старых инструкциях устаревали; актуальный путь сверять по доступам к mongo.

3.3. Файлы. Очередь, group_vars, cfg, профили железа:

tar -C /opt/ampli/apps/marvinbase -czf "<BACKUP_DIR>/queue-$(date +%F).tgz" queue
tar -czf "<BACKUP_DIR>/cfg-$(date +%F).tgz" \
  /opt/ampli/cfg/dss* /opt/ampli/cfg/marvin /opt/ampli/cfg/haproxy \
  /opt/ampli/cfg/samurai /opt/ampli/cfg/product/hardware/types \
  /opt/ampli/provision/playbooks/group_vars

Перечислять только существующие каталоги: отсутствие, например, /opt/ampli/cfg/haproxy в конкретной сборке — не ошибка. У нас для модели есть полевой скрипт, который снимает её через mTLS API и складывает каталог с датой-временем; он же удобен, когда mongodump недоступен.

4. Бэкап — вне каталога продукта

Это не формальность. Ansible 1.9.6 в поставке читает все файлы каталога group_vars: если рядом с рабочим .yml лежит .orig или .bak, бэкап может «победить» и применится старое значение. Поэтому копии group_vars не оставляют в самом каталоге.

Правила:

• <BACKUP_DIR> — вне /opt/ampli (отдельный диск, каталог администратора, сетевая шара).
• Имя каталога содержит дату и время: <BACKUP_DIR>/model-YYYYMMDD-HHMMSS/.
• В каталоге — SHA256SUMS, чтобы через месяц можно было отличить целый снимок от обрезанного.
• Временные распаковки и сравнения — тоже вне каталога продукта, иначе их подхватит рендер.
• Не складывать бэкап на ту же ноду, которую собираетесь менять: снимок должен пережить её переустановку.

5. Проверка, что бэкап читается

Снимок, который не открывается, — не бэкап. Проверка занимает минуту и делается до изменений.

1. JSON парсится, коллекция не пуста: bash for f in "<BACKUP_DIR>"/*.json; do python3 -c 'import json,sys; d=json.load(open(sys.argv[1])); k=list(d)[0]; print(sys.argv[1], k, len(d[k]))' "$f" done Ожидается: имя файла, ключ коллекции и число документов. 0 у machine/environment — признак, что запрос ушёл не туда или снимок пустой.

2. Число документов совпадает с живой моделью: bash sudo -n curl -sk --cert /opt/ampli/cfg/marvin/ssl/machine.cert \ --key /opt/ampli/cfg/marvin/ssl/machine.key \ "https://127.0.0.1:8443/model/machine/" \ | python3 -c 'import json,sys; print(len(json.load(sys.stdin)["machine"]))' Сравнить с числом из снимка. Расхождение — либо снимок старее, либо часть документов не выгрузилась (пагинация, права).

3. Архивы целые: bash tar -tzf "<BACKUP_DIR>/cfg-$(date +%F).tgz" | head Ожидается список путей, а не ошибка формата.

4. mongodump не пустой: bash ls "<BACKUP_DIR>"/modeldb_*/modeldb/*.bson | wc -l Ожидается число коллекций больше нуля; файлы ненулевого размера.

5. Контрольные суммы записаны: bash cd "<BACKUP_DIR>" && sha256sum *.json *.tgz > SHA256SUMS Через месяц sha256sum -c SHA256SUMS покажет, цел ли снимок.

6. Хранение и чего бэкап не покрывает

Хранение. Держать копию перед изменением и периодическую копию отдельно от неё; ротация — по датам в имени каталога, удалять самые старые, а не «все кроме последнего». Перед снятием проверить место: df -h <BACKUP_DIR>; обрезанный по месту архив выглядит целым файлом и молча ломается при распаковке.

Снимок модели может содержать чувствительные поля — учётки подключений (почта, SNMP, коннектор ленты), ключи. Хранить с ограниченным доступом и не выкладывать в общие каталоги.

Чего бэкап конфигурации не покрывает:

• Данные S3. Объекты и бакеты — данные приложения; их защита — репликация, версионирование, Object Lock, а не снимок модели.
• Метаданные DSS. /mnt/meta4/arakoon_*/db — отдельный тяжёлый объект; снимается перед работами по DSS/ленте, не в ежедневный конфиг-бэкап.
• Кассеты и лента. Реестр живёт в Tape Connector; снимок модели его не заменяет.

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

7. Восстановление: ожидания и границы

mongorestore возвращает документы в базу, но модель — не изолированная таблица: она связана с arakoon, DSS и приложениями. Восстановление «как было» может разойтись с фактическим состоянием дисков, колонок и ленты.

Поэтому:

• Точечная правка откатывается не архивом, а PUT конкретного документа значениями из снимка — это безопаснее и проверяемо.
• Полное восстановление базы — операция уровня вендора: сначала на не-прод, с отмашкой, с планом сверки (GET /model/<entity>/ до и после).
• Перед восстановлением зафиксировать текущее состояние: без «до» невозможно доказать, что стало лучше.
• Если менялся group_vars/очередь — восстанавливать файлы нужно вне каталога, из которого читает ansible, и переносить по одному, иначе снова сработает эффект «бэкап побеждает».

8. Профилактика: чек-лист перед изменением

• [ ] Понятно, какой документ/файл меняется и какое поле.
• [ ] Снимок снят в <BACKUP_DIR> вне /opt/ampli, с датой в имени.
• [ ] JSON парсится, число документов совпадает.
• [ ] SHA256SUMS записан.
• [ ] Место на диске проверено.
• [ ] Для деструктивных шагов — отмашка и план отката.
• [ ] После изменения — сверка моделью и событиями, а не «на глаз».

В GUI есть Download (выгрузка логов и диагностики) и health check (Configuration > System > General Info > Health Check → Run, результат в Jobs), но кнопки «бэкап конфигурации» в этих разделах нет: снимок делается через Model API и копирование файлов.

Источники

• Quantum, Manage System Settings (дата доступа 2026-11-07): разделы Configuration > System, Download, health check.
• Наша практика (обезличено): снимки модели через mTLS API и mongodump перед правками политики и перед вайпом на кластерах из трёх нод.
• Обновлено: 2026-11-07.