Przejdź do treści

Restart i recovery

Procedury kolejnych poziomów eskalacji: pojedynczy serwis → cały kontener → reboot hosta → restore z backupu → host-son standby. Zawsze zaczynaj od najmniejszego kroku.

Krótko

  • Pojedynczy serwis: incus exec <container> -- docker compose -f /root/dapps/<service>/compose.yaml restart (per-usługa: Inwentarz Usług).
  • Cały kontener Incus: incus restart <container> na hoście.
  • Reboot hosta: ssh aio-{mom,dad,son} sudo reboot. Last resort dla pojedynczego hosta — kontenery wracają same.
  • Restore z backupu: gdy serwis działa ale dane są zepsute / utracone → patrz Backupy.
  • host-son aktywacja: gdy host-mom + host-dad jednocześnie down → patrz niżej.

Diagnostyka — czy serwis jest niezdrowy?

Przed restartem zorientuj się, co się dzieje. Nie restartuj na ślepo.

1. Beszel — pierwsze spojrzenie

beszel.aiofactory.pl (login w Bitwardenie, panel-aio / beszel-admin).

Sygnały, że coś jest nie tak:

Sygnał Co znaczy
Czerwony badge Down przy hoście Host nieosiągalny — netbird drop, sieć, hardware. Eskalacja od razu.
Czerwony badge przy kontenerze Docker Kontener Exited lub Restarting w pętli.
Dysk > 90 % Backupy się sypią, logi rosną — wyczyść lub powiększ wolumen.
RAM > 95 % stały OOM killer już mógł zabić procesy. Sprawdź dmesg.
CPU 100 % przez >30 min Pętla / wyciek wątków. Restart serwisu zwykle pomaga.

2. Konkretne symptomy + reakcja

Symptom (operator widzi) Najpewniejsza przyczyna Pierwszy strzał
panel.aiofactory.pl zwraca 502 Kontener panel (dashboard) restartowany — Convex/dashboard albo windmill server ssh aio-dad incus exec panel -- docker compose ps → szukaj Exited
panel ładuje się, ale „Brak danych" wszędzie Convex backend down lub dashboard nie ma admin keya Beszel → convex-backend health; curl https://convex.aiofactory.pl/version
Synchronizacje marketplace stoją Windmill workery zatrzymane / kolejka pełna wmill job list --running --limit 50 z lokalnej stacji; incus exec panel -- docker compose ps windmill-worker-*
Mailcow nie wysyła wiadomości Zwykle DNS/DKIM albo dovecot/postfix down incus exec email -- docker compose ps na host-mom
Sklep buyspace.pl 503 WP-FPM down albo MariaDB incus exec web -- docker compose ps na host-mom
Backupy starsze niż 25 h Backrest crash albo plan disabled backrest.aiofactory.pl UI; wmill script run f/infra/backup_health_monitor

3. Logi — przed restartem zerknij co krzyczy

ssh aio-<host>
sudo incus exec <container> -- bash -c 'cd /root/dapps && docker compose logs --tail=200 <service>'

Jeśli logi pokazują znany błąd (np. out of memory, connection refused to 127.0.0.1:5432) — nie restartuj na chybił trafił, napraw przyczynę.

Poziom 1 — restart pojedynczego serwisu (Docker compose)

Najtańsza i najczęstsza akcja. Per-serwis komendy w Inwentarzu Usług — ta sekcja pokazuje wzorzec.

Kontenery na host-dad / panel

ssh aio-dad

# Restart jednego serwisu (np. windmill-server po zmianie envs)
sudo incus exec panel -- bash -c "cd /root/dapps && docker compose restart windmill-server"

# Restart całego stosu (panel + convex + windmill + dashboard)
sudo incus exec panel -- bash -c "cd /root/dapps && docker compose restart"

Kontenery na host-mom / services

ssh aio-mom
sudo incus exec services -- bash -c "cd /root/dapps/listmonk && docker compose restart"
sudo incus exec services -- bash -c "cd /root/dapps/postiz && docker compose restart"
# itd. — każdy serwis ma własny katalog /root/dapps/<service>/

Mailcow — wieloserwisowy

ssh aio-mom
sudo incus exec email -- bash -c "cd /root/dapps/mailcow-dockerized && docker compose restart"

Mailcow restart trwa ~30s (ClamAV ładuje sygnatury). Wstrzymaj fetch IMAP w panelu Konfiguracja jeśli planujesz długi przestój.

Restart panelu (dashboard)

ssh aio-dad
sudo incus exec panel -- bash -c "cd /root/dapps && docker compose restart panel"
# albo, jeśli zmieniłeś sekrety w env:
sudo incus exec panel -- bash -c "cd /root/dapps && docker compose up -d --force-recreate panel"

Poziom 2 — restart całego kontenera Incus

Gdy poziom 1 nie wystarcza (np. caddy zwraca 502 niezależnie od serwisów wewnątrz, networking incusowy się zaciął):

ssh aio-<host>
sudo incus list                       # zobacz aktywne
sudo incus restart <container>        # graceful — wysyła SIGTERM, czeka 30s, SIGKILL
sudo incus restart --force <container>  # twardy restart, jeśli graceful zawiódł

Po restarcie kontenery Dockera w środku startują w kolejności z compose.yaml (depends_on). Czas: ~60s do pełnego zdrowia (Caddy + Postgres + serwis aplikacji).

