Capitolul 7. Copierea de rezervă și restaurarea datelor utilizând Acronis True Image Home Există multe produse diferite pe piață astăzi pentru realizarea de copii de rezervă și restaurarea datelor și le-am întâlnit deja pe unele dintre ele în

Backup-ul datelor este o funcție esențială pentru fiecare utilizator responsabil de computer. Nu este nimic mai rău decât să fii conștient, stând în fața unui computer, că rezultatul muncii tale lunare sau fișierele importante care nu pot fi restaurate tocmai s-au pierdut.

Datele au deseori un preț ridicat. Și nu contează dacă sunt fișiere personale sau informații care sunt folosite pentru muncă. Să ne dăm seama ce funcții pentru backup și recuperarea datelor au echipat dezvoltatorii Microsoft cea mai recentă versiune a sistemului lor de operare - Windows 10 și, de asemenea, să luăm în considerare posibilitatea de a face backup pentru recuperarea datelor folosind programe de la terți.

Backup de date: ce este?

Backup fișier

Auzim uneori despre necesitatea de a „crea o copie de rezervă a computerului”. Dar a spune acest lucru nu este în întregime corect, deoarece există două modalități de a face copii de rezervă ale datelor. În primul rând, crearea unei copii de rezervă a fișierelor, cu ajutorul căreia puteți crea copii ale fișierelor și folderelor individuale stocate pe un computer sau pe orice alt mediu de stocare. Fiecare utilizator care are date importante pe computer ar trebui să le facă copii de rezervă pe un hard disk extern în cazul în care sursa originală este pierdută sau ștearsă.

Backup de sistem

O altă modalitate de a crea copii de rezervă a datelor este cunoscută sub numele de System Backup sau System Image. Aceasta este o modalitate mai complexă de a face copii de siguranță ale datelor, deoarece în acest caz vorbim despre crearea unei copii a întregului sistem de operare al unui anumit computer, împreună cu programe, fișiere și instalări. O copie de rezervă a sistemului este utilizată pentru a-l restabili în cazul în care Windows începe să funcționeze instabil sau încetează să funcționeze cu totul.

O copie de rezervă Windows poate ocupa sute de gigaocteți de memorie. Dar folosind un software special pentru copierea de rezervă a datelor, puteți configura funcția să salveze doar modificările care au fost făcute de la ultima copie de rezervă a sistemului.

Copiere de rezervă și restaurare a datelor folosind Windows

Windows 10 are instrumente încorporate care sunt concepute pentru a crea copii de rezervă ale fișierelor și ale sistemului, precum și pentru a restaura informațiile cu ajutorul acestora. Mulți utilizatori nu le folosesc, neștiind despre existența lor sau cum să le configureze corect. Ei tind să folosească programe terțe mai des decât instrumentele încorporate în sistemul de operare.

Istoricul fișierelor

Cel mai într-un mod simplu crearea unei copii de rezervă a fișierelor și folderelor, precum și restaurarea din acestea, este Istoricul fișierelor. Cu această funcție, puteți copia datele în mod regulat, conform programului stabilit de utilizator, și le puteți salva în dur extern disc sau alt mediu de stocare extern. Copiile fișierelor pot fi, de asemenea, salvate pe hard disk-ul computerului (deși acest lucru este contrar regulii de bază de backup).

Pentru a personaliza Istoricul fișierelor, accesați meniul Start și selectați Setări. În meniul Setări care se deschide, intrați în meniul Actualizare și securitate / Serviciu de backup.

În partea dreaptă a panoului, sub Backups istoric fișiere, faceți clic pe Adăugare disc. Vi se va solicita să selectați unul dintre mediile de stocare externe conectate la computer. Selectați cel în care doriți să faceți backup datelor și setați parametrii de backup: intervalul de salvare a copiilor fișierelor și durata stocării acestora, dacă este necesar, puteți specifica un folder anume pentru o copie a fișierelor din care doriți pentru a crea sau elimina cele inutile.

În timpul creării unei copii de rezervă, Istoricul fișierelor copiază automat și toate folderele contului de utilizator: Imagini, Documente, Descărcări etc.

Această funcție poate fi dezactivată în orice moment, dar pentru ca copierea datelor specificate de utilizator să aibă loc la un interval de timp stabilit, copia de rezervă automată a fișierelor trebuie să fie activată.

În mod implicit, se face copii de siguranță ale fișierelor la fiecare oră. Timpul minim care poate fi setat este de 10 minute, maximul este Zilnic. De asemenea, puteți seta durata de stocare pentru copii de rezervă: de la o lună până când este nevoie de spațiu liber (în acest caz, copiile de rezervă mai vechi vor fi șterse automat pentru a elibera spațiu pentru copiile de rezervă noi).

Restaurarea fișierelor dintr-o copie de rezervă

Pentru a recupera fișiere de pe un disc cu o copie de rezervă a datelor, accesați Panoul de control și selectați meniul Istoric fișiere.

În coloana din stânga a ferestrei care se deschide, selectați Recuperare fișiere personale, accesați folderul și găsiți fișierul pe care doriți să îl recuperați. Pentru a restabili un fișier, faceți clic pe butonul verde de mai jos și specificați calea pentru a-l restaura. Puteți selecta versiunile de rezervă ale fișierelor după dată și oră apăsând butoanele săgeți stânga și dreapta.

Serviciu cloud OneDrive

O altă modalitate de a vă proteja de pierderea fișierelor importante este să le transferați pe stocarea în cloud și să le sincronizați cu computerul. Există multe astfel de depozite: Dropbox, Google drive etc. Dar o caracteristică a celor mai recente versiuni de Windows (10, 8, 8.1) este prezența propriului serviciu cloud al Microsoft încorporat în sistemul de operare, care se numește OneDrive.

Când folosesc unul dintre serviciile cloud, de obicei creează un folder pe discul computerului sub propriul nume, fișierele din care se sincronizează. V ultimele versiuni folderul Windows OneDrive există implicit, adică serviciul este disponibil pentru fiecare utilizator imediat după instalarea sistemului de operare.

Orice fișier. care va fi salvat în acest folder va fi imediat copiat în stocarea în cloud și sincronizat cu acesta. De asemenea, utilizatorul poate accesa fișierele din acest folder de pe orice alt dispozitiv, trebuie doar să accesați contul OneDrive de pe acesta.

Punct de recuperare

