O nivel de capacidade (ou como o chamamos dentro de Vim - captir) apareceu nos tempos da actualización 9.5 de Veeam Backup and Replication 4 baixo o nome Archive Tier. A idea detrás é facer posible mover as copias de seguridade que caeron fóra da chamada xanela de restauración operativa ao almacenamento de obxectos. Isto axudou a liberar espazo no disco para aqueles usuarios que tiñan pouco del. E esta opción chamábase Modo Mover.

Para realizar esta acción sinxela (como parece), abondaba con cumprir dúas condicións: todos os puntos da copia de seguridade movida deben estar fóra dos límites da xanela de restauración operativa mencionada anteriormente, que está definida explícitamente na IU. E segundo: a cadea debe estar na chamada "forma selada" (cadea de copia de seguridade selada ou Cadea de copia de seguridade inactiva). É dicir, non se producen cambios nesta cadea ao longo do tempo.

Pero en VBR v10, o concepto complementouse con novas funcións: o modo de copia, o modo selado e apareceu algo co nome difícil de pronunciar Immutability.

Estas son as cousas fascinantes das que falaremos hoxe. Primeiro, sobre como funcionou en VBR9.5u4, e despois sobre os cambios na décima versión.

E que me perdoen os campións da lingua pura, pero hai demasiados termos que non se poden traducir.
Polo tanto, aquí haberá unha tonelada de anglicismos.
E moitos gifs.
E imaxes.

• Sen o máis mínimo pesar. Autor do artigo.

Como foi

Ben, comecemos analizando a xanela de restauración operativa e a copia de seguridade selada (ou como se chaman na documentación da cadea de copia de seguridade inactiva). Sen a súa comprensión, non serán posibles máis explicacións.

Como vemos na imaxe, temos unha especie de cadea de copia de seguridade con bloques de datos, que se atopa no nivel de rendemento SOBR do repositorio ao que está conectado o nivel de capacidade. A nosa xanela de copia de seguridade operativa é de tres días.

En consecuencia, o .vbk creado o luns sela a cadea anterior, cuxa xanela está configurada en tres días. E iso significa que podes comezar con seguridade a transportar todo o que teña máis antigüidade que estes tres días ata o campo de tiro.

Pero, que quería dicir exactamente unha cadea selada e que se podería enviar ao campo de tiro de capacidade na actualización 4?

Para Forward Incremental, un sinal de selar a cadea é a creación dunha nova copia de seguridade completa. E non importa como se obteña esta copia de seguridade completa: considéranse tanto as copias de seguridade completas sintéticas como as activas.

No caso de Reverse, estes son todos os ficheiros que non entran na xanela operativa.

No caso de Forward increment with rollbacks, todos estes son rollbacks e .vbk, se hai outro .vbk sobre a extensión do rendemento

Agora imos considerar a opción de traballar con cadeas de copia de seguridade. Aquí só se transportaron os artigos que se atopaban baixo retención de GFS. Porque todo o almacenado nas cadeas de copias de seguranza máis recentes pódese cambiar dun xeito ou doutro.

Agora imos mirar debaixo do capó. Alí, prodúcese un proceso chamado deshidratación: deixando os ficheiros de copia de seguridade baleiros na extensión e arrastrando bloques destes ficheiros ata o rango de disparo de capacidade. Para optimizar este proceso utilízase o denominado índice de deshidratación, que permite evitar copiar bloques que xa foron copiados no campo de tiro de capacidade.

Vexamos como se ve isto cun exemplo: digamos que temos un .vbk que saíu da xanela da transacción e pertence a unha cadea selada. Isto significa que temos todo o dereito a movelo ao campo de tiro con capacidade. No momento do traslado, créase un ficheiro de metadatos no guión de capacidade e nos bloques do ficheiro transferido. O ficheiro de metadatos a nivel de ligazón describe en que bloques consiste o noso ficheiro. No caso da imaxe, o noso primeiro ficheiro está formado por bloques a, b, c e os metadatos contén ligazóns a estes bloques. Cando temos un segundo ficheiro .vbk, listo para mover e formado por bloques a, b e d, nós, analizando o índice de deshidratación, entendemos que só hai que transferir o bloque d. E o seu ficheiro de metadatos conterá ligazóns a dous bloques anteriores e un novo.