Restart panel nie wymusza restartu Convexa lub Windmilla

Te trzy są w jednym kontenerze incus (panel na host-dad), ale to osobne usługi compose. incus restart panel restartuje wszystko naraz — co bywa ostry kij dla Convexa (DB stan w wolumenie). Wolisz pojedyncze docker compose restart <service> — patrz Poziom 1.

Poziom 3 — reboot hosta NixOS

Cały serwer fizyczny. Robisz to gdy kontenery wstają zepsute po incus restart, hardware sygnalizuje błędy w dmesg, albo jądro / sterownik wymaga przeładowania.

ssh aio-<host> sudo reboot
# host-mom / host-dad: ~3 min do pełnego zdrowia (BIOS POST + NixOS boot + incus + kontenery)

Po reboocie:

  1. ssh aio-<host> — sprawdź, że SSH wraca.
  2. sudo incus list — wszystkie kontenery RUNNING.
  3. Beszel → host green badge.
  4. Test funkcjonalny: curl -I https://panel.aiofactory.pl (z lokalnej stacji), curl -I https://mail.aiofactory.pl.

Reboot host-mom — przerwa pocztowa

email kontener (Mailcow) wraca jako ostatni (~2 min). W tym czasie SMTP odbiera tymczasowe 421 try later — Gmail / pozostali wysyłający spróbują ponownie sami. Ale jeśli reboot trwa >10 min, możesz zacząć tracić maile (sender retries się kończą). Plan duże okno — między 03:00 a 06:00 ruch minimalny.

Poziom 4 — restore z backupu

Gdy stan danych jest zepsuty (corruption, accidental delete, schema mismatch), nie pomaga restart.

Pełna procedura per usługa: Backupy → Per-service runbooks. Skrót decyzji:

Co restorować Czas Scenariusz
Pojedyncza tabela Convex ~5 min Operator usunął przez pomyłkę kluczowe dokumenty
Cały Convex DB ~30 min Korupcja schema, niezgrane migracje
Mailcow (skrzynki) ~1 h Akcydentalne usunięcie skrzynki, atak ransomware
WordPress (master / eu / de) ~30 min Zhackowany WP, przywrócenie do daty pre-attack
Windmill DB ~15 min Korupcja kolejki jobów, „zalany" stan

Poziom 5 — host-son aktywacja (last resort)

host-son (OVH baremetal) jest w stanie standby — sprzęt skonfigurowany, NixOS zainstalowany, Incus + Docker — ale rutynowo nie obsługuje produkcji.

Aktywacja host-son to akt eskalacji — koszty i czas

Pełna replikacja stanu z host-mom + host-dad to godziny pracy:

  • Restore Convex DB z B2 (restic restore ~20 min dla snapshot ~5 GB).
  • Restore Mailcow z B2 (~45 min — skrzynki + ClamAV signatures).
  • Restore WordPress instancji (~30 min × 4 sklepy).
  • Przepięcie IP failover OVH z host-mom/host-dad → host-son (kilka minut).
  • Update DNS records (TTL 300s minimum).
  • Wyłączenie scheduledów Windmill na czas restore'u (żeby nie pisały do na wpół zsynchronizowanego stanu).

Aktywuj host-son tylko gdy host-mom + host-dad są oba niedostępne (pożar w DC Hetzner + OVH jednocześnie — bardzo nieprawdopodobne). W innych przypadkach — repair na żywym hoście.

Procedura wysokopoziomowa — szczegóły przygotowane jako runbook w infra/host-son/ (osobne repo infra):

  1. SSH do aio-son → check incus list. Standardowe kontenery: bare NixOS + incus.
  2. Restore z B2 → najnowsze snapshoty per kontener (patrz infra/host-son/restore.md).
  3. Update Caddy config — point reverse-proxy na lokalne kontenery host-son.
  4. Update DNS A-records (provider: first-ns.de) — wskaż na host-son IP.
  5. OVH IP failover — przepnij z host-dad na host-son (panel OVH).
  6. Czekaj na DNS propagację (max 5 min jeśli TTL=300s).
  7. Smoke test: panel.aiofactory.pl, mail.aiofactory.pl, każdy *.buyspace.pl.

Serwery → host-son — wysokopoziomowy opis filozofii „trzeciej linii obrony".

Awaria sieci — diagnostyka

Niektóre objawy „panel down" tak naprawdę są problemami sieciowymi, nie aplikacyjnymi.

# Z lokalnej stacji
ping -c 3 panel.aiofactory.pl                # ICMP
curl -I --connect-timeout 5 https://panel.aiofactory.pl   # TCP+TLS handshake
dig panel.aiofactory.pl                       # DNS resolution
mtr -n panel.aiofactory.pl                    # routing path

Jeśli dig zwraca pusty wynik — problem z DNS (ns1.first-ns.de albo Hetzner DNS). Jeśli dig OK ale curl timeoutuje — problem z routingiem / firewallem hosta. Jeśli curl zwraca 502/503 — kontener nie odpowiada Caddy'emu, restart kontenera (Poziom 1).

Netbird mesh-VPN (netbird.aiofactory.pl) musi być up żebyś dostał się do narzędzi wewnętrznych (Beszel, Backrest, Forgejo). Sprawdź klienta lokalnie: netbird status na laptopie operatora.

Powiązane