O altă parte a backupului și recuperării Date Windows 10, există recuperare fișiere de sistemși starea de sănătate a sistemului de operare. Crearea și restaurarea unei copii de siguranță a sistemului de operare este un proces mai complicat decât cu fișierele personale și folderele utilizator. Dar pentru aceasta, Windows 10 oferă o funcție specială - Restaurare sistem. Cu ajutorul acestuia, utilizatorul poate restabili sistemul de operare să funcționeze, „revenire” la starea inițială salvată - punctul de recuperare.

În mod implicit, funcția de restaurare din sistemul de operare nu este activată. Pentru a-l putea folosi, trebuie configurat. System Restore funcționează prin crearea de puncte de restaurare, cu ajutorul cărora starea Windows este salvată la un moment dat. Împreună cu setările și starea sistemului de operare, punctul de recuperare include aplicații instalate(De exemplu, Microsoft Office) și drivere de dispozitiv (de exemplu, o placă video).

Utilizatorul poate crea un punct de restaurare în orice moment convenabil. De asemenea, este creat automat dacă o aplicație este instalată pe computer sau sunt descărcate actualizări de sistem etc. Dar rețineți că Restaurarea sistemului nu restaurează fișierele personale ale utilizatorului.

Dacă începeți să observați că sistemul de operare funcționează defectuos sau cu defecțiuni și erori, atunci puteți rula unul dintre punctele de restaurare salvate anterior și Windows va reveni la starea din momentul creării sale.

Pentru a face acest lucru, accesați Panoul de control și selectați meniul Restore / System Restore Settings / Configurare, cu ajutorul căruia puteți activa și configura funcția.

Pentru a restaura Windows dintr-un punct de restaurare, accesați Panoul de control și selectați meniul Restaurare / Executare Restaurare sistem, selectați Punctul de restaurare dorit și faceți clic pe Următorul.

Imaginea sistemului

Probabil cea mai simplă și complexă caracteristică de backup din Windows este o caracteristică numită System Image.

Folosind această opțiune, puteți crea o „duplicare” a întregului disc al computerului, inclusiv Windows 10, precum și toate programele și datele personale ale utilizatorului. Imaginea sistemului este salvată pe un hard disk extern, de pe care, dacă este necesar sau dacă computerul eșuează, este implementată înapoi pe hard diskul computerului. Ca rezultat, utilizatorul primește o versiune funcțională a sistemului de operare, împreună cu programe și fișiere.

Aceasta este foarte functie utila, dar dezavantajul său este că utilizatorul nu are capacitatea de a restaura fișiere individuale din imaginea sistemului, ca din Istoricul fișierelor. Puteți extinde complet întreaga imagine doar. Prin urmare, utilizatorii folosesc adesea aceste funcții în paralel.

Pentru a crea o imagine de sistem, accesați Panoul de control și selectați meniul Backup și restaurare fișier. În coloana din stânga, faceți clic pe Creare imagine de sistem și selectați unitatea pe care doriți să o salvați. Vă rugăm să rețineți că imaginea sistemului este de obicei mare.

Pentru a vă restaura sistemul dintr-o imagine de sistem, accesați Setări sistem / Actualizare și securitate / Recuperare și selectați Opțiuni de pornire personalizate. După repornirea Windows 10, selectați Restaurare sistem dintr-o imagine din meniul furnizat.

Alt software de backup și restaurare fișiere Windows 10

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 sistemul de backup, trebuie să construiți o strategie reală pentru salvarea și restaurarea informațiilor.

Backup-ul (sau, cum se mai spune, backup - din cuvântul englezesc „backup”) este un proces important în viața oricărei structuri IT. Aceasta este o parașuta de 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 companiei pe o anumită perioadă de viață. Lucrul fără o rezervă este ca și cum ai trăi în aer liber - vremea se poate deteriora în orice moment și nu există unde să te ascunzi. Dar cum să-l organizezi corect pentru a nu pierde date importante și a cheltui sume fantastice pe el?

De obicei, articolele pe tema organizării backup-urilor se ocupă în principal de 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 este pus pe concepte generale, iar instrumentele 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 să o facem mai rapid, mai ieftin și mai fiabil?”

Scopurile și obiectivele backupului

În procesul de organizare a unui backup sunt stabilite două sarcini principale: recuperarea 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 backup de recuperare în caz de dezastru este o imagine a partiției de sistem a unui server creată de Acronis True Image.

Un exemplu de arhivă poate fi o descărcare lunară a bazelor de date din 1C, înregistrate pe casete cu stocare ulterioară într-un loc special destinat.

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

• Perioada de stocare a datelor. Pentru copiile de arhivă, este destul de lung. În unele cazuri, este reglementat nu numai de cerințele de afaceri, ci și de lege. Copiile de recuperare în caz de dezastru au o cantitate relativ mică. De obicei, se creează una sau două (cu cerințe de fiabilitate sporite) copii de rezervă pentru Recuperarea în caz de dezastru cu un interval maxim de o zi sau două, după care sunt suprascrise cu altele noi. În cazuri deosebit de critice, este, de asemenea, posibil să actualizați mai des backup-ul de 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, revenirea la versiunea anterioara etc., adică nu în regim de urgență. Un alt lucru este recuperarea în caz de dezastru, când datele necesare și performanța serviciilor trebuie returnate cât mai curând posibil. În acest caz, viteza de acces la backup este extrem de importantă.
• Compoziția informațiilor copiate. Copia arhivată conține de obicei numai date despre utilizator și despre companie pentru perioada specificată. Copia de recuperare în caz de dezastru conține, în plus față de aceste date, fie imagini de sistem, fie copii ale setărilor sistemului de operare și ale software-ului aplicației, precum și alte informații necesare pentru recuperare.

Uneori este posibil să combinați aceste sarcini. De exemplu, un set anual de „instantanee” complete lunare ale serverului de fișiere, plus modificările efectuate în timpul săptămânii. True Image este potrivit ca instrument 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 s-a prăbușit din cauza unei erori de matrice de discuri. In stoc exista un potrivit Hardware, deci singura soluție la problemă a fost recuperarea 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 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 restabilirii serverului î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ă vă mai dau un exemplu. De-a lungul carierei, tânărul specialist a creat o singură copie a unui server de fișiere care rulează Windows Server 2003 utilizând programul ntbackup, incluzând datele și starea sistemului într-un folder partajat pe alt computer. Din cauza lipsei de spațiu pe disc, această copie a fost în mod constant suprascrisă. După un timp, i s-a cerut să restaureze versiunea anterioară a raportului cu mai multe pagini, care a fost deteriorată la salvare. Este clar că, neavând istoric de arhivă cu Shadow Copy dezactivat, nu a putut îndeplini această solicitare.

