De ce eșuează backup-urile în IMM-uri

Întrebați un patron dacă are backup și răspunsul este da. Întrebați când a fost testată ultima restaurare și răspunsul își schimbă forma.

Cele trei eșecuri pe care le găsim cel mai des

Copia este pe aceeași mașină cu datele. Un al doilea disc în același server protejează împotriva defectării unui disc și a nimic altceva — nici incendiu, nici furt, nici ransomware, care criptează fiecare unitate la care ajunge.

Nimeni nu citește rapoartele. Jobul eșuează din martie. E-mailul merge la o adresă pe care nu o urmărește nimeni sau la o persoană care a plecat.

Restaurarea nu a fost încercată niciodată. Backup-ul rulează, fișierul există și nimeni nu a confirmat vreodată că el conține ce ar trebui sau cât ar dura readucerea lui.

Regula care rămâne valabilă

Trei copii ale datelor, pe două tipuri diferite de suport, cu una păstrată în altă locație. Este anterioară cloud-ului și i-a supraviețuit. Practic, pentru o firmă mică:

• Datele vii pe server
• Un backup local pentru restaurări rapide
• O copie externă sau în cloud pentru ziua proastă

Adăugați a patra condiție

Ransomware-ul modern caută în mod special backup-urile și de obicei le găsește, pentru că, prin construcție, contul de backup are acces la tot. Așa că o copie trebuie să fie imutabilă: scrisă o dată și imposibil de șters sau modificat pentru o perioadă fixă de retenție, chiar și cu credențiale valide de administrator.

Dacă backup-ul poate fi șters de cine vă compromite contul de administrator de domeniu, nu este un backup. Este o a doua țintă.

Ce să verificați săptămâna aceasta

• Deschideți consola de backup și citiți ultimele treizeci de zile de rezultate
• Confirmați că adresa de alertă aparține cuiva încă angajat
• Alegeți un fișier important și restaurați-l într-o locație temporară
• Notați cât a durat

Ultima cifră este cea pe care v-o va cere conducerea în timpul unui incident.

Lucrările noastre de servere și backup încep exact cu aceste verificări.