Статусы хранилища

Статус хранилища виден в списке «Хранилища», колонка «Состояние», и на странице хранилища под названием. Панель проверяет хранилища сама: доступ — раз в 6 часов, место — раз в 45 минут, данные — каждую ночь с 03:00 до 06:00 по поясу панели. Как устроены проверки — Проверки хранилища.

Уровни

Хранилище с проблемой в списке идёт первым. Если места до лимита хватит меньше чем на 30 дней, «Хватит на» выделено цветом и хранилище тоже поднимается вверх, но статус от этого не меняется — Место.

Нет доступа

В ЛК: «Нет доступа: 403 AccessDenied с 12:02». Статус — «Критично».

Проверка доступа панели не прошла: list, read или write в тестовой папке .arcula-check/ вернули ошибку. Код — первый ответ S3 с ошибкой, как есть. «С 12:02» — с какого времени проверки не проходят.

Пока доступа нет:

• копии всех серверов здесь — «нет доступа», в «Последней копии» они не считаются;
• проверка данных и очистка не идут;
• место не измеряется, в «Хватит на» — «—».

Агенты при этом продолжают отправлять бэкапы сами, своим ключом из плана. Их ошибки — в журнале, строки «Бэкап не сохранён».

Когда появляется: после неудачной проверки — раз в 6 часов, после смены ключа и по кнопке «Проверить доступ».

Что делать — по коду:

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

Исправили — нажмите «Проверить доступ».

Уходит само: после удачной проверки — не позже чем через 6 часов, по кнопке — сразу.

До лимита осталось мало места

В ЛК: «До лимита осталось 18 ГБ — занято 95%». Статус — «Есть замечания».

Лимит — бюджет места, который вы задали у хранилища в ЛК, а не квота провайдера. По умолчанию считаются только данные arcula. Если у лимита выбран «весь bucket», то вместе с не нашими.

Когда появляется: занято 90 % лимита или больше. Место измеряется раз в 45 минут.

arcula не останавливает бэкапы на лимите. Если у провайдера есть своя квота, по её исчерпании бэкапы перестанут сохраняться.

Что делать:

• Включите очистку или сократите правила хранения. Предпросмотр покажет, что удалится и сколько освободится — Очистка.
• «Очистить сейчас» на вкладке «Очистка» — удалить по правилам и освободить место, не дожидаясь ночи.
• Если место у провайдера есть, поднимите лимит: вкладка «Подключение», строка «Лимит».

Уходит само: да, когда занятое место опустится ниже 90 % лимита. После очистки панель сразу измеряет место заново.

Не сохранено подряд

В ЛК: «Не сохранено подряд: prod-db-01 — 36 бэкапов». Статус — «Есть замечания».

У этих серверов бэкапы после последнего сохранённого сюда не дошли: не отправились с ошибкой или были пропущены, потому что за время отправки был готов более новый. Число — сколько таких подряд.

Когда появляется: хотя бы один бэкап сервера после последнего сохранённого не сохранён здесь. Пока у хранилища нет доступа, строка не показывается — причина и так видна.

Что делать:

• Откройте сервер → вкладка «Хранилища»: у копии в этом хранилище написана причина.
• В журнале хранилища, в строках «Бэкап не сохранён», — ответ хранилища и строки restic. Что значит каждая ошибка — Ошибки копий.
• Один-два пропуска во время долгой отправки — нормально: в хранилище уходит последний готовый бэкап.

Уходит само: да, когда следующий бэкап сервера сохранится здесь.

Проверка данных нашла повреждение

В ЛК: «Проверка данных: в репозитории registry-02 повреждён 1 файл данных — pack 7c1e…: ciphertext verification failed». Статус — «Есть замечания».

Ночная проверка читает часть данных каждого репозитория (restic check --read-data-subset) и сверяет шифрование и контрольные суммы. Она нашла файл, который не читается или не сходится. После тире — строка restic как есть.

Когда появляется: сразу после проверки, которая нашла ошибку. Круг проверки дальше не идёт: следующей ночью та же часть читается снова.

Что делать:

1. Нажмите «Проверить данные» на странице хранилища: та же часть повреждённого репозитория прочитается ещё раз. Ошибка могла быть разовой.
2. В журнале «Проверка данных: ошибка подтвердилась» — данные в этом хранилище повреждены. Восстанавливайте этот сервер из другого хранилища.
3. Сообщите провайдеру хранилища.
4. Не откладывайте: restic не отправляет заново то, что считает уже сохранённым, поэтому и новые бэкапы могут зависеть от повреждённого файла.

arcula сам репозиторий не чинит. Починить его можно вручную командами restic repair; пароль репозитория и ключи — в recovery kit.

Уходит само: да, когда эта часть прочитается без ошибок — ночью или по кнопке.

Указан тот же аккаунт

В ЛК: «Указан тот же аккаунт, что у Основной». Статус не меняет.

У двух хранилищ в поле «Аккаунт» стоит одна и та же подпись. Её вы вводите сами при подключении: номер аккаунта через S3 у большинства провайдеров не узнать, поэтому arcula сравнивает только подписи.

Что это значит: если аккаунт заблокируют, взломают или он перестанет оплачиваться, пропадут оба хранилища сразу. Такие копии не независимы — в плане сервера это видно в карточке «Где храним»: «независимых копий: 1».

Что делать: если так задумано — ничего. Для настоящей второй копии подключите хранилище у другого провайдера или в другом аккаунте — Хранилища.

Уходит само: нет. Это факт о настройке, а не сбой.

В bucket есть не наши данные

В ЛК: «В bucket есть не наши данные: 1,2 ТБ — arcula их не трогает». Статус остаётся «Норма».

В том же bucket лежит что-то кроме данных arcula: файлы, старые бэкапы, чужие restic-репозитории, каталог arcula/ другой панели. Наше — только папки серверов этой панели arcula/<id сервера>/ и тестовая папка .arcula-check/. Всё остальное arcula никогда не пишет, не меняет и не удаляет, а только считает объём.

Когда появляется: при подключении хранилища и после замера места, если не наше нашлось.

Что делать: обычно ничего. Лимит по умолчанию считается только по данным arcula; можно считать и весь bucket — это выбирается у лимита. Подключить найденный старый restic-репозиторий для просмотра в arcula пока нельзя.

Уходит само: да, если не наших данных в bucket не останется.