Care concluzie urmează: trebuie să utilizați ambele tipuri de copii de rezervă: pentru recuperarea în caz de dezastru și pentru stocarea arhivei. În acest caz, este imperativ să se determine lista resurselor copiate, timpul de execuție al sarcinilor, precum și unde, cum și cât timp vor fi stocate backup-urile.

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țiilor și bazelor de date de disc. Dar este totuși mai bine să distingem cele două capete și să alegeți mijloacele potrivite pentru fiecare dintre ele. În consecință, se utilizează un instrument separat pentru fiecare sarcină, deși există soluții universale, cum ar fi același pachet 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.

Există diferite strategii care pot fi utilizate pentru a implementa o sarcină de recuperare în caz de dezastru.

În unele cazuri, este necesară o recuperare directă a sistemului la metalul gol. Acest lucru se poate face, de exemplu, folosind Acronis True Image inclus cu Universal Restore. În acest caz, configurația serverului poate fi readusă în funcțiune într-un timp foarte scurt. De exemplu, este foarte posibil să ridicaț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 arhivă să fie disponibilă într-o rețea de 1 Gb/s).

Într-un alt caz, este mai convenabil să „reveniți” pur și simplu setările la sistemul nou instalat, cum ar fi copierea fișierelor de configurare din folderul / etc în sisteme similare UNIX (în Windows, acest lucru este aproximativ echivalent cu copierea și restaurarea sistemului Stat). Desigur, cu această abordare, serverul va fi pus în funcțiune nu mai devreme de instalarea sistemului de operare și restabilirea setărilor necesare, ceea ce va dura mult mai mult. termen lung... Dar, în orice caz, decizia despre ce să fie Recuperare în caz de dezastru provine din nevoile afacerii și din constrângerile de resurse.

Diferența fundamentală dintre sistemele de rezervă și cele redundante

Aceasta este o altă întrebare interesantă pe care aș dori să o ridic. Sistemele de redundanță ale echipamentelor redundante înseamnă introducerea unei anumite redundanțe în hardware pentru a rămâne operațional în cazul unei defecțiuni bruște a uneia dintre componente. Un exemplu grozav în acest caz este un RAID (Redundant Array of Independent Disks). În cazul unei singure defecțiuni de disc, se poate evita pierderea de informații și se poate face o înlocuire sigură, păstrând datele datorită organizării specifice a matricei de discuri în sine (citiți mai multe despre RAID în).

Am auzit fraza: „Avem echipamente foarte fiabile, există matrice RAID peste tot, deci nu avem nevoie de copii de rezervă”. Da, desigur, aceeași matrice RAID va salva datele de la distrugere dacă un hard disk se defectează. Dar aici este de la corupția datelor virus de calculator sau nu te va salva de acțiunile inepte ale utilizatorului. Nu va salva RAID chiar dacă sistemul de fișiere se blochează ca urmare a unei reporniri neautorizate.

Permiteți-mi să vă dau un exemplu. Există momente în care evenimentele se dezvoltă conform următorului scenariu: atunci când un disc se defectează, datele sunt restaurate datorită mecanismului de redundanță, în special, cu ajutorul dispozitivelor stocate. sume de control... În același timp, există o scădere semnificativă a performanței, serverul se îngheață, controlul este practic pierdut. Administrator de sistem nevăzând nicio altă cale de ieșire, repornește serverul cu o repornire la rece (cu alte cuvinte, dă clic pe „RESET”). Ca urmare a acestei supraîncărcări live, apar erori ale sistemului de fișiere. Cel mai bun lucru de așteptat în acest caz este rularea lungă a verificatorului de disc pentru a restabili integritatea sistemului de fișiere. În cel mai rău caz, va trebui să-ți iei rămas bun Sistemul de fișiereși fiți nedumerit de întrebarea unde, cum și în ce interval de timp este posibil să restabiliți datele și performanța serverului.

Nu puteți evita backup-urile chiar dacă aveți o arhitectură în cluster. Un cluster de failover, de fapt, menține operabilitatea serviciilor care îi sunt încredințate în cazul unei defecțiuni a unuia dintre servere. În cazul problemelor de mai sus, cum ar fi, atac de virus sau coruperea datelor din cauza notoriului „factor uman”, niciun cluster nu va salva.

Singurul lucru care poate acționa ca un înlocuitor de rezervă inferior pentru Disaster Recovery este un server de rezervă în oglindă cu replicare continuă a datelor de la serverul principal la backup (conform principiului Primar  Standby). În acest caz, dacă serverul principal eșuează, sarcinile acestuia vor fi preluate de cel de rezervă și nici măcar nu trebuie să transferați date. Dar un astfel de sistem este destul de costisitor și necesită timp de organizat. Nu uitați 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 banilor. Și această schemă este un substitut inferior pentru copierea de rezervă, deoarece nu contează dacă datele sunt deteriorate de un virus informatic, acțiuni inepte ale utilizatorului sau munca greșită aplicațiile, 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ă.

Fereastra de backup

Efectuarea unei copii de rezervă pune o sarcină grea pe serverul redundant. Acest lucru este valabil mai ales pentru subsistemul de disc și conexiunile de rețea. În unele cazuri, când procesul de copiere are suficient prioritate ridicată, 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.

Ieșirea la rezolvarea acestor probleme descrise mai sus sugerează de la sine: să amâne începutul procesului de creare a copiilor pentru o perioadă de timp inactivă, când influența reciprocă a sistemelor de rezervă și a altor sisteme de lucru va fi minimă. Această perioadă de timp se numește „fereastră de rezervă”. De exemplu, pentru o organizație care operează pe formula 8x5 (cinci zile de lucru 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), timpul 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 unui backup, precum și, 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. Este cea mai completă și fiabilă metodă de backup, deși este și cea 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 o 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 o recuperare 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 de rezervă. Pentru a afla timpul de copiere, puteți utiliza metode diferite de exemplu, sistemele care rulează sisteme de operare Windows folosesc atributul de fișier corespunzător (bit de arhivă), care este setat atunci când fișierul a fost modificat și șters de programul de rezervă. Pe alte sisteme, data la care a fost modificat fișierul poate fi utilizată. Este clar că o schemă care utilizează acest tip de backup va fi incompletă dacă nu efectuați o copie de rezervă completă din când în când. Când restaurați complet sistemul, trebuie să restaurați din ultima copie creată de copierea de rezervă completă și apoi să rulați datele din copiile incrementale una câte una, în ordinea creării lor.

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, să se reducă numărul de medii pe bandă utilizate). De asemenea, va permite minimizarea timpului de execuție a 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 cantități mari de informații.

