Software de backup. Compararea metodelor de backup

Pregătirea unui nou server pentru funcționare ar trebui să înceapă cu configurarea Rezervă copie. Toată lumea pare să știe despre asta - dar uneori chiar și administratorii de sistem experimentați fac greșeli de neiertat. Iar ideea aici nu este doar că sarcina de a configura un nou server trebuie rezolvată foarte rapid, ci și că nu este întotdeauna clar ce metodă de backup ar trebui utilizată.

Desigur, este imposibil să creezi o metodă ideală care să se potrivească tuturor: totul are avantajele și dezavantajele sale. Dar, în același timp, pare destul de realist să alegeți o metodă care se potrivește cel mai bine specificului unui anumit proiect.

Atunci când alegeți o metodă de backup, trebuie mai întâi să acordați atenție următoarelor criterii:

1. Viteza (timpul) de backup la stocare;
2. Viteza (timpul) de restaurare dintr-o copie de rezervă;
3. Câte copii pot fi păstrate cu o dimensiune limitată de stocare (server de stocare de rezervă);
4. Sfera riscurilor din cauza inconsecvenței copii de rezervă, lipsa depanării metodei de backup, pierderea totală sau parțială a backup-urilor;
5. Costuri generale: nivelul de încărcare creat pe server la efectuarea unei copii, o scădere a vitezei de răspuns a serviciului etc.
6. Costul închirierii tuturor serviciilor utilizate.

În acest articol vom vorbi despre principalele metode de backup pentru servere care rulează sisteme Linux și despre cele mai multe probleme tipice problemele pe care le pot întâmpina noii veniți în acest domeniu foarte important al administrării sistemului.

Schemă de organizare a stocării și recuperării din copiile de rezervă

Atunci când alegeți o schemă de organizare a metodei de backup, ar trebui să acordați atenție următoarelor puncte de bază:

