En el artículo anterior, le contamos acerca de las nuevas características en la versión Update 4 para Veeam Backup & Replication 9.5 (VBR), lanzada en enero, donde las copias de seguridad en la cinta no se mencionaron conscientemente. La historia sobre esta área merece un artículo separado, porque realmente había muchas características nuevas.

- QA chicos, ¿escriben un artículo?
- ¡Por qué no!

Unidades de cinta en el siglo XXI

El almacenamiento de datos en cintas magnéticas (casetes, puntas , como los llamamos en I + D) no se limita a la computadora ZX-Spectrum, que era cosa del pasado, un juego para el cual se podía cargar en una RAM de 48 kb desde un casete de cinta durante varios minutos. Durante un cuarto de siglo, la velocidad y la capacidad de los casetes aumentaron en 6-7 órdenes de magnitud. Esta comparación no es del todo correcta, y el estándar LTO no sigue el ritmo de la ley de Moore . Sin embargo, las tecnologías modernas permiten grabar 12 terabytes de datos en una cinta de un kilómetro de cinta (hasta 30 terabytes en modo de compresión), por lo que el disco de 160 dólares deja a los competidores en el costo del almacenamiento a largo plazo de una gran cantidad de datos, incluso teniendo en cuenta las inversiones en equipos de grabación / leer. Los datos en tales cintas se almacenan de manera confiable durante 15-30 años.

Vendré del otro lado. Los virus ransomware han alcanzado un nuevo nivel recientemente. Pueden esperar su tiempo en la infraestructura de una gran empresa durante semanas y meses, y con el advenimiento de otra vulnerabilidad de día cero, pueden destruir (no sin ayuda humana, porque hay mucho dinero en juego) no solo todos los datos, sino también todas las copias de seguridad que se pueden alcanzar . Aquí hay un nuevo ejemplo de cuándo una empresa tuvo que pagar ransomware. El llamado espacio de aire , es decir, las copias de seguridad que estaban físicamente aisladas de la infraestructura, se convirtió, de hecho, en la única salvación confiable de tales historias. La cinta magnética aquí es una de las soluciones atemporales.



Pero una especificación y novedades tecnológicas de hierro y ferrita de bario de los principales fabricantes (IBM, HPE, Oracle, Dell) para una protección de datos confiable no es suficiente, necesita un buen software. En Veeam, todo nuestro equipo se dedica a realizar copias de seguridad en cinta, aproximadamente 10 personas analizan, planifican, investigan, desarrollan y prueban diariamente. Puede ver los resultados de este trabajo en artículos anteriores ( uno , dos ). ¿Qué se ha hecho durante el año pasado?

Glosario

Existe la posibilidad de elegir entre libertades en relación con el idioma nativo y complicar la legibilidad del clericalismo. Prefiero el primero, así que pido disculpas de antemano si alguien dice en jerga las palabras de la lista a continuación. Aquí recordaré brevemente lo que significa un término en particular.

Inquilino para grabar. Proveedor protegido: clientes protegidos

Inmediatamente triunfan las cartas sobre la mesa. La característica más ambiciosa de nuestra actualización, diseñada para proveedores de nube que usan VBR en su infraestructura. El desarrollo se inició hace dos años. Pronto nos dimos cuenta de que no tendremos tiempo para hacer frente a una tarea tan seria para la próxima versión, hicimos una breve pausa y finalmente lanzamos una función en 9.5 Actualización 4.

En resumen, ahora los proveedores tienen la oportunidad de copiar las copias de seguridad de sus clientes en casetes utilizando trabajos de cinta en el grupo de GFS. Esto les da a los proveedores, y estos son muchachos muy queridos por nuestro corazón y el departamento comercial, dos posibilidades:

• proteja a sus clientes (inquilinos, inquilino - inquilino) de la pérdida de datos como resultado de la eliminación accidental o problemas de infraestructura ("inundación en la sala del servidor");
• Proporcionar a los inquilinos un servicio adicional para restaurar los datos de una copia de seguridad anterior, que se ha eliminado del repositorio en la nube de acuerdo con la política de almacenamiento de datos, pero que aún permanece en la cinta.

Desde el punto de vista del marketing, la funcionalidad es muy "sabrosa", nuestra, no menos difícil de implementar.

Desarrollo