Copierea incrementală are un lucru de care trebuie să fii conștient. Recuperarea pas cu pas aduce înapoi ceea ce este necesar fișiere șterseîn perioada de recuperare. Să vă dau un exemplu. Să presupunem că o copie completă este efectuată în weekend, iar o copie incrementală în zilele lucrătoare. Un utilizator a creat un fișier luni, l-a schimbat marți, l-a redenumit miercuri și l-a șters joi. Deci, cu recuperarea secvențială pas cu pas a datelor pe 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 datele dintr-o arhivă „ca atare” într-o manieră secvențială, este logic să rezervați mai mult spațiu pe disc, astfel încât fișierele șterse să se potrivească și ele.

Backup diferențial

Acesta diferă de cel incremental prin faptul că datele sunt copiate din ultimul moment al backup-ului complet. În acest caz, datele sunt plasate în arhivă „pe un total cumulat”. În sistemele din familia Windows, acest efect este obținut prin faptul că bitul de arhivă nu este șters în timpul copierii diferențiale, astfel încât datele modificate sunt incluse în copia de arhivă până când copia completă șterge biții de arhivă.

Datorită faptului că fiecare copie nouă creată în acest fel conține date din cea anterioară, este mai convenabil pentru recuperarea completă a datelor în momentul dezastrului. Pentru a face acest lucru, sunt necesare doar 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 să rulați toate incrementele pas cu pas. În plus, acest tip de copiere este lipsit de caracteristicile incrementale menționate mai sus, atunci când, după o restaurare completă, fișierele vechi, precum pasărea Phoenix, renasc din cenușă. Apare mai puțină confuzie.

Dar copierea diferențială este semnificativ inferioară copierii incrementale în ceea ce privește economisirea spațiului necesar. Deoarece fiecare copie nouă conține date din cele anterioare, cantitatea totală de date susținute poate fi comparabilă cu o copie completă. Și, bineînțeles, atunci când planificați programul (și calculați dacă procesul de backup se va încadra într-o „fereastră”) temporară, trebuie să luați în considerare timpul necesar pentru a crea ultima copie diferențială „cea mai groasă”.

Topologie de rezervă

Să luăm în considerare care sunt schemele de rezervă.

Schema descentralizata

Miezul acestei scheme este o partajare a rețelei (vezi Figura 1). De exemplu, un folder partajat sau un server FTP. De asemenea, este nevoie de un set de programe de backup, încărcând din când în când informații de pe servere și stații de lucru, precum și alte obiecte de rețea (de exemplu, fișiere de configurare de la routere) în această resursă. Aceste programe sunt instalate pe fiecare server și funcționează independent unul de celălalt. Avantajul incontestabil este simplitatea implementării acestei scheme și costul redus al acesteia. Instrumentele standard încorporate în sistemul de operare sau software-ul, cum ar fi un SGBD, sunt potrivite ca programe de copiere. De exemplu, 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 SQL Server încorporate pentru a descărca bazele de date în fișiere de rezervă. Un alt plus este capacitatea de a utiliza diverse programe și sisteme, atâta timp cât toate pot accesa resursa țintă pentru stocarea backup-urilor.

Dezavantajul este lentul acestei scheme. Deoarece programele sunt instalate independent unele de altele, trebuie să le configurați pe fiecare separat. Este destul de dificil să se țină cont de particularitățile programului și să aloce 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 celelalte, ceea ce, la rândul său, poate duce la costuri mari cu forța de muncă.

Prin urmare, această schemă este utilizată în rețelele mici, precum și într-o situație în care este imposibil să se organizeze o schemă de backup centralizată cu mijloacele disponibile. Mai mult descriere detaliata această schemă şi organizare practică se regăsesc în.

Backup centralizat

Spre deosebire de schema anterioară, în acest caz, se utilizează un model ierarhic clar care funcționează pe principiul client-server. În versiunea clasică, pe fiecare computer sunt instalate programe speciale de agenți, iar modulul server al pachetului software este instalat pe serverul central. Aceste sisteme au și o consolă dedicată de gestionare a serverului. Schema de control este următoarea: din consolă creăm sarcini de copiere, restaurare, colectare de informații despre sistem, diagnosticare și așa mai departe, iar serverul oferă agenților instrucțiunile necesare pentru a efectua aceste operațiuni.

Acesta este modul în care funcționează cele mai 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 companiile foarte mici, în unele cazuri, puteți încerca o versiune simplificată a unei scheme de backup centralizate fără a utiliza software-ul agent (vezi Figura 3). De asemenea, această schemă poate fi utilizată dacă nu este implementat un agent special pentru software-ul de rezervă utilizat. În schimb, modulul server va folosi serviciile și serviciile existente. De exemplu, „scoop” date din ascunse foldere partajate pe serverele Windows sau copiați fișierele de către Protocolul SSH de la servere care rulează sisteme UNIX. Această schemă are limitări foarte semnificative asociate cu problemele de salvare a fișierelor deschise pentru scriere. Ca urmare a unor astfel de acțiuni, fișierele deschise fie vor fi sărite și nu vor fi copiate de rezervă, fie copiate cu erori. Există diverse soluții pentru această problemă, de exemplu, reexecutarea lucrării pentru a copia numai fișierele deschise anterior, dar niciuna nu este de încredere. Prin urmare, o astfel de schemă este potrivită pentru utilizare numai în anumite situații. De exemplu, în organizațiile mici 5x8 cu angajați disciplinați care salvează modificările și închid fișierele înainte de a pleca de acasă. Pentru a organiza o astfel de schemă centralizată trunchiată, lucrând 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 volatilă, pot apărea evenimente care pot provoca consecințe neplăcute pentru infrastructura IT și afaceri în general. De exemplu, un incendiu într-o clădire. Sau o descoperire a unei baterii de încălzire centrală într-o cameră de servere. Sau furtul banal de echipamente și componente. Una dintre metodele de evitare a pierderii de informații în astfel de situații este stocarea copiilor de rezervă într-o locație îndepărtată de locația principală a echipamentului server. Î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, păstrarea copiilor în afara site-ului). 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 mijloacele de livrare rapidă a suportului media în caz de eșec. De exemplu, depozitați-le într-o clădire din apropiere. Avantajul acestei metode este capacitatea de a organiza acest proces fără nicio dificultate. Dezavantajul este dificultatea de a returna suportul media și însăși nevoia de a transfera informațiile în stocare, precum și riscul de a deteriora mediul în timpul transportului.

