# Проба живости бэкап-сервера Gitea

## Цель

Установить фактическое состояние резервного сервера Gitea в Yandex Cloud (виртуальная
машина `gitea`, внутренний хост-алиас `liderra-bastion`, IP `111.88.252.149`), на котором
хранится полная зеркальная история репозитория `liderra/portal` и общий `git bundle`.
Владелец сообщил, что сервер «похоже, упал». Нужно отличить три исхода: (1) машина жива и
здорова, (2) машина жива, но сменился внешний IP (адрес `nip.io` зашит на старый IP, поэтому
сайт и заход «отваливаются» при живой машине), (3) машина действительно недоступна. Проба
строго read-only — ничего на сервере не меняем; восстановление, если понадобится, — отдельной
задачей после получения фактов.

## Контракт пробы {#D1}

Снимаем три независимых сигнала через единственный канал доступа — SSH на хост-алиас
`liderra-bastion` (он же бэкап-ВМ):

- **Живость и время работы.** Команда `uptime` на сервере. Ожидаемый успех — строка вида
  `up N days`, подтверждающая, что ОС поднята; малое время работы (минуты) косвенно указывает на
  недавнюю перезагрузку.
- **Состояние контейнеров.** Команда `docker ps` на сервере. Стек развёрнут тремя контейнерами
  (`gitea-db` = postgres, `gitea`, `caddy`), все с политикой авто-перезапуска. Ожидаемый успех —
  все три в статусе `Up`. Отсутствие любого контейнера = деградация сервиса при живой ОС.
- **Свободное место на диске.** Команда `df -h /` на сервере. Контролируем заполнение корневого
  раздела: переполнение диска — известная причина каскадных отказов сервисов.

Каждый сигнал снимается отдельной одиночной командой без цепочек, чтобы вывод каждого читался
изолированно и не маскировал отказ соседнего.

## Крайние случаи {#D2}

- **ВМ остановлена → сменился IP.** У этой ВМ публичный IP динамический и меняется при полной
  остановке машины. Если `ssh` на `liderra-bastion` (старый IP) виснет до таймаута или отвечает
  «connection refused/timed out», а сама ВМ при этом числится запущенной — типовой симптом смены
  адреса. Вывод: машина и бэкап целы, чинится обновлением адреса в домене `<новыйIP>.nip.io`
  (Caddy reverse-proxy и ROOT_URL Gitea) и в `~/.ssh/config`.
- **ОС жива, но Docker лежит.** `uptime` отвечает, а `docker ps` пуст или падает — упал демон
  Docker либо контейнеры не поднялись. Бэкап-данные на диске целы, нужен перезапуск контейнеров.
- **Диск переполнен.** `df -h /` показывает 100% — сервисы могли отказать вторично; до перезапуска
  контейнеров требуется освобождение места.
- **Таймаут соединения.** Любая из команд не отвечает в окне `ConnectTimeout` — трактуем как
  «адрес недоступен», переходим к проверке состояния и текущего IP ВМ в консоли Yandex Cloud.

## Критерий успеха {#D3}

Проба считается завершённой, когда по собранным выводам трёх команд (или по факту их
таймаута) можно вынести однозначный вердикт ровно одного из трёх видов: **жив-здоров** /
**жив, сменился IP** / **недоступен**, с указанием конкретного следствия для восстановления.
Никаких изменений на сервере при этом не произведено (read-only инвариант соблюдён).

## Конвенция оформления {#D4}

Результат пробы controller сообщает владельцу простым языком: вердикт одной из трёх
категорий §D3 + что это значит для бэкапа + следующий шаг. Точные выводы команд приводятся как
доказательство вердикта. Файлы памяти и нормативки эта задача не трогает.

```verified-context-json
[
  {"id":"vc1","kind":"EXTRACTED","ref":"docs/ops/gitea/2026-06-15-gitea-backup-server-actual.md","anchor":"--restart unless-stopped"},
  {"id":"vc2","kind":"EXTRACTED","ref":"docs/ops/gitea/2026-06-15-gitea-backup-server-actual.md","anchor":"caddy reverse-proxy"}
]
```
