Статусы сервера

Статус сервера виден в списке «Серверы» — отметкой у имени и короткими строками под ним. На странице сервера те же причины написаны полными фразами под заголовком. У каждой фразы есть «?» — он ведёт в нужный раздел этой статьи.

Статус пересчитывается сам. Ушла причина — ушла и строка.

Уровни

Свежесть считается от нормы профиля, который выбран в плане:

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

План защиты не подтверждён

В ЛК: «План защиты не подтверждён — бэкапов нет». Статус — «Не настроено».

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

Когда появляется: сразу после подключения сервера и до первого подтверждения плана.

Что делать: на странице сервера нажмите «Подтвердить план». Выберите, что защищать, профиль частоты и хранилища — Выбрать, что защищать. Агент получит план в течение минуты и сразу сделает первый бэкап.

Уходит само: нет, только после подтверждения плана.

Нет свежего бэкапа ни в одном хранилище

В ЛК: «Нет свежего бэкапа ни в одном хранилище: последний 26 ч назад». Статус — «Критично».

Самый свежий бэкап среди всех доступных хранилищ старше двух норм профиля. Если сервер упадёт сейчас, потеряется больше, чем вы задали в плане.

Когда появляется: бэкап старше 2 ч у «Критичного», 24 ч у «Обычного», 72 ч у «Редко меняется». Если план подтверждён, а ни одного бэкапа так и не сохранилось, — через те же две нормы после подтверждения.

Что делать:

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

То же видно на самом сервере:

sudo arcula status
sudo arcula doctor

Пока агент молчит, панель раз в час сама смотрит список бэкапов в его репозиториях. Бэкапы, сделанные без связи, тоже засчитываются.

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

Компонент не попадает в бэкап

В ЛК: «PostgreSQL 16 не попадает в бэкап: …». В списке серверов — «Не попадает в бэкап: PostgreSQL 16» или «Бэкап собран не полностью: 3 компонента не попали». Статус — «Критично».

В последнем бэкапе нет обязательного компонента из плана: агент не смог его собрать. После двоеточия — причина как есть, например вывод pg_dump или No space left on device. Остальное в этом бэкапе собрано и сохранено.

Когда появляется: сразу после первого бэкапа без этого компонента.

Что делать:

• Прочитайте причину. Полный текст и строки лога — во вкладке «Журнал», строка «Бэкап не собран: …».
• База не отвечает или упал дамп — почините на сервере и нажмите «Бэкап сейчас».
• Не хватило места в staging — В staging не хватит места.
• Пути или тома больше нет на сервере — в журнале «Нет на сервере: …». Уберите его из плана — Пропало с сервера.
• Этот компонент нужен прямо сейчас — он есть в более раннем бэкапе, вкладка «Бэкапы» — Бэкапы.

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

Копия отстаёт

В ЛК: «Резервный: отстаёт на 18 ч · не сохранено 36 бэкапов подряд». Статус — «Есть замечания».

В одно хранилище бэкапы перестали доходить, а в другом есть свежий. «Не сохранено подряд» — сколько бэкапов после последнего сохранённого сюда не дошли: не отправились с ошибкой или были пропущены ради более нового.

Когда появляется: последний бэкап в этом хранилище старше нормы профиля — 1 ч, 12 ч или 36 ч. Если свежего бэкапа нет нигде, вместо этой строки будет Нет свежего бэкапа.

Что делать:

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

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

Копия: нет доступа

В ЛК: «idr-fra-01: нет доступа · 403 AccessDenied». Статус — «Есть замечания».

Проверка доступа панели к этому хранилищу не прошла. После точки — ответ S3 как есть. Пока доступа нет, копии в этом хранилище не считаются в «Последней копии».

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

Что делать: откройте хранилище — там та же ошибка подробнее: Нет доступа. Исправили — нажмите «Проверить доступ» на странице хранилища.

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

Агент не на связи

В ЛК: «Агент не на связи 26 ч, последний сигнал вчера 11:58». Сама по себе строка даёт «Есть замечания».

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

Когда появляется: сигнала нет дольше 3 минут. Агент шлёт его раз в минуту.

Что делать: проверьте, работает ли сервер и выходит ли он к панели по HTTPS. На сервере:

sudo systemctl status arcula-agent
sudo journalctl -u arcula-agent --since "1 hour ago"
sudo arcula status

Если дело в связи с панелью, arcula status напишет «Panel unreachable since …» и покажет потерю по своим данным.

Уходит само: да, как только агент выйдет на связь.

Не попадает в бэкап

В ЛК: «Том prometheus_v3_data не попадает в бэкап · 9,4 ГБ», «Каталог /srv/data не попадает в бэкап» или «PostgreSQL 17 — новое, не в плане защиты: включите или отметьте «не защищаем»». Если таких больше двух, в списке серверов одна строка: «Не защищено: 5 ресурсов — решите в плане». Статус — «Есть замечания».

Агент нашёл на сервере то, чего нет в плане и о чём вы ещё не решали:

• том или каталог с неизвестными данными — он в «Нужно решение»;
• распознанное после плана — новую базу, данные нового приложения: оно в плане с меткой «новое» и уже отмечено галочкой, осталось сохранить план.

Уведомление об этом приходит один раз — «найдено и не защищено».

Когда появляется: после обхода сервера, который это нашёл. Агент обходит сервер раз в 1, 6 или 24 часа — как задано в плане, по умолчанию раз в 6 часов. Остановленные контейнеры и внешние данные сюда не попадают: они в «Не входит в бэкап».