Copierea datelor într-o altă locație printr-un canal 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ățile întâmpinate în transferul unor cantități mari de date pot fi reduse semnificativ prin utilizarea algoritmilor de compresie sau a tehnologiei de deduplicare.

Separat, trebuie spus despre măsurile de securitate la organizarea stocării datelor. În primul rând, este necesar să ne asigurăm că purtătorii de date se află într-o zonă protejată și despre măsurile care împiedică persoanele neautorizate să citească datele. De exemplu, utilizați un sistem de criptare, încheiați un acord de nedivulgare și așa mai departe. Dacă este implicat un suport amovibil, datele de pe acesta trebuie, de asemenea, să fie criptate. În acest caz, sistemul de marcare utilizat nu ar trebui să ajute un atacator în analiza datelor. Este necesar să se folosească o schemă de numerotare fără chip pentru marcarea purtătorilor numelor fișierelor transferate. Când transferați date prin rețea, este necesar (așa cum sa menționat deja mai sus) să utilizați metode securizate de transfer de date, de exemplu, un tunel VPN.

Am acoperit principalele puncte atunci când organizăm o copie de rezervă. În partea următoare vor fi luate în considerare recomandările metodologice și exemple practice pentru a crea un sistem eficient de rezervă.

1. Descrierea copiei de rezervă în 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. A. Berezhnoy Optimizarea MS SQL Server. // Administrator de sistem, Nr. 1, 2008 - P. 14-22 ().
6. A. Berezhnoy.Organizăm un sistem de rezervă pentru birourile mici și mijlocii. // Administrator de sistem, Nr. 6, 2009 - P. 14-23 ().
7. Markelov A. Linux în paza Windows. Revizuirea și instalarea sistemului de backup BackupPC. // Administrator de sistem, Nr. 9, 2004 - S. 2-6 ().
8. Descriere VPN - http://ru.wikipedia.org/wiki/VPN.
9. Deduplicarea datelor - http://en.wikipedia.org/wiki/Data_deduplication.

In contact cu

Aproape toți clienții noștri care au implementat sisteme de backup (DBS) cred că acest lucru le-a rezolvat toate problemele. Ei au făcut tot ce le-a stat în putință pentru a se asigura că totul a fost susținut, iar în cazul unui accident, acesta a fost corect restaurat. Dar de multe ori se întâmplă așa: compania se confruntă cu o problemă serioasă, iar sistemul tradițional de backup nu permite recuperarea în timpul pe care compania îl consideră a fi țintă. De fapt, SLA-ul pe care trebuie să-l îndeplinească sistemul de rezervă nu este îndeplinit. Din păcate, în timpul muncii noastre am acumulat multe exemple triste care confirmă acest lucru. Mai jos vom da două cazuri și vom oferi sfaturi despre ce mijloace tehnice vor reduce timpul de recuperare. Alegând cazuri, ne-am oprit la exemple legate de bazele de date, unde erau stocate cele mai critice informații pentru afaceri.

Provocări cu amănuntul

Client: mare companie de asigurări.

O scurtă descriere a cauzei accidentului: eroare de personal, instalare incorectă a patch-urilor pe Oracle.

Descrierea problemei

Aceasta este o companie mare care are un departament IT matur și care investește suficient în echipamente și personal. Este suficient să spunem că Oracle DBMS a rulat pe două Oracle Exadata, distribuite pe două site-uri tehnologice, cu o soluție DR bine dezvoltată și un sistem de backup configurat.

Într-o zi tristă s-a decis să instalăm un patch pe Oracle DBMS. Din păcate, inginerul nu a citit instrucțiunile până la capăt: „Ce sunt, nu voi instala patch-ul fără o bucată de hârtie?!” - și a făcut-o greșit. Eroarea a fost observată câteva ore mai târziu, când SGBD-ul a început să se comporte ciudat și să o raporteze în jurnalele. Apoi inginerul a decis să se întoarcă înapoi. Această acțiune a imobilizat în cele din urmă ambele copii ale bazei de date (toate modificările au fost replicate în Standby) și a corupt toate datele.

Compania a rămas fără principalul său activ informativ - o bază de date prin care au funcționat toate procesele de afaceri. Afacerea practic s-a oprit.

Soluţie

Clientul a decis să restaureze dintr-o copie de rezervă. La acel moment, restaurarea unei baze de date de 5 TB (acum ~ 15 TB) a luat - atenție! - mai mult de 30 de ore!În total, după 1,5 zile, baza a fost restaurată cu o zi înainte de accident. Dar erau mai multe date! Orice altceva a fost restaurat de programatori și personal din alte sisteme ale companiei, din documentația primară (formulare de cerere, copii, scanări). A fost nevoie de încă 1,5 zile de muncă grea.

Total

2 sisteme Oracle Exadata de ultimă generație, Oracle Standby, un sistem de rezervă funcțional și 3 !!! a zilei timp de nefuncţionare complet la instalare incorectă plasture. A fost acest lucru permis conform reglementărilor companiei? Desigur că nu.

Principala problemă: lipsa instrumentelor de recuperare rapidă din erorile logice.

Cum ai fi putut evita

Pentru a atenua consecințele unor astfel de accidente, trebuie să vă deplasați în două direcții. Pe de o parte, faceți copii de rezervă mai des și, pe de altă parte, puteți recupera rapid. Următoarele produse ar putea ajuta:

Oracle FlashBack- o tehnologie care vă permite nu numai să „rulați înainte” de date noi sistem de rezervă Oracle, dar și rollback la tranzacția dorită. Cu o astfel de schemă, ar fi posibilă derularea sistemului înainte de a începe problemele cu patch-ul, ceea ce ar facilita foarte mult recuperarea datelor.

