Per què cal fer còpies de seguretat? Al cap i a la fi, l'equip és molt, molt fiable i, a més, hi ha "núvols" que són més fiables que els servidors físics: amb una configuració adequada, un servidor "núvol" pot sobreviure fàcilment a la fallada d'un servidor físic d'infraestructura, i des de des del punt de vista dels usuaris del servei, hi haurà un petit salt de temps, poc perceptible, en el servei. A més, la duplicació d'informació sovint requereix pagar per temps de processador, càrrega de disc i trànsit de xarxa "extra".
Un programa ideal s'executa ràpidament, no perd memòria, no té forats i no existeix.
-Desconegut
Atès que els programes encara estan escrits per desenvolupadors de proteïnes, i sovint no hi ha cap procés de prova, a més, els programes rarament es lliuren utilitzant "pràctiques recomanades" (que també són programes i, per tant, imperfectes), els administradors de sistemes sovint han de resoldre problemes que sonen breument però de manera succinta: "tornar com era", "portar la base al funcionament normal", "funciona lentament - retrocedeix" i també el meu favorit "no sé què, però arregla'l".
A més dels errors lògics que sorgeixen com a resultat del treball descuidado dels desenvolupadors, o una combinació de circumstàncies, així com un coneixement incomplet o una incomprensió de les petites característiques dels programes de creació, incloses les de connexió i del sistema, inclosos els sistemes operatius, els controladors i el microprogramari. - També hi ha altres errors. Per exemple, la majoria de desenvolupadors confien en el temps d'execució, oblidant-se completament de les lleis físiques, que encara són impossibles d'eludir amb programes. Això inclou la fiabilitat infinita del subsistema de disc i, en general, de qualsevol subsistema d'emmagatzematge de dades (incloent-hi la memòria cau i la memòria cau del processador!), i el temps de processament zero al processador, i l'absència d'errors durant la transmissió a la xarxa i durant el processament a la xarxa. processador, i latència de xarxa, que és igual a 0. No heu de descuidar el famós termini, perquè si no el compliu a temps, hi haurà problemes pitjors que els matisos del funcionament de la xarxa i del disc.
Què fer amb els problemes que s'amplien amb tota força i es pengen sobre dades valuoses? No hi ha res que substitueixi els desenvolupadors vius i no és un fet que sigui possible en un futur proper. D'altra banda, només uns quants projectes han aconseguit demostrar plenament que el programa funcionarà com es pretenia, i no necessàriament serà possible prendre i aplicar l'evidència a altres projectes similars. A més, aquestes proves requereixen molt de temps i requereixen habilitats i coneixements especials, i això pràcticament minimitza la possibilitat d'utilitzar-los tenint en compte els terminis. A més, encara no sabem com utilitzar una tecnologia ultraràpida, barata i infinitament fiable per emmagatzemar, processar i transmetre informació. Aquestes tecnologies, si existeixen, es troben en forma de conceptes o, la majoria de vegades, només en llibres i pel·lícules de ciència ficció.
Els bons artistes copien, els grans artistes roben.
—Pablo Picasso.
Les solucions més reeixides i les coses sorprenentment senzilles solen passar on es troben conceptes, tecnologies, coneixements i camps de la ciència absolutament incompatibles a primera vista.
Per exemple, els ocells i els avions tenen ales, però malgrat la similitud funcional, el principi de funcionament en alguns modes és el mateix i els problemes tècnics es resolen de manera similar: ossos buits, ús de materials forts i lleugers, etc. els resultats són completament diferents, encara que molt semblants. Els millors exemples que veiem en la nostra tecnologia també estan en gran part manllevats de la natura: els compartiments a pressió de vaixells i submarins són una analogia directa amb els anèl·lids; construir matrius de raid i comprovar la integritat de les dades - duplicar la cadena d'ADN; així com òrgans aparellats, independència del treball dels diferents òrgans del sistema nerviós central (automatització del cor) i reflexos - sistemes autònoms a Internet. Per descomptat, prendre i aplicar solucions ja fetes "de front" està ple de problemes, però qui sap, potser no hi ha altres solucions.
Si hagués sabut on cauries, hauria posat palletes!
—Refrany popular bielorús
Això vol dir que les còpies de seguretat són vitals per a aquells que volen:
- Ser capaç de restaurar el funcionament dels vostres sistemes amb un temps d'inactivitat mínim, o fins i tot sense fer-ho
- Actueu amb valentia, perquè en cas d'error sempre hi ha la possibilitat de retrocedir
- Minimitzar les conseqüències de la corrupció intencionada de dades
Aquí teniu una petita teoria
Qualsevol classificació és arbitrària. La natura no classifica. Classifiquem perquè ens és més convenient. I classifiquem segons dades que també prenem arbitràriament.
—Jean Bruler
Independentment del mètode d'emmagatzematge físic, l'emmagatzematge lògic de dades es pot dividir en dues maneres d'accedir a aquestes dades: bloc i fitxer. Aquesta divisió s'ha vist molt difuminada recentment, perquè no existeix l'emmagatzematge lògic de blocs, així com de fitxers. Tanmateix, per senzillesa, suposarem que existeixen.
L'emmagatzematge de dades de blocs implica que hi ha un dispositiu físic on les dades s'escriuen en determinades parts fixes, blocs. S'accedeix als blocs des d'una adreça determinada; cada bloc té la seva pròpia adreça dins del dispositiu.
Normalment, una còpia de seguretat es fa copiant blocs de dades. Per garantir la integritat de les dades, en el moment de la còpia se suspèn l'enregistrament de nous blocs, així com els canvis dels existents. Si prenem una analogia del món ordinari, el més proper és un armari amb cel·les numerades idèntiques.
L'emmagatzematge de dades de fitxers basat en el principi del dispositiu lògic és proper a l'emmagatzematge de blocs i sovint s'organitza a la part superior. Les diferències importants són la presència d'una jerarquia d'emmagatzematge i noms llegibles pels humans. Una abstracció s'assigna en forma d'un fitxer, una àrea de dades anomenada, així com un directori, un fitxer especial en el qual s'emmagatzemen descripcions i accés a altres fitxers. Els fitxers es poden subministrar amb metadades addicionals: temps de creació, marques d'accés, etc. Les còpies de seguretat solen fer-se d'aquesta manera: busquen fitxers modificats i després els copien a un altre emmagatzematge de fitxers amb la mateixa estructura. La integritat de les dades normalment s'implementa per l'absència de fitxers en què s'escriuen. Es fa una còpia de seguretat de les metadades del fitxer de la mateixa manera. L'analogia més propera és una biblioteca, que té seccions amb diferents llibres, i també té un catàleg amb els noms dels llibres llegibles pels humans.
Recentment, de vegades es descriu una altra opció, a partir de la qual, en principi, va començar l'emmagatzematge de dades de fitxers, i que té les mateixes característiques arcaiques: l'emmagatzematge de dades d'objectes.
Es diferencia de l'emmagatzematge de fitxers perquè no té més d'un nidificació (esquema pla) i els noms dels fitxers, tot i que són llegibles pels humans, encara són més adequats per al processament per màquines. Quan es realitzen còpies de seguretat, l'emmagatzematge d'objectes sovint es tracta de manera similar a l'emmagatzematge de fitxers, però de vegades hi ha altres opcions.
— Hi ha dos tipus d'administradors de sistemes, els que no fan còpies de seguretat i els que JA en fan.
- En realitat, n'hi ha de tres tipus: també n'hi ha que comproven que les còpies de seguretat es poden restaurar.-Desconegut
També val la pena entendre que el procés de còpia de seguretat de dades en si es realitza mitjançant programes, de manera que té els mateixos inconvenients que qualsevol altre programa. Per eliminar (no eliminar!) la dependència del factor humà, així com les característiques, que individualment no tenen un efecte fort, però junts poden donar un efecte notable, l'anomenat regla 3-2-1. Hi ha moltes opcions sobre com desxifrar-lo, però m'agrada més la següent interpretació: s'han d'emmagatzemar 3 conjunts de les mateixes dades, s'han d'emmagatzemar 2 conjunts en formats diferents i 1 conjunt s'ha d'emmagatzemar en un emmagatzematge remot geogràficament.
El format d'emmagatzematge s'ha d'entendre de la següent manera:
- Si hi ha una dependència del mètode d'emmagatzematge físic, canviem el mètode físic.
- Si hi ha una dependència del mètode d'emmagatzematge lògic, canviem el mètode lògic.
Per aconseguir el màxim efecte de la regla 3-2-1, es recomana canviar el format d'emmagatzematge de les dues maneres.
Des del punt de vista de la preparació d'una còpia de seguretat per al seu propòsit (restaurar la funcionalitat), es fa una distinció entre còpies de seguretat "calentes" i "fredes". Els calents només es diferencien dels freds en una cosa: estan immediatament a punt per al seu ús, mentre que els freds requereixen alguns passos addicionals per a la recuperació: desxifrat, extracció de l'arxiu, etc.
No confongueu les còpies en calent i en fred amb les còpies en línia i fora de línia, que impliquen un aïllament físic de les dades i, de fet, són un signe més de la classificació dels mètodes de còpia de seguretat. Per tant, una còpia fora de línia (no connectada directament al sistema on s'ha de restaurar) pot ser calenta o freda (en termes de preparació per a la recuperació). Una còpia en línia pot estar disponible directament allà on cal restaurar-la, i la majoria de vegades fa calor, però també n'hi ha de fredes.
A més, no oblideu que el procés de creació de còpies de seguretat en si no sol acabar amb la creació d'una còpia de seguretat, i pot haver-hi un nombre bastant gran de còpies. Per tant, cal distingir entre còpies de seguretat completes, és a dir. aquelles que es poden restaurar independentment d'altres còpies de seguretat, així com còpies diferencials (incrementals, diferencials, decrementals, etc.): aquelles que no es poden restaurar de manera independent i requereixen la restauració preliminar d'una o més còpies de seguretat.
Les còpies de seguretat incrementals diferencials són un intent d'estalviar espai d'emmagatzematge de còpies de seguretat. Així, només s'escriuen a la còpia de seguretat les dades modificades de la còpia de seguretat anterior.
Es creen decrementals diferencials amb la mateixa finalitat, però d'una manera lleugerament diferent: es fa una còpia de seguretat completa, però només s'emmagatzema la diferència entre la còpia fresca i l'anterior.
Per separat, val la pena considerar el procés de còpia de seguretat sobre emmagatzematge, que admet l'absència d'emmagatzematge de duplicats. Així, si escriviu còpies de seguretat completes a sobre, només s'escriuran realment les diferències entre les còpies de seguretat, però el procés de restauració de les còpies de seguretat serà similar a la restauració des d'una còpia completa i totalment transparent.
Qui custodiet ipsos custodes?
(Qui vigilarà els mateixos vigilants? - lat.)
És molt desagradable quan no hi ha còpies de seguretat, però és molt pitjor si sembla que s'ha fet una còpia de seguretat, però en restaurar-la resulta que no es pot restaurar perquè:
- La integritat de les dades d'origen s'ha vist compromesa.
- L'emmagatzematge de còpia de seguretat està danyat.
- La restauració funciona molt lentament; no podeu utilitzar dades que s'hagin recuperat parcialment.
Un procés de còpia de seguretat ben construït ha de tenir en compte aquests comentaris, especialment els dos primers.
La integritat de les dades d'origen es pot garantir de diverses maneres. Els més utilitzats són els següents: a) crear instantànies del sistema de fitxers a nivell de bloc, b) "congelar" l'estat del sistema de fitxers, c) un dispositiu de bloc especial amb emmagatzematge de versions, d) enregistrament seqüencial de fitxers o blocs. També s'apliquen sumes de control per garantir que les dades es verifiquen durant la recuperació.
La corrupció de l'emmagatzematge també es pot detectar mitjançant sumes de control. Un mètode addicional és l'ús de dispositius especialitzats o sistemes de fitxers en els quals no es poden canviar les dades ja enregistrades, però sí que se'n poden afegir de nous.
Per accelerar la recuperació, la recuperació de dades s'utilitza amb diversos processos de recuperació, sempre que no hi hagi cap coll d'ampolla en forma de xarxa lenta o sistema de disc lent. Per evitar la situació amb dades recuperades parcialment, podeu dividir el procés de còpia de seguretat en subtasques relativament petites, cadascuna de les quals es realitza per separat. Així, és possible restaurar el rendiment de manera coherent mentre es preveu el temps de recuperació. Aquest problema es troba més sovint en el pla organitzatiu (SLA), per la qual cosa no ens atendrem en detall.
Un expert en espècies no és qui les afegeix a cada plat, sinó qui mai hi afegeix res de més.
-IN. Sinyavski
Les pràctiques respecte al programari utilitzat pels administradors de sistemes poden variar, però els principis generals segueixen sent, d'una manera o altra, els mateixos, en particular:
- Es recomana fer servir solucions ja fetes.
- Els programes han de funcionar de manera previsible, és a dir. No hi hauria d'haver cap característiques no documentades ni colls d'ampolla.
- Configurar cada programa hauria de ser tan senzill que no haureu de llegir el manual o el full de trucs cada vegada.
- Si és possible, la solució hauria de ser universal, perquè els servidors poden variar molt en les seves característiques de maquinari.
Hi ha els següents programes habituals per fer còpies de seguretat des de dispositius de bloc:
- dd, familiar per als veterans de l'administració del sistema, també inclou programes similars (el mateix dd_rescue, per exemple).
- Utilitats integrades en alguns sistemes de fitxers que creen un abocament del sistema de fitxers.
- Utilitats omnívores; per exemple partclone.
- Decisions pròpies, sovint de propietat; per exemple, NortonGhost i posteriors.
Per als sistemes de fitxers, el problema de còpia de seguretat es resol parcialment mitjançant mètodes aplicables als dispositius de bloc, però el problema es pot resoldre de manera més eficient utilitzant, per exemple:
- Rsync, un programa i protocol de propòsit general per sincronitzar l'estat dels sistemes de fitxers.
- Eines d'arxiu incorporades (ZFS).
- Eines d'arxiu de tercers; el representant més popular és quitrà. N'hi ha d'altres, per exemple, dar - un reemplaçament del quitrà destinat als sistemes moderns.
Val la pena esmentar per separat les eines de programari per garantir la coherència de les dades en crear còpies de seguretat. Les opcions més utilitzades són:
- Muntar el sistema de fitxers en mode de només lectura (ReadOnly) o congelar el sistema de fitxers (congelar) - el mètode és d'aplicabilitat limitada.
- Creació d'instantànies de l'estat dels sistemes de fitxers o dispositius de bloc (LVM, ZFS).
- L'ús d'eines de tercers per organitzar les impressions, fins i tot en els casos en què els punts anteriors no es poden proporcionar per algun motiu (programes com hotcopy).
- La tècnica de còpia en canvi (CopyOnWrite), però, sovint està lligada al sistema de fitxers utilitzat (BTRFS, ZFS).
Per tant, per a un servidor petit, heu de proporcionar un esquema de còpia de seguretat que compleixi els requisits següents:
- Fàcil d'utilitzar: no calen passos addicionals especials durant el funcionament, passos mínims per crear i restaurar còpies.
- Universal: funciona tant en servidors grans com petits; això és important a l'hora d'augmentar el nombre de servidors o d'escalar.
- Instal·lat per un gestor de paquets, o en una o dues ordres com ara "descarregar i desempaquetar".
- Estable: s'utilitza un format d'emmagatzematge estàndard o establert des de fa temps.
- Ràpid a la feina.
Sol·licitants d'aquells que compleixen més o menys els requisits:
- rdiff-còpia de seguretat
- rsnapshot
- eructar
- duplicar
- duplicitat
- deixa dup
- donar
- zbackup
- repòs
- borgbackup
Com a banc de proves s'utilitzarà una màquina virtual (basada en XenServer) amb les característiques següents:
- 4 nuclis 2.5 GHz,
- 16 GB de RAM,
- Emmagatzematge híbrid de 50 GB (sistema d'emmagatzematge amb memòria cau en SSD el 20% de la mida del disc virtual) en forma de disc virtual independent sense particions,
- Canal d'Internet de 200 Mbps.
Gairebé la mateixa màquina s'utilitzarà com a servidor receptor de còpia de seguretat, només amb un disc dur de 500 GB.
Sistema operatiu - Centos 7 x64: partició estàndard, s'utilitzarà una partició addicional com a font de dades.
Com a dades inicials, prenem un lloc de WordPress amb 40 GB de fitxers multimèdia i una base de dades mysql. Com que els servidors virtuals varien molt en característiques, i també per a una millor reproductibilitat, aquí teniu
resultats de les proves del servidor mitjançant sysbench.sysbench --threads=4 --time=30 --cpu-max-prime=20000 cpu run
sysbench 1.1.0-18a9f86 (utilitzant LuaJIT 2.1.0-beta3 inclòs)
Execució de la prova amb les opcions següents:
Nombre de fils: 4
Inicialització del generador de números aleatoris des de l'hora actual
Límit de nombres primers: 20000
S'estan inicialitzant fils de treball...
Els fils han començat!
Velocitat de la CPU
esdeveniments per segon: 836.69
Rendiment:
esdeveniments/s (eps): 836.6908
temps transcorregut: 30.0039 s
nombre total d'actes: 25104
Latència (ms):
min: 2.38
mitjana: 4.78
màxim: 22.39
Percentil 95: 10.46
suma: 119923.64
Equitat dels fils:
esdeveniments (mitjana/stddev): 6276.0000/13.91
temps d'execució (mitjana/stddev): 29.9809/0.01
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=llegir l'execució de la memòria
sysbench 1.1.0-18a9f86 (utilitzant LuaJIT 2.1.0-beta3 inclòs)
Execució de la prova amb les opcions següents:
Nombre de fils: 4
Inicialització del generador de números aleatoris des de l'hora actual
Execució de la prova de velocitat de memòria amb les opcions següents:
Mida del bloc: 1 KiB
Mida total: 102400 MiB
funcionament: llegir
àmbit: global
S'estan inicialitzant fils de treball...
Els fils han començat!
Total d'operacions: 50900446 (1696677.10 per segon)
49707.47 MiB transferits (1656.91 MiB/s)
Rendiment:
esdeveniments/s (eps): 1696677.1017
temps transcorregut: 30.0001 s
nombre total d'actes: 50900446
Latència (ms):
min: 0.00
mitjana: 0.00
màxim: 24.01
Percentil 95: 0.00
suma: 39106.74
Equitat dels fils:
esdeveniments (mitjana/stddev): 12725111.5000/137775.15
temps d'execució (mitjana/stddev): 9.7767/0.10
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=escriptura d'execució de memòria
sysbench 1.1.0-18a9f86 (utilitzant LuaJIT 2.1.0-beta3 inclòs)
Execució de la prova amb les opcions següents:
Nombre de fils: 4
Inicialització del generador de números aleatoris des de l'hora actual
Execució de la prova de velocitat de memòria amb les opcions següents:
Mida del bloc: 1 KiB
Mida total: 102400 MiB
operació: escriure
àmbit: global
S'estan inicialitzant fils de treball...
Els fils han començat!
Total d'operacions: 35910413 (1197008.62 per segon)
35068.76 MiB transferits (1168.95 MiB/s)
Rendiment:
esdeveniments/s (eps): 1197008.6179
temps transcorregut: 30.0001 s
nombre total d'actes: 35910413
Latència (ms):
min: 0.00
mitjana: 0.00
màxim: 16.90
Percentil 95: 0.00
suma: 43604.83
Equitat dels fils:
esdeveniments (mitjana/stddev): 8977603.2500/233905.84
temps d'execució (mitjana/stddev): 10.9012/0.41
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run
sysbench 1.1.0-18a9f86 (utilitzant LuaJIT 2.1.0-beta3 inclòs)
Execució de la prova amb les opcions següents:
Nombre de fils: 4
Inicialització del generador de números aleatoris des de l'hora actual
Senyals d'obertura de fitxers addicionals: (cap)
128 fitxers, 8 MiB cadascun
Mida total del fitxer 1 GiB
Mida del bloc 4 KiB
Nombre de sol·licituds d'IO: 0
Relació de lectura/escriptura per a la prova d'IO aleatòria combinada: 1.50
FSYNC periòdic habilitat, trucant a fsync() cada 100 peticions.
Trucant a fsync() al final de la prova, activat.
Utilitzant el mode d'E/S síncrona
Fent una prova aleatòria de r/w
S'estan inicialitzant fils de treball...
Els fils han començat!
Rendiment:
llegir: IOPS=3868.21 15.11 MiB/s (15.84 MB/s)
escriviu: IOPS=2578.83 10.07 MiB/s (10.56 MB/s)
fsync: IOPS=8226.98
Latència (ms):
min: 0.00
mitjana: 0.27
màxim: 18.01
Percentil 95: 1.08
suma: 238469.45
Aquesta nota comença en gran
sèrie d'articles sobre còpies de seguretat
- Còpia de seguretat, part 1: Per què es necessita una còpia de seguretat, una visió general dels mètodes i les tecnologies
- Còpia de seguretat Part 2: revisar i provar les eines de còpia de seguretat basades en rsync
- Còpia de seguretat Part 3: revisió i prova de duplicitat, duplicació, deja dup
- Còpia de seguretat Part 4: revisió i prova de zbackup, restic, borgbackup
- Còpia de seguretat Part 5: prova de còpia de seguretat de bacula i veeam per a Linux
- Còpia de seguretat Part 6: comparació d'eines de còpia de seguretat
- Còpia de seguretat Part 7: Conclusions
Font: www.habr.com