docs(cluster): incident pvemini backup SSD hang + thermal monitoring

Documenteaza incidentul Kingston SNV3S2000G hang la 2026-04-30 (Sensor 2 74°C → emergency mode + restart loop) si masurile aplicate: distantare temporala backup-uri par/impar, mutare CT 101+110 pe pve1 backup-ssd, nofail in fstab, hardware watchdog iTCO_wdt, monitoring CSV la 30 min. Adauga scripturile /opt/scripts/kingston-thermal-{monitor,report}.sh pentru tracking trend si alertare la depasirea pragurilor termale. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-01 01:04:02 +03:00
parent 2109bc7f5e
commit 3ded5d3f2f
3 changed files with 756 additions and 0 deletions
--- a/proxmox/cluster/incidents/2026-04-30-pvemini-backup-ssd-hang.md
+++ b/proxmox/cluster/incidents/2026-04-30-pvemini-backup-ssd-hang.md
@@ -0,0 +1,406 @@
+# Incident 2026-04-30 — pvemini emergency mode + restart loop (Kingston backup SSD hang)
+
+**Severity:** Medium (efect amplu pe cluster, dar **fără pierdere de date** și **fără impact pe disponibilitatea producției** — datele live + DR sunt pe Samsung mirror, replicare ZFS independentă)
+**Detected:** 2026-04-30 ~23:14 EEST (user — screenshot-uri ecran cu emergency mode)
+**Resolved:** 2026-04-30 ~22:41 EEST (cold power cycle de la user → Kingston revine la enumerare; ulterior reboot curat la 23:37)
+**Author:** Claude Code (mmarius28@gmail.com)
+
+---
+
+## TL;DR — lanțul cauzal
+
+1. **2026-04-30 22:13:01 EEST** — pvemini se oprește brusc după **10 zile uptime** (boot anterior din 2026-04-20 14:19, post-incident cluster outage). Cauza opririi nu e clară din log-uri — posibil hang controller Kingston blochează I/O kernel.
+2. **22:15:35** — primul boot attempt. systemd așteaptă `/dev/nvme2n1p1` (Kingston SNV3S2000G, mount `/mnt/backup`) — **nu răspunde la enumerare PCIe**.
+3. **22:17:05** — timeout 90s; `mnt-backup.mount`, `systemd-fsck@dev-nvme2n1p1.service` eșuează.
+4. **22:17 → 22:40** — încă **2 cicluri de boot** (probabil user retries via reset). De fiecare dată: Kingston tăcut → timeout → emergency mode → "Give root password for maintenance".
+5. **~22:40** — user face **cold power cycle complet** (oprește din buton, apasă din nou). Controllerul Kingston revine după pierdere completă de putere.
+6. **22:41:37** — boot reușit. Kingston răspunde, fsck rulează (`recovering journal` → `clean, 102/122101760 files`), mount OK.
+7. **23:18:22** — user face shutdown deliberat pentru investigație.
+8. **23:37:09** — reboot final, totul stabil. Investigație + plan prevenție.
+
+**Root cause likely:** thermal throttle / hang controller pe Kingston SNV3S2000G (model DRAM-less QLC, low-end). SMART confirmă **Temperature Sensor 2 = 74°C** la 1°C sub warning threshold (75°C, critical 80°C). În timpul activității de backup nocturn (job vzdump 02:00 zilnic + 22:00 zilnic, totalizând ~12 GB scriere zstd compressed peste ~1h), temperatura crește, controllerul intră în throttle/hang, partiția devine non-responsive, sistemul nu o mai vede chiar și la reboot — până la pierdere completă de alimentare care reset-ează controllerul.
+
+**Cluster-wide impact secundar:** NFS server pe pvemini exportă `/mnt/backup` către `10.0.20.0/24`. Clienți activi: pveelite + pve1. Când Kingston hang-uiește, pveelite + pve1 au mount-uri NFS stuck → orice operație care atinge `/mnt/pve/backup-pvemini-nfs` se înghețează. Plus dependency chain pe pvemini: `nfs-server.service` depinde de `/mnt/backup` mount → cade în cascadă cu `local-fs.target`.
+
+**Pierdere de date:** ZERO. ZFS rpool a detectat 14 erori de checksum la boot pe `nvme-eui.0025384551a1560c-part3` (Samsung 990 PRO) — efect colateral al opririi neașteptate, nu probleme media — și a făcut auto-resilver de 33.6 MB cu 0 erori.
+
+---
+
+## Cronologie (EEST)
+
+| Ora | Eveniment | Sursa |
+|-----|-----------|-------|
+| 2026-04-20 14:19:58 | Boot precedent pvemini (post-incident cluster outage) | journalctl |
+| → 10 zile uptime normal | Joburi vzdump rulează zilnic 02:00 + 22:00. Replicare ZFS continuă neîntrerupt. | - |
+| **2026-04-30 22:13:01** | **pvemini se oprește brusc.** Cauza opririi opace în log-uri. | journalctl --list-boots |
+| 22:15:35 | Boot attempt #1. systemd: `Expecting device dev-nvme2n1p1.device` | journalctl -b -2 |
+| 22:17:05 | Timeout 90s. `Dependency failed for mnt-backup.mount`, `nfs-server.service`, `local-fs.target`. Reached `emergency.target`. | journalctl -b -2 |
+| 22:36:52 | Boot attempt #2 (probabil user retry via reset). Same timeout. | journalctl -b -2 |
+| 22:38:45 | Boot attempt #3. Same timeout. | journalctl -b -2 |
+| 22:40:15 | Al treilea timeout. Emergency mode persist. | journalctl -b -2 |
+| ~22:40 | **User: cold power cycle complet** (oprește buton + repornește) | user |
+| **22:41:37** | Boot reușit. `Found device dev-nvme2n1p1.device - KINGSTON SNV3S2000G 1`. fsck recovering journal → clean. | journalctl -b -1 |
+| 22:41:40 | smartd identifică toate 3 NVMe-uri. ZED detectează 14 checksum errors pe Samsung 990 PRO part3, resilver 33.6M cu 0 errors. | zed, smartd |
+| 23:18:22 | User: shutdown deliberat pentru investigație. | journalctl |
+| 23:37:09 | Boot stabil. Storage `backup` active, `/mnt/backup` mounted, NFS export reactiv. | journalctl -b 0 |
+| 23:14 → 00:30 | Investigație + sinteză plan prevenție. | acest document |
+
+---
+
+## Analiză detaliată
+
+### 1. Hardware: Kingston SNV3S2000G — diagnostic SMART
+
+```
+Model Number:                       KINGSTON SNV3S2000G
+Serial Number:                      50026B76873E864F
+Firmware Version:                   P3BR0A27
+Capacity:                           2.00 TB (1.79 TiB usable)
+Power On Hours:                     5,884
+Power Cycles:                       18
+Unsafe Shutdowns:                   12   (mare, dar EFECT al hangurilor anterioare, nu cauză)
+Critical Warning:                   0x00 (clean)
+Available Spare:                    100%
+Percentage Used:                    24%
+Media and Data Integrity Errors:    0
+Error Information Log Entries:      0
+Data Units Written:                 56,733,416 [29.0 TB]
+Data Units Read:                    1,274,664  [652 GB]
+Temperature Sensor 1:               49 Celsius  (idle, OK)
+Temperature Sensor 2:               74 Celsius  ⚠️ (warning at 75, critical at 80)
+Temperature Sensor 3:               28 Celsius  (idle, OK)
+SMART overall-health:               PASSED
+```
+
+**Concluzia tehnică:**
+- Wear (24%) și endurance (29 TB written din ~600 TBW spec) = **OK**, nu e eroare de uzură
+- Media errors = 0 → NAND-ul fizic e bun
+- Temperature Sensor 2 la 74°C **idle** (sistem tocmai bootat, nu sub load) → controllerul intern sau zona NAND principală e supraîncălzită cronic
+- Modelul SNV3S = DRAM-less QLC, controller silicon-motion entry-level, cunoscut pentru:
+  - Thermal throttle agresiv >70°C
+  - Controller hang sub workload de scriere secvențială mare (cazul backup-urilor zstd-compressed)
+  - SLC cache mic, post-cache-fill performance dramatic mai mică + temperatură mare
+
+**Kingston nu e potrivit pentru rolul de backup target la load-ul de aici.**
+
+### 2. Cascade systemd dependency
+
+Lanțul de dependențe care pune pvemini în emergency mode:
+
+```
+/dev/nvme2n1p1 (NVMe Kingston) timeout 90s
+    └─> dev-nvme2n1p1.device FAILED
+        ├─> systemd-fsck@dev-nvme2n1p1.service (dependency)
+        ├─> mnt-backup.mount (RequiresMountsFor)
+        │       ├─> nfs-server.service (After=mnt-backup.mount)
+        │       │       ├─> nfs-mountd.service
+        │       │       └─> nfs-idmapd.service
+        │       └─> local-fs.target (Wants=)
+        │               └─> multi-user.target → boot fail
+        └─> emergency.target (fallback)
+                └─> systemd-ask-password-console.service ("Give root password")
+```
+
+**Punct critic de design:** mount-ul `/mnt/backup` nu are `nofail` în fstab. Orice failure pe Kingston blochează boot-ul. Cu `nofail`, sistemul ar continua boot-ul fără mount, primești alertă pe `pvesm status`, dar restul cluster-ului (NFS pentru pveelite/pve1 + dependencies) e mai degradat decât rupt.
+
+### 3. NFS server activ + clienți consequenți
+
+```
+/etc/exports:
+  /mnt/backup 10.0.20.0/24(rw,sync,no_subtree_check,no_root_squash)
+
+Active clients (NFSv4.2):
+  pveelite (10.0.20.202) — confirmed, callback UP
+  pve1     (10.0.20.200) — confirmed, callback UP
+```
+
+**Observație importantă:** Proxmox storage `backup-pvemini-nfs` apare `disabled` în `pvesm status`, **dar mount-urile kernel pe pveelite + pve1 sunt încă VII**. Clienții se reconectează automat după restart pvemini, dar în timpul hangului orice operație se înghețează.
+
+Asta amplifică incidentul: chiar și pveelite + pve1 (care n-au probleme cu Kingston) ar putea ajunge să-și înghețe niște procese (vzdump, df, ls pe `/mnt/pve/backup-pvemini-nfs`) cât timp pvemini era hung.
+
+### 4. ZFS rpool — fals pozitiv, nu altă problemă
+
+În log-ul de boot 22:41 apar 14 erori de checksum pe `rpool` (Samsung 990 PRO mirror, OS pool):
+```
+zed[1809]: eid=1 class=checksum pool='rpool' vdev=nvme-eui.0025384551a1560c-part3 err=52
+```
+
+**NU e o problemă a Samsung-ului.** SMART pe ambele Samsung 990 PRO confirmă:
+- `Percentage Used: 3%`
+- `Media Errors: 0`
+- `Error Log Entries: 0`
+- Temperature 43-55°C
+
+Erorile au apărut pentru că Kingston-ul a hang-uit I/O subsystemul în timpul activității, scrierile spre rpool n-au mai ajuns coerent pe ambele oglinzi → la reboot ZFS a detectat divergența, a făcut resilver de 33.6 MB din partenerul de mirror, **0 errors finale**. Mecanism normal ZFS — exact ce trebuie să facă mirror-ul.
+
+### 5. Severitate finală — DE CE MEDIE și nu CRITICĂ
+
+Infrastructura ROMFASTSQL are **două mecanisme separate** de protecție date, pe storage-uri fizic separate:
+
+| Mecanism | Storage | Disc fizic | Frecvență max | Status după hang |
+|----------|---------|------------|---------------|------------------|
+| **Replicare ZFS** | `rpool/data` | Samsung 990 PRO mirror | 5 min (CT 108 + VM 201) | ✅ Continuă neafectată |
+| **Backup vzdump** | `/mnt/backup` | Kingston SNV3S | 24h | ⚠️ Stop pe durata hangului |
+
+**Replicare ZFS configurată (verificat 04-30 23:55):**
+- CT 108 Oracle XE → pve1 + pveelite, schedule `*/5 min` (RPO 5 min)
+- VM 201 Windows IIS → pve1 + pveelite, schedule `*/5 min` (RPO 5 min)
+- CT 171 Claude Agent → pve1 + pveelite, `*/15 min`
+- CT 106 Gitea, CT 110 MoltBot → toate noduri, `*/2h`
+- CT 100/101/103/104/105, VM 109 → 24h
+- Toate joburile: FailCount=0, Yes/Enabled
+
+**De ce contează:** dacă Kingston-ul ar muri DEFINITIV chiar acum, infrastructura **continuă să funcționeze**:
+- Toate VM/CT-urile rămân online (live data e pe Samsung)
+- DR rapid prin `pvesr switchover` posibil în <1 min
+- Pierderi efective: capacitate de archive/rollback istoric (ex: cineva DROP TABLE acum 3 zile, descoperă azi → fără vzdump nu poți rollback)
+
+Severity = MEDIE pentru că: efectul vizibil e amplu (pvemini hang, cluster degradat), dar **nu există pierdere de servicii sau date**.
+
+---
+
+## Cine scrie pe `/mnt/backup` — referință
+
+**Backup vzdump zilnic 02:00 (storage `backup`):**
+| ID | Serviciu | Severitate dacă pierdem archive |
+|----|----------|--------------------------------|
+| CT 100 | portainer | 🟡 MEDIE (recoverable din replicare) |
+| CT 104 | Flowise (chatbot AI) | 🟠 IMPORTANT |
+| CT 106 | Gitea (git server) | 🟠 IMPORTANT |
+| CT 108 | **Oracle XE producție** | 🔴 IMPORTANT (rollback istoric pierdut) |
+| CT 171 | Claude Agent | 🟡 MEDIE |
+| VM 201 | **Windows IIS + ROA** | 🔴 IMPORTANT |
+
+**Backup vzdump 22:00 + sâmbătă 15:00 (storage `backup-pvemini-nfs`):**
+- CT 101 minecraft, CT 110 MoltBot, VM 109 Oracle DR
+
+**NFS export către cluster:**
+- Path: `/mnt/backup` exportat `10.0.20.0/24(rw,sync,no_root_squash)`
+- Clienți activi: pveelite, pve1
+
+**Samba windows-share:**
+- `/mnt/backup/windows-share` cu samba `[backup-share]` pentru `backup-user`
+- Conținut actual: 1 fișier text de test (irelevant)
+
+---
+
+## Plan de prevenție
+
+### 🔴 Tier 1 — Stop la cascada de azi (5-15 min, low risk, REVERSIBIL)
+
+**1. `nofail` pe `/mnt/backup` în fstab**
+```bash
+ssh root@10.0.20.201
+# Editare /etc/fstab linia /mnt/backup:
+# vechi:  /dev/nvme2n1p1 /mnt/backup ext4 defaults 0 2
+# nou:    /dev/nvme2n1p1 /mnt/backup ext4 defaults,nofail,x-systemd.device-timeout=10s 0 2
+systemctl daemon-reload
+```
+Boot-ul nu mai cade în emergency mode dacă SSD-ul e mort. `pvesm status` raportează `inactive`. Joburile vzdump eșuează cu eroare clară (nu hang).
+
+**2. Decuplează NFS server de mount**
+```bash
+# /etc/systemd/system/nfs-server.service.d/no-backup-dependency.conf
+[Unit]
+RequiresMountsFor=
+After=
+```
+Sau, mai sigur, dezactivează exportul `/mnt/backup` complet (nu mai e folosit pentru Proxmox cluster):
+```bash
+# /etc/exports — comentează linia
+# /mnt/backup 10.0.20.0/24(rw,sync,no_subtree_check,no_root_squash)
+exportfs -ra
+# Verifică pe pveelite + pve1 că nu mai au nimic care folosește mount-ul:
+ssh root@10.0.20.202 "umount /mnt/pve/backup-pvemini-nfs 2>/dev/null"
+ssh root@10.0.20.200 "umount /mnt/pve/backup-pvemini-nfs 2>/dev/null"
+```
+
+**3. Hardware watchdog activ**
+```bash
+# /etc/systemd/system.conf
+RuntimeWatchdogSec=30s
+RebootWatchdogSec=10min
+```
+Dacă pvemini intră în hang persistent (>30s fără ping watchdog), kernel-ul resetează automat. Combinat cu `kernel.panic=10` (deja setat după 04-20), recovery autonom fără intervenție fizică.
+
+**4. smartd alerting configurat (nu doar monitor)**
+```bash
+# /etc/smartd.conf — adăugare per device
+/dev/nvme2 -d nvme -W 0,70,75 -l error -l selftest -m root@romfast.ro
+```
+Trimite email la temperature >70°C (warning) sau >75°C (critical), plus orice eroare critică. **Necesită fix DKIM/SPF pe romfast.ro** (rămas din planul 04-20).
+
+### 🟠 Tier 2 — Detecție înainte să dăuneze (30-60 min)
+
+**5. Înlocuiește Kingston-ul** pentru rolul de backup target
+- Recomandare: Samsung 990 PRO 2TB / WD Red SN700 / Crucial T500 (TLC + DRAM, EWS suficient)
+- Buget: ~700-1000 RON
+- Migrare: copy `/mnt/backup` pe disc nou, swap fizic, nou mount cu `nofail` din start
+
+**6. Backup secundar oglindit pe pve1**
+- pve1 are 32 GB RAM nefolosit + storage `local` (1.25 TiB liber)
+- Mirror nightly al `/mnt/backup` → `/var/lib/vz/dump/` pe pve1 prin rsync
+- Dacă Kingston moare, ai copia pe pve1 ca insurance archive
+
+**7. Prometheus node-exporter cu metrice SMART/temperature**
+- Trend de temperatură vizibil grafic, nu doar prag
+- Alertă proactivă când pattern-ul de temperatură se modifică (presimptom de hang)
+
+### 🟡 Tier 3 — Reducere blast radius (1-2 zile)
+
+**8. Mută destinația principală vzdump pe pve1**
+- pvemini = host primary services, NU și backup target (dublu rol = dublu SPOF)
+- pve1 = quorum-only acum, ar putea găzdui storage backup principal
+- Modifică joburile vzdump: `storage backup` → storage nou pe pve1 montat NFS pe pvemini
+
+**9. Termină rămășițele din 2026-04-20**
+- [ ] kdump-tools pe pvemini (crash dump capture, necesită `crashkernel=256M` în GRUB + reboot)
+- [ ] apcupsd/nut UPS monitoring (cablul e conectat, dar nu există jurnal evenimente)
+- [ ] **DKIM/SPF fix `romfast.ro`** — fără ăsta, alertele smartd nu ajung pe Gmail (vezi log 2026-04-20 00:00:02)
+- [ ] OOM alerting cron (oom-alert.sh)
+
+### 🟢 Tier 4 — Capacity planning
+
+**10. RAM upgrade pveelite la 32+ GB** (rămas din 04-20, ~300 RON)
+- Permite HA failover real al serviciilor pvemini către pveelite în caz de hang lung
+- Acum pveelite (16 GB) nu poate prelua CT 108 + VM 201 + restul în paralel
+
+---
+
+## Acțiuni — executate 2026-04-30 23:14 → 2026-05-01 00:20
+
+### Investigație
+- [x] Diagnostic SMART pe toate 3 NVMe-uri (Kingston + 2x Samsung 990 PRO)
+- [x] Verificare ZFS rpool — auto-resilver 33.6M, 0 erori, OK
+- [x] Analiză cronologie hang via journalctl --list-boots + journalctl -b -2
+- [x] Identificare scriitori `/mnt/backup` (vzdump joburi, NFS export, samba windows-share)
+- [x] Verificare replicări ZFS — toate joburile FailCount=0
+- [x] Documentare incident (acest fișier)
+
+### Tier 1 prevention — APLICAT (2026-05-01 00:11 → 00:20)
+
+Backup-uri config la `/root/backup-tier1-prevention-2026-04-30/` pe pvemini.
+
+- [x] **Tier 1.1** `nofail` în fstab pentru `/mnt/backup`
+  ```
+  /dev/nvme2n1p1 /mnt/backup ext4 defaults,nofail,x-systemd.device-timeout=10s 0 2
+  ```
+  Efect: la boot, dacă Kingston nu răspunde, sistemul nu mai cade în emergency mode. Storage `backup` apare `inactive` în pvesm — semnal vizual clar.
+
+- [x] **Tier 1.3** Hardware watchdog activat
+  - `iTCO_wdt` încărcat (anterior doar `softdog` software era activ, ineficient la kernel hang)
+  - `/etc/systemd/system.conf`:
+    ```
+    RuntimeWatchdogSec=30s
+    WatchdogDevice=/dev/watchdog1
+    RebootWatchdogSec=10min
+    ```
+  - `systemctl daemon-reexec` aplicat — systemd ping-uiește activ `/dev/watchdog1` (use count = 2)
+  - Persistență la boot: `/etc/modules-load.d/itco-wdt.conf` + blacklist softdog în `/etc/modprobe.d/blacklist-softdog.conf`
+  - Verificare: `wdctl /dev/watchdog1` → Identity: `iTCO_wdt`, Timeout: 30s, Timeleft: 30s
+
+  Efect: dacă pvemini hang-uiește total (orice cauză — Kingston, kernel panic, RAM error), hardware-ul resetează automat în maxim 30s. Combinat cu `kernel.panic=10` (deja setat din 2026-04-20) → recovery autonom, fără intervenție fizică. Va salva și de incidente similare cu cel din 2026-04-20 (hang total fără logs).
+
+### Tier 2 + Distantare temporală — APLICAT (2026-05-01 00:30)
+
+Backup config la `/root/backup-tier1-prevention-2026-04-30/jobs.cfg.original`.
+
+- [x] **Restructurare joburi vzdump pentru reducere stres thermal Kingston pvemini**
+
+**Schimbări fundamentale:**
+1. **Distantare temporală** — joburile rulează la ore diferite (în loc de 6 consecutive în 8 minute), permitând cooldown între ele
+2. **Alternare zile par/impar** — fiecare CT/VM primește backup la 2 zile (în loc de zilnic), reducând la jumătate scrisul
+3. **Mutare CT 101 + CT 110 pe pve1 `backup-ssd`** — scoate ~55 GB scrieri/2 zile de pe Kingston pvemini, le pune pe Kingston SA400S37 SATA pe pve1 (rece 30°C, 98% life left)
+
+**Joburi vechi șterse:**
+- `backup-fbb668c0-726e` (02:00 zilnic, 6 servicii) → suprimat
+- `backup-981b377f-a661` (22:00 zilnic, 2 servicii) → suprimat
+
+**Joburi noi configurate:**
+
+| Job ID | Schedule | Storage | VM/CT |
+|--------|----------|---------|-------|
+| `backup-impare-oracle` | `*-*-01/2 02:00` | backup (Kingston pvemini) | CT 108 Oracle |
+| `backup-impare-rest` | `*-*-01/2 03:00` | backup (Kingston pvemini) | CT 100, 106, 171 |
+| `backup-pare-flowise` | `*-*-02/2 02:00` | backup (Kingston pvemini) | CT 104 Flowise |
+| `backup-pare-windows` | `*-*-02/2 03:30` | backup (Kingston pvemini) | VM 201 IIS |
+| `backup-pve1-minecraft` | `*-*-01/2 22:00` | **backup-ssd (pve1)** | CT 101 minecraft |
+| `backup-pve1-moltbot` | `*-*-02/2 22:00` | **backup-ssd (pve1)** | CT 110 MoltBot |
+| `backup-f1c87584-8eb2` | sat lunar 15:00 | backup-pvemini-nfs | VM 109 (păstrat) |
+
+**Retenție:** `keep-last=2, keep-weekly=1` — păstrăm 2 backup-uri recente + 1 săptămânal vechi.
+
+**Calendar de execuție pe Kingston pvemini:**
+- **Zile impare** (1, 3, 5, 7, ...): 02:00 CT 108 → 03:00 CT 100, 106, 171 (1h cooldown)
+- **Zile pare** (2, 4, 6, 8, ...): 02:00 CT 104 → 03:30 VM 201 (1.5h cooldown)
+- **Sâmbăta lunar** (1-7 ale lunii): 15:00 VM 109
+
+**Calendar de execuție pe pve1 backup-ssd:**
+- **Zile impare**: 22:00 CT 101 minecraft (~38 GB)
+- **Zile pare**: 22:00 CT 110 MoltBot (~17 GB)
+
+**Beneficii thermale așteptate:**
+- Reducere scrieri pe Kingston pvemini: ~50% (alternanță par/impar)
+- Plus: ~55 GB / 2 zile mutate pe pve1
+- Cooldown 1+ oră între joburi pe Kingston pvemini (vs. 0 înainte)
+- Net total: ~75% reducere stres thermic concentrat pe Kingston pvemini
+
+### Tier 1 — SKIPPED cu motivație
+
+- [ ] ~~**Tier 1.2** Decuplare NFS server / dezactivare export `/mnt/backup`~~
+  **Motiv:** verificare cluster a arătat că `backup-pvemini-nfs` este `active` pe pveelite și pve1 (mount NFS live). Joburile vzdump 22:00 (CT 101 minecraft, CT 110 MoltBot — ambele live pe pve1) și sâmbătă 15:00 (VM 109 Oracle DR — live pe pveelite) folosesc acest mount pentru a scrie pe Kingston. Dezactivarea exportului ar rupe acele joburi.
+  **Plan:** se rezolvă în Tier 3.8 prin mutarea backup target-ului pe pve1 (storage local), când joburile vor fi reconfigurate.
+
+- [ ] ~~**Tier 1.4** smartd alerting cu email~~
+  **Motiv:** depinde de DKIM/SPF fix `romfast.ro` rămas din 2026-04-20. Fără DKIM, Gmail respinge alertele. Configurare locală în log e oricum activă deja prin smartd default.
+
+### Monitoring — APLICAT (2026-05-01 00:31)
+
+- [x] **`/opt/scripts/kingston-thermal-monitor.sh`** — rulează la fiecare 30 min via cron pe pvemini
+  - Citește SMART JSON via `smartctl -j -A /dev/nvme2`
+  - Loghează CSV trend în `/var/log/kingston-thermal.csv` (timestamp, temperaturi, spare, used, errors, etc.)
+  - State management în `/var/run/kingston-thermal-state` (ok/warning/critical)
+  - Trimite mail alertă DOAR la tranziție de la stare bună la mai rea (no spam)
+  - Trigger automat journal logging via `logger -t kingston-thermal`
+  - Praguri: Sensor 2 ≥70°C warning, ≥75°C critical, plus media errors / spare / used
+
+  Testare la deploy: state inițial = `warning` (Sensor 2 = 74°C), alertă inițială trimisă către mmarius28@gmail.com.
+
+  Verificare trend: `journalctl -t kingston-thermal --since today` sau `tail /var/log/kingston-thermal.csv`
+
+## Acțiuni — RĂMAS DE FĂCUT
+
+- [ ] **MONITORIZARE** — după primul ciclu complet de backup-uri par+impar (3 zile, până 2026-05-04), verifică `tail -100 /var/log/kingston-thermal.csv` și calculează trend Sensor 2:
+  - Așteptare: media zilnică Sensor 2 sub 70°C, vârfuri în timp de backup ≤72°C
+  - Dacă rămâne ≥74°C constant: problema e structural în hardware (controller / cooling pasiv insuficient), nu în load — trecere la Tier 2.5 (înlocuire SSD).
+- [ ] **Verificare fizică Kingston pvemini** — are heatsink M.2? Are flux de aer? E sub alt component cald? (răcire pasivă insuficientă = cauză probabilă)
+- [ ] **DKIM/SPF fix `romfast.ro`** — prerequisite pentru Tier 1.4 + restul alertelor email (rămas din 2026-04-20)
+- [ ] **Tier 1.4** smartd email alerting cu prag temperatură 70°C (după DKIM fix)
+- [ ] **Tier 2.5** Înlocuire Kingston SNV3S → SSD adecvat (Samsung 990 PRO / WD Red SN700 / Crucial T500)
+- [ ] **Tier 2.6** Backup secundar oglindit (mirror nightly /mnt/backup → /mnt/pve/backup-ssd via rsync ca insurance)
+- [ ] **Tier 3.8** NFS export pentru `backup-ssd` ca să poată găzdui și VM 109 (acum doar local pe pve1)
+- [ ] **Verificare** `zpool scrub rpool` — confirmă sănătate Samsung după turbulență (durată estimată 15-40 min, online)
+
+---
+
+## Anexă — comenzi de verificare
+
+```bash
+# Stare curentă storage și mount
+ssh root@10.0.20.201 "pvesm status; df -h /mnt/backup; mount | grep nvme2"
+
+# SMART Kingston (vezi temperatura Sensor 2)
+ssh root@10.0.20.201 "smartctl -a /dev/nvme2 | grep -iE 'temperature|critical|spare|percentage|media'"
+
+# Verificare cronologie boot-uri
+ssh root@10.0.20.201 "journalctl --list-boots --no-pager | tail -10"
+
+# Verificare clienți NFS activi
+ssh root@10.0.20.201 "cat /proc/fs/nfsd/clients/*/info 2>/dev/null | grep -E 'name|address'"
+
+# Verificare replicare (cea care chiar te salvează)
+ssh root@10.0.20.201 "pvesr status"
+
+# Verificare scrub rpool
+ssh root@10.0.20.201 "zpool status rpool"
+```