Tehnologia instantanee. Instantaneele vă permit să faceți copii de rezervă și să restaurați datele în câteva secunde. În același timp, au un efect redus asupra performanței și este posibil să faci poze destul de des (de exemplu, o dată pe oră). Astfel, a fost posibil să reveniți cu o oră și să recuperați doar o oră de date pierdute.

Protecția continuă a datelor- protectia continua a datelor. Acesta este un dispozitiv sau software proprietar care vă permite să înregistrați toate înregistrările cu posibilitatea de a reveni în orice moment. Acționează ca Oracle FlashBack, dar pentru orice date.

Caz: Eroare hardware

Client: Serviciu federal într-unul dintre subiectele Federației Ruse

O scurtă descriere a cauzei accidentului: o eroare hardware în interiorul matricei de discuri.

Descrierea problemei

De data aceasta compania are o infrastructură IT ceva mai puțin dezvoltată, dar este mai frecventă în rândul clienților noștri: nu sunt folosite matrice de discuri de nivel mediu, DBMS Oracle, Standby.

Așa cum se întâmplă adesea, vineri, când toată lumea mergea deja fericiți acasă, a avut loc o defecțiune hardware a matricei. Din cauza unei erori în firmware, dacă discul eșuează, matricea a transformat datele într-o mizerie. Din această cauză, bazele de date ale serviciului la nivel federal au încetat să funcționeze. De mai bine de o zi, clientul aștepta o soluție de la furnizorul de depozitare. După ce a analizat toate jurnalele, vânzătorul a dat concluzia: datele sunt pierdute!

Soluţie

Clientul a luat decizia de a restaura dintr-o copie de rezervă. Acest proces a durat aproximativ o zi, în ciuda tuturor ajustărilor și reglajului de performanță (baza este destul de mare). În timp ce baza de date era restaurată, copia de rezervă a jurnalelor a fost pierdută (Perioada de păstrare a fost prea mică, SRK le-a șters singur).

Mai departe - mai adânc. Compania, la fel ca multe altele, a folosit la un moment dat operațiuni neînregistrate în Oracle, ceea ce îmbunătățește serios performanța, dar nu lasă nicio șansă de recuperare decât dintr-o copie de rezervă. Adică trebuie făcut imediat după trecerea sesiunii de operații. Desigur, acest lucru a fost uitat în departamentul de întreținere de-a lungul anilor. Astfel, o parte din date s-a pierdut complet.

A mai durat câteva zile pentru a recrea complet serviciile de infrastructură - nu au existat copii de siguranță ale sistemelor de operare, binare, configurații etc.

Toate informațiile pierdute au fost colectate din documente primare (baze de date terțe, documente pe hârtie, date de pe computerele casierelor), ceea ce a durat încă 3 zile. Este posibil ca unele documente să nu fi fost niciodată recuperate.

Total

Problema matricei a cauzat pierderi de date și timp de nefuncționare pentru aproximativ o săptămână! În condiții moderne, acest lucru poate duce la falimentul companiei.

Probleme principale:

• IBS a fost configurat incorect și nu au fost efectuate restaurări de probă.
• Nu existau mijloace de recuperare promptă în caz de dezastru și sisteme redundante.
• Nu a existat un plan clar de DR.

Cum ar fi putut fi evitat acest lucru:

• Utilizați Oracle Standby situat pe o altă matrice. Acest lucru ar permite o scurtă perioadă de timp pentru a trece la o instanță de date care rulează.
• Oracle ZDLRA ar permite restaurarea bazei de date pe echipamentul de backup într-un timp mult mai scurt.
• Planificarea inteligentă a proceselor de backup și recuperare ar putea evita pierderi atât de mari și poate recupera în mai puțin de o zi.

Concluzie. Din exemplele de mai sus, se poate observa că sistemele de backup au fost instalate și configurate, dar, în ciuda acestui fapt, nu au reușit să se recupereze în intervalele de timp specificate în SLA.

Principalele probleme ale sistemelor de backup

Pe baza experienței noastre, am decis să evidențiem o serie de probleme cărora, în opinia noastră, ar trebui să li se acorde o atenție deosebită.

Backup și restabilirea vitezei

Pe acest moment viteza de backup este direct proporțională cu cantitatea de date, în timp ce toți clienții noștri au o creștere anuală a datelor de cel puțin 30%. În 3-4 ani, datele cel puțin se dublează, dar pentru unele companii această cifră este și mai mare, în timp ce viteza de backup nu se modifică deloc în același timp. Aici putem trage o concluzie simplă că acei termeni și acele SLA care erau relevante acum 3-4 ani trebuie să fie mărite de cel puțin două ori. În același timp, cerințele de afaceri pentru recuperarea datelor (RPO / RTO) sunt în continuă creștere.

Treptat, toate procesele de afaceri ale companiei sunt transferate în IT, iar documentele primare (copii și originale ale documentelor, declarații, scanări etc.) dispar. Totul se învârte în interiorul sistemelor IT, iar pierderea datelor este, de fapt, pierderea a tot. IT nu mai are loc de eroare. În cazurile pe care le-am dat, tot timpul, în timp ce datele nu erau disponibile din diverse circumstanțe, companiile nu au putut funcționa. Aceasta a dus atât la pierderi directe, când era imposibil de realizat principalul proces de afaceri al organizației, cât și la cele implicite, de exemplu, la pierderi de reputație, care nu sunt atât de ușor de măsurat în termeni monetari, dar care pe termen lung. termenul poate cauza nu mai puțin prejudiciu companiei.

Pe imagine Am reflectat observațiile mele cu privire la timpul de recuperare (RTO). Pe măsură ce datele dvs. cresc, timpul real de recuperare va crește, iar cerințele SLA devin mai stricte. Punctul din grafic în care timpul real este egal cu timpul necesar a fost deja trecut pentru majoritatea clienților.

Timp de recuperare versus volumul de date

Granularitate scăzută a recuperării

De fapt, majoritatea erorilor sunt legate de pierderea unei părți a datelor. În același timp, instrumentele tradiționale de backup vă permit să restaurați datele direct din backup, dar mai des trebuie să restaurați întregul sistem. Dacă baza ta de date are 15 TB, vei petrece câteva zile pentru asta. Nu cunoaștem clienți care au o cerință RTO (Recovery Time Objective) de 2 zile. În practica noastră, nu existau astfel de exemple când un client ar spune: „Băieți, este în regulă să vă recuperați în 2 zile, o voi tolera” - dacă administratorul ștergea accidental mai multe rânduri din baza de date. O problemă destul de comună cu care se confruntă clienții noștri: cum să extragem o mică bucată de date dintr-o copie de rezervă fără a o restaura (și fără a petrece câteva zile pe ea).