El principal problema encontrado es el cifrado de datos. La mayoría de las copias de seguridad en la nube están encriptadas, según las estadísticas sobre ⅔ del total. Para nosotros, esta cifra fue una sorpresa, se asumió que casi todo está encriptado, pero no, muchos clientes parecen confiar incondicionalmente en sus proveedores.

El paradigma es simple: el proveedor no debería poder descifrar los datos de sus inquilinos. Al mismo tiempo, dentro del marco de la nueva característica, se requiere del lado del proveedor abrir el almacenamiento con copias de seguridad. Esto es necesario para transferir bloques de datos, por ejemplo, para crear una copia de seguridad completa virtual . Lo principal es hacer esto independientemente del inquilino, cuando las claves necesarias no se transmiten al proveedor durante la ejecución del trabajo.

La solución a este problema, utilizada, por cierto, en otra característica importante del complemento lanzado - Nivel de capacidad - consiste en agregar una clave de cifrado adicional. La clave de archivo (clave de archivo) se almacena en la base de datos del proveedor en forma cifrada. Según un esquema complicado del lado del proveedor, se puede usar para abrir la tienda, mover y volver a cifrar bloques de datos entre las tiendas (después de todo, cada uno tiene su propia clave), pero los datos en sí no se pueden descifrar.


^{Esquema complicado (versión de trabajo)}

Agrego que todos los ingenieros en I + D son muy aficionados al cifrado en nuestro producto, sin embargo, nadie sabe en detalle cómo funciona. (Todavía había una broma "y por qué funciona en absoluto", pero los editores no se la perdieron).

Prueba

Cientos de errores se registraron en la función. Las áreas más difíciles son encriptación, interfaz de usuario, problemas con la restauración.

Desde el punto de vista de las pruebas, la gran variabilidad representaba la "combinación" de los tipos y tipos de trabajos y repositorios de inquilinos; me refiero a la fuente y al destino al restaurar las copias de seguridad en la infraestructura. Todo esto se basa en la lógica dentro del marco del modelo GFS (incluido el nuevo: paralelismo y conjuntos de medios diarios, más sobre esto a continuación) y, en general, en los detalles de la nube que son inusuales para los consejos. Recuerde sazonar con abundante encriptación. Para continuar con la metáfora, comimos mucho de este plato, pero también lo probamos por todos lados.


^{Fragmento del plan de prueba.}

Como resultado

Se puede encontrar una descripción detallada en el manual del usuario (hasta ahora en inglés): copia de seguridad , recuperación . Me detendré en los puntos principales.

Copia de seguridad

El proveedor agrega inquilinos al trabajo teip con el grupo GFS como destino. Si hay una licencia en la nube en el segundo paso del asistente, la opción Inquilinos está disponible. Puede agregar todos los inquilinos a la vez o por separado, o puede elegir solo una cuota separada (pero no una subcota) de un inquilino individual. No puede mezclar copias de seguridad de inquilinos y copias de seguridad locales regulares en el mismo trabajo.



El resto de las tinturas son casi completamente idénticas al trabajo habitual en el grupo de GFS.

La restauración de datos es posible tanto del lado del proveedor como del lado del inquilino mismo.

Proveedor de recuperación lateral

Realizado a través de un nuevo asistente. Aquí ya puede pasar a un trabajo separado, se restaura toda la cadena que estaba en el repositorio en un día determinado.



Hay tres opciones de restaurantes:

1. En la ubicación original. En este caso, la copia de seguridad original, si la hay, se elimina; los trabajos del inquilino se reconfiguran automáticamente en la cadena restaurada. Se entiende que dicha restauración será generalmente invisible para el cliente, solo por un corto tiempo se desconectará del repositorio en la nube.
2. En una nueva cuota / repositorio. Un proveedor puede, por ejemplo, crear una cuenta temporal separada para este propósito, que posteriormente eliminará. La copia de seguridad aparece en la infraestructura del inquilino después de la sincronización con la base de datos del proveedor.
3. Solo en una unidad de servidor Linux o Windows registrada en la infraestructura del proveedor. Además, esta cadena se puede grabar en una unidad flash y enviar inquilino.

Recuperación del inquilino

