fix(dr): Windows Update rebota VM 109 in mijlocul testului DR

Testul DR din 2026-08-08 a raportat "Restore failed" dupa 11 secunde, fara niciun log RMAN. Cauza nu a fost restore-ul: KB5101001 fusese descarcat in timpul testului din 2026-08-01 (singurul moment in care VM 109 e pornit), a ramas staged dupa qm stop si s-a finalizat la boot-ul testului urmator. Cronologie din Event Log-ul guest-ului: 06:00:58 RestartManager 10010 - nu poate reporni powershell.exe (restore-ul) 06:01:04 SCM 7034 - OpenSSH SSH Server terminat neasteptat 06:01:06 pveelite: client_loop: send disconnect: Broken pipe -> FAILED 06:01:38 VM-ul se reboteaza singur Fereastra testului (Sambata 06:00) era in afara Active Hours (08:00-17:00), deci pentru Windows era fereastra de mentenanta valida - iar VM 109 fiind pornit doar in timpul testului, aceea era singura fereastra posibila. Agravant: sshd nu avea acsiuni de recovery (RESET_PERIOD 0), deci dupa ce a murit a ramas mort si au esuat si colectarea logului si shutdown-ul gratios. Masuri: - NoAutoUpdate=1 + AUOptions=2 pe VM 109 (aplicat direct in registry) - actiuni de recovery pentru sshd: restart la 5s/10s/30s, reset=86400 - guard "STEP 3b: Windows servicing" inainte de restore (check_servicing.ps1): asteapta idle 300s, consuma controlat un reboot in asteptare, altfel abandoneaza cu "ABORTED - Windows servicing" in loc de un "Restore failed" inselator. Fail-open daca checkul lipseste - nu are voie sa pice testul. - fereastra lunara de patching (vm109-patch-window.sh + install_updates.ps1), prima duminica 03:00, cu re-armare NoAutoUpdate=1 indiferent de rezultat Adaugat si .gitattributes: cu core.autocrlf=true scripturile .sh ajungeau in working tree cu CRLF, iar ele se deployeaza prin scp direct pe Proxmox. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BhQBTegE4PiMPPaapLHjkc
2026-08-08 16:56:24 +03:00
parent f5dbb4cc2d
commit 94758421c5
6 changed files with 542 additions and 1 deletions
--- a/proxmox/vm109-windows-dr/README.md
+++ b/proxmox/vm109-windows-dr/README.md
@@ -31,6 +31,81 @@ ssh root@10.0.20.202 "qm status 109"          # trebuie stopped între teste

 Script-urile refuză să ruleze dacă cealaltă parte e accesibilă (anti-split-brain).

