Veeam are de mult timp feature-ul SureBackup, dar mulți admini îl ignoră pentru că pare complicat. Nu e. Ideea de bază: Veeam pornește VM-ul restaurat într-un sandbox izolat (Virtual Lab), îl bootează din backup, rulează ping/script-uri custom, și îți confirmă că de fapt poate fi restaurat funcțional.

Setup-ul minimal pentru un client cu 20 VM-uri arată cam așa:

1. Application Group: VM-urile critice (DC, SQL, file server)
2. Virtual Lab: izolat pe un proxy ESXi/Hyper-V dedicat sau partajat
3. SureBackup Job: rulează săptămânal (sâmbătă noapte)
4. Tests:
   - Heartbeat (VM tools răspund)
   - Ping (rețea izolată funcționează)
   - Application-specific (script PowerShell pentru SQL/AD)

În plus, o regulă pe care am învățat-o pe pielea mea: nu te baza doar pe Backup Verification din job-ul principal. Acel “CRC check” verifică integritatea blocurilor, dar nu îți spune dacă VM-ul chiar bootează. Le văd pe amândouă confuze chiar și la admini cu experiență.

Un client cu un Veeam B&R 12 instalat pe Windows Server 2019, repository pe un Synology NAS prin SMB. 30 de VM-uri, jobs zilnice, retention 14 zile. Totul verde de 8 luni.

Caz: “Am pierdut un VM cu aplicația de contabilitate, ne trebuie restore urgent”. OK, deschid consola, găsesc VM-ul în restore points, pornesc Instant VM Recovery. Rulează 40 de secunde, raportează “Success”. VM-ul apare în vSphere. Bootează. BSOD. Restart. BSOD. Restart. BSOD.

Verific log-urile: corupție pe nivelul VMDK-ului. Încerc backup point cu o zi mai devreme – same. Și încă unul mai devreme. La al 5-lea restore point găsesc unul curat (de acum 6 zile). Dar contabilitatea avea date introduse zilnic.

Cauza, după 4 ore de verificare: un firmware bug pe NAS-ul Synology care la sync-uri concurente scria blocuri parțiale fără să raporteze eroare. CRC-ul Veeam nu detectase pentru că datele “se citeau” – pur și simplu erau greșite. Un SureBackup săptămânal ar fi prins problema în prima săptămână, când încă aveam 7 zile de backup-uri sănătoase în istorie.

Recovery final: am refăcut bazele de date din ultimele tranzacții logate de aplicație, plus 2 zile pierdute pe care le-au reintrodus manual. Clientul a plătit echivalentul a 6 luni de backup în ore om. Și de atunci, SureBackup e bifa pe care o cer obligatoriu la orice setup nou.

Vechea regulă 3-2-1 (3 copii, 2 medii diferite, 1 offsite) e bună, dar incompletă pentru epoca ransomware-ului. Versiunea actualizată pe care o aplic:

3 copii ale datelor
2 medii diferite (disc + tape SAU disc + cloud)
1 copie offsite (Wasabi, Backblaze, Azure Blob)
1 copie immutable / air-gapped (Object Lock S3 sau hardware tape)
0 erori la verificare (SureBackup săptămânal)

Pentru SMB, Wasabi cu Object Lock activat e cel mai bun raport preț/protecție pe care l-am găsit – cam 6 USD/TB/lună, immutable garantat 30 de zile, integrare nativă în Veeam. Tape-ul rămâne cea mai sigură opțiune pentru paranoici, dar adaugă complexitate operațională (rotație, storage offsite fizic, drive maintenance).

Backup-ul care nu a fost niciodată restaurat nu există. E o promisiune, nu o realitate. Iar diferența între un sysadmin senior și unul junior nu e în câte job-uri configurează, ci în câte restore-uri reale a făcut și câte teste programate rulează automat.

Dacă acum, citind asta, realizezi că nu ai mai testat un restore de luni de zile – oprește-te aici, deschide Veeam, și pornește un Instant Recovery pe un VM oarecare în Virtual Lab. Durează 5 minute. Te va salva într-o zi când nu mai sunt 5 minute disponibile.