RPO excesiv (Obiectiv punct de recuperare)

Într-o lume în care hârtia primară a dispărut și totul este stocat în sistemele IT, fiecare secundă creează date pe care aș dori să le protejez imediat - chiar în momentul în care a fost creată. Dar acest lucru nu se poate face folosind sistemele clasice de backup. Pentru fiecare parte de date există o anumită perioadă lungă de timp în care aceste date există în întreaga lume într-o singură copie. Clienții noștri doresc să își protejeze datele în mod continuu, din momentul în care acestea apar. Când decideți să restaurați dintr-o copie de rezervă, cel mai probabil va trebui să recuperați o zi în urmă, apoi datele vor trebui să fie obținute din altă parte într-o zi. De regulă, este muncă îndelungată administratorilor, durând câteva zile. Odată cu evoluția cea mai negativă a evenimentelor, acest lucru poate duce la o pierdere. informatii critice... Desigur, problema nu se limitează doar la backup, ci se referă la construcția sistemului IT în ansamblu, dar subiectul SRK în acest caz este foarte important, nu poate fi neglijat.

Erori ascunse

Din păcate, încă nu există opțiuni ieftine și rapide pentru a verifica cât de bine a fost făcută backup-ul. Desigur, acest lucru se poate face cu restaurări periodice de test, dar aceasta este o operațiune foarte costisitoare din punct de vedere al efortului uman și al resurselor IT. Aceasta este munca unei echipe separate pe un hardware separat.

Din păcate, majoritatea clienților noștri nu fac asta. Se întâmplă adesea ca toată lumea să facă copii de siguranță, dar până în momentul restaurării, se dovedește că acestea nu ar fi putut fi făcute - pur și simplu nu pot fi restaurate, în ciuda funcționării corecte în exterior a RMS. Acest lucru se întâmplă din diverse motive. Acest lucru este cel mai bine ilustrat cu un exemplu. Unul dintre clienții noștri a folosit un sistem SAP cu o bază de date Oracle. Backup-ul a fost realizat de instrumentele SAP încorporate cu ajutorul unuia dintre cei mai mari furnizori SRK.

Au fost configurate două politici de backup diferite: una dintre ele a fost bazată pe fișiere - a copiat datele sistemelor de operare și setările software-ului, iar a doua - baza de date în sine. Deoarece au fost direcționați către același sistem, o listă de excluderi a fost configurată și introdusă în baza de date. Politica de fișiere a luat în considerare această listă și nu a rezervat directoarele în care se afla baza de date. Datorită particularităților arhitecturii SRK, politica de backup a bazei de date a ignorat lista de excluderi și a copiat corect datele necesare.

Într-una dintre versiunile de software, acest furnizor a remediat această „eroare”, din acea zi, ambii politicieni au început să ia în considerare lista de excluderi și să ocolească baza de date. Mai mult, acest lucru nu a afectat în niciun fel erorile din software-ul SRK, deoarece a funcționat normal: toate datele care nu sunt indicate în listă au fost copiate în mod normal. Sistemul a raportat că funcționează corect.

Astfel, totul a funcționat mai bine de șase luni. Până în acel moment, până a fost necesar să se recupereze...

Abordare nesistematică

O problemă importantă este abordarea nesistematică a problemei backup-ului. SRK a fost construit din punct de vedere istoric fie de către companie însăși, fie de către un integrator. La momentul construcției, cu siguranță a îndeplinit toate cerințele și și-a îndeplinit funcția în întregime. De-a lungul anilor, peisajul IT al companiei s-a schimbat. În același timp, sistemul de rezervă pur și simplu s-a adaptat la el pe măsură ce sistemul s-a dezvoltat și, cel mai adesea, nu a fost urmată nicio abordare sistematică, care să țină cont de importanța conformării sistemului cu indicatorii inițiali în toate etapele ulterioare. Când construiți un sistem de protecție a datelor în organizația dvs., rețineți - aceasta este doar o parte a strategiei dvs. de protecție a datelor.

Am prezentat mai multe studii de caz care demonstrează că abordarea privind protecția datelor ar trebui să fie cuprinzătoare. Din păcate, SRK este doar o parașută de rezervă, nu un glonț de argint, așa că atunci când începeți să o creați, trebuie să înțelegeți clar ce loc va ocupa în strategia globală de protecție a datelor.

Pentru a verifica cât de sistematic ați abordat problema construirii IMS, răspundeți la câteva întrebări simple:

• Aveți un model de risc construit, în cadrul căruia este precizat locul IBS?
• De ce eșecuri te protejează IBS?
• Cum vă protejați de alte riscuri (acestea pot fi nu doar soluții tehnice, ci și alte măsuri compensatorii)?
• Sunteți încrezător că sistemul se va recupera la timp?
• Ai testat asta în practică?

Soluţie

Pe baza propriei noastre experiențe și a experienței clienților noștri, am încercat să dezvoltăm o abordare care să rezolve sau să reducă semnificativ consecințele problemelor enumerate. Esența abordării noastre:

În primul rând, este necesar să se decupleze viteza de backup și de recuperare de la volumul sistemului. Producătorii de sisteme de stocare a datelor, aplicații software și RMS sugerează utilizarea unor instrumente care pot fi folosite pentru a rezolva această problemă. Mai jos le voi descrie pe cele mai promițătoare dintre ele.

Instantaneele (instantanee) vă permit să faceți copii de rezervă și să restaurați datele în câteva secunde, cu un impact redus sau deloc asupra performanței. Acest lucru se realizează prin intermediul matricei și, în același timp, SRK poate fi controlat, să fie parte din politica sa. Acest tip de backup și recuperare durează cu adevărat câteva secunde, ceea ce distinge această tehnologie de sistemele clasice cu medii alienabile.

O altă soluție ar putea fi utilizarea diferitelor instrumente de aplicație, cum ar fi Oracle Standby, DB2 HADR, MS SQL Always On. Toate aceste instrumente vă permit să aveți o copie de lucru a unui sistem de producție, detașată de original, care poate fi implementată instantaneu. Acest lucru vă permite să începeți să lucrați imediat după defecțiuni.

