El nivel de capacidad (o como lo llamamos dentro de Vim, captir) apareció en los días de Veeam Backup and Replication 9.5 Update 4 con el nombre de Archive Tier. La idea detrás de esto es hacer posible mover las copias de seguridad que han caído de la llamada ventana de restauración operativa al almacenamiento de objetos. Esto ayudó a liberar espacio en disco para aquellos usuarios que tenían poco. Y esta opción se llamó Modo Mover.

Para realizar esta (como parece) acción simple, fue suficiente cumplir dos condiciones: todos los puntos de la copia de seguridad movida deben estar fuera de los límites de la ventana de restauración operativa mencionada anteriormente, que está configurada explícitamente en la interfaz de usuario. Y segundo: la cadena debe estar en la llamada “forma sellada” (cadena de respaldo sellada o Cadena de respaldo inactiva). Es decir, no se producen cambios en esta cadena a lo largo del tiempo.

Pero en VBR v10, el concepto se complementó con nuevas funciones: apareció el modo de copia, el modo sellado y algo con el nombre difícil de pronunciar Inmutabilidad.

Estas son las cosas fascinantes de las que hablaremos hoy. Primero, sobre cómo funcionó en VBR9.5u4 y luego sobre los cambios en la décima versión.

Y que me perdonen los defensores del lenguaje puro, pero hay demasiados términos que no se pueden traducir.
Entonces habrá un montón de anglicismos aquí.
Y muchos gifs.
Y fotografías.

• Sin el menor arrepentimiento. Autor del artículo.

Como era

Bueno, comencemos analizando la ventana de restauración operativa y la copia de seguridad sellada (o como se les llama en la documentación de la Cadena de copia de seguridad inactiva). Sin su comprensión, no será posible una mayor explicación.

Como vemos en la imagen, tenemos una especie de cadena de respaldo con bloques de datos, que se ubica en el nivel de Rendimiento SOBR del repositorio al que está conectado el Nivel de Capacidad. Nuestra ventana de respaldo operativo es de tres días.

En consecuencia, el .vbk creado el lunes sella la cadena anterior, cuya ventana está fijada en tres días. Y eso significa que puedes empezar a transportar de forma segura todo lo que tenga más de estos tres días al campo de tiro.

Pero, ¿qué se entiende exactamente por una cadena sellada y qué se podría enviar al campo de tiro de capacidad en la actualización 4?

Para Forward Incremental, una señal de que se está sellando la cadena es la creación de una nueva copia de seguridad completa. Y no importa cómo se obtenga esta copia de seguridad completa: se consideran tanto las copias de seguridad completas sintéticas como las completas activas.

En el caso de Reverse, estos son todos los archivos que no caen en la ventana operativa.

En el caso de incremento hacia adelante con reversiones, todas estas son reversiones y .vbk, si hay otro .vbk en la extensión de rendimiento.

Ahora consideremos la opción de trabajar con cadenas de copias de seguridad. Aquí sólo se transportaron los artículos sujetos a retención GFS. Porque todo lo almacenado en cadenas de copias de seguridad más recientes se puede cambiar de una forma u otra.

Ahora miremos debajo del capó. Allí, se produce un proceso llamado deshidratación: dejar archivos de respaldo vacíos en la extensión y arrastrar bloques de estos archivos al rango de disparo de capacidad. Para optimizar este proceso se utiliza el llamado índice de deshidratación, que permite evitar copiar bloques que ya han sido copiados al campo de tiro de capacidad.

Veamos cómo se ve esto con un ejemplo: digamos que tenemos un .vbk que salió de la ventana de transacción y pertenece a una cadena sellada. Esto significa que tenemos todo el derecho a trasladarlo al campo de tiro de capacidad. En el momento de la mudanza, se crea un archivo de metadatos en el guión de capacidad y en los bloques del archivo transferido. El archivo de metadatos a nivel de enlace describe en qué bloques consta nuestro archivo. En el caso de la imagen, nuestro primer archivo consta de los bloques a, b, cy los metadatos contienen enlaces a estos bloques. Cuando tenemos un segundo archivo .vbk, listo para mover y compuesto por los bloques a, byd, analizando el índice de deshidratación, entendemos que solo es necesario transferir el bloque d. Y su archivo de metadatos contendrá enlaces a dos bloques anteriores y uno nuevo.

