A copia di salvezza ùn hè micca una di e tecnulugia di moda chì tutti gridanu. Hè solu deve esse in ogni cumpagnia seria, questu hè tuttu. U nostru bancu sustene parechji milla servitori - questu hè un travagliu cumplessu è interessante, è vogliu parlà di alcune di l'intricacies di questu, è ancu di cuncepzioni sbagliate tipiche riguardanti backups.
Aghju travagliatu annantu à questu tema per quasi 20 anni, di quale l'ultimi anni 2 sò stati in Promsvyazbank. À u principiu di a mo pratica, aghju fattu backups quasi manualmente, utilizendu scripts chì simpliciamente copiavanu i schedari. Allora apparsu strumenti convenienti in Windows: l'utilità Robocopy per a preparazione di fugliali è NT Backup per a copia. È solu dopu hè ghjuntu u tempu per u software specializatu, principalmente Veritas Backup Exec, chì hè issa chjamatu Symantec Backup Exec. Allora aghju avutu familiarizatu cù e backup per un bellu pezzu.
Bastamente, a copia di salvezza hè di salvà una copia di dati (macchine virtuali, applicazioni, basa di dati è schedari) solu in casu cù una certa regularità. Ogni casu di solitu si manifesta in a forma di un fallimentu hardware o logicu è porta à a perdita di dati. U scopu di un sistema di salvezza hè di riduce a perdita di l'infurmazioni. Un fallimentu hardware hè, per esempiu, un fallimentu di u servitore o di l'almacenamiento induve si trova a basa di dati. A logica hè a perdita o u cambiamentu di parte di e dati, ancu per u fattore umanu: una tavola o un schedariu hè stata sguassata accidentalmente, o un script hè stata lanciata per eseguisce una curveball. Ci hè ancu esigenze regulatorii per almacenà certi tipi di informazioni per un longu periodu, per esempiu, finu à parechji anni.
L'usu più tipicu di copia di salvezza hè a restaurazione di una copia salvata di basa di dati per implementà diversi sistemi di teste è cloni per i sviluppatori.
Ci sò parechji miti cumuni intornu à a copia di salvezza chì sò longu per dispelling. Eccu i più famosi di elli.
Mitu 1. A copia di salvezza hè stata longa solu una funzione minore in i sistemi di sicurità o di almacenamento
I sistemi di salvezza fermanu sempre una classa separata di suluzioni, è assai indipendenti. Li sò stati affidati un compitu troppu impurtante. Essenzialmente, sò l'ultima linea di difesa quandu si tratta di sicurità di dati. Allora a copia di salvezza travaglia à u so ritmu, in u so propiu calendariu. Un rapportu di ogni ghjornu hè generatu nantu à i servitori; ci sò avvenimenti chì agiscenu cum'è attivatori per u sistema di monitoraghju.
In più, u mudellu di l'accessu à u sistema di salvezza permette di delegate alcuni di i puteri à l'amministratori di i sistemi di destinazione per gestisce e copie di salvezza.
Mitu 2. Quandu ci hè RAID, a copia di salvezza ùn hè più necessariu
Indubbiamente, l'arrays RAID è a replicazione di dati sò un bonu modu per prutege i sistemi d'infurmazioni da i fallimenti di hardware, è se tenete un servitore standby, urganizà rapidamente u cambiamentu in l'eventu di fallimentu di a macchina principale.
A redundanza è a replicazione ùn vi salvanu micca da l'errori lògichi fatti da l'utilizatori di u sistema. Eccu un servitore in standby cù a registrazione ritardata - iè, pò aiutà se un errore hè rilevatu prima di sincronizà. E se u mumentu hè mancatu? Solu una copia di salvezza puntuale aiuterà quì. Se sapete chì e dati anu cambiatu eri, pudete restaurà u sistema cum'è l'avanti di aieri è estrae i dati necessarii da ellu. Cunsiderendu chì l'errori lògichi sò i più cumuni, a bona copia di salvezza antica resta un strumentu pruvucatu è necessariu.
Mitu 3. A copia di salvezza hè qualcosa chì hè fatta una volta à u mese.
A frequenza di salvezza hè un paràmetru configurabile chì dipende principalmente da i bisogni di u sistema di salvezza. Hè abbastanza pussibule di truvà dati chì quasi mai cambianu è ùn hè micca particularmente impurtante; a so perdita ùn serà micca critica per a cumpagnia.
Infatti, ponu esse salvate una volta à u mese o ancu menu spessu. Ma i dati più critichi sò salvati più spessu, secondu l'indicatore RPO (Objrective Point Recovery), chì stabilisce a perdita di dati accettabile. Questu pò esse una volta à settimana, una volta à ghjornu, o ancu parechje volte à l'ora. Per noi, questi sò logs di transazzione da u DBMS.
Quandu si mette i sistemi in u funziunamentu cummerciale, a documentazione di salvezza deve esse appruvata, chì riflette i punti principali, i rigulamenti di l'aghjurnamentu, i prucessi di ricuperazione di u sistema, i prucedure di almacenamiento di salvezza, è simili.
Mitu 4. U voluminu di copie hè in constantemente crescente è occupa ogni spaziu assignatu cumpletamente
I backups anu una durata limitata. Ùn hà micca sensu, per esempiu, per almacenà tutte e 365 copia di salvezza di ogni ghjornu in tuttu l'annu. Comu regula, hè permissibile di guardà e copie di ogni ghjornu per 2 sette, dopu chì sò rimpiazzati cù i freschi, è per u almacenamentu à longu andà a versione chì hè stata fatta prima in u mese resta. Hè, à u turnu, hè ancu guardatu per un certu tempu - ogni copia hà una vita.
Ci hè prutezzione contru a perdita di dati. A regula s'applica: prima chì una copia di salvezza hè sguassata, u prossimu deve esse creatu. Dunque, i dati ùn saranu micca sguassati se a copia di salvezza falla, per esempiu, per a indisponibilità di u servitore. Ùn sò micca solu i limiti di tempu rispettati, ma u numeru di copie in un settore hè ancu cuntrullatu. Se u sistema abbisogna chì ci deve esse duie copie di salvezza sanu, ci saranu sempre dui, è u vechju serà sguassatu solu quandu un novu terzu hè scrittu successu. Allora l'aumentu di u voluminu occupatu da l'archiviu di salvezza hè assuciatu solu cù l'aumentu di a quantità di dati prutetti è ùn dipende micca di u tempu.
Mitu 5. Quandu una copia di salvezza principia, tuttu si congela
Hè megliu dì questu: se tuttu pende, significa chì e mani di l'amministratore ùn sò micca crescenu da quì. In generale, u rendiment di salvezza dipende da parechji fatturi. Per esempiu, nantu à u funziunamentu di u sistema di salvezza stessu: quantu veloce sò l'almacenamiento di discu è e librerie di cinta. Da u funziunamentu di i servitori di u sistema di salvezza: s'ellu anu tempu per processà e dati, cumpressione è deduplicazione. È ancu nantu à a velocità di e linee di cumunicazione trà u cliente è u servitore.
A copia di salvezza pò andà à unu o più fili, secondu chì u sistema di salvezza supporta multithreading. Per esempiu, l'Oracle DBMS permette di mandà parechji filamenti, secondu u numeru di prucessori dispunibili, finu à chì a velocità di trasferimentu tocca u limitu di larghezza di banda di a rete.
Sè vo pruvate à a copia di salvezza di un gran numaru di fili, allura ci hè una chance di overload u sistema in esecuzione, veramente cumincià à rallentà. Per quessa, u nùmeru ottimali di fili hè sceltu per assicurà un rendimentu abbastanza. Se ancu a minima diminuzione di u rendiment hè critica, allora ci hè una excelente opzione quandu a copia di salvezza hè realizata micca da u servitore di produzzione, ma da u so clone - standby in terminologia di basa di dati. Stu prucessu ùn carica u sistema di travagliu principale. I dati ponu esse recuperati attraversu più fili postu chì u servitore ùn hè micca usatu per mantenimentu.
In i grandi urganisazioni, una reta separata hè creata per u sistema di salvezza in modu chì a copia di salvezza ùn hà micca affettatu a produzzione. Inoltre, u trafficu pò esse trasmessu micca per a reta, ma per u SAN.
Pruvemu ancu di distribuisce a carica cù u tempu. I backups sò realizati soprattuttu durante l'ora di travagliu: di notte, di fine settimana. Inoltre, ùn sò micca tutti cuminciati à u stessu tempu. A copia di salvezza di a macchina virtuale hè un casu particulari. U prucessu ùn hà praticamenti micca effettu nant'à u funziunamentu di a macchina stessa, cusì a copia di salvezza pò esse sparghje in tuttu u ghjornu, piuttostu cà di mette tuttu di notte. Ci sò parechje suttilità, se pigliate tuttu in contu, a copia di salvezza ùn affetterà micca u rendiment di u sistema.
Mitu 6. Lanciatu un sistema di salvezza - chì hè a tolleranza di colpa per voi
Ùn vi scurdate mai chì u sistema di salvezza hè l'ultima linea di difesa, chì significa chì ci deve esse cinque più sistemi davanti à ellu chì assicuranu a continuità, alta dispunibilità è resistenza di disastru di l'infrastruttura IT di l'impresa è i sistemi d'informazione.
Ùn ci hè nunda di sperà chì una copia di salvezza restituverà tutte e dati è risturà rapidamente u serviziu cadutu. A perdita di dati da u mumentu di a copia di salvezza finu à u mumentu di u fallimentu hè garantitu, è i dati ponu esse caricati in un novu servitore per parechje ore (o ghjorni, secondu a vostra furtuna). Dunque, hè sensu di creà sistemi full-fledged tolleranti à i difetti senza trasfurmà tuttu à a copia di salvezza.
Mitu 7. Aghju stallatu una copia di salvezza una volta è verificatu chì hà travagliatu. Tuttu ciò chì resta hè di guardà i logs
Questu hè unu di i miti più dannosi, a falsità di quale avete realizatu solu durante l'incidentu. I logs nantu à una copia di salvezza successu ùn sò micca una guaranzia chì tuttu hè andatu cum'è previstu. Hè impurtante di verificà a copia salvata in anticipu per a implementazione. Questu hè, eseguite u prucessu di ricuperazione in un ambiente di prova è fighjate u risultatu.
È un pocu di u travagliu di un amministratore di sistema
Nimu copia dati manualmente per un bellu pezzu. I SRC muderni ponu una copia di salvezza di quasi tuttu, basta à cunfigurà bè. Se un novu servitore hè statu aghjuntu, cunfigurà e pulitiche: selezziunate u cuntenutu chì serà salvatu, specificà i paràmetri di almacenamento è applicà a pianificazione.
À u listessu tempu, ci hè sempre assai travagliu per via di a larga flotta di servitori, cumprese basa di dati, sistemi di mail, clusters di macchine virtuali, è risorse di fugliale in Windows è Linux / Unix. L'impiegati chì mantenenu u sistema di salvezza ùn sò micca stati inattivi.
In l'onore di e vacanze, vogliu auguri à tutti l'amministratori nervi forti, muvimenti chjaru è spaziu infinitu per almacenà e backup!
Source: www.habr.com