Ce faceți dacă…

Backupul din această noapte a eșuat

Un backup eșuat într-o noapte nu este un sinistru, ci o întârziere: ultima copie sănătoasă are cel puțin 48 de ore, dacă cea din ajun reușise. Mai multe eșecuri la rând reprezintă un incident de protecție: cauza se caută chiar în aceeași zi, nu vă limitați la confirmarea alertei.

Actualizat în octombrie 20263 min de lectură5 surse citate

Pe scurt

Citiți mesajul de eroare, nu doar indicatorul roșu: spațiu, sursă absentă, date de autentificare, fișiere blocate, debit, agent oprit.
Un job „reușit” poate să fi copiat un dosar gol: verificați dimensiunea copiată.
Notați data ultimei reușite și comunicați-o responsabilului departamentului vizat.
Relansați după corectare, apoi verificați noaptea următoare.
Trei eșecuri într-o lună pe aceeași mașină: schimbați configurarea, nu apăsați doar butonul „relansează”.

1. Citiți eroarea, nu doar indicatorul roșu

Cauzele obișnuite, în ordinea în care apar:

Cauză	Semn	Corectare
Nu mai există spațiu la destinație sau cota a fost atinsă	Eroare de scriere, retenție care se scurtează	Măriți volumul sau scurtați istoricul în cunoștință de cauză
Sursă oprită, în afara rețelei, cale schimbată	Literă de unitate sau share redenumit; job „reușit” pe un dosar gol	Restabiliți sursa, corectați calea, verificați dimensiunea copiată
Date de autentificare refuzate	Parola contului de serviciu a expirat	Restabiliți contul: altfel, toate nopțile vor eșua
Fișiere blocate sau bază de date nepregătită pentru copiere	Copie parțială	Folosiți metoda prevăzută pentru bazele de date deschise; o bază SQL în această stare nu poate fi restaurată corect
Conexiune prea lentă sau întreruptă	Job întrerupt la sfârșitul ferestrei	Backup incremental mai eficient, fereastră mai lungă sau mai puține date inutile
Agent oprit pe mașină	Nicio trimitere	Reporniți serviciul, aflați de ce s-a oprit

Cazul cel mai înșelător este jobul verde pe un dosar gol. ANSSI, agenția națională de securitate cibernetică a Franței, cere ca backupul să facă sistematic obiectul unui control, urmărind în special un volum de date sau de fișiere incoerent, lentori de rețea și modificări de configurație. O dimensiune copiată care scade brusc de la o noapte la alta merită la fel de multă atenție ca un eșec.

2. Aflați când a fost ultima reușită

Este singura dată care contează pentru RPO-ul zilei. Dacă are mai mult de câteva zile, spuneți-o persoanei responsabile de departamentul vizat. Lucrează fără plasă de siguranță și trebuie să știe. A confirma alerta în consolă fără această frază este gestul care transformă un incident într-o pierdere de date două săptămâni mai târziu.

3. Relansați după corectare

Relansați manual un job după ce cauza a fost tratată. Așteptați să se termine. Un eșec la relansare înseamnă că problema persistă. A doua zi dimineața, verificați noaptea următoare: multe corectări „evidente” nu rezistă la a doua trecere.

Un job reușit dovedește că o copie a fost scrisă, nu că poate fi restaurată. Pentru o bază de date SQL Server, Microsoft precizează că comanda de verificare a unui backup nu controlează structura datelor pe care le conține. ANSSI cere ca backupurile să fie testate periodic, cu o procedură de restaurare scrisă; și NIST recomandă testarea backupurilor pentru a vă asigura că fișierele se recuperează fără erori. După un incident de backup, o restaurare de probă a unui fișier sau a unei baze de date este cel mai bun control. Vedeți Cum testați dacă un backup funcționează?.

4. Dacă situația se repetă

Trei eșecuri într-o lună pe aceeași mașină: perimetrul, debitul sau produsul sunt nepotrivite. Schimbați un parametru (excludeți un dosar uriaș și inutil, împărțiți jobul, măriți stocarea), nu vă mulțumiți să relansați manual în fiecare luni.

Lista de verificare de dimineață

Toate joburile din noaptea trecută s-au terminat, nu doar „nu sunt în eroare”?
Dimensiunea copiată este coerentă cu cea din nopțile precedente?
Data ultimei reușite pentru fiecare mașină critică este mai recentă de 24 de ore?
Alertele au fost citite de o persoană desemnată, nu doar primite?
Spațiul rămas la destinație acoperă retenția prevăzută?

La WeDoBack

Monitorizarea 24/7 vizează backupurile și trimite o alertă atunci când un backup nu se finalizează. Alerta este începutul acestei pagini, nu sfârșitul ei. În INTEGRAL, cele două ore de asistență pe lună pot fi folosite pentru tratarea cauzei. În SMART, asistența este facturată per intervenție: eșecul rămâne vizibil pentru client în consolă și îi revine acestuia să îl citească. Asistența este disponibilă la +33 9 72 50 78 28, între 09:00 și 13:00 și între 14:00 și 17:30 (ora Parisului). Pentru dimensionarea stocării, ordinul de mărime publicat este volumul actual înmulțit cu trei, urmat de o ajustare după o săptămână de utilizare: un volum prea mic se observă prin joburi care eșuează sau printr-o retenție care se scurtează. Cheia de criptare, deținută de client, nu are niciun rol în eșecul trimiterii: dacă jobul eșuează, copia de la distanță pur și simplu nu a fost actualizată.

Sunați la +33 9 72 50 78 28 Descoperiți oferta INTEGRAL

Întrebări frecvente

Este gravă o noapte de eșec?

Rareori, dacă noaptea precedentă a reușit și cauza este corectată în cursul zilei. Riscul vine din acumulare: fiecare noapte de eșec mărește cantitatea de muncă ce s-ar pierde în caz de sinistru. După câteva zile, este un incident care trebuie semnalat conducerii.

Este suficient statusul „reușit” pentru a dovedi că un backup este bun?

Nu. ANSSI, agenția națională de securitate cibernetică a Franței, cere un control sistematic al backupurilor, în special al volumelor de date incoerente, precum și teste de restaurare periodice. Pentru SQL Server, Microsoft precizează că verificarea unui backup nu controlează structura datelor pe care le conține: doar o restaurare reală, urmată de un control de coerență, o dovedește.

Cine trebuie să urmărească alertele de backup?

O persoană desemnată, cu un înlocuitor pentru concedii. O alertă care ajunge într-o cutie partajată pe care nu o citește nimeni echivalează cu lipsa alertei. Stabiliți și cine anunță conducerea atunci când ultima reușită depășește un prag convenit în prealabil.

Pentru a afla mai mult

Surse

Documente consultate în octombrie 2026.

Backupul sistemelor informatice – Elementele fundamentale (ANSSI-BP-100, v1.1, 27 noiembrie 2025) — ANSSI (agenția franceză)
Cybersecurity guide for SMEs (în limba engleză, iunie 2021) — ENISA
RESTORE VERIFYONLY (Transact-SQL) — Microsoft Learn
SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — NIST
Oferte și prețuri — WeDoBack

Aveți nevoie de ajutor acum?

Nu restaurați nimic înainte de a fi identificat o copie sănătoasă. Vă putem ghida.

Sunați la +33 9 72 50 78 28 sau scrieți-ne

Vă confruntați chiar acum cu un incident?

Echipele noastre vă ajută să identificați copia potrivită și să o restaurați, de luni până vineri, între orele 9:00–13:00 și 14:00–17:30 (ora Parisului).

Sunați la +33 9 72 50 78 28 Scrieți echipei