En consecuencia, el proceso de llenar estos espacios vacíos con datos se llama rehidratación. Ya utiliza su propio índice de rehidratación, basado en el archivo .vbk más antiguo en la extensión de rendimiento local. Es decir, si el usuario desea devolver un archivo del campo de tiro de capacidad, primero creamos un índice de los bloques de la copia de seguridad completa más antigua y transferimos solo los bloques que faltan del campo de tiro de capacidad. En el caso que se presenta en la imagen, para rehidratar FullBackup1.vbk según el índice de rehidratación, solo necesitamos el bloque C, que tomamos del rango de disparo de capacidad. Si un objeto de almacenamiento en la nube sirve como campo de tiro de capacidad, esto le permitirá ahorrar enormes cantidades de dinero.

Aquí puede parecer que esta tecnología es idéntica a la utilizada en los Aceleradores WAN, pero sólo lo parece. En los aceleradores, la deduplicación es global; aquí, la deduplicación local se utiliza dentro de cada archivo en un desplazamiento específico. Esto sucede debido a la diferencia en las tareas a resolver: aquí necesitamos copiar grandes archivos de respaldo completos y, según nuestra investigación, incluso si pasa un largo período de tiempo entre ellos, este algoritmo de deduplicación da el mejor resultado.

¡Pero más índices para el dios de los índices! ¡También hay un índice para la recuperación de datos! Cuando comenzamos a restaurar una máquina ubicada en el tablero de capacidad, solo leeremos bloques de datos únicos que no están en el tablero de rendimiento.

Como se hizo

Eso es todo por la parte introductoria. Es bastante detallado, pero como se mencionó anteriormente, sin estos detalles no será posible explicar cómo funcionan las nuevas funciones. Por tanto, sin más, pasemos al primero.

Modo de copia

Se basa en gran medida en tecnologías existentes, pero conlleva una lógica de uso completamente diferente. 

El propósito de este modo es garantizar que todos los datos ubicados en la extensión local tengan una copia en el guión de capacidad.

Si comparas los modos Mover y Copiar de frente, se verá así:

• Sólo se puede mover la cadena sellada. En el caso del modo copia, se transfiere absolutamente todo, independientemente de lo que suceda en la tarea de copia de seguridad.
• El movimiento se activa cuando los archivos van más allá de los límites de la ventana de copia de seguridad operativa y la copia se activa tan pronto como aparece el archivo de copia de seguridad.
• El monitoreo de nuevos datos para copiar se realiza constantemente y para mover se activa una vez cada 4 horas.

Al considerar el nuevo modo, propongo pasar de ejemplos simples a ejemplos complejos.

En el caso más común, simplemente tenemos archivos nuevos con incrementos y simplemente los copiamos al campo de tiro de capacidad. Independientemente del modo que se utilice en el trabajo de copia de seguridad, independientemente de si pertenece a la parte sellada de la cadena o no, independientemente de si nuestra ventana operativa ha expirado. Simplemente lo tomaron y lo copiaron.

El proceso detrás de esto sigue siendo la deshidratación como se describe anteriormente. En el modo de copia, también se asegura de que no copiemos bloques que ya están en nuestro almacenamiento. La única diferencia es que si en el modo película reemplazamos archivos reales por archivos ficticios, aquí no los tocamos de ninguna manera y dejamos todo como está. De lo contrario, es exactamente el mismo índice de deshidratación, lo que intenta cuidadosamente ahorrarle dinero y tiempo.

Surge la pregunta: si observa la interfaz de usuario, existe la posibilidad de seleccionar ambas opciones al mismo tiempo. ¿Cómo funcionará ese modo combinado?

Vamos a resolverlo.

El comienzo es estándar: se crea un archivo de copia de seguridad y se copia inmediatamente. Se le crea un incremento y también se copia. Esto sucede hasta el momento en que nos damos cuenta de que los archivos han salido de nuestra ventana operativa y ha aparecido una cadena sellada. En este punto realizamos una operación de deshidratación y reemplazamos estos archivos con archivos ficticios. Por supuesto, no volvemos a copiar nada al campo de tiro de capacidad.

Toda esta fascinante lógica es responsable de una sola casilla de verificación en la interfaz: copiar copias de seguridad al almacenamiento de objetos tan pronto como se crean.

¿Por qué necesitamos este modo Copiar?

Es incluso mejor reformular la pregunta de esta manera: ¿de qué riesgos estamos protegidos con su ayuda? ¿Qué problema nos ayuda a resolver?

