# 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"
```