Esta opción implica que el cliente tiene su propia infraestructura de punta y una gran cantidad de datos para el restaurante. El proveedor puede enviar físicamente la cinta con las copias de seguridad grabadas al cliente por el servicio de entrega, la cataloga en su equipo, descifra las cintas y las copias de seguridad y trabaja con las copias de seguridad como si él mismo las hubiera escrito en cinta. Aquí hay un truco para no descargar terabytes en WAN.

Mejoras a gran escala para el grupo GFS

Los grupos de medios de GFS aparecieron en VBR hace dos años, en la versión 9.5. En la última actualización, tanto en relación con la aparición de la función de inquilino a cinta, como a petición de los usuarios, aprovechamos bien esta funcionalidad.

Conjuntos de medios diarios

Ha aparecido un nuevo conjunto de medios diarios . Ahora en el grupo de GFS puede almacenar copias de seguridad para todos los días, y no solo completas, sino también incrementales. Estos últimos ocupan significativamente menos espacio, y esto se hizo para ahorrar cinta. Se entiende que estos casetes rotan constantemente en la biblioteca, no se transportan al almacenamiento remoto. Al mismo tiempo, para un restaurante desde un punto de vista incremental, necesitará las cintas de uno de los conjuntos de medios de alto nivel (semanal, mensual, trimestral o anual). Es imposible encender el conjunto de medios diario sin incluir el semanal, por lo que en la mayoría de los casos se necesitarían casetes semanales para restaurar desde una copia incremental. Siempre están en la biblioteca o se almacenan en un almacén no tan remoto.



La lógica para trabajar con trabajos de cinta en el grupo de medios GFS no es la más fácil , los escritores técnicos no te dejarán mentir. En pocas palabras, omitiendo los detalles, solo las copias de seguridad completas (incluidas las copias de seguridad completas virtuales) se copian en los conjuntos de medios semanales y superiores, uno para cada fecha, y en la copia de seguridad diaria de todas las copias de seguridad que están en el repositorio para el día actual, porque la copia de seguridad -El trabajo puede comenzar más de una vez al día.

Simultaneidad, hora de inicio y espera en grupos de GFS

Ahora también es posible la grabación paralela de varias cadenas o el trabajo en varias unidades de biblioteca en agrupaciones de medios GFS (antes, solo en forma ordinaria). Se incluye en el paso Opciones del grupo de medios.



Una aclaración importante : el mismo archivo siempre se escribe en la misma secuencia, por lo tanto, en el caso de varias máquinas virtuales grandes, se recomienda habilitar la configuración por VM en el repositorio para que la copia de seguridad consista en varias cadenas.

Además, se hizo posible elegir la hora de inicio del trabajo GFS . A muchos usuarios no les gustaba comenzar a medianoche y luego esperar casi todo el día hasta que finalizara el trabajo de abastecimiento. Ahora, esta hora se puede configurar, por ejemplo, al final de la tarde, cuando ya hay algo que copiar en la cinta. Además, a solicitud de los usuarios, colocamos en la configuración avanzada una opción que anteriormente solo se podía activar con la clave de registro. Es suficiente seleccionar Procesar el punto de restauración más reciente en lugar de esperar , y lo que está en el repositorio en el momento del inicio del trabajo de cinta (el punto de ayer, por ejemplo) se copia en la cinta, no hay espera en absoluto.

Trabajo mejorado con múltiples bibliotecas.

Se tratará de la situación cuando se agregue más de una biblioteca a un grupo de medios. Apoyamos esto antes, pero de vez en cuando los clientes venían con quejas sobre un comportamiento poco predecible.

Era

Por ejemplo, el trabajo de cinta comenzó, tomó dos unidades en la primera biblioteca, pero la configuración de concurrencia le permite usar 4 unidades a la vez. ¿Debería este trabajo cambiar a la segunda biblioteca del grupo de medios y usarlo también, o será un desperdicio de recursos?

Otro caso Se seleccionó una opción para cambiar por la condición “no hay cassettes disponibles”, en la primera biblioteca solo hay un cassette, pero todos los datos se colocan potencialmente en él. Sin embargo, la configuración le permite escribir en paralelo en dos cintas. ¿Debería estar involucrada la segunda biblioteca en este caso?

Decidimos poner esta área en orden, haciendo posible personalizar el comportamiento explícitamente.

Se ha convertido