La respuesta es obvia: por supuesto, se trata de recuperación de datos. Si tenemos una copia completa de los datos locales en el almacenamiento del objeto, pase lo que pase con nuestro producto, siempre podremos restaurar los datos de los archivos ubicados en el Amazon condicional.

Así que repasemos los escenarios posibles, desde el más simple hasta el más complejo.

La desgracia más simple que puede caer sobre nuestra cabeza es la inaccesibilidad de uno de los archivos de la cadena de copia de seguridad.

Una historia más triste es que una de las extensiones de nuestro repositorio SOBR se rompió.

La situación empeora aún más cuando todo el repositorio SOBR se vuelve inaccesible, pero el campo de tiro de capacidad está funcionando.
Y todo va realmente mal: es entonces cuando el servidor de respaldo muere y tu primer deseo es intentar correr a la frontera canadiense en diez minutos.

Ahora veamos cada situación por separado.

Cuando hemos perdido uno (o incluso varios) archivos de copia de seguridad, todo lo que tenemos que hacer es iniciar el proceso de volver a escanear el repositorio y el archivo perdido será reemplazado por un archivo ficticio. Y utilizando el proceso de rehidratación (que se analizó al principio del artículo), el usuario podrá descargar datos del campo de tiro de capacidad al almacenamiento local.

Ahora la situación es más complicada. Supongamos que nuestro SOBR consta de dos extensiones que se ejecutan en modo Rendimiento, lo que significa que nuestros .vbk y .vib están distribuidos sobre ellos en una capa bastante desigual. Y en algún momento, una de las extensiones deja de estar disponible y el usuario necesita urgentemente restaurar la máquina, parte de cuyos datos se encuentran precisamente en esta extensión.

El usuario inicia el asistente de recuperación, selecciona el punto al que desea restaurar y el asistente, mientras trabaja, se da cuenta de que no tiene todos los datos necesarios para la recuperación localmente y, por lo tanto, debe descargarlos desde la capacidad de disparo. galería. Al mismo tiempo, los bloques que permanezcan en el almacenamiento local no se descargarán de la nube. Gloria al índice de restauración (sí, también se mencionó al principio del artículo).

Un subtipo de este caso es que todo el repositorio SOBR se volvió inaccesible. En este caso, no tenemos nada que copiar del almacenamiento local y todos los bloques se descargan de la nube.

Y la situación más interesante es que el servidor de respaldo falló. Aquí hay dos opciones: el administrador es excelente e hizo copias de seguridad de la configuración, y el administrador es un Pinocho malvado y no hizo copias de seguridad de la configuración.

En el primer caso, le bastará con implementar una instalación limpia de VBR en algún lugar y restaurar su base de datos desde una copia de seguridad utilizando medios estándar. Al finalizar este proceso todo volverá a la normalidad. O se restaurará según uno de los escenarios anteriores.

Pero si el administrador es su propio enemigo o la copia de seguridad de la configuración también sufrió un fallo épico, entonces ni siquiera aquí lo dejaremos a merced del destino. Para este caso, hemos introducido un nuevo procedimiento llamado Importar almacenamiento de objetos. Le permite omitir el proceso de recrear manualmente un repositorio SOBR y adjuntarle un campo de tiro de capacidad con una nueva exploración, y simplemente agregar un objeto de almacenamiento a la interfaz de Vim y ejecutar el procedimiento Importar repositorio de almacenamiento. Lo único que puede interponerse entre usted y sus copias de seguridad es una solicitud para ingresar una contraseña si sus copias de seguridad estaban cifradas.

Probablemente se trate del Modo Copiar y pasamos a

Modo sellado

La idea principal es que no pueden aparecer nuevas copias de seguridad en la extensión SOBR seleccionada del repositorio. Antes de la v10, solo teníamos el Modo Mantenimiento, cuando cualquier trabajo con el repositorio estaba completamente prohibido. Una especie de modo extremo para cerrar el almacenamiento, donde solo está disponible el botón Evacuar, que transporta las copias de seguridad a otra extensión una sola vez.

Y el modo sellado es una especie de opción "suave": prohibimos la creación de nuevas copias de seguridad y eliminamos gradualmente las antiguas según la retención seleccionada, pero en el proceso no perdemos la capacidad de restaurar desde puntos almacenados. Algo muy útil cuando tenemos una pieza de hardware acercándose al final de su vida útil y necesitamos reemplazarla, o simplemente necesitamos liberarla para algo más importante, pero no hay ningún lugar donde llevarla y mover todo de una vez. O no se puede eliminar.