1. Copiile de rezervă nu pot fi stocate în același loc cu datele pentru care se face backup. Dacă stocați o copie de rezervă pe aceeași matrice de discuri cu datele dvs., o veți pierde dacă cea principală este deteriorată. matrice de discuri.
2. Oglindirea (RAID1) nu poate fi comparată cu backupul. Raidul vă protejează doar de o problemă hardware cu unul dintre discuri (și mai devreme sau mai târziu o astfel de problemă va apărea, deoarece subsistemul discului este aproape întotdeauna blocaj pe server). În plus, la utilizarea raidurilor hardware există riscul defecțiunii controlerului, de exemplu. trebuie să păstrați un model de rezervă.
3. Dacă stocați copii de rezervă într-un rack într-un DC sau pur și simplu într-un DC, atunci în această situație există și anumite riscuri (puteți citi despre acest lucru, de exemplu,.
4. Dacă stocați copii de rezervă în diferite DC, costurile de rețea și viteza de recuperare dintr-o copie de la distanță cresc brusc.

Adesea, motivul pentru recuperarea datelor este deteriorarea sistemului de fișiere sau a discurilor. Acestea. copiile de rezervă trebuie să fie stocate undeva pe un server de stocare separat. În acest caz, problema poate fi „lățimea” canalului de transmisie a datelor. Dacă aveți un server dedicat, atunci este foarte recomandabil să efectuați copii de siguranță pe un separat interfata retea, și nu pe același lucru care face schimb de date cu clienții. În caz contrar, solicitările clientului dvs. s-ar putea să nu „încadreze” în canalul de comunicare limitat. Sau din cauza traficului de clienți, backup-urile nu se vor face la timp.

În continuare, trebuie să vă gândiți la schema și timpul de recuperare a datelor în ceea ce privește stocarea copiilor de rezervă. S-ar putea să fiți destul de mulțumit de finalizarea unei copii de rezervă în 6 ore pe timp de noapte pe stocare cu o viteză de acces limitată, dar este puțin probabil să vă convină o recuperare de 6 ore. Aceasta înseamnă că accesul la copiile de rezervă ar trebui să fie convenabil, iar datele trebuie copiate suficient de rapid. Deci, de exemplu, restaurarea a 1 TB de date cu o lățime de bandă de 1 Gb/s va dura aproape 3 ore și asta dacă nu întâmpinați probleme de performanță subsistem de discîn stocare și server. Și nu uitați să adăugați la aceasta timpul necesar pentru a detecta problema, timpul necesar pentru a decide derularea înapoi, timpul necesar pentru a verifica integritatea datelor recuperate și cantitatea de nemulțumire ulterioară în rândul clienților/colegilor. .

Backup incremental

La incrementale copie de rezervă copiază numai fișierele care s-au modificat de la backup-ul precedent. Backup-urile incrementale ulterioare adaugă doar fișiere care s-au schimbat față de cea anterioară. În medie, backup-urile incrementale durează mai puțin, deoarece sunt copiate mai puține fișiere. Cu toate acestea, procesul de recuperare a datelor durează mai mult, deoarece datele din ultima copie de rezervă completă trebuie restaurate, plus datele din toate copiile de rezervă incrementale ulterioare. În acest caz, spre deosebire de copierea diferențială, fișierele modificate sau noi nu le înlocuiesc pe cele vechi, ci sunt adăugate în medii independent.

Copierea incrementală se face cel mai adesea folosind utilitarul rsync. Cu ajutorul acestuia, puteți economisi spațiu de stocare dacă numărul de modificări pe zi nu este foarte mare. Dacă fișierele modificate au marime mare, apoi vor fi copiate complet fără a înlocui versiunile anterioare.

Procesul de backup folosind rsync poate fi împărțit în următorii pași:

1. Este compilată o listă de fișiere de pe serverul redundant și din stocare, sunt citite metadate (permisiuni, timp de modificare etc.) sau o sumă de control (când se folosește cheia —checksum) pentru fiecare fișier.
2. Dacă metadatele fișierelor diferă, atunci fișierul este împărțit în blocuri și se calculează o sumă de control pentru fiecare bloc. Blocurile care diferă sunt încărcate în stocare.
3. Dacă în timpul numărării sume de control sau transferul unui fișier, i s-a făcut o modificare, backup-ul acestuia se repetă de la început.
4. În mod implicit, rsync transferă date prin SSH, ceea ce înseamnă că fiecare bloc de date este criptat suplimentar. Rsync poate fi rulat și ca un daemon și poate transfera date fără criptare folosind protocolul său.

Cu mai mult informatii detaliate Puteți afla mai multe despre cum funcționează rsync pe site-ul oficial.

Pentru fiecare fișier, rsync are performanțe foarte bune un numar mare de operațiuni. Dacă există o mulțime de fișiere pe server sau dacă procesorul este încărcat puternic, atunci viteza de backup va fi redusă semnificativ.

Din experiență putem spune că problemele pe discurile SATA (RAID1) încep după aproximativ 200G de date pe server. De fapt, totul, desigur, depinde de numărul de inoduri. Și în fiecare caz, această valoare se poate deplasa într-o direcție sau alta.

După un anumit moment, timpul de execuție al backupului va fi foarte lung sau pur și simplu nu va fi finalizat într-o zi.

Pentru a nu compara toate fișierele, există lsyncd. Acest demon colectează informații despre fișierele modificate, de ex. vom avea deja o listă cu ele pregătită pentru rsync în avans. Cu toate acestea, ar trebui să se țină cont de faptul că pune o sarcină suplimentară subsistemului de disc.

Backup diferențial

La diferenţialÎntr-o copie de rezervă, fiecare fișier care s-a modificat de la ultima copie de rezervă completă este copiat de fiecare dată. Copierea diferențială accelerează procesul de recuperare. Tot ce aveți nevoie este cel mai recent backup complet și cel mai recent diferențial. Copiile de rezervă diferențiale sunt în creștere în popularitate, deoarece toate copiile fișierelor sunt făcute la anumite momente în timp, ceea ce, de exemplu, este foarte important atunci când sunt infectate cu viruși.

Backup-ul diferențial se realizează, de exemplu, utilizând un utilitar precum rdiff-backup. Când lucrați cu acest utilitar, apar aceleași probleme ca și în cazul backup-urilor incrementale.

În general, dacă efectuați o căutare completă a fișierelor atunci când căutați diferențe de date, problemele acestui tip de backup sunt similare cu problemele cu rsync.

Am dori să reținem separat că, dacă în schema dvs. de rezervă fiecare fișier este copiat separat, atunci merită să ștergeți/excludeți fișierele de care nu aveți nevoie. De exemplu, acestea ar putea fi cache-uri CMS. Astfel de cache conțin de obicei o mulțime de fișiere mici, a căror pierdere nu va afecta funcţionare corectă Server.

Backup complet

O copie de rezervă completă afectează de obicei întregul sistem și toate fișierele. Backup-urile săptămânale, lunare și trimestriale implică crearea unei copii complete a tuturor datelor. Acest lucru se face de obicei în zilele de vineri sau în weekend la copiere volum mare datele nu afectează activitatea organizației. Backup-urile ulterioare, efectuate de luni până joi până la următoarea copie de rezervă completă, pot fi diferențiate sau incrementale, în primul rând pentru a economisi timp și spațiu de stocare. O copie de rezervă completă ar trebui efectuată în conformitate cu macar săptămânal.

Cele mai multe publicații conexe recomandă să efectuați o copie de siguranță completă o dată sau de două ori pe săptămână și să utilizați copii de siguranță incrementale și diferențiate în restul timpului. Există un motiv pentru un astfel de sfat. În cele mai multe cazuri, o copie de rezervă completă o dată pe săptămână este suficientă. Este logic să-l rulați din nou dacă nu aveți capacitatea de a-l actualiza pe partea de stocare backup completși pentru a asigura corectitudinea copiei de rezervă (acest lucru poate fi necesar, de exemplu, în cazurile în care, dintr-un motiv sau altul, nu aveți încredere în scripturile sau software-ul de backup pe care îl aveți.

De fapt, o copie de rezervă completă poate fi împărțită în 2 părți:

1. Backup complet la nivel de sistem de fișiere;
2. Backup complet la nivel de dispozitiv.

Să ne uităm la ele caracteristici De exemplu:
root@komarov:~# df -h Dimensiunea sistemului de fișiere Utilizat Utilizare disponibilă% Montat pe /dev/mapper/komarov_system-root 3.4G 808M 2.4G 25% / /dev/mapper/komarov_system-home 931G 439G 493G 48% /home ude 4.0K 383M 1% /dev tmpfs 107M 104K 107M 1% /run tmpfs 531M 0 531M 0% /tmp niciunul 5.0M 0 5.0M 0% /run/lock none 531M 0 0 531M 0 531M/vshmda 22M 109M 17% /pornire

Vom rezerva doar /casa. Orice altceva poate fi restaurat rapid manual. Puteți, de asemenea, să implementați un server cu un sistem de gestionare a configurației și să vă conectați /home-ul nostru.

Backup complet la nivel de sistem de fișiere

Reprezentant tipic: gunoi.

Utilitarul creează o „dump” a sistemului de fișiere. Puteți crea nu numai o copie de rezervă completă, ci și o copie incrementală. dump funcționează cu tabelul de inoduri și „înțelege” structura fișierului (deci fișierele rare sunt comprimate).
Eliminarea unui sistem de fișiere care rulează este „prost și periculoasă”, deoarece sistemul de fișiere se poate schimba în timpul creării depozitului. Acesta trebuie creat dintr-un instantaneu (puțin mai târziu vom discuta mai detaliat caracteristicile de lucru cu instantanee), un sistem de fișiere montat sau înghețat.

Această schemă depinde și de numărul de fișiere, iar timpul de execuție al acesteia va crește odată cu cantitatea de date de pe disc. În același timp, dump are o viteză de operare mai mare decât rsync.
Dacă trebuie să restaurați nu întreaga copie de rezervă, ci, de exemplu, doar câteva fișiere corupte accidental), recuperarea acestor fișiere cu utilitarul de restaurare poate dura prea mult timp

Backup complet la nivel de dispozitiv

1. mdraid si DRBD
   De fapt, RAID1 este configurat cu un disc/raid pe server și unitate de rețeași din când în când (pe baza frecvenței backup-urilor) disc suplimentar sincronizat cu discul/raid-ul principal de pe server.

   Cel mai mare plus este viteza. Durata sincronizării depinde doar de numărul de modificări efectuate în ultima zi.
   Acest sistem de backup este folosit destul de des, dar puțini oameni realizează că copiile de rezervă obținute cu ajutorul lui pot fi ineficiente și iată de ce. Când sincronizarea discului este completă, discul care conține copia de rezervă este deconectat. Dacă, de exemplu, avem un DBMS care rulează care scrie date în disc local porțiuni, stochând date intermediare în cache, nu există nicio garanție că vor ajunge chiar pe discul de rezervă. ÎN cel mai bun scenariu vom pierde unele dintre datele modificate. Prin urmare, astfel de backup-uri cu greu pot fi considerate fiabile.

2. LVM+dd
   Instantaneele sunt un instrument minunat pentru crearea unor copii de rezervă consistente. Înainte de a crea un instantaneu, trebuie să resetați memoria cache a FS și software-ul dvs. la subsistemul disc.

De exemplu, numai cu MySQL ar arăta astfel:
$ sudo mysql -e "FLUSH TABLES WI READ LOCK;" $ sudo mysql -e "FLUSH LOGS;" $ sudo sync $ sudo lvcreate -s -p r -l100%free -n %s_backup /dev/vg/%s $ sudo mysql -e "DEBLOCARE TABELE;"

* Colegii spun povești despre modul în care „blocarea de citire” a cuiva a dus uneori la blocaje, dar în memoria mea acest lucru nu s-a întâmplat niciodată.

Backup-urile DBMS pot fi create separat (de exemplu, folosind jurnalele binare), eliminând astfel timpul de nefuncționare în timpul resetărilor cache-ului. De asemenea, puteți crea depozite în stocare lansând o instanță DBMS acolo. Copierea de rezervă a diferitelor SGBD este un subiect pentru publicații separate.

Puteți copia un instantaneu folosind reluarea (de exemplu, rsync cu un patch pentru copierea dispozitivelor blocate bugzilla.redhat.com/show_bug.cgi?id=494313), puteți bloca cu bloc și fără criptare (netcat, ftp). Puteți transfera blocuri sub formă comprimată și le puteți monta în stocare folosind AVFS și puteți monta o partiție cu copii de siguranță prin SMB pe server.

Comprimarea elimină problemele legate de viteza de transmisie, aglomerarea canalelor și spațiul de stocare. Dar, totuși, dacă nu utilizați AVFS în stocare, atunci vă va lua mult timp să restaurați doar o parte a datelor. Dacă utilizați AVFS, veți întâlni „umiditatea” acestuia.
O alternativă la blocarea compresiei este squashfs: puteți monta, de exemplu, o partiție Samba pe server și puteți rula mksquashfs, dar acest utilitar funcționează și cu fișiere, de exemplu. depinde de cantitatea lor.

În plus, atunci când se creează squashfs, se irosește destul de multă memorie RAM, ceea ce poate duce cu ușurință la apelarea oom-killer.

Siguranță

Este necesar să te protejezi de o situație în care stocarea sau serverul tău este piratat. Dacă serverul este piratat, atunci este mai bine ca utilizatorul care scrie date acolo să nu aibă drepturi de ștergere/modificare a fișierelor din stocare.
Dacă stocarea este piratată, atunci este de asemenea recomandabil să limitați la maximum drepturile utilizatorului de rezervă pe server.

Dacă canalul de rezervă poate fi interceptat, atunci este necesară criptarea.

Concluzie

Fiecare sistem de rezervă are propriile sale avantaje și dezavantaje. În acest articol, am încercat să evidențiem câteva dintre nuanțe atunci când alegem un sistem de rezervă. Sperăm că vor ajuta cititorii noștri.

Ca urmare, atunci când alegeți un sistem de rezervă pentru proiectul dvs., trebuie să efectuați teste ale tipului de rezervă selectat și să acordați atenție:

• timpul de rezervă în stadiul curent al proiectului;
• timpul de rezervă în cazul în care există mult mai multe date;
• sarcina canalului;
• încărcarea pe subsistemul disc de pe server și în stocare;
• timpul pentru a restabili toate datele;
• timpul de recuperare pentru o pereche de fișiere;
• nevoia de consecvență a datelor, în special a bazelor de date;
• consumul de memorie și prezența apelurilor oom-killer;

Ca soluții de rezervă, puteți utiliza supload și stocarea noastră în cloud.
Cititorii care nu pot lăsa comentarii aici sunt invitați să ni se alăture pe blog.

Etichete: Adăugați etichete

ALEXEY BEREZHNOY, Administrator de sistem. Domenii principale de activitate: virtualizare și rețele eterogene. Un alt hobby pe lângă scrierea de articole este popularizarea software-ului liber

Backup
Teorie și practică. rezumat

Pentru a organiza cel mai eficient un sistem de rezervă, trebuie să construiți o strategie reală pentru salvarea și restaurarea informațiilor

Backup (sau, așa cum se mai numește, backup - din cuvântul englezesc „backup”) este proces importantîn viața oricărei structuri IT. Este o parașuta pentru salvare în cazul unui dezastru neprevăzut. În același timp, backup-ul este folosit pentru a crea un fel de arhivă istorică a activităților de afaceri ale unei companii pe o anumită perioadă de viață. Lucrul fără o rezervă este ca și cum ai trăi sub cerul liber - vremea se poate înrăutăți în orice moment și nu există unde să te ascunzi. Dar cum să-l organizezi corect pentru a nu pierde date importante și pentru a nu cheltui sume fantastice de bani pe el?

De obicei, articolele pe tema organizării backup-urilor se concentrează în principal pe solutii tehnice, și doar ocazional se acordă atenție teoriei și metodologiei de organizare a stocării datelor.

Acest articol se va concentra pe exact opusul: accentul se va concentra pe concepte generale, A mijloace tehnice vor fi atinse doar ca exemple. Acest lucru ne va permite să facem abstracție de la hardware și software și să răspundem la două întrebări principale: „De ce facem asta?”, „Putem face acest lucru mai rapid, mai ieftin și mai fiabil?”

Scopurile și obiectivele backupului

În procesul de organizare a unui backup, sunt stabilite două sarcini principale: restaurarea infrastructurii în caz de defecțiuni (Disaster Recovery) și menținerea unei arhive de date pentru a oferi ulterior accesul la informațiile din perioadele trecute.

Un exemplu clasic de copie de rezervă pentru Disaster Recovery este imaginea partiției de sistem server creată de program Acronis True Imagine.

Un exemplu de arhivă ar fi descărcarea lunară a bazelor de date din 1C, înregistrate pe casete și stocarea ulterioară într-un loc special destinat.

Există mai mulți factori care diferențiază o copie de rezervă pentru recuperare rapida din arhiva:

• Perioada de stocare a datelor. Pentru copiile de arhivă durează destul de mult. În unele cazuri, este reglementat nu numai de cerințele de afaceri, ci și de lege. Aveți copii pentru recuperare în caz de dezastru este relativ mic. De obicei creează una sau două (cu cerințe de fiabilitate sporite) copii de rezervă pentru Disaster Recovery cu un interval maxim de o zi sau două, după care sunt suprascrise cu altele noi. În cazuri deosebit de critice, este posibil mai mult actualizări frecvente backup pentru recuperare în caz de dezastru, de exemplu, o dată la câteva ore.
• Acces rapid la date. Viteza de acces la o arhivă pe termen lung nu este critică în majoritatea cazurilor. De obicei, necesitatea de a „strânge datele pentru perioada” apare în momentul reconcilierii documentelor, reveniți la versiunea anterioara etc., adică nu în modul de urgență. Un alt lucru este recuperarea în caz de dezastru, când datele necesare și performanța serviciului trebuie returnate cât mai curând posibil. În acest caz, viteza de acces la backup este un indicator extrem de important.
• Compoziția informațiilor copiate.În mod obișnuit, copia de rezervă conține numai date despre utilizator și despre companie pentru o perioadă specificată. În plus față de aceste date, copia destinată recuperării în caz de dezastru conține fie imagini de sistem, fie copii ale setărilor sistemului de operare și ale aplicațiilor software, precum și alte informații necesare recuperării.

Uneori este posibil să combinați aceste sarcini. De exemplu, un an de „instantanee” complete lunare server de fișiere, plus modificările făcute în timpul săptămânii. True Image este un instrument potrivit pentru crearea unei astfel de copii de rezervă.

Cel mai important lucru este să înțelegeți clar de ce se face rezervarea. Permiteți-mi să vă dau un exemplu: un server SQL critic a eșuat din cauza unei erori de matrice de discuri. Avem pe stoc pe cel potrivit Hardware, deci soluția problemei a fost doar restaurarea software-ului și a datelor. Conducerea companiei pune o întrebare de înțeles: „Când va începe să funcționeze?” – și este neplăcut surprins să afle că va dura patru ore întregi pentru a se recupera. Faptul este că pe toată durata de viață a serverului, numai bazele de date au fost făcute în mod regulat copii de siguranță, fără a ține cont de necesitatea de a restaura serverul însuși cu toate setările, inclusiv software SGBD în sine. Mai simplu spus, eroii noștri au salvat doar bazele de date și au uitat de sistem.

Să-ți dau un alt exemplu. De-a lungul întregii perioade de activitate, tânărul specialist a creat, folosind programul ntbackup, o singură copie a serverului de fișiere sub Control Windows Server 2003, inclusiv datele și starea sistemului într-un folder partajat pe alt computer. Din cauza penuriei spatiu pe disc această copie a fost în mod constant suprascrisă. După ceva timp, i s-a cerut să restaureze o versiune anterioară a unui raport cu mai multe pagini, care a fost deteriorat când a fost salvat. Este clar că, neavând istoricul arhivat cu Shadow Copy dezactivat, nu a putut finaliza această solicitare.

Pe o notă Copie Shadow, literalmente - " copie umbră" Se asigură că copiile instantanee ale sistemului de fișiere sunt create în așa fel încât modificările ulterioare ale originalului să nu aibă efect asupra lor. Cu această funcție este posibil să creați mai multe copii ascunse fisier pentru anumită perioadă timp, precum și copii de rezervă din mers ale fișierelor deschise pentru scriere. Serviciul Shadow Copy este responsabil pentru operarea Shadow Copy. Starea sistemului, literal – „starea sistemului”. System State Copy creează copii de rezervă ale componentelor critice sisteme de operare Familia Windows. Acest lucru vă permite să restaurați un sistem instalat anterior după distrugere. Când copiați starea sistemului, registry, boot și alte fișiere importante pentru sistem sunt salvate, inclusiv cele pentru recuperare Director activ, baza de date Certificate Service, baza de date COM+Class Registration, directoare SYSVOL. În sistemele de operare UNIX, un analog indirect al copierii stării sistemului salvează conținutul directoarelor /etc, /usr/local/etc și al altor fișiere necesare pentru a restabili starea sistemului.

Ce rezultă din aceasta: trebuie să utilizați ambele tipuri de backup: atât pentru recuperarea în caz de dezastru, cât și pentru stocarea arhivă. În acest caz, este necesar să se determine lista resurselor copiate, timpul de execuție al sarcinilor, precum și unde, cum și pentru cât timp vor fi stocate copiile de rezervă.

Cu cantități mici de date și o infrastructură IT nu foarte complexă, puteți încerca să combinați ambele sarcini într-una singură, de exemplu, să faceți o copie zilnică completă a tuturor partiții de discși baze de date. Dar este mai bine să distingem două obiective și să selectați mijloacele potrivite pentru fiecare dintre ele. În consecință, se folosește un instrument diferit pentru fiecare sarcină, deși există și soluții universale, cum ar fi pachetul Acronis True Image sau programul ntbackup

Este clar că atunci când se definesc scopurile și obiectivele backup-ului, precum și soluțiile de implementare, este necesar să se pornească de la cerințele afacerii.

Când implementați o sarcină de recuperare în caz de dezastru, puteți utiliza diferite strategii.

În unele cazuri, este necesară restaurarea directă a sistemului la metalul gol. Acest lucru se poate face, de exemplu, folosind programe Acronis True Image inclus cu modulul Universal Restore. În acest caz, configurația serverului poate fi readusă în funcțiune într-un timp foarte scurt. Pe termen scurt. De exemplu, este foarte posibil să recuperați o partiție cu un sistem de operare de 20 GB dintr-o copie de rezervă în opt minute (cu condiția ca copia de rezervă să fie accesibilă printr-o rețea de 1 Gb/s).

Într-o altă opțiune, este mai convenabil să „reveniți” pur și simplu setările la sistemul nou instalat, cum ar fi, de exemplu, copierea fișierelor de configurare din folderul /etc și altele în sisteme asemănătoare UNIX (în Windows aceasta corespunde aproximativ copierii și recuperare sistem Stat). Desigur, cu această abordare, serverul va fi pus în funcțiune nu mai devreme de când sistemul de operare a fost instalat și restaurat. setările necesare, ceea ce va dura mult mai mult termen lung. Dar, în orice caz, decizia cu privire la ce fel de recuperare în caz de dezastru ar trebui să fie provine din nevoile afacerii și constrângerile de resurse.

Diferența fundamentală dintre sistemele de backup și redundanță redundante

Acesta este altul interes Întreabă pe care aş dori să ating. Sistemele de redundanță ale echipamentelor redundante înseamnă introducerea unei anumite redundanțe în hardware pentru a menține funcționalitatea în cazul unei defecțiuni bruște a uneia dintre componente. Un exemplu excelent în acest caz este o matrice RAID (Redundant Array of Independent Disks). În cazul unei defecțiuni a unui disc, puteți evita pierderea de informații și le puteți înlocui în siguranță, salvând date datorită organizării specifice a matricei de discuri în sine (citiți mai multe despre RAID în).

Am auzit fraza: „Avem echipamente foarte fiabile, avem matrice RAID peste tot, așa că nu avem nevoie de copii de rezervă.” Da, desigur, aceeași matrice RAID va proteja datele de distrugere dacă una nu reușește hard disk. Dar din coruperea datelor virus de calculator sau acest lucru nu vă va salva de acțiunile inepte ale utilizatorului. RAID nu vă va salva dacă sistemul de fișiere se prăbușește ca urmare a unei reporniri neautorizate.

Apropo Importanța distingerii sistemelor de backup de sistemele redundante ar trebui evaluată atunci când se elaborează un plan de copiere a datelor, indiferent dacă este vorba despre o organizație sau computere de acasă. Întrebați-vă de ce faceți copii. Dacă despre care vorbim despre backup, înseamnă salvarea datelor în timpul unei acțiuni accidentale (intenționate). Redundanța redundantă face posibilă salvarea datelor, inclusiv a copiilor de rezervă, în cazul defecțiunii echipamentului. Acum există multe dispozitive ieftine pe piață care oferă backup fiabil folosind matrice RAID sau tehnologii cloud(de ex. Amazon S3). Se recomandă utilizarea simultană a ambelor tipuri de backup a informațiilor. Andrei Vasiliev, CEO Qnap Rusia

Permiteți-mi să vă dau un exemplu. Există cazuri în care evenimentele se dezvoltă conform următorului scenariu: atunci când un disc eșuează, datele sunt restaurate printr-un mecanism de redundanță, în special, folosind sumele de control salvate. În acest caz, există o scădere semnificativă a performanței, serverul se îngheață și controlul este aproape pierdut. Administrator de sistem, nevăzând altă cale de ieșire, repornește serverul cu o repornire la rece (cu alte cuvinte, dă clic pe „RESETARE”). Ca urmare a unei astfel de supraîncărcări live, apar erori ale sistemului de fișiere. Cel mai bun lucru de care se poate aștepta în acest caz este muncă îndelungată programe de verificare a discului pentru a restabili integritatea sistemului de fișiere. În cel mai rău caz, trebuie să-ți iei rămas bun Sistemul de fișiereși fiți nedumerit de întrebarea unde, cum și în ce interval de timp puteți restabili datele și performanța serverului.

Nu veți putea evita backup-urile chiar dacă aveți o arhitectură de cluster. Cluster de failover, de fapt, menține funcționalitatea serviciilor care îi sunt încredințate în cazul în care unul dintre servere eșuează. În cazul problemelor de mai sus, cum ar fi, atac de virus sau coruperea datelor din cauza notoriului „factor uman”, niciun cluster nu vă poate salva.

Singurul lucru care poate acționa ca o copie de rezervă inferioară pentru recuperarea în caz de dezastru este prezența unei oglinzi server de rezervă cu replicare constantă a datelor de pe serverul principal pe cel de rezervă (după principiul Primar  Standby). În acest caz, dacă serverul principal eșuează, sarcinile sale vor fi preluate de cel de rezervă și nici măcar nu va trebui să transferați date. Dar un astfel de sistem este destul de costisitor și necesită forță de muncă de organizat. Să nu uităm de necesitatea unei replici constante.

Devine clar că o astfel de soluție este rentabilă numai în cazul serviciilor critice cu cerințe ridicate de toleranță la erori și timp minim de recuperare. De regulă, astfel de scheme sunt utilizate în organizații foarte mari, cu o cifră de afaceri ridicată a mărfurilor și a numerarului. Și această schemă este un înlocuitor inferior pentru backup, deoarece, oricum, dacă datele sunt deteriorate de un virus informatic, acțiunile utilizatorului inepte sau munca incorecta aplicația, datele și software-ul de pe ambele servere pot fi afectate.

Și, desigur, niciun sistem de backup redundant nu va rezolva problema menținerii unei arhive de date pentru o anumită perioadă.

Conceptul de „fereastră de rezervă”

Efectuarea unei copii de rezervă pune o sarcină grea pe serverul pentru care faceți backup. Acest lucru este valabil mai ales pentru subsistemul disc și conexiuni de retea. În unele cazuri, când procesul de copiere are o prioritate destul de mare, acest lucru poate duce la indisponibilitatea anumitor servicii. În plus, copierea datelor în momentul efectuării modificărilor este asociată cu dificultăți semnificative. Desigur, există mijloace tehnice pentru a evita problemele menținând integritatea datelor în acest caz, dar, dacă este posibil, este mai bine să evitați o astfel de copiere din mers.

Soluția pentru rezolvarea acestor probleme descrise mai sus sugerează de la sine: amânarea începerii procesului de creare a copiei la o perioadă de timp inactivă, când influența reciprocă a sistemului de rezervă și a altor sisteme care rulează va fi minimă. Această perioadă de timp se numește „fereastră de rezervă”. De exemplu, pentru o organizație care operează sub formula 8x5 (cinci zile lucrătoare de opt ore pe săptămână), o astfel de „fereastră” este de obicei weekend-uri și orele de noapte.

Pentru sistemele care funcționează conform formulei 24x7 (toată săptămâna non-stop), perioada de activitate minimă este utilizată ca atare perioadă, când nu există încărcare mare pe servere.

Tipuri de backup

Pentru a evita costurile materiale inutile la organizarea backup-urilor și, de asemenea, dacă este posibil, pentru a nu depăși fereastra de backup, au fost dezvoltate mai multe tehnologii de backup, care sunt utilizate în funcție de situația specifică.

Backup complet (sau backup complet)

Este metoda principală și fundamentală de a crea copii de rezervă, în care matricea de date selectată este copiată în întregime. Acesta este cel mai complet și mai fiabil tip de backup, deși este cel mai scump. Dacă este necesară salvarea mai multor copii de date, volumul total stocat va crește proporțional cu numărul acestora. Pentru a preveni astfel de risipă, se folosesc algoritmi de compresie, precum și o combinație a acestei metode cu alte tipuri de backup: incremental sau diferențial. Și, desigur, o copie de rezervă completă este indispensabilă atunci când trebuie să pregătiți o copie de rezervă pentru restaurarea rapidă a sistemului de la zero.

Copie incrementală

Spre deosebire de o copie de rezervă completă, în acest caz nu sunt copiate toate datele (fișiere, sectoare etc.), ci doar cele care s-au modificat de la ultima copie. Pentru a determina timpul de copiere, puteți utiliza diverse metode De exemplu, sistemele care rulează familia de sisteme de operare Windows utilizează un atribut de fișier corespunzător (bitul de arhivă) care este setat atunci când fișierul a fost modificat și șters de programul de backup. Alte sisteme pot folosi data la care fișierul a fost modificat. Este clar că o schemă care utilizează acest tip de backup va fi incompletă dacă nu se efectuează din când în când o copie de rezervă completă. Când restaurați complet sistemul, trebuie să faceți restaurarea de la ultimul exemplar create de copiere de rezervă completă, apoi „strângeți” una câte una datele din copiile incrementale în ordinea în care au fost create.

La ce se folosește acest tip de copiere? În cazul creării de copii de arhivă, este necesar să se reducă volumele consumate pe dispozitivele de stocare (de exemplu, reducerea numărului de suporturi pe bandă utilizate). Acest lucru va minimiza, de asemenea, timpul necesar pentru finalizarea sarcinilor de backup, care poate fi extrem de important în condițiile în care trebuie să lucrați într-un program încărcat 24x7 sau să pompați volume mari de informații.

Există o avertizare la copierea incrementală pe care trebuie să o știți. Recuperarea pas cu pas returnează necesarul fișiere șterseîn perioada de recuperare. Să vă dau un exemplu. Să presupunem că o copie de rezervă completă este efectuată în weekend, iar una incrementală în zilele lucrătoare. Utilizatorul a creat un fișier luni, l-a schimbat marți, l-a redenumit miercuri și l-a șters joi. Deci, cu o recuperare secvenţială, pas cu pas, a datelor pentru o perioadă săptămânală, vom primi două fişiere: cu numele vechi marţi înainte de redenumire şi cu un nume nou creat miercuri. Acest lucru sa întâmplat deoarece au fost stocate diferite copii incrementale versiuni diferite același fișier și, eventual, toate variantele vor fi restaurate. Prin urmare, atunci când restaurați secvențial datele dintr-o arhivă „ca atare”, este logic să rezervați mai mult spațiu pe disc, astfel încât fișierele șterse să poată încăpea și ele.

Backup diferențial

Diferă de incremental prin faptul că datele sunt copiate din ultimul moment al backupului complet. Datele sunt stocate în arhivă în mod „cumulat”. Pe sistemele din familia Windows, acest efect este realizat prin faptul că bitul de arhivă nu este resetat în timpul copierii diferențiale, astfel încât datele modificate ajung în copie de arhivă până când o copie completă resetează biții de arhivă.

Datorită faptului că fiecare exemplar nou, creat în acest fel, conține date din precedentul, acest lucru este mai convenabil pentru recuperare totală date la momentul accidentului. Pentru a face acest lucru, aveți nevoie doar de două copii: cea completă și ultima dintre cele diferențiale, astfel încât să puteți readuce datele la viață mult mai repede decât derularea treptată a tuturor incrementelor. În plus, acest tip de copiere este lipsit de caracteristicile de copiere incrementală menționate mai sus, atunci când, cu o recuperare completă, fișierele vechi, ca o pasăre Phoenix, renasc din cenușă. Există mai puțină confuzie.

Dar copie diferenţială pierde semnificativ în creșterea în economisirea spațiului necesar. Deoarece fiecare copie nouă stochează date din cele anterioare, volumul total de date rezervate poate fi comparabil cu o copie completă. Și, desigur, atunci când planificați programul (și calculați dacă procesul de backup se va potrivi în fereastra de timp), trebuie să luați în considerare timpul necesar pentru a crea ultima copie diferențială, cea mai groasă.

Topologie de rezervă

Să ne uităm la ce scheme de rezervă există.

Schema descentralizata

Miezul acestei scheme este un anumit general resursă de rețea(vezi Fig. 1). De exemplu, un folder partajat sau un server FTP. De asemenea, este necesar un set de programe de backup, care din când în când descarcă informații de pe servere și stații de lucru, precum și din alte obiecte de rețea (de exemplu, fișierele de configurare de la routere) la această resursă. Aceste programe sunt instalate pe fiecare server și funcționează independent unul de celălalt. Un avantaj incontestabil este ușurința de implementare a acestei scheme și costul redus al acesteia. Potrivit pentru copierea programelor mijloace regulate, încorporat în sistemul de operare sau software, cum ar fi un SGBD. De exemplu, acesta ar putea fi programul ntbackup pentru familia Windows, programul tar pentru sisteme de operare asemănătoare UNIX sau un set de scripturi care conțin comenzi de server SQL încorporate pentru descărcarea bazelor de date în fișierele de rezervă. Un alt avantaj este capacitatea de utilizare diverse programeși sisteme, atâta timp cât toți pot accesa resursa țintă pentru stocarea copiilor de rezervă.

Dezavantajul este stângăcia acestei scheme. Deoarece programele sunt instalate independent unul de celălalt, fiecare trebuie configurat separat. Este destul de dificil să țineți cont de particularitățile programului și să distribuiți intervale de timp pentru a evita competiția pentru resursa țintă. Monitorizarea este, de asemenea, dificilă; procesul de copiere de pe fiecare server trebuie monitorizat separat de alții, ceea ce, la rândul său, poate duce la costuri ridicate ale forței de muncă.

Prin urmare, această schemă este utilizată în rețele mici, precum și într-o situație în care este imposibil să se organizeze o schemă de backup centralizată folosind mijloacele disponibile. Mai mult descriere detaliata Această diagramă și organizarea practică pot fi găsite în.

Backup centralizat

Spre deosebire de schema anterioară, în acest caz se utilizează un model ierarhic clar, care lucrează pe principiul client-server. ÎN varianta clasica programe speciale de agent sunt instalate pe fiecare computer, iar un modul de server este instalat pe serverul central pachete software. Aceste sisteme au și o consolă de management backend specializată. Schema de control este următoarea: din consolă creăm sarcini pentru copierea, restaurarea, colectarea informațiilor de sistem, diagnosticare și așa mai departe, iar serverul oferă agenților instructiunile necesare pentru a efectua operațiunile specificate.

Acesta este principiul prin care lucrează majoritatea oamenilor. sisteme populare sisteme de backup, cum ar fi Symantec Backup Exec, CA Bright Store ARCServe Backup, Bacula și altele (vezi Figura 2).

În plus față de diferiți agenți pentru majoritatea sistemelor de operare, există dezvoltări pentru backup-ul bazelor de date populare și sisteme corporative de exemplu pentru MS SQL Server, MS Exchange, Oracle Database și așa mai departe.

Pentru absolut firme miciîn unele cazuri, puteți încerca o versiune simplificată a schemei de backup centralizată fără utilizarea programelor agent (vezi Fig. 3). Această schemă poate fi utilizată și dacă nu este implementat un agent special pentru software-ul de rezervă utilizat. În schimb, modulul server va folosi deja serviciile existente si servicii. De exemplu, „excluderea” datelor din ascunse foldere partajate pe servere Windows sau copiați fișiere prin SSH de pe servere care rulează sisteme UNIX. Această schemă are limitări foarte semnificative legate de problemele de salvare a fișierelor deschise pentru scriere. Ca urmare a unor astfel de actiuni deschide fișiere fie va fi ratat și nu va fi inclus în copia de rezervă, fie va fi copiat cu erori. Există diverse soluții pentru această problemă, cum ar fi rularea din nou a lucrării pentru a copia numai fișierele deschise anterior, dar niciuna nu este de încredere. Prin urmare, această schemă este potrivită pentru utilizare numai în anumite situații. De exemplu, în organizatii mici, lucrând în modul 5x8, cu angajați disciplinați care salvează modificările și închid fișierele înainte de a merge acasă. Pentru a organiza o astfel de schemă centralizată trunchiată, care funcționează exclusiv în Mediul Windows, ntbackup funcționează bine. Dacă trebuie să utilizați o schemă similară în medii eterogene sau exclusiv între computere UNIX, vă recomand să priviți spre Backup PC (vezi).

Figura 4. Schema de backup mixtă

Ce este off-site?

În lumea noastră turbulentă și în schimbare, pot avea loc evenimente care pot provoca consecințe neplăcute pentru infrastructura IT și afaceri în ansamblu. De exemplu, un incendiu într-o clădire. Sau o defecțiune a bateriei de încălzire centrală în camera serverelor. Sau furtul banal de echipamente și componente. O metodă pentru a evita pierderea de informații în astfel de situații este de a stoca copii de rezervă într-o locație departe de locația principală a hardware-ului serverului. În acest caz, este necesar să se prevadă cale rapidă acces la datele necesare pentru recuperare. Metoda descrisă se numește off-site (cu alte cuvinte, stocarea copiilor în afara teritoriului întreprinderii). Practic, se folosesc două metode de organizare a acestui proces.

Scrierea datelor pe suporturi amovibile și mutarea lor fizică. În acest caz, trebuie să aveți grijă de fonduri livrare rapidă media înapoi în caz de eșec. De exemplu, depozitați-le într-o clădire învecinată. Avantajul acestei metode este capacitatea de a organiza acest proces fără dificultăți. Dezavantajul este dificultatea de a returna suportul media și însăși nevoia de a transfera informații pentru stocare, precum și riscul de a deteriora mediul în timpul transportului.

Copierea datelor într-o altă locație printr-o legătură de rețea. De exemplu, folosind un tunel VPN prin Internet. Avantajul în acest caz este că nu este nevoie să transportați media cu informații undeva, dezavantajul este necesitatea de a folosi un canal suficient de larg (de regulă, acesta este foarte scump) și de a proteja datele transmise (de exemplu, folosind același VPN). Dificultăți emergente de transmisie volume mari datele pot fi reduse semnificativ folosind algoritmi de compresie sau tehnologia de deduplicare.

Merită menționat separat măsurile de securitate la organizarea stocării datelor. În primul rând, trebuie avut grijă să se asigure că suporturile de date sunt amplasate într-o zonă sigură și că sunt luate măsuri pentru a preveni citirea datelor. de către străini. De exemplu, utilizați un sistem de criptare, încheiați acorduri de nedivulgare și așa mai departe. Dacă se utilizează medii amovibile, datele de pe acesta trebuie, de asemenea, să fie criptate. Sistemul de etichetare utilizat nu ar trebui să ajute atacatorul în analiza datelor. Este necesar să se folosească o schemă de numerotare fără chip pentru marcarea purtătorilor de nume fișierele transferate. Când transmiteți date prin rețea, este necesar (așa cum a fost deja scris mai sus) să utilizați metode sigure transmisie de date, de exemplu, tunel VPN.

Am discutat principalele puncte atunci când organizăm o copie de rezervă. Următoarea parte va discuta recomandări metodologice și va oferi exemple practice pentru a crea sistem eficient Rezervă copie.

1. Descrierea copiei de rezervă sistem Windows, inclusiv starea sistemului - http://www.datamills.com/Tutorials/systemstate/tutorial.htm.
2. Descrierea Shadow Copy - http://ru.wikipedia.org/wiki/Shadow_Copy.
3. Site-ul oficial Acronis – http://www.acronis.ru/enterprise/products.
4. Descrierea ntbackup - http://en.wikipedia.org/wiki/NTBackup.
5. Berezhnoy A. Optimizarea funcționării MS SQL Server. //Administrator de sistem, Nr. 1, 2008 – p. 14-22 ().
6. Berezhnoy A. Organizam un sistem de rezervă pentru birouri mici și mijlocii. //Administrator de sistem, Nr. 6, 2009 – p. 14-23 ().
7. Markelov A. Linux care păzește Windows. Revizuirea și instalarea sistemului de backup BackupPC. //Administrator de sistem, Nr. 9, 2004 – P. 2-6 ().
8. Descrierea VPN– http://ru.wikipedia.org/wiki/VPN.
9. Deduplicarea datelor - http://en.wikipedia.org/wiki/Data_deduplication.

In contact cu

De la dezastre naturale și provocate de om, acțiuni ale intrușilor. Aceste tehnologii sunt utilizate în mod activ în infrastructurile IT ale organizațiilor de diferite industrii și dimensiuni.

Clasificare de rezervă

În funcție de caracterul complet al informațiilor stocate

• Rezervare completă(Copie de rezervă completă) - creare arhiva de rezervă toata lumea fișiere de sistem, incluzând de obicei starea sistemului, registry și alte informații necesare pentru restaurarea completă a stațiilor de lucru. Adică, nu numai fișierele sunt copiate, ci și toate informațiile necesare funcționării sistemului.
• Rezervare suplimentară(Copie de rezervă incrementală) - crearea unei arhive de rezervă din toate fișierele care au fost modificate de la backupul complet sau incremental precedent.
• Rezervare diferențială(Copie de rezervă diferențială) - crearea unei arhive de rezervă din toate fișierele care au fost modificate de la backupul complet precedent.
• Rezervare selectivă(Copie de rezervă selectivă) - crearea unei arhive de rezervă numai din fișierele selectate.

Prin metoda de accesare a mass-media

• Backup operațional(Copia de rezervă online) - crearea unei arhive de rezervă pe un mediu conectat permanent (direct sau prin rețea).
• Rezervare offline(Copie de rezervă offline) - stocarea unei copii de rezervă suporturi amovibile, casetă sau cartuş, care trebuie instalate în unitate înainte de utilizare.

Reguli pentru lucrul cu sistemele de rezervă

Atunci când utilizați orice tehnologie de backup, ar trebui să respectați câteva reguli fundamentale, respectarea cărora va asigura siguranța maximă a datelor în cazul unor situații neprevăzute.

• Pre-planificare. Toate componentele infrastructurii de backup trebuie luate în considerare în procesul de planificare, iar toate aplicațiile, serverele și tendințele capacității de stocare primară nu trebuie ignorate.
• Stabilire ciclu de viațăși calendarul operațiunilor. Toate sarcinile legate de backup trebuie să fie documentate și efectuate conform programului. Mai jos este o listă de sarcini care trebuie îndeplinite zilnic:
  • monitorizarea sarcinilor;
  • rapoarte de eșec și succes;
  • analiza și rezolvarea problemelor;
  • manipularea benzilor și gestionarea bibliotecii;
  • programarea sarcinilor.
• Revizuirea zilnică a jurnalelor procesului de backup. Deoarece fiecare eșec de backup poate duce la multe dificultăți, trebuie să verificați progresul procesului de backup cel puțin în fiecare zi.
• Protejați-vă baza de date sau directorul de rezervă. Fiecare aplicație de backup își menține propria bază de date, a cărei pierdere ar putea însemna pierderea copiilor de rezervă.
• Definiți zilnic o fereastră de timp de rezervă. Dacă timpii de execuție a lucrărilor încep să depășească fereastra de timp alocată, acesta este un semn că sistemul se apropie de limitele de capacitate sau că există legături slabe în performanță. Detectarea la timp a unor astfel de semne poate preveni defecțiunile ulterioare mai mari ale sistemului.
• Localizarea și conservarea sistemelor și volumelor „externe”. Este necesar să verificați personal dacă copiile de rezervă corespund așteptărilor dvs., bazându-vă în primul rând pe observațiile dvs., mai degrabă decât pe rapoartele programului.
• Centralizarea și automatizarea maximă posibilă a backupului. Consolidarea mai multor sarcini de backup într-una singură simplifică foarte mult procesul de backup.
• Crearea si suportul de rapoarte deschise, rapoarte despre probleme deschise. A avea un jurnal al problemelor nerezolvate poate ajuta la rezolvarea lor cât mai repede posibil și, în consecință, la optimizarea procesului de backup.
• Încorporarea copiei de rezervă în procesul de control al schimbării sistemului.
• Consultatii cu furnizorii. Ar trebui să se asigure că sistemul implementat îndeplinește pe deplin așteptările organizației.

Tehnologii de backup

Siguranță

De obicei, backup-urile au loc automat. Accesul la date necesită de obicei privilegii ridicate. Deci, procesul care oferă backup rulează de dedesubt cont cu privilegii ridicate - aici se strecoară un anumit risc. Citește articolul