Las bibliotecas en el grupo de medios aparecieron roles: activos y pasivos . Y el grupo de medios en sí tiene dos modos: a prueba de fallas, o conmutación por error y en paralelo . Ahora, según los requisitos, puede configurar el grupo de medios de diferentes maneras.

• Si tiene varias bibliotecas pares y necesita paralelizar la grabación en ellas, active el modo de grabación paralela, para esto todas las bibliotecas deben tener roles activos asignados. En este caso, las nuevas cintas y unidades se activarán inmediatamente, tan pronto como sea necesario, independientemente de la biblioteca en la que se encuentren. Todavía hay prioridad: primero, intentaremos encontrar recursos en la biblioteca ubicada más arriba en la lista.
• Si hay una biblioteca principal y una unidad antigua o independiente en reserva, habilite el modo feylover colocando la biblioteca principal en la parte superior de la lista y eligiendo un rol pasivo para los dispositivos de respaldo. El cambio a un dispositivo de este tipo solo ocurrirá cuando sea realmente necesario que el trabajo funcione al menos de alguna manera. Esta situación se considerará anormal y se le enviará una notificación por correo.

Hay una situación más complicada que aún no admitimos: varias bibliotecas activas con pasivas. Los comentarios mostrarán si existe la necesidad de tales configuraciones y si es necesario "finalizar" la función en el futuro. Práctica estándar

Soporte WORM

WORM : escribir una vez, leer muchas: las cintas que no se pueden borrar ni sobrescribir en el nivel de hierro solo pueden agregar datos. Su uso obligatorio está regulado por las reglas de algunas organizaciones, por ejemplo, aquellas que trabajan en el campo de la medicina. El principal problema con tales cintas antes era que VBR durante el inventario o la catalogación registraba un encabezado que ya no podía borrarse en el futuro, y los trabajos de cinta caían con un error durante dicho intento.

En 9.5 Actualización 4, se implementa el soporte completo para tales cintas. Se agregaron grupos de medios WORM, regulares y GFS, donde solo puede colocar cintas de este tipo.



Los nuevos cassettes tienen un icono azul "congelado". Desde el punto de vista del usuario, trabajar con cassettes WORM no es diferente de trabajar con los ordinarios.

La "alimentación" de los casetes se determina inicialmente por el sufijo del código de barras , si el código de barras en ellos es regular o no se puede leer, la unidad proporciona información cuando se inserta el cartucho por primera vez. Coloque cintas WORM en un grupo de medios normal y escribirles no funcionará. De lo divertido: ya había usuarios que pegaron códigos de barras WORM en casetes normales y se sorprendieron de los cambios en su infraestructura después de la actualización.

Chip de cartucho

Junto con la introducción de casetes no regrabables, comenzaron a trabajar con el chip . Antes no usábamos atributos estándar en el chip, ahora escribimos y leemos algunos de ellos, pero no los percibimos como la fuente principal de datos. La directriz principal sigue siendo el título del cassette. Esta decisión resultó ser correcta: después de un mes después del lanzamiento, vemos cómo el "zoológico" del hierro del usuario trae sorpresas en términos de trabajar con el chip.

Copia de seguridad en cinta de volúmenes NDMP

En conclusión, sobre la característica más solicitada por el número de revisiones de esta Actualización. La copia de seguridad de los volúmenes NDMP en cintas se hizo disponible. Es necesario agregar un servidor NDMP a la infraestructura de VBR, después de lo cual será posible seleccionar volúmenes de este host en el trabajo de sugerencia de archivo. Caen en el cassette en forma de archivos con un atributo especial para distinguirlos de la catalogación habitual.



En la primera implementación, existen ciertas limitaciones: las extensiones no son compatibles, además es posible realizar copias de seguridad y restaurar solo el volumen completo, pero no los archivos individuales. La copia de seguridad funciona mediante el volcado (en el caso de NetApp - ufsdump ), hay algunas peculiaridades: el número máximo de puntos incrementales es 9, después de lo cual se fuerza una copia de seguridad completa.

En conclusión

VBR 9.5 Update 4. :

• - -;
• Tape Operator ( , – Restore Operator);
• include/exclude- - ( NDMP);
• - ( , , , - – , );
• ;
• , , / , ;
• .

Enlaces utiles

:

• VBR 9.5 Update 4
• « Veeam »
• «7 -»
• , ( .)
• « » (, ) – . 95 – 102.