Что делать: откройте план — находка в «Нужно решение». Включите её в бэкап или отметьте «не защищаем» с причиной и сохраните план — Нужно решение.

Уходит само: нет. Только после решения в плане или если том или каталог исчезнет с сервера.

Для сервера не задан ключ

В ЛК: «Резервный: для сервера не задан ключ — бэкапы сюда не отправляются; задайте его в хранилище → «Подключение» → «Ключи серверов»». Статус — «Есть замечания».

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

Когда появляется: сразу после смены режима ключа у хранилища или после добавления такого хранилища в план сервера.

Что делать:

1. Создайте у провайдера ключ с доступом только к папке сервера. Путь папки показан в «Ключах серверов».
2. Хранилище → «Подключение» → «Ключи серверов» → «Задать ключ» → «Проверить и сохранить».

Панель проверит ключ в папке сервера до сохранения, а следующий бэкап уйдёт в это хранилище.

Уходит само: нет, только после сохранения ключа.

В staging не хватит места

В ЛК: «В staging свободно 3 из 40 ГБ — следующий бэкап (≈ 4 ГБ) не поместится». Статус — «Есть замечания».

Staging — место на диске сервера, где дампы баз и настройки хоста ждут отправки во все хранилища. Каталоги и тома туда не копируются: restic читает их прямо с диска. Размер staging — лимит из плана, по умолчанию 40 ГБ, но не больше свободного места на диске. Набор держится там, пока его ждёт хоть одно хранилище.

Когда появляется: свободное место в staging меньше оценки следующего бэкапа — сколько занял последний набор плюс 10 %. Место агент сообщает раз в минуту.

Что делать:

• Освободите место на диске сервера.
• Уберите из staging то, чего никто не ждёт. Бэкапы в хранилищах команда не трогает.
• Поднимите лимит: сервер → «Настройки защиты» → «Staging» → «Изменить».
• Staging занят набором, который ждёт медленного хранилища, — сначала разберитесь с ним: Копия отстаёт.

sudo arcula clean --dry-run
sudo arcula clean

Если не исправить, следующий компонент не соберётся — Компонент не попадает в бэкап.

Уходит само: да, когда места станет достаточно.

Часы сервера отстают или спешат

В ЛК: «Часы сервера отстают на 3 мин — S3 может отвечать 403 RequestTimeTooSkewed». Статус — «Есть замечания».

Часы сервера расходятся с часами панели. S3 сверяет время в каждом запросе и при большом расхождении отказывает. Тогда бэкапы перестанут сохраняться с ошибкой s3_clock_skew.

Когда появляется: расхождение больше 2 минут по последнему сигналу агента.

Что делать: включите синхронизацию времени на сервере.

sudo timedatectl set-ntp true
timedatectl status

В выводе должно быть System clock synchronized: yes. Если строка появилась у всех серверов сразу, скорее всего, сбиты часы на сервере панели.

Уходит само: да, со следующим сигналом после того, как часы сойдутся.

Бэкап идёт почти весь интервал

В ЛК: «Бэкап идёт 28 мин при расписании раз в 30 мин». Статус — «Есть замечания».

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

Когда появляется: обычная длительность — медиана последних 10 бэкапов — больше 80 % интервала расписания.

Что делать:

• Откройте последний бэкап на вкладке «Бэкапы»: там видно, сколько заняла подготовка и отправка в каждое хранилище.
• Долго идёт отправка в одно хранилище — медленный канал или ограничение скорости в его настройках отправки.
• Долго идёт подготовка — обычно это большой дамп базы.
• Ускорить нельзя — выберите в плане профиль реже, карточка «Как часто».

Уходит само: да, когда обычная длительность станет меньше 80 % интервала. Считается медиана 10 бэкапов, поэтому строка уходит не с первого быстрого бэкапа.

Размер дампа не как обычно

В ЛК: «PostgreSQL 16: 0,1 ГБ — обычно 2,0–2,2 ГБ». Статус — «Есть замечания».

Компонент в последнем бэкапе намного меньше или больше обычного. Сам бэкап сохранён — это не ошибка arcula. Но резкое падение размера часто значит, что данные пропали на самом сервере: удалили таблицу, приложение пишет в пустую базу.

Когда появляется: размер меньше половины обычного минимума или больше двух обычных максимумов. «Обычно» — разброс за последние 14 дней без 10 % крайних значений. Нужно хотя бы 7 бэкапов, иначе сравнивать не с чем.

Что делать:

• Проверьте данные на сервере.
• Данные пропали — закрепите последний хороший бэкап ключевой точкой, чтобы очистка его не удалила: Ключевые точки. Как поднять данные — Восстановление.
• Размер изменился законно — почистили старое или загрузили новое — ничего делать не нужно.

Уходит само: да, когда размер вернётся к обычному. Если новый размер останется, со временем он сам станет «обычным».

Сервер отключён

В ЛК: «Сервер отключён: ключи агента отозваны · последний сигнал …». Такой сервер стоит в конце списка, без статуса и причин.

Сервер отключили в ЛК или командой sudo arcula logout или sudo arcula uninstall на нём самом. Агент больше не ходит в панель и не делает бэкапов. История и бэкапы в хранилищах остаются.

Что делать: подключить снова — на сервере sudo arcula logout, затем sudo arcula login. Убрать совсем — «Настройки защиты» → «Удалить сервер» — Удалить сервер или хранилище. Ключи S3 у отключённого сервера остаются — смените их, если сервер больше не ваш.