+## 🩹 Windows Update pe VM 109 — incident 2026-08-08
+
+**Simptom:** testul DR din 2026-08-08 a raportat `FAILED`, `Database Restore: Restore failed` după 11 secunde, `Tables restored: 0`, iar raportul nu conținea niciun log RMAN („No restore logs or RMAN scripts found"). Testul din 2026-08-01 trecuse în 18 minute pe exact același cod (scripturile nu s-au modificat din 2026-04-25).
+
+**Cauza reală: RMAN nici nu a apucat să pornească.** Windows Update a rebootat VM-ul în mijlocul testului.
+
+Cronologia din Event Log-ul guest-ului:
+
+| Ora | Eveniment |
+|-----|-----------|
+| 06:00:26 | boot VM 109 |
+| 06:00:53 | scriptul DR confirmă SSH + PowerShell |
+| 06:00:55 | STEP 4 pornește `rman_restore_from_zero.ps1` |
+| 06:00:58 | `RestartManager 10010` — nu poate reporni `powershell.exe` (pid 5964) = **procesul de restore** |
+| 06:00:59 | `Winlogon 6004` — TrustedInstaller a eșuat o notificare critică |
+| 06:01:02 | `SCM 7023` — Update Orchestrator Service terminat |
+| 06:01:04 | `SCM 7034` — **OpenSSH SSH Server terminat neașteptat** |
+| 06:01:06 | pveelite vede `client_loop: send disconnect: Broken pipe` → restore marcat FAILED |
+| 06:01:38 | **VM-ul se reboteaza singur** (al doilea eveniment `Kernel-General 12`) |
+| 06:02:20 | scriptul renunță la SSH și forțează `qm stop 109` |
+
+Update-ul vinovat: **KB5101001**, `InstalledOn 8/8/2026`.
+
+**De ce s-a întâmplat exact atunci — problemă structurală, nu ghinion:**
+
+- VM 109 e pornit **doar** în timpul testului DR. Deci fereastra testului era singura fereastră în care Windows Update putea rula vreodată.
+- Update-ul fusese descărcat **în timpul testului precedent** — evenimentele `WindowsUpdateClient id=44` sunt la 08-01 06:13–06:17, adică în interiorul rulării din 1 august. A rămas staged după `qm stop` și s-a finalizat la boot-ul următor = testul următor.
+- Active Hours erau 08:00–17:00, deci 06:00 era pentru Windows o fereastră de mentenanță **validă**.
+- `NoAutoRebootWithLoggedOnUsers=1` nu ajută: o sesiune SSH nu e logon interactiv.
+
+**Factor agravant:** `sc qfailure sshd` nu avea nicio acțiune de recovery (`RESET_PERIOD: 0`). După ce sshd a murit a rămas mort, deci și STEP 6 (colectare log) și STEP 7 (shutdown grațios) au eșuat — de aici raportul fără loguri.
+
+**Ce NU a fost:** host-ul e curat — fără OOM, fără erori de storage, cluster quorate, replicarea ZFS a rulat normal la 06:00. Backup-urile nu au fost implicate în niciun fel.
+
+### Măsuri aplicate (2026-08-08)
+
+| # | Măsură | Unde |
+|---|--------|------|
+| 1 | `NoAutoUpdate=1` + `AUOptions=2` — Windows Update nu mai pornește singur | registry VM 109, `HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU` |
+| 2 | Acțiuni de recovery pentru sshd: restart la 5s / 10s / 30s, `reset=86400` | serviciu `sshd` pe VM 109 |
+| 3 | Guard „STEP 3b: Windows servicing" înainte de restore | `weekly-dr-test-proxmox.sh` + `check_servicing.ps1` |
+| 4 | Fereastră lunară dedicată de patching | `vm109-patch-window.sh` + `install_updates.ps1` |
+
+**3 — guard-ul de servicing.** Între verificarea NFS și restore, scriptul rulează `check_servicing.ps1` pe guest, care întoarce `STATE=IDLE` sau `STATE=BUSY REBOOT_PENDING=... REASONS=...` (CBS RebootPending, WU RebootRequired, PendingFileRename, TiWorker, TrustedInstaller, UsoSvc). Comportament:
+
+- așteaptă până la 300s ca servicing-ul să devină idle;
+- dacă e reboot în așteptare, îl consumă controlat (un singur reboot) și reia verificarea;
+- dacă tot nu e curat, **abandonează înainte de restore** cu `ABORTED - Windows servicing` în loc de un „Restore failed" înșelător, care arată ca o problemă de backup;
+- dacă `check_servicing.ps1` lipsește sau nu răspunde, guard-ul se auto-dezactivează cu un warning — nu are voie să pice testul din cauza propriei absențe.
+
+**4 — fereastra de patching.** Prima duminică din lună, 03:00, pe nodul care găzduiește VM 109:
+
+```bash
+0 3 1-7 * * /opt/scripts/vm109-patch-window.sh > /dev/null 2>&1   # garda „duminică" e în script
+```
+
+Scriptul pornește VM 109 (cu `vm109-debug.flag` setat, fiindcă patching-ul depășește limita de 60 min a watchdog-ului), permite temporar Windows Update (`NoAutoUpdate=0`), aplică update-urile prin API-ul COM `Microsoft.Update.Session`, tolerează până la 3 cicluri de reboot, **re-armează `NoAutoUpdate=1` indiferent de rezultat**, verifică starea finală și oprește VM-ul. Trimite mail doar când rezultatul nu e curat.
+
+Rulare manuală (ignoră garda de calendar):
+
+```bash
+ssh root@10.0.20.202 "/opt/scripts/vm109-patch-window.sh --now"
+tail -f /var/log/oracle-dr/patch-window.log
+```
+
+**Verificare stare Windows Update pe VM 109:**
+
+```bash
+ssh root@10.0.20.202 "ssh -p 22122 romfast@10.0.20.37 \
+  'powershell -ExecutionPolicy Bypass -File D:\\oracle\\scripts\\check_servicing.ps1'"
+# Așteptat între ferestre: STATE=IDLE
+```
+
+**Zgomot preexistent, fără legătură cu incidentul:** la fiecare boot apar `VSS 8213` + `SCM 7023` pentru `OracleVssWriterROA` („General access denied"). Serviciul VSS writer al Oracle nu are drepturi suficiente. Nu afectează restore-ul RMAN (care nu folosește VSS) — de rezolvat separat.
+
 ---

 # 🛡️ Oracle DR System - Complete Architecture
@@ -156,6 +231,8 @@ Scheduled Tasks:
 /opt/scripts/
 ├── oracle-backup-monitor-proxmox.sh  # Daily backup monitoring
 ├── weekly-dr-test-proxmox.sh         # Weekly DR test
+├── vm109-patch-window.sh             # Monthly Windows patching (incident 08-08)
+├── vm109-watchdog.sh                 # Force-stop VM 109 outside test window
 └── PROXMOX_NOTIFICATIONS_README.md   # Documentation

 /mnt/pve/oracle-backups/ROA/autobackup/
@@ -166,6 +243,8 @@ Scheduled Tasks:
 Cron Jobs:
 0 9 * * * /opt/scripts/oracle-backup-monitor-proxmox.sh
 0 6 * * 6 /opt/scripts/weekly-dr-test-proxmox.sh
+0 3 1-7 * * /opt/scripts/vm109-patch-window.sh    # prima duminică (gardă în script)
+* * * * * /opt/scripts/vm109-watchdog.sh
 ```

 ### 📁 DR VM 109 (10.0.20.37) - When Running
@@ -173,6 +252,8 @@ Cron Jobs:
 D:\oracle\scripts\
 ├── rman_restore_from_zero.cmd    # Main restore script ⭐
 ├── cleanup_database.cmd          # Cleanup after test
+├── check_servicing.ps1           # Servicing guard (incident 08-08)
+├── install_updates.ps1           # Used only by vm109-patch-window.sh
 └── mount-nfs.bat                 # Mount F:\ at startup

 F:\ (NFS mount from Proxmox)
@@ -248,6 +329,14 @@ ssh root@10.0.20.202 "qm stop 109"

 ## 🐛 Troubleshooting

+### ⚡ Simptome frecvente — unde te uiți întâi
+
+| Simptom în raportul DR | Cauză probabilă |
+|---|---|
+| `Restore failed` în < 60s, **fără log RMAN**, `Broken pipe` în log-ul bash | Nu e problemă de backup — sesiunea SSH a murit. Vezi [Windows Update pe VM 109](#-windows-update-pe-vm-109--incident-2026-08-08). Verifică `SCM 7034 sshd` în Event Log-ul guest-ului. |
+| `ABORTED - Windows servicing` | Guard-ul STEP 3b a oprit testul intenționat: Windows Update era activ. Backup-urile nu sunt implicate. Rulează fereastra de patching manual. |
+| `Restore failed` după 10+ minute, cu log RMAN | Problemă reală de restore — continuă cu secțiunile de mai jos. |
+
 ### 🔍 Debugging Restore Tests

 #### Check Backup Files on Proxmox (10.0.20.202)