—
▶Serviciu
▶Fire active
FirModelDirectorStareUSD
▶Diagnostic
se încarcă…
▶Confirmări în așteptare
niciuna
▶Jurnal 
se încarcă…
▶Punte WhatsApp
▶Consumer RAG
▶Conectare WhatsApp
se încarcă…
▶Trimise la suport
se încarcă…
▶Fire de discuție active
JIDSubiectUltima activitate
▶Clienți cunoscuți
NumeNumere

Adaugă client

▶Documente indexate
NumeMărime

Adaugă document (.txt / .md)

▶Jurnal Maria 
se încarcă…
▶Stare cluster citire · la 30 s
NodStareCPURAMGuestUptime
▶Oprire clustercluster-shutdown.sh · 15–40 min
  1. Verificări: ping, ssh, cvorum, fără task-uri în curs
  2. Salvează lista guest-urilor pornite (.cluster-state.txt)
  3. Trimite instrucțiunile de pornire cât încă merge totul: mesaj în Discord + email
  4. HA pe freeze; pauză la alerte, la testul DR și la fereastra de patch
  5. Oprește guest-urile, Oracle 108 ultimul (shutdown immediate)
  6. LXC 171 se oprește odată cu pvemini, la final: dashboard-ul și Discord nu mai răspund
  7. pveelite → pve1 → pvemini; raportul final vine pe email
▶Pornire clustertrezire de pe telefon, apoi de aici

Cu dashboard-ul oprit, instrucțiunile de pornire se găsesc în Discord (mesaj fixat la oprire) și pe email. Textul lor e mai jos.

—
▶UPS
Test rapid baterie
ups-monthly-test.sh · ~2 min pe baterie
Simulează oprirea de urgență
ups-shutdown-cluster.sh --dry-run --force, ca nut
Istoric autonomie
ultimele rânduri din trendul de baterie
▶DR · VM 109
Test DR acum
restaurează backup-ul RMAN pe VM 109, verifică, oprește · ~25 min
Fereastră de patch Windows
vm109-patch-window.sh --now · 30–60 min
VM 109 manual
pentru depanare; watchdog-ul intră pe pauză
▶Failover și failbackdistructivcând un nod a căzut; deschide o operație pentru instrucțiuni
▶Backup-urile Oracle trec pe pveminipveelite a căzut și nu revine curând
Situația
Serverul de producție (10.0.20.36) își copiază în fiecare noapte backup-urile RMAN pe pveelite. De acolo le folosește VM 109 la testul DR. Dacă pveelite e jos, copia din noaptea asta nu mai are unde ajunge.
Ce face
1. Verifică de două ori că pveelite chiar nu răspunde.
2. Pe pvemini, copia backup-urilor devine activă, cu scriere, partajată prin NFS.
3. Pe 10.0.20.36, transfer_backups.ps1 e redirecționat spre pvemini.
4. Oprește replicarea pveelite → pvemini.
Ce pierzi
Nimic din producție. Backup-urile ajunse pe pveelite după ultima replicare (maximum 15 min) rămân doar acolo.
Cum revii
Operația de mai jos, după ce pveelite a repornit.
failover-dr-to-pvemini.sh · pe pvemini · ~2 min
▶Backup-urile Oracle revin pe pveelitedupă ce pveelite a repornit
Situația
Operația de mai sus a rulat. Între timp pvemini a primit backup-uri noi, iar pveelite e din nou pornit, dar are date vechi.
Ce face
1. Face un snapshot pe pvemini și îl trimite pe pveelite, suprascriind ce e acolo.
2. pvemini redevine replica read-only, fără NFS.
3. Pe 10.0.20.36, transferul e redirecționat înapoi spre pveelite.
4. Repornește replicarea.
Ce pierzi
Tot ce e pe pveelite și nu e pe pvemini. Nu rula dacă pveelite a mai primit backup-uri după căderea lui.
Cum revii
Nu există un pas invers; suprascrierea e definitivă.
failback-dr-to-pveelite.sh · pe pvemini · durează după volumul datelor
▶VM 201 (roacentral) pe alt nodarhivat — vezi proxmox/cluster/failover/arhiva/învechit
De ce nu
Scripturile au fost scrise când VM 201 nu era în HA. Din 2026-04-25 e în HA (ha-prefer-pvemini): dacă pvemini cade, se mută singur pe pve1 și revine singur. Un failover manual ar intra în conflict cu HA.
În schimb
Nu apar ca butoane aici. Panoul „Stare cluster" arată doar unde rulează VM 201 și starea HA. Scripturile sunt arhivate în repo.
▶Discord · /infraaceleași acțiuni, confirmare cu butoane
/infra starestarea clusterului, ca embed /infra oprire · porniresimulare implicit /infra ups-test · ups-simularetest rapid · dry-run urgență /infra dr-test · dr-patch · vm109VM 109 /infra backup-pe-pvemini · backup-pe-pveelitearată fișa de instrucțiuni, apoi butonul /infra sarcinice rulează + ultimele linii din jurnal