Al doilea este de a face posibilă restaurarea numai a datelor de care aveți nevoie. Abordarea noastră ține cont de faptul că atunci când recuperăm o parte a datelor, nu este nevoie să copiem întregul sistem ca întreg, putem recupera datele de care avem nevoie în acest moment. Acest lucru se realizează prin capacitatea de a implementa sau utiliza rapid sisteme deja implementate care conțin aceste date. Ca și în primul caz, snapshot vă permite să rezolvați această problemă (puteți deschide rapid un snapshot pe un server vecin și puteți extrage datele necesare). Aceasta include și tehnologiile de protecție continuă a datelor, de exemplu, Oracle Standby cu Flashback, soluții de protecție continuă a datelor (CDP). Acestea vă permit să implementați rapid o copie funcțională a datelor dvs momentul potrivit timp.

Când trebuie să obțineți un bloc logic, de exemplu, un rând sau un tabel de bază de date, aceste instrumente facilitează foarte mult sarcina, permițându-vă să recuperați datele necesare fără a restaura întreaga copie.

Al treilea este reducerea decalajului dintre aspectul datelor și protecția acestora. Acest lucru poate fi realizat în mai multe moduri, în funcție de specificul unui anumit caz și de gradul de importanță al datelor.

De exemplu, pentru sistemele mai puțin critice, intervalul de timp pentru backup poate fi redus la câteva ore. În acest caz, folosim instantanee. Ele pot servi ca punct de restaurare care se poate face o dată pe oră. Unele matrice moderne gestionează aceste procese suficient de bine și pot stoca suficient un numar mare de instantanee ale sistemului. Aceasta este o modalitate excelentă de ieșire dintr-o situație în care trebuie să reveniți pentru o perioadă.

Pentru cele mai critice sisteme, este posibil să nu existe deloc un interval orar - datele trebuie protejate continuu. Există mai multe soluții din această clasă, de exemplu, Oracle Standby cu FlashBack, care vă permite să anulați baza de date pentru o perioadă prin înregistrarea tuturor modificărilor. De asemenea, puteți utiliza Oracle ZDLRA PAK, care primește aproape sincron toate modificările din baza de date sau sistemele hardware și software scop general precum EMC RecoverPoint, software-ul Vision Solutions Double-Take. De asemenea, ele înregistrează toate modificările și vă permit să vă recuperați în orice moment al intervalului de timp.

Oracle Zero Data Loss Recovery Appliance (ZDLRA) trebuie menționat atunci când vine vorba de inovație în sistemele de backup și recuperare. Acest dispozitiv din familia Oracle Engineered Systems oferă capabilități de backup și recuperare rapidă pentru Oracle Database pe orice platformă și orice ediție (Enterprise și Standard). ZDLRA se bazează pe baze de date de backup virtuale (Virtual Full Backup), obținute pe baza primului backup complet și a jurnalelor de modificări ulterioare. Datorită acestor backup-uri virtuale, este posibilă restaurarea bazei de date în orice moment mult mai rapid decât în ​​cazul utilizării clasice a SRK conform schemei „o dată pe săptămână backup complet, o dată pe zi incremental”. Se poate spune că ZDLRA continuă direcția stabilită de Oracle Exadata. Exadata folosește software special pentru a implementa un sistem inovator de stocare optimizat pentru sarcinile Oracle Database. Și în ZDLRA există un Software special care optimizează backup-ul bazei de date Oracle.

Acum vorbim doar de recuperare rapidă. În cazul unor dezastre majore sau al necesității de a recupera cu mai mult timp în urmă, backup-urile convenționale rămân un instrument indispensabil. Dar in conditiile actuale este doar o parasuta de rezerva, desfasurata in ultimul moment.

Al patrulea este de a reduce erorile ascunse. Există o singură modalitate de a vă asigura că backup-ul funcționează corect - să încercați să o restaurați. Aceasta este metoda cea mai corectă și rar folosită de clienții noștri.

Dar oferim și o cale de ieșire din această situație. În primul rând, aveți instanțe de sisteme ușor de recuperat. Aceasta este din nou o poveste despre sistemele instantanee și de așteptare, care pot fi implementate și testate rapid. Va dura incomparabil mai puțin timp și efort decât „desfășurarea” întregului backup. Desigur, acest lucru nu ajută întotdeauna, dar lasă puțin mai multă speranță că în caz de urgență va fi posibilă restabilirea datelor cel puțin prin aceste mijloace.

În al doilea rând, unele SRC-uri permit testarea automată. La o anumită oră din program, puteți alerga mașini virtualeîntr-un mediu izolat și folosind algoritmi predeterminați pentru a verifica dacă datele au fost efectiv restaurate, dacă aplicația este disponibilă, dacă este consecventă și dacă răspunde la solicitările necesare. În acest fel, administratorii pot scăpa de munca de rutină îndelungată.

În al cincilea rând, transparența sistemului de rezervă. Abordarea integrată descrisă implică construirea unui sistem complex folosind o varietate de tehnologii de la diferiți producători. Sarcina de a face acest sistem cu adevărat funcțional, de a pune în el posibilitatea unor modificări și scalare ulterioară, este netrivială și poate fi rezolvată în două moduri:

• Prima modalitate este asigurată ca clientul să fie el însuși suficient de competent și să dorească să pună în funcțiune acest sistem. Aici, în calitate de integrator, ajutăm la construirea tuturor proceselor necesare, la crearea unui cadru de reglementare, la dezvoltarea tuturor instrucțiunilor și planurilor necesare, astfel încât departamentul IT al clientului să poată dezvolta și opera în mod independent sistemul în continuare. drumul cel bun... Și apoi transferați toată această bază practică de reglementări și sarcini către client sub forma unui sistem de lucru al proceselor de afaceri.

• A doua modalitate, atunci când clientul nu este sigur că va putea menține sistemul SRK în mod constant în stare de luptă, soluția va fi transferarea sistemului la externalizare parțială sau totală. Și avem astfel de clienți care folosesc cu succes acest serviciu, crescând în mod constant atât cerințele SLA, cât și amploarea implicării noastre ca externalizator IT.

Din păcate, nu există încă o rețetă universală care să rezolve problema recuperării datelor în condițiile actuale de creștere constantă și complicare a sistemelor. Doar o combinație a soluțiilor de mai sus și o abordare sistematică va permite companiilor să recupereze datele în timpul necesar afacerii.