En consecuencia, el principio de funcionamiento es bastante simple: es necesario prohibir todas las operaciones de escritura (aparición de nuevos datos), dejar de leer (restauraciones) y eliminar (retener).

Ambos modos se pueden utilizar simultáneamente, pero tenga en cuenta que el Mantenimiento tiene mayor prioridad.

Como ejemplo, considere un SOBR que consta de dos extensiones. Supongamos que durante los primeros cuatro días creamos copias de seguridad en el modo Forward Forever Incremental y luego sellamos la extensión, lo que lleva al hecho de que iniciamos la creación de una nueva extensión activa completa en la segunda extensión disponible. Si nuestra retención es cuatro, cuando toda la cadena ubicada en la extensión sellada sobrepase sus límites, se eliminará con la conciencia tranquila.

Hay situaciones en las que la eliminación se produce antes. Por ejemplo, esto es incremental hacia adelante con completaciones periódicas. Si creamos copias de seguridad completas para los primeros dos días y el jueves decidimos sellar el repositorio, el viernes, cuando se cree una nueva copia de seguridad, el archivo del lunes se eliminará porque no hay dependencias hasta este punto. Y el punto en sí no depende de nadie. Luego esperamos hasta que se creen cuatro puntos en la extensión disponible y eliminamos los tres restantes, que no se pueden eliminar de forma independiente unos de otros.

Las cosas son más sencillas con Reverse Incremental. En él, los puntos más antiguos no dependen de nada y se pueden eliminar de forma segura. Por lo tanto, tan pronto como se crea un nuevo .vbk en una nueva extensión, los .vrbs antiguos se eliminarán uno por uno.

Por cierto, ¿por qué creamos un nuevo .vbk cada vez? Si no lo creamos, pero continuamos con la antigua cadena de incrementos, entonces el antiguo .vbk se congelaría durante un tiempo infinitamente largo en cualquier modo, evitando su eliminación. Por lo tanto, se decidió que tan pronto como se selle la extensión, crearemos una copia de seguridad completa en la extensión libre.

Las cosas son más complicadas con el campo de tiro de capacidad.

Primero, veamos el modo de copia. Supongamos que estuvimos creando copias de seguridad activamente durante cuatro días y luego se selló la capacidad del campo de tiro. No eliminamos nada, pero soportamos humildemente la retención, después de lo cual eliminamos los datos del campo de tiro de capacidad.

Aproximadamente lo mismo sucede en el modo de movimiento: esperamos el retoque, eliminamos el antiguo en el almacenamiento local y eliminamos el almacenado en el almacenamiento de objetos.

Un ejemplo interesante con Forever forward incremental. Instalamos retención en tres puntos y comenzamos a realizar copias de seguridad el lunes, que se copian periódicamente en la nube. Después de sellar el almacenamiento, se continúan creando copias de seguridad, manteniendo tres puntos, pero los datos almacenados en el tablero de capacidad siguen siendo dependientes y no se pueden eliminar. Por lo tanto, esperamos hasta el jueves, cuando nuestro .vbk ya no se puede conservar, y solo entonces eliminamos tranquilamente toda la cadena guardada.

Y un pequeño descargo de responsabilidad: todos los ejemplos aquí se muestran con una máquina. Si tienes varios de ellos en tu copia de seguridad, entonces su retoque será diferente dependiendo de si se realizó Active Full o no.

Eso es básicamente todo lo que hay que hacer. Así que pasemos a la característica más importante:

Inmutabilidad

Como ocurre con los puntos anteriores, lo primero es qué problema soluciona esta función. Tan pronto como subimos nuestras copias de seguridad a algún lugar para su almacenamiento, existe un fuerte deseo de garantizar su seguridad, es decir, de prohibir físicamente su eliminación y cualquier modificación durante una determinada retención. Incluidos los administradores, incluso bajo sus cuentas raíz. Esto le permite protegerlos de daños accidentales o intencionales. Cualquiera que trabaje con AWS puede haber encontrado una característica similar llamada Object Lock.

Ahora veamos el modo en términos generales y luego profundicemos en los detalles. En nuestro ejemplo, se habilitará la inmutabilidad para nuestro campo de tiro de capacidad con una retención de cuatro días. Y el modo Copiar está habilitado en la copia de seguridad.