En consecuencia, o proceso de encher estes espazos baleiros con datos chámase rehidratación. Xa usa o seu propio índice de rehidratación, baseado no ficheiro .vbk máis antigo sobre a extensión do rendemento local. É dicir, se o usuario quere devolver un ficheiro do intervalo de disparo de capacidade, primeiro creamos un índice dos bloques da copia de seguridade completa máis antiga e transferimos só os bloques que faltan da galería de disparo de capacidade. No caso que se presenta na imaxe, para rehidratar FullBackup1.vbk segundo o índice de rehidratación só necesitamos o bloque C, que tomamos do campo de tiro de capacidade. Se un obxecto de nube de almacenamento serve como campo de tiro de capacidade, isto permítelle aforrar enormes cantidades de diñeiro.

Aquí pode parecer que esta tecnoloxía é idéntica á utilizada nos Aceleradores WAN, pero só o parece. Nos aceleradores, a deduplicación é global; aquí, a deduplicación local úsase dentro de cada ficheiro cunha compensación específica. Isto ocorre debido á diferenza nas tarefas que se están a resolver: aquí necesitamos copiar ficheiros de copia de seguridade completos de gran tamaño e, segundo a nosa investigación, aínda que pase un longo período de tempo entre eles, este algoritmo de deduplicación dá o mellor resultado.

Pero máis índices para o deus dos índices! Tamén hai un índice para a recuperación de datos. Cando comezamos a restaurar unha máquina situada no guión de capacidade, só leremos bloques de datos únicos que non estean no guión de rendemento.

Como pasou?

Iso é todo para a parte introdutoria. É bastante detallado, pero como se mencionou anteriormente, sen estes detalles non será posible explicar como funcionan as novas funcións. Polo tanto, sen máis, pasemos ao primeiro.

Modo de copia

Baséase en gran parte nas tecnoloxías existentes, pero leva unha lóxica de uso completamente diferente. 

O obxectivo deste modo é garantir que todos os datos localizados na extensión local teñan unha copia no guión de capacidade.

Se comparas directamente os modos Mover e Copiar, quedará así:

• Só se pode mover a cadea selada. No caso dun modo de copia, transfírese absolutamente todo, independentemente do que suceda no traballo de copia de seguridade.
• O movemento desenvólvese cando os ficheiros van máis aló dos límites da xanela de copia de seguranza operativa, e a copia desenvólvese en canto aparece o ficheiro de copia de seguridade.
• O seguimento dos novos datos para copialos prodúcese constantemente, e para o seu movemento accionouse unha vez cada 4 horas.

Ao considerar o novo modo, propoño pasar dos exemplos simples a outros complexos.

No caso máis común, simplemente temos ficheiros novos con incrementos, e simplemente copialos ao campo de tiro de capacidade. Independentemente do modo que se utilice no traballo de copia de seguridade, independentemente de que pertenza á parte selada da cadea ou non, independentemente de que a nosa xanela de funcionamento caducou. Só o colleron e copiárono.

O proceso detrás desta aínda é a deshidratación como se describe anteriormente. No modo de copia, tamén se asegura de que non copiamos bloques que xa están no noso almacenamento. A única diferenza é que se no modo película substituímos ficheiros reais por ficheiros ficticios, aquí non os tocamos de ningún xeito e deixamos todo como está. Se non, é exactamente o mesmo índice de deshidratación, que trata coidadosamente de aforrar diñeiro e tempo.

Xorde a pregunta: se miras a IU, hai a oportunidade de seleccionar ambas opcións ao mesmo tempo. Como funcionará un modo combinado así?

Imos descubrilo.

O principio é estándar: créase e cópiase inmediatamente un ficheiro de copia de seguridade. Créase un incremento nel e tamén se copia. Isto ocorre ata o momento en que nos decatamos de que os ficheiros saíron da nosa xanela de funcionamento e apareceu unha cadea selada. Neste punto realizamos unha operación de deshidratación e substituímos estes ficheiros por ficheiros ficticios. Por suposto, non copiamos nada de novo no campo de tiro de capacidade.

Toda esta lóxica fascinante é responsable de só unha caixa de verificación na interface: copiar as copias de seguridade no almacenamento de obxectos tan pronto como se crean.

Por que necesitamos este modo de copia?

Aínda é mellor reformular a pregunta deste xeito: de que riscos estamos protexidos coa súa axuda? Que problema nos axuda a resolver?

