NVMe dropout — všechny dynamické appky 502, SSH resetuje, statika jede

Symptom

• Všechny dynamické aplikace (Node/PM2 za reverse proxy) vrací 502, web UI mail serveru 500.
• Statické weby jedou dál (proxy je drží v paměti/cache), ping OK.
• SSH: kex_exchange_identification: read: Connection reset by peer — ze všech IP, přes IPv4 i IPv6 i z jiného serveru (tím vyloučen fail2ban/GeoIP ban, který by dal timeout/refused jen některým zdrojům).
• TCP port 22 přitom spojení přijme (nc -zv uspěje) a zabije ho až při handshake.

Příčina

Vadný NVMe disk: kernel log ukázal I/O error, dev nvme0n1 + reset řadiče už ráno; odpoledne druhý dropout. Se ztraceným root diskem:

• běžící procesy postupně padají na I/O (PM2 appky, docker web),
• fork nových procesů selhává (binárky nejdou číst) — socket-aktivované SSH spojení přijme, ale sshd se nespustí → reset při handshake,
• journal ztichne uprostřed provozu (nemá kam zapisovat) — po rebootu v journalctl -b -1 žádný OOM ani panic, log prostě končí.

SMART může být i „PASSED” s 0 media errors — rozhodující je percentage_used (endurance), počet záznamů v error-logu řadiče a fakt, že disk vypadává ze sběrnice.

Řešení

1. Hardware reset přes management konzoli providera (ze sítě se dovnitř nedostanete).
2. Po naběhnutí: journalctl -b -1 -k | tail (I/O chyby před pádem), nvme smart-log /dev/nvme0 (percentage_used, err-log entries).
3. Ověřit zálohy a požádat providera o výměnu disku — dropout se zopakuje.

Prevence

• Diagnostický klíč: statika jede + všechna dynamika 502 + SSH reset (ne timeout) ze všech IP = fork/IO selhání na hostu (disk nebo OOM), ne síť ani firewall. Ušetří hodinu honění fail2banu.
• Root FS na jediném disku bez redundance = celý server visí na jednom kusu hardwaru; RAID1 jen na datovém poli nepomůže.
• Mít na serveru předinstalované nvme-cli/smartmontools — po incidentu se hodí okamžitě.