El nivell de capacitat (o com l'anomenem dins de Vim - captir) va aparèixer en els dies de l'actualització 9.5 de Veeam Backup and Replication 4 amb el nom Archive Tier. La idea que hi ha darrere és fer possible moure les còpies de seguretat que han caigut fora de l'anomenada finestra de restauració operativa a l'emmagatzematge d'objectes. Això va ajudar a netejar espai en disc per als usuaris que en tenien poc. I aquesta opció es va anomenar Move Mode.

Per dur a terme aquesta acció senzilla (tal com sembla), n'hi havia prou amb complir dues condicions: tots els punts de la còpia de seguretat moguda han d'estar fora dels límits de la finestra de restauració operativa esmentada anteriorment, que s'estableix explícitament a la interfície d'usuari. I segon: la cadena ha d'estar en l'anomenada "forma segellada" (cadena de còpia de seguretat segellada o cadena de còpia de seguretat inactiva). És a dir, no es produeixen canvis en aquesta cadena al llarg del temps.

Però a VBR v10, el concepte es va complementar amb noves funcions: el mode de còpia, el mode segellat i va aparèixer una cosa amb el nom difícil de pronunciar Immutability.

Aquestes són les coses fascinants de les quals parlarem avui. Primer, sobre com funcionava a VBR9.5u4, i després sobre els canvis a la desena versió.

I que els defensors del llenguatge pur em perdonin, però hi ha massa termes que no es poden traduir.
Així que aquí hi haurà un munt d'anglicismes.
I molts gifs.
I imatges.

• Sense el més mínim pesar. Autor de l'article.

Tal com va ser

Bé, comencem analitzant la finestra de restauració operativa i la còpia de seguretat segellada (o com s'anomenen a la documentació de la cadena de còpia de seguretat inactiva). Sense la seva comprensió, no serà possible una explicació addicional.

Com veiem a la imatge, tenim una mena de cadena de còpia de seguretat amb blocs de dades, que es troba al nivell de rendiment SOBR del dipòsit al qual està connectat el nivell de capacitat. La nostra finestra de còpia de seguretat operativa és de tres dies.

En conseqüència, el .vbk creat dilluns segella la cadena anterior, la finestra de la qual està fixada en tres dies. I això vol dir que podeu començar a transportar amb seguretat tot allò que sigui més antic d'aquests tres dies al camp de tir.

Però, què volia dir exactament una cadena segellada i què es podria enviar al camp de tir de capacitat a l'actualització 4?

Per a Forward Incremental, un signe de segellat de la cadena és la creació d'una nova còpia de seguretat completa. I no importa com s'obté aquesta còpia de seguretat completa: es consideren tant les còpies de seguretat completes sintètiques com les actives.

En el cas de Reverse, tots aquests són fitxers que no cauen a la finestra operativa.

En el cas de l'increment Forward with rollbacks, tots aquests són rollbacks i .vbk, si hi ha un altre .vbk en l'extensió del rendiment

Ara considerem l'opció de treballar amb cadenes de còpia de seguretat. Aquí només s'han transportat els articles que incloïen la retenció de GFS. Perquè tot el que s'emmagatzema a les cadenes de còpies de seguretat més recents es pot canviar d'una manera o altra.

Ara mirem sota el capó. Allà, es produeix un procés anomenat deshidratació: deixant els fitxers de còpia de seguretat buits a l'extensió i arrossegant els blocs d'aquests fitxers al rang de tir de capacitat. Per optimitzar aquest procés s'utilitza l'anomenat índex de deshidratació, que permet evitar la còpia de blocs que ja s'han copiat al camp de tir de capacitat.

Vegem com es veu això amb un exemple: suposem que tenim un .vbk que va sortir de la finestra de transacció i que pertany a una cadena segellada. Això vol dir que tenim tot el dret a traslladar-lo al camp de tir amb capacitat. En el moment del trasllat, es crea un fitxer de metadades al guió de capacitat i blocs del fitxer transferit. El fitxer de metadades a nivell d'enllaç descriu en quins blocs consisteix el nostre fitxer. En el cas de la imatge, el nostre primer fitxer consta de blocs a, b, c i les metadades conté enllaços a aquests blocs. Quan tenim un segon fitxer .vbk, preparat per moure i format per blocs a, b i d, analitzant l'índex de deshidratació, entenem que només cal moure el bloc d. I el seu fitxer de metadades contindrà enllaços a dos blocs anteriors i un de nou.

En conseqüència, el procés d'omplir aquests espais buits amb dades s'anomena rehidratació. Ja fa servir el seu propi índex de rehidratació, basat en el fitxer .vbk més antic sobre l'extensió del rendiment local. És a dir, si l'usuari vol retornar un fitxer del rang de tir de capacitat, primer creem un índex dels blocs de la còpia de seguretat completa més antiga i transferim només els blocs que falten de la galeria de tir de capacitat. En el cas que es presenta a la imatge, per rehidratar FullBackup1.vbk segons l'índex de rehidratació, només necessitem el bloc C, que agafem del camp de tir de capacitat. Si un objecte del núvol d'emmagatzematge serveix com a camp de tir de capacitat, això us permet estalviar enormes quantitats de diners.

Aquí pot semblar que aquesta tecnologia és idèntica a la que s'utilitza als acceleradors WAN, però només ho sembla. En els acceleradors, la deduplicació és global; aquí, la deduplicació local s'utilitza dins de cada fitxer amb un desplaçament específic. Això passa per la diferència en les tasques que s'estan resolent: aquí hem de copiar fitxers de còpia de seguretat complets grans i, segons la nostra investigació, encara que passi un llarg període de temps entre ells, aquest algorisme de deduplicació dóna el millor resultat.

Però més índexs per al déu dels índexs! També hi ha un índex per a la recuperació de dades! Quan comencem a restaurar una màquina situada al tauler de capacitat, només llegirem blocs de dades únics que no es troben al tauler de rendiment.

Com ha passat?

Això és tot per a la part introductòria. És força detallat, però com s'ha esmentat anteriorment, sense aquests detalls no serà possible explicar com funcionen les noves funcions. Per tant, sense més preàmbuls, passem al primer.

Mode de còpia

Es basa en gran mesura en tecnologies existents, però té una lògica d'ús completament diferent. 

L'objectiu d'aquest mode és garantir que totes les dades localitzades a l'extensió local tinguin una còpia al guió de capacitat.

Si compareu frontalment els modes de moviment i de còpia, es veurà així:

• Només es pot moure la cadena segellada. En el cas d'un mode de còpia, es transfereix absolutament tot, independentment del que passi a la tasca de còpia de seguretat.
• El moviment s'activa quan els fitxers van més enllà dels límits de la finestra de còpia de seguretat operativa, i la còpia s'activa tan bon punt apareix el fitxer de còpia de seguretat.
• El seguiment de noves dades per a la còpia es produeix constantment, i per al seu moviment es va activar una vegada cada 4 hores.

En considerar el nou mode, proposo passar d'exemples simples a exemples complexos.

En el cas més habitual, simplement tenim fitxers nous amb increments i simplement els copiem al camp de tir de capacitat. Independentment de quin mode s'utilitzi a la tasca de còpia de seguretat, independentment de si pertany o no a la part segellada de la cadena, independentment de si la nostra finestra operativa ha caducat. Només l'han agafat i l'han copiat.

El procés darrere d'això encara és la deshidratació tal com es descriu anteriorment. En mode de còpia, també s'assegura que no copiem blocs que ja estan al nostre emmagatzematge. L'única diferència és que si en mode pel·lícula substituïm els fitxers reals per fitxers ficticis, aquí no els toquem de cap manera i ho deixem tot tal qual. En cas contrari, és exactament el mateix índex de deshidratació, que intenta amb cura estalviar-vos diners i temps.

Sorgeix la pregunta: si mireu la interfície d'usuari, hi ha l'oportunitat de seleccionar les dues opcions alhora. Com funcionarà aquest mode combinat?

Esbrinem-ho.

El principi és estàndard: es crea un fitxer de còpia de seguretat i es copia immediatament. S'hi crea un increment i també es copia. Això passa fins al moment en què ens adonem que els fitxers han sortit de la nostra finestra de funcionament i ha aparegut una cadena segellada. En aquest punt realitzem una operació de deshidratació i substituïm aquests fitxers per fitxers simulats. Per descomptat, no tornem a copiar res al camp de tir de capacitat.

Tota aquesta lògica fascinant és responsable d'una sola casella de selecció a la interfície: copieu les còpies de seguretat a l'emmagatzematge d'objectes tan bon punt es creïn.

Per què necessitem aquest mode de còpia?

Encara és millor reformular la pregunta d'aquesta manera: de quins riscos estem protegits amb la seva ajuda? Quin problema ens ajuda a resoldre?

La resposta és òbvia: per descomptat, es tracta de la recuperació de dades. Si tenim una còpia completa de les dades locals a l'emmagatzematge d'objectes, no importa el que passi amb el nostre producte, sempre podem restaurar les dades dels fitxers ubicats a l'Amazon condicional.

Així doncs, passem pels escenaris possibles, des dels més simples als més complexos.

La desgràcia més senzilla que ens pot caure al cap és la inaccessibilitat d'un dels fitxers de la cadena de còpia de seguretat.

Una història més trista és que una de les extensions del nostre dipòsit SOBR es va trencar.

Encara empitjora quan tot el dipòsit SOBR s'ha tornat inaccessible, però el rang de tir de capacitat funciona.
I tot és realment dolent: és quan el servidor de còpia de seguretat mor i el vostre primer desig és intentar córrer a la frontera canadenca en deu minuts.

Ara mirem cada situació per separat.

Quan hem perdut un (i fins i tot diversos) fitxers de còpia de seguretat, tot el que hem de fer és iniciar el procés de reexploració del dipòsit i el fitxer perdut es substituirà per un fitxer simulat. I utilitzant el procés de rehidratació (que es va parlar al principi de l'article), l'usuari podrà descarregar dades del camp de tir de capacitat a l'emmagatzematge local.

Ara la situació és més complicada. Suposem que el nostre SOBR consta de dues extensions que s'executen en mode Rendiment, la qual cosa significa que els nostres .vbk i .vib s'estenen sobre ells en una capa força desigual. I en algun moment, una de les extensions no està disponible i l'usuari necessita urgentment restaurar la màquina, part de les dades de la qual es troben precisament en aquesta extensió.

L'usuari inicia l'assistent de recuperació, selecciona el punt on vol restaurar i l'assistent, mentre treballa, s'adona que no disposa de totes les dades necessàries per a la recuperació localment i, per tant, s'ha de descarregar des de la capacitat de tir. galeria. Al mateix temps, els blocs que romanen a l'emmagatzematge local no es baixaran del núvol. Glòria a l'índex de restauració (sí, també es va esmentar al principi de l'article).

Un subtipus d'aquest cas és que tot el repositori SOBR es va tornar inaccessible. En aquest cas, no tenim res per copiar des de l'emmagatzematge local i tots els blocs es descarreguen del núvol.

I la situació més interessant és que el servidor de còpia de seguretat va morir. Aquí hi ha dues opcions: l'administrador és fantàstic i va fer còpies de seguretat de configuració, i l'administrador és un Pinotxo malvat i no va fer còpies de seguretat de la configuració.

En el primer cas, n'hi haurà prou amb desplegar una instal·lació neta de VBR en algun lloc i restaurar la seva base de dades des d'una còpia de seguretat mitjançant mitjans estàndard. Al final d'aquest procés, tot tornarà a la normalitat. O es restaurarà segons un dels escenaris anteriors.

Però si l'administrador és el seu propi enemic o la còpia de seguretat de la configuració també va patir un fracàs èpic, fins i tot aquí no el deixarem a mercè del destí. Per a aquest cas, hem introduït un nou procediment anomenat Import Object Storage. Us permet ometre el procés de recrear manualment un dipòsit SOBR i adjuntar-hi un rang de tir de capacitat amb una nova exploració posterior, i simplement afegir un objecte d'emmagatzematge a la interfície de Vim i executar el procediment d'importació d'emmagatzematge. L'únic que pot interposar-vos entre vosaltres i les vostres còpies de seguretat és una sol·licitud per introduir una contrasenya si les vostres còpies de seguretat estan xifrades.

Probablement tot es tracta del mode de còpia i passem a

Mode segellat

La idea principal és que les noves còpies de seguretat no poden aparèixer a l'extensió SOBR seleccionada del dipòsit. Abans de la v10, només teníem el mode de manteniment, quan qualsevol treball amb el dipòsit estava completament prohibit. Una mena de mode hardcore per tancar l'emmagatzematge, on només està disponible el botó Evacuar, que transporta còpies de seguretat en una altra mesura una vegada.

I el mode segellat és una mena d'opció "suau": prohibim la creació de còpies de seguretat noves i eliminem progressivament les antigues segons la retenció seleccionada, però en el procés no perdem la capacitat de restaurar des dels punts emmagatzemats. Una cosa molt útil quan tenim una peça de maquinari que s'acosta al final de la seva vida útil i hem de substituir-la, o només hem d'alliberar-la per a alguna cosa més important, però no hi ha on agafar-la i moure-ho tot alhora. O no es pot esborrar.

En conseqüència, el principi de funcionament és bastant simple: cal prohibir totes les operacions d'escriptura (aparició de dades noves), deixar llegir (restauracions) i suprimir (retenció).

Els dos modes es poden utilitzar simultàniament, però tingueu en compte que el manteniment té una prioritat més alta.

Com a exemple, considereu un SOBR que consta de dues extensions. Suposem que durant els primers quatre dies vam crear còpies de seguretat en el mode Forward Forever Incremental i després segellem l'extensió. Això fa que iniciem la creació d'un nou complet actiu a la segona extensió disponible. Si la nostra retenció és de quatre, quan tota la cadena situada a l'extensió segellada va més enllà dels seus límits, s'elimina amb la consciència tranquil·la.

Hi ha situacions en què l'eliminació es produeix abans. Per exemple, això és Endavant incremental amb plens periòdics. Si hem creat còpies de seguretat completes durant els dos primers dies, i dijous decidim segellar el repositori, divendres, quan es creï una còpia de seguretat nova, s'eliminarà el fitxer del dilluns perquè no hi ha dependències fins a aquest punt. I el punt en si no depèn de ningú. A continuació, esperem fins que es creïn quatre punts sobre l'extensió disponible i eliminem els tres restants, que no es poden eliminar independentment els uns dels altres.

Les coses són més senzilles amb Reverse Incremental. En ell, els punts més antics no depenen de res i es poden suprimir de manera segura. Per tant, tan bon punt es crei un nou .vbk en una nova extensió, els antics .vrbs s'eliminaran un a un.

Per cert, per què creem un nou .vbk cada vegada: si no el creàvem, però continuàvem amb l'antiga cadena d'increments, llavors el .vbk antic es congelaria durant un temps infinitament llarg en qualsevol mode, impedint-ne la supressió. Per tant, es va decidir que tan aviat com l'extensió estigui segellada, creem una còpia de seguretat completa de l'extensió gratuïta.

Les coses són més complicades amb la capacitat del camp de tir.

Primer, mirem el mode de còpia. Suposem que estàvem creant còpies de seguretat de manera activa durant quatre dies i després es va segellar el camp de tir de capacitat. No suprimim res, però suportem humilment la retenció, després de la qual cosa eliminem les dades del camp de tir de capacitat.

Aproximadament passa el mateix en mode de moviment: esperem el retoc, eliminem l'antic a l'emmagatzematge local i suprimim el emmagatzemat a l'emmagatzematge d'objectes.

Un exemple interessant amb Forever forward incremental. Instal·lem la retenció en tres punts i comencem a fer còpies de seguretat dilluns, que es copien regularment al núvol. Després de segellar l'emmagatzematge, es continuen creant còpies de seguretat, mantenint tres punts, però les dades emmagatzemades al tauler de capacitat segueixen sent dependents i no es poden suprimir. Per tant, esperem fins dijous, quan el nostre .vbk va més enllà de la retenció, i només aleshores suprimim amb calma tota la cadena desada.

I una petita exempció de responsabilitat: tots els exemples aquí es mostren amb una màquina. Si en teniu diversos a la vostra còpia de seguretat, el retoc serà diferent segons si s'ha fet Active Full o no.

Això és bàsicament tot el que hi ha. Així que passem a la funció més hardcore:

Immutabilitat

Com en els punts anteriors, el primer és quin problema resol aquesta funció. Tan bon punt pengem les nostres còpies de seguretat en algun lloc per a l'emmagatzematge, hi ha un fort desig de garantir-ne la seguretat, és a dir, prohibir físicament la seva supressió i qualsevol modificació durant una determinada retenció. Inclòs els administradors, fins i tot sota els seus comptes root. Això us permet protegir-los de danys accidentals o intencionats. Qualsevol persona que treballi amb AWS pot haver trobat una funció similar anomenada Object Lock.

Ara mirem el mode en termes generals i després aprofundim en els detalls. En el nostre exemple, la Immutabilitat s'habilitarà per al nostre camp de tir de capacitat amb una retenció de quatre dies. I el mode de còpia està habilitat a la còpia de seguretat.

La immutabilitat no interacciona amb la retenció general de cap manera. Per exemple, no afegeix punts addicionals ni res semblant. És només que una persona no pot suprimir els fitxers de còpia de seguretat en quatre dies. Si feu una còpia de seguretat dilluns, només podreu esborrar-ne el fitxer divendres.

Tots els conceptes de deshidratació, índexs i metadades explicats anteriorment continuen funcionant exactament igual. Però amb una condició: el bloc s'estableix no només per a les dades, sinó també per a les metadades. Això es fa en cas que un atacant astut decideixi esborrar la nostra base de dades de metadades i per evitar que els blocs de dades es converteixin en una barreja binari inútil.

Ara és un bon moment per explicar la nostra tecnologia de generació de blocs. O generació de blocs. Per fer-ho, tingueu en compte la situació que va provocar la seva aparició.

Prenem una escala de temps de sis dies i a continuació marcarem el moment de la caducitat esperada de la immutabilitat. El primer dia agafem i creem un fitxer format pel bloc de dades a i les seves metadades. Si la immutabilitat s'estableix en tres dies, és lògic suposar que al quart dia les dades seran desbloquejades i suprimides. El segon dia afegirem un nou fitxer2, format pel bloc b amb la mateixa configuració. El bloc encara s'ha d'eliminar el quart dia. Però al tercer dia passa alguna cosa terrible: es crea un fitxer File3, que consta d'un nou bloc d i un enllaç al bloc antic a. Això vol dir que per a un bloc i la seva bandera d'immutabilitat s'ha de restablir a una nova data, que es trasllada al sisè dia. I aquí sorgeix un problema: a les còpies de seguretat reals hi ha un gran nombre d'aquests blocs. I per allargar el seu període d'immutabilità, cal fer un gran nombre de sol·licituds cada vegada. I de fet, aquest serà un procés diari gairebé interminable, ja que amb un alt grau de probabilitat trobarem grans piles de blocs deduplicats amb cada còpia. Què significa un gran nombre de sol·licituds de proveïdors d'emmagatzematge d'objectes? Dret! Factura enorme a finals de mes.

I per no exposar de sobte els vostres clients preferits per diners substancials, es va inventar el mecanisme de generació de blocs. Aquest és un període addicional que afegim al període d'immutabilità establert. A l'exemple següent, aquest període és de dos dies. Però això és només un exemple. En realitat, utilitzen la seva pròpia fórmula, que ofereix aproximadament deu dies addicionals durant un bloqueig mensual.

Continuem considerant la mateixa situació, però amb la generació de blocs. El primer dia creem fitxer1 a partir del bloc a i metadades. Sumem el període de generació i la immutabilitat, això vol dir que l'oportunitat d'eliminar el fitxer serà el sisè dia. Si el segon dia creem Fitxer2, format pel bloc b i un enllaç per bloquejar a, no passa res amb la data d'eliminació prevista. Es va quedar com el sisè dia. I així estem intentant estalviar diners en el nombre de peticions. L'única situació en què es pot canviar el termini és si el període de generació ha expirat. És a dir, si el tercer dia el nou File3 conté un enllaç per bloquejar a, s'afegirà la generació 2 ja que Gen1 ja ha caducat. I la data prevista per suprimir el bloc a es canviarà al vuitè dia. Això ens permet reduir dràsticament el nombre de sol·licituds per allargar la vida útil dels blocs deduplicats, cosa que estalvia molts diners als clients.

La tecnologia en si està disponible per als usuaris de maquinari compatible amb S3 i S3, els fabricants del qual garanteixen que la seva implementació no difereix de la d'Amazon. D'aquí la resposta a la pregunta legítima per què Azure no és compatible: tenen una característica similar, però funciona a nivell de contenidors, no d'objectes individuals. Per cert, Amazon mateix té bloqueig d'objectes en dues maneres: compliment i govern. En el segon cas, hi ha la possibilitat que l'administrador més gran per sobre dels administradors i l'arrel per sobre de les arrels, malgrat el bloqueig d'objectes, encara esborri les dades. En cas de compliment, tot està ben clavat i ningú pot eliminar les còpies de seguretat. Fins i tot els administradors d'Amazon (segons les seves declaracions oficials). Aquest és el mode que admetem.

I, com és habitual, alguns enllaços útils:

• Про Generació de blocs en cada detall.
• Tota la informació sobre Veeam Backup & Replication 10 en el seu millor moment
• О Nivell de capacitat en detalls

Font: www.habr.com