A resposta é obvia: por suposto, esta é a recuperación de datos. Se temos unha copia completa dos datos locais no almacenamento de obxectos, non importa o que pase co noso produto, sempre podemos restaurar os datos dos ficheiros situados no Amazon condicional.

Así que repasemos os posibles escenarios, dende os máis sinxelos ata os máis complexos.

A desgraza máis sinxela que pode caer sobre as nosas cabezas é a inaccesibilidade dun dos ficheiros da cadea de copias de seguridade.

Unha historia máis triste é que unha das extensións do noso repositorio SOBR rompeu.

Ainda empeora cando todo o repositorio SOBR se volve inaccesible, pero a capacidade de tiro está funcionando.
E todo é realmente malo: é cando o servidor de copia de seguridade morre e o teu primeiro desexo é tentar correr ata a fronteira canadense en dez minutos.

Agora vexamos cada situación por separado.

Cando perdemos un (e incluso varios) ficheiros de copia de seguranza, todo o que temos que facer é iniciar o proceso de re-escaneo do repositorio e o ficheiro perdido será substituído por un ficheiro ficticio. E usando o proceso de rehidratación (do que se falou ao comezo do artigo), o usuario poderá descargar datos do campo de tiro de capacidade ao almacenamento local.

Agora a situación é máis complicada. Supoñamos que o noso SOBR consta de dúas extensións que se executan no modo Performance, o que significa que os nosos .vbk e .vib están repartidos por eles nunha capa bastante irregular. E nalgún momento, unha das extensións non está dispoñible e o usuario precisa restaurar con urxencia a máquina, parte dos datos que se atopan precisamente nesta extensión.

O usuario inicia o asistente de recuperación, selecciona o punto no que quere restaurar e o asistente, mentres traballa, dáse conta de que non ten todos os datos necesarios para a recuperación localmente e, polo tanto, debe descargarse desde a capacidade de disparo. galería. Ao mesmo tempo, os bloques que permanecen no almacenamento local non se descargarán da nube. Gloria ao índice de restauración (si, tamén se mencionou ao comezo do artigo).

Un subtipo deste caso é que todo o repositorio SOBR quedou inaccesible. Neste caso, non temos nada que copiar do almacenamento local e todos os bloques descárganse da nube.

E a situación máis interesante é que o servidor de copia de seguridade morreu. Aquí hai dúas opcións: o administrador é xenial e fixo copias de seguridade da configuración, e o administrador é un malvado Pinocho e non fixo copias de seguridade da configuración.

No primeiro caso, bastará con que simplemente despregue unha instalación limpa de VBR nalgún lugar e restaure a súa base de datos desde unha copia de seguridade mediante medios estándar. Ao final deste proceso, todo volverá á normalidade. Ou restaurarase segundo un dos escenarios anteriores.

Pero se o administrador é o seu propio inimigo ou a copia de seguridade da configuración tamén sufriu un fracaso épico, aínda aquí non o deixaremos a mercé do destino. Para este caso, introducimos un novo procedemento chamado Importar almacenamento de obxectos. Permítelle omitir o proceso de recrear manualmente un repositorio SOBR e anexarlle un rango de disparo de capacidade coa posterior exploración, e simplemente engadir un obxecto de almacenamento á interface de Vim e executar o procedemento Importar repositorio de almacenamento. O único que pode intervir entre ti e as túas copias de seguridade é unha solicitude para introducir un contrasinal se as túas copias de seguranza estaban cifradas.

Probablemente todo se trate do modo de copia e pasamos a

Modo selado

A idea principal é que as copias de seguranza novas non poden aparecer na extensión SOBR seleccionada do repositorio. Antes da versión 10, só tiñamos o modo de mantemento, cando calquera traballo co repositorio estaba completamente prohibido. Unha especie de modo hardcore para apagar o almacenamento, onde só está dispoñible o botón Evacuar, que transporta copias de seguranza a outra medida dunha soa vez.

E o modo Selado é unha especie de opción "suave": prohibimos a creación de novas copias de seguridade e eliminamos gradualmente as antigas segundo a retención seleccionada, pero no proceso non perdemos a capacidade de restaurar desde os puntos almacenados. Unha cousa moi útil cando temos un hardware próximo ao final da súa vida útil e necesitamos substituílo, ou só necesitamos liberalo para algo máis importante, pero non hai onde levalo e movelo todo á vez. Ou non se pode eliminar.

En consecuencia, o principio de funcionamento é bastante sinxelo: é necesario prohibir todas as operacións de escritura (a aparición de novos datos), deixando ler (restauracións) e borrar (retención).

Ambos os modos pódense usar simultaneamente, pero ten en conta que o mantemento ten unha prioridade máis alta.

Como exemplo, considere un SOBR que consta de dúas extensións. Supoñamos que durante os primeiros catro días creamos copias de seguranza no modo Forward Forever Incremental e despois selamos a extensión, o que leva ao feito de que iniciamos a creación dun novo activo completo na segunda extensión dispoñible. Se a nosa retención é de catro, entón cando toda a cadea situada na extensión selada supera os seus límites, elimínase coa conciencia tranquila.

Hai situacións nas que a eliminación ocorre antes. Por exemplo, este é un avance incremental con cheos periódicos. Se creamos copias de seguridade completas durante os dous primeiros días e o xoves decidimos selar o repositorio, o venres, cando se crea unha nova copia de seguranza, eliminarase o ficheiro do luns porque non hai dependencias ata este punto. E o punto en si non depende de ninguén. A continuación, agardamos ata que se creen catro puntos sobre a extensión dispoñible e eliminamos os tres restantes, que non se poden eliminar independentemente uns dos outros.

As cousas son máis sinxelas con Reverse Incremental. Nela, os puntos máis antigos non dependen de nada e pódense eliminar con seguridade. Polo tanto, en canto se cree un novo .vbk nunha nova extensión, os antigos .vrbs eliminaranse un por un.

Por certo, por que creamos un novo .vbk cada vez: se non o creamos, pero continuamos coa antiga cadea de incrementos, entón o antigo .vbk conxelaríase durante un tempo infinitamente longo en calquera modo, evitando a súa eliminación. Polo tanto, decidiuse que tan pronto como se sela a extensión, creamos unha copia de seguridade completa na extensión gratuíta.

As cousas son máis complicadas coa capacidade do campo de tiro.

Vexamos primeiro o modo de copia. Supoñamos que estivemos creando copias de seguridade de forma activa durante catro días e despois se selou a capacidade do campo de tiro. Non borramos nada, pero soportamos humildemente a retención, despois de que borramos os datos do campo de tiro de capacidade.

Aproximadamente o mesmo ocorre no modo de movemento: agardamos ao retoque, eliminamos o antigo no almacenamento local e eliminamos o almacenado no almacenamento de obxectos.

Un exemplo interesante con Forever forward incremental. Instalamos a retención en tres puntos e comezamos a facer copias de seguridade o luns, que se copian regularmente na nube. Despois de selar o almacenamento, continúan creándose copias de seguridade, mantendo tres puntos, pero os datos almacenados no guión de capacidade seguen sendo dependentes e non se poden eliminar. Polo tanto, agardamos ata o xoves, cando o noso .vbk vai máis aló da retención, e só entón eliminamos con calma toda a cadea gardada.

E unha pequena exención de responsabilidade: todos os exemplos aquí móstranse cunha única máquina. Se tes varios deles na túa copia de seguranza, o seu retoque será diferente segundo se realizou ou non Active Full.

Isto é basicamente todo o que hai. Entón, imos pasar á función máis dura:

Inmutabilidade

Como nos puntos anteriores, o primeiro é que problema soluciona esta función. En canto cargamos as nosas copias de seguridade nalgún lugar para o almacenamento, hai un forte desexo de garantir a súa seguridade, é dicir, de prohibir fisicamente a súa eliminación e calquera modificación durante unha determinada retención. Incluíndo os administradores, incluso baixo as súas contas raíz. Isto permítelle protexelos de danos accidentais ou intencionados. Calquera persoa que traballe con AWS pode ter atopado unha función similar chamada Object Lock.

Agora vexamos o modo en termos xerais e, a continuación, profundicemos nos detalles. No noso exemplo, a inmutabilidade estará habilitada para o noso campo de tiro de capacidade cunha retención de catro días. E o modo de copia está activado na copia de seguridade.