La inmutabilidad no interactúa de ninguna manera con la retención general. Por ejemplo, no suma puntos extra ni nada por el estilo. Es solo que una persona no puede eliminar archivos de respaldo en cuatro días. Si realiza una copia de seguridad el lunes, solo podrá eliminar su archivo el viernes.

Todos los conceptos de deshidratación, índices y metadatos explicados anteriormente siguen funcionando exactamente igual. Pero con una condición: el bloque se establece no solo para los datos, sino también para los metadatos. Esto se hace en caso de que un atacante astuto decida borrar nuestra base de datos de metadatos y evitar que los bloques de datos se conviertan en una mezcla binaria inútil.

Ahora es un buen momento para explicar nuestra tecnología de generación de bloques. O generar bloques. Para ello, consideremos la situación que motivó su aparición.

Tomemos una escala de tiempo de seis días y debajo marcaremos el momento del vencimiento esperado de la inmutabilidad. El primer día tomamos y creamos un archivo que consta del bloque de datos a y sus metadatos. Si la inmutabilidad se establece en tres días, es lógico suponer que al cuarto día los datos se desbloquearán y eliminarán. El segundo día agregaremos un nuevo archivo2, que consta del bloque b con la misma configuración. El bloque a aún debe eliminarse al cuarto día. Pero al tercer día sucede algo terrible: se crea un archivo File3, que consta de un nuevo bloque d y un enlace al antiguo bloque a. Esto significa que para un bloque y su indicador de inmutabilidad se debe restablecer a una nueva fecha, que se desplaza al sexto día. Y aquí surge el problema: en las copias de seguridad reales hay una gran cantidad de estos bloques. Y para extender su período de inmutabilidad, es necesario realizar una gran cantidad de solicitudes cada vez. Y, de hecho, este será un proceso diario casi interminable, ya que con un alto grado de probabilidad encontraremos grandes pilas de bloques deduplicados con cada copia. ¿Qué significa una gran cantidad de solicitudes de proveedores de almacenamiento de objetos? ¡Bien! Factura enorme a final de mes.

Y para no exponer inesperadamente a sus clientes favoritos a una cantidad sustancial de dinero, se inventó el mecanismo de generación de bloques. Este es un período adicional que agregamos al período de inmutabilidad establecido. En el siguiente ejemplo, este período es de dos días. Pero esto es sólo un ejemplo. En realidad, utilizan su propia fórmula, que proporciona aproximadamente diez días adicionales durante un bloqueo mensual.

Sigamos considerando la misma situación, pero con generación de bloques. El primer día creamos el archivo1 a partir del bloque a y los metadatos. Sumamos el período de generación y la inmutabilidad; esto significa que la oportunidad de eliminar el archivo será el sexto día. Si el segundo día creamos el Archivo2, que consta del bloque b y un enlace al bloque a, entonces no sucede nada con la fecha de eliminación esperada. Ella permaneció como el sexto día. Y así estamos tratando de ahorrar dinero en la cantidad de solicitudes. La única situación en la que se puede cambiar el plazo es si el período de generación ha expirado. Es decir, si al tercer día el nuevo File3 contiene un enlace para bloquear a, entonces se agregará la generación 2 ya que Gen1 ya expiró. Y la fecha prevista para eliminar el bloque a pasará al octavo día. Esto nos permite reducir drásticamente la cantidad de solicitudes para extender la vida útil de los bloques deduplicados, lo que ahorra a los clientes una gran cantidad de dinero.

La tecnología en sí está disponible para los usuarios de S3 y hardware compatible con S3, cuyos fabricantes garantizan que su implementación no difiere de la de Amazon. De ahí la respuesta a la pregunta legítima de por qué no se admite Azure: tienen una característica similar, pero funciona a nivel de contenedores, no de objetos individuales. Por cierto, la propia Amazon tiene bloqueo de objetos en dos modos: cumplimiento y gobernanza. En el segundo caso, existe la posibilidad de que el administrador superior por encima de los administradores y el root por encima de los root, a pesar del bloqueo del objeto, todavía elimine los datos. En caso de cumplimiento, todo está bien definido y nadie puede eliminar las copias de seguridad. Incluso los administradores de Amazon (según sus declaraciones oficiales). Este es el modo que apoyamos.

Y, como siempre, algunos enlaces útiles:

• Про Generación de bloques en cada detalle.
• Toda la información sobre Copia de seguridad y replicación de Veeam 10 en su mejor momento
• О Nivel de capacidad en detalle

Fuente: habr.com