arculaДокументация

Хранилища

Проверки хранилища

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

Что показывает «Состояние»

Сначала критичное, потом замечания, потом факты:

ФразаЧто значит
«Нет доступа: 403 AccessDenied с 12:02.»Не прошла проверка доступа
«Не сохранено подряд: prod-db-01 — 36 бэкапов.»Эти серверы сейчас не сохраняют сюда новые бэкапы
«Проверено 03:18: часть 2/30, ошибок нет.»Ночная проверка данных прошла
«Проверка 03:18: в репозитории prod-db-01 повреждён 1 файл данных.»Проверка данных нашла ошибку
«Данные не проверялись.»Проверки данных ещё не было
«Подключено, бэкапов пока нет.»Сюда ещё не пишет ни один сервер
«Указан тот же аккаунт, что у …»У двух хранилищ одна подпись аккаунта
«Не наших данных 1,2 ТБ — arcula их не трогает.»В bucket есть чужие данные — факт, не проблема

Статус хранилища: «Критично» — нет доступа; «Есть замечания» — бэкапы не сохраняются, проверка данных нашла ошибку, занято 90 % лимита или места хватит меньше чем на 30 дней; иначе «Норма».

Проверка доступа

Что проверяется. Панель ключом хранилища работает в тестовом префиксе .arcula-check/: получает список объектов (list), записывает тестовый объект (write), читает его и сверяет с записанным (read), удаляет его. Заодно — загрузку частями (multipart), версионирование и Object Lock. Чужие данные не трогаются.

Когда. Раз в 6 часов; по кнопке «Проверить доступ»; сразу после смены режима ключа; когда копия легла, а доступ числился сломанным. Новый ключ хранилища проверяется до сохранения: старый перестаёт использоваться, только если новый прошёл. Ключ сервера в режиме «Свой у каждого сервера» проверяется при вводе — в папке этого сервера.

Результаты — как ответил S3, без выводов: «✓ прошло», «✕ ошибка», «разрешено — защиты от удаления нет», «провайдер не отвечает на этот запрос (NotImplemented)», «нет прав проверить». Вся таблица — вкладка «Подключение», «Проверки возможностей».

Если не прошли list, read или write, хранилище «Критично»: «Нет доступа: 403 AccessDenied с 12:02». У копий серверов здесь — «нет доступа», ночные проверка данных и очистка не идут, объём не обновляется. Остальные хранилища продолжают сохранять.

Что делать:

  1. Посмотрите код ошибки: 403 AccessDenied — ключ отозван или у него нет прав, NoSuchBucket — нет такого bucket, таймауты — сеть или провайдер.
  2. Исправьте у провайдера или замените ключ: «Подключение» → «Заменить».
  3. Нажмите «Проверить доступ».

Место и «Хватит на»

Замер. Раз в 45 минут, после каждой сохранённой копии и после освобождения места панель перечисляет объекты в bucket и складывает их размеры. «Занято» — сумма наших объектов, «измерено 12 мин назад». Метрик провайдера через S3 нет, поэтому это не цифра из счёта провайдера.

«Хватит на» — сколько осталось до лимита, делённое на средний рост в сутки. Рост — по замерам за последние 30 дней.

В ЛКЧто значит
«≈ 18 дней», «≈ 9 мес», «больше года»Прогноз по среднему росту. Меньше 30 дней — предупреждение
«мало данных: замеры за 3 дн»Замеров меньше чем за 7 дней — прогноз был бы случайным. Через неделю после подключения он появится
«без лимита»Лимит не задан: прогноза нет, под ним — рост «+1,2 ГБ в сутки»
«бэкапов пока нет»Считать нечего
«—»Нет доступа — объём не обновляется; или место за 30 дней не выросло

Место не растёт, когда очистка освобождает столько же, сколько добавляют бэкапы, — тогда тоже «—». Кто сколько добавляет — вкладка «Очистка», «Откуда растёт место».

Проверка данных

Каждую ночь, между 03:00 и 06:00 по поясу панели, worker панели для каждого репозитория сервера в этом хранилище запускает:

restic check --read-data-subset=2/30

restic проверяет структуру репозитория — индексы и снимки — и читает из S3 одну тридцатую часть файлов данных: расшифровывает их и сверяет с контрольными суммами. Следующей ночью — часть 3/30, и так по кругу: за 30 ночей прочитываются все данные, потом круг начинается заново.

«Проверено 03:18: часть 2/30, ошибок нет» значит: этой ночью панель прочитала из хранилища часть 2 из 30 каждого репозитория и к 03:18 закончила — все файлы сошлись с контрольными суммами.

  • Зачем по частям: прочитать всё — значит скачать из S3 весь объём бэкапов. По частям трафик и время делятся на 30 ночей.
  • «Проверить данные» — прочитать следующую часть сразу, не дожидаясь ночи.
  • Ночью проверка идёт, только если доступ к хранилищу есть и в нём есть репозитории, и не чаще раза в 12 часов. Если вы проверяли вручную вечером, ночная может пропуститься.
  • Пока идёт проверка, репозиторий заблокирован: бэкап сервера в это хранилище ждёт её конца.
  • У сервера проверка видна на вкладке «Хранилища», колонка «Проверка данных». В журнале хранилища — «Проверка данных» с шагом по каждому репозиторию.

Что она доказывает, а что нет

Доказывает: данные у провайдера целы и читаются паролем репозитория. Не доказывает, что из бэкапа поднимется приложение — что дамп правильный и сервис стартует. Это проверяет только восстановление arcula restore, его итог — в колонке «Восстановление» вкладки «Бэкапы» сервера (Точки и копии).

Если нашлась ошибка

Хранилище — «Есть замечания»: «Проверка данных: в репозитории prod-db-01 повреждён 1 файл данных — pack 7c1e…: ciphertext verification failed». В журнале — «Проверка данных: найдена ошибка» со строками restic. Круг не идёт дальше: следующей ночью читается та же часть.

Что делать:

  1. Нажмите «Проверить данные». Панель ещё раз прочитает ту же часть повреждённого репозитория. Ошибки нет — это был сбой чтения или сети. Есть — в журнале «Проверка данных: ошибка подтвердилась».
  2. Убедитесь, что у этого сервера есть свежая копия в другом хранилище: повреждение в одном хранилище другие не затрагивает.
  3. Напишите провайдеру и приложите строки restic из журнала. arcula сам репозиторий не чинит; разобрать его можно обычным restic с паролем и ключами из recovery kit.

Та же статья — в панели, в разделе «Справка».