A inmutabilidade non interactúa coa retención xeral de ningún xeito. Por exemplo, non engade puntos extra nin nada parecido. É só que unha persoa non pode eliminar ficheiros de copia de seguranza dentro de catro días. Se fai unha copia de seguridade o luns, só poderás eliminar o seu ficheiro o venres.

Todos os conceptos de deshidratación, índices e metadatos explicados anteriormente seguen funcionando exactamente igual. Pero cunha condición: o bloque está configurado non só para os datos, senón tamén para os metadatos. Isto faise no caso de que un atacante astuto decida borrar a nosa base de datos de metadatos e evitar que os bloques de datos se convertan nunha masa binaria inútil.

Agora é un bo momento para explicar a nosa tecnoloxía de xeración de bloques. Ou xeración de bloques. Para iso, considere a situación que levou á súa aparición.

Tomemos unha escala temporal de seis días e a continuación marcaremos o momento da esperada caducidade da inmutabilidade. O primeiro día tomamos e creamos un ficheiro composto polo bloque de datos a e os seus metadatos. Se a inmutabilidade se establece en tres días, é lóxico asumir que o cuarto día os datos serán desbloqueados e eliminados. O segundo día engadiremos un novo ficheiro2, composto polo bloque b coa mesma configuración. O bloque a aínda debe eliminarse o cuarto día. Pero ao terceiro día ocorre algo terrible: créase un ficheiro File3, composto por un novo bloque d e unha ligazón ao bloque antigo a. Isto significa que para un bloque e a súa bandeira de inmutabilidade debe restablecerse a unha nova data, que se traslada ao sexto día. E aquí xorde un problema: nas copias de seguridade reais hai un gran número de tales bloques. E para estender o seu período de inmutabilidade, cómpre facer un gran número de solicitudes cada vez. E, de feito, este será un proceso diario case interminable, xa que cun alto grao de probabilidade atoparemos con cada copia grandes pilas de bloques deduplicados. Que significa un gran número de solicitudes de provedores de almacenamento de obxectos? Certo! Factura enorme a finais de mes.

E para non expor por casualidade aos teus clientes favoritos por diñeiro substancial, inventouse o mecanismo de xeración de bloques. Este é un período adicional que engadimos ao período de inmutabilidade establecido. No exemplo seguinte, este período é de dous días. Pero este é só un exemplo. En realidade, usan a súa propia fórmula, que dá aproximadamente dez días adicionais durante un bloqueo mensual.

Sigamos considerando a mesma situación, pero coa xeración de bloques. O primeiro día creamos o ficheiro1 a partir do bloque a e os metadatos. Sumamos o período de xeración e a inmutabilidade; isto significa que a oportunidade de eliminar o ficheiro será o sexto día. Se o segundo día creamos o Ficheiro2, composto polo bloque b e unha ligazón para bloquear a, non pasa nada coa data de eliminación prevista. Ela quedou como o sexto día. E así estamos tentando aforrar diñeiro no número de solicitudes. A única situación na que se pode trasladar o prazo é se expirou o período de xeración. É dicir, se ao terceiro día o novo File3 contén unha ligazón para bloquear a, entón engadirase a xeración 2 xa que Gen1 xa caducou. E a data prevista para eliminar o bloque a pasará ao oitavo día. Isto permítenos reducir drasticamente o número de solicitudes para estender a vida útil dos bloques deduplicados, o que aforra aos clientes unha tonelada de diñeiro.

A tecnoloxía en si está dispoñible para os usuarios de hardware compatible con S3 e S3, cuxos fabricantes garanten que a súa implementación non difire da de Amazon. De aí a resposta á pregunta lexítima de por que Azure non é compatible: teñen unha característica similar, pero funciona a nivel de contedores, non de obxectos individuais. Por certo, Amazon ten bloqueo de obxectos en dous modos: cumprimento e goberno. No segundo caso, existe a posibilidade de que o maior administrador por riba dos administradores e root por riba das raíces, a pesar do bloqueo de obxectos, aínda elimine os datos. No caso de cumprir, todo está ben cravado e ninguén pode eliminar as copias de seguridade. Incluso os administradores de Amazon (segundo as súas declaracións oficiais). Este é o modo que admitimos.

E, como é habitual, algúns enlaces útiles:

• en Xeración de bloques en cada detalle.
• Toda a información sobre Veeam Backup & Replication 10 no seu mellor momento
• О Nivel de capacidade en detalle

Fonte: www.habr.com