Hoy, con mucho gusto, les presento algunos consejos útiles de mi colega Evgeny Ivanov, líder del equipo de soporte técnico de Veeam. Esta vez, Zhenya ha compartido recomendaciones para trabajar con copias de seguridad y réplicas. Espero que les ayuden a evitar errores comunes y que sus réplicas y copias de seguridad nunca sean el "eslabón débil" en el proceso de recuperación, si es que se requiere.

Así que, bienvenidos al post.

En mi anterior el artículo exploramos cómo optimizar la carga en los componentes de la infraestructura de copias de seguridad y revisamos errores comunes de configuración. Ahora pasamos a otro tema importante: la preparación y ejecución adecuadas de la recuperación. También lo examinaremos con ejemplos reales en los que ha trabajado el equipo de soporte técnico.

Copia de seguridad sin pruebas — dinero tirado a la basura

Regularmente recibimos consultas de usuarios que se encuentran en situaciones difíciles similares: es necesario realizar una recuperación de una copia de seguridad, pero al intentar hacerlo, las personas se encuentran con un problema que no pueden resolver. Y este problema no es la falta de una copia de seguridad, la actividad de CryptoLocker o algo similar. Es "simplemente" la falta de atención a la verificación de las copias de seguridad y las réplicas para su capacidad de recuperación. Muchos a menudo se enfocan únicamente en el proceso de creación de copias de seguridad, olvidando que tener una copia de seguridad no es una panacea contra posibles problemas. Es necesario entender que la recuperación es un proceso completamente diferente, que tiene sus propias características, y que debe ser controlado y probado antes de su implementación en producción. Aquí tienen algunos ejemplos ilustrativos:

El usuario experimentó una falla en una máquina virtual crítica de 20 TB. Las interrupciones, por supuesto, son inaceptables, y el administrador inicia el proceso de recuperación instantánea de la VM (VM instant recovery) – en 5 minutos la máquina está operativa. Sin embargo, recordamos que este estado de la máquina solo puede ser temporal; debe migrarse al datastore de producción. En este caso, como se descubrió, las capacidades de la infraestructura no permitían copiar 20 TB de datos en un tiempo razonable. Además, en la configuración del proceso de recuperación instantánea, se eligió guardar los cambios en el disco. C: servidores Veeam Backup & Replication (a diferencia de un snapshot de vSphere) – como resultado, el espacio libre en el disco se llenó rápidamente. Para cuando el usuario se comunicó con el soporte, la VM ya tenía cambios que no podían ser ignorados. Es decir, tenemos la situación donde no se puede finalizar rápidamente el proceso de recuperación instantánea de una máquina crítica – ¿cómo se pueden salvar los datos?
La verdad, debido al tiempo que ha pasado, ya no recuerdo todos los detalles del desenlace, pero sé que al final no encontramos nada genial. Los clientes, por su parte, resolvieron este problema de manera razonable, ampliando el disco C: a partir de sus reservas, copiaron los archivos más importantes y luego apagaron la VM y así realizaron la migración. En resumen, no ocurrió ningún milagro.
En la infraestructura del usuario había un único controlador de dominio, y todos los componentes de Veeam Backup & Replication estaban configurados utilizando DNS. Sí, así es, no has oído mal. Hubo cientos de posibles desarrollos, pero la realidad fue así: la gente programó un mantenimiento y decidió cambiarse a la réplica de su controlador de dominio. Llevaron a cabo el cambio programado, lo cual, en general, se recomienda hacer en situaciones como esta. En la primera etapa todo iba bien, pero en la segunda, la VM original fue apagada brevemente para transferir los datos restantes. Por supuesto, la tarea de conmutación falló inmediatamente, ya que DNS dejó de funcionar.
Afortunadamente, pudimos manejar la situación aquí activando la réplica manualmente desde vSphere (en realidad, no se recomienda realizar esta operación por cuenta propia, como verán en el siguiente ejemplo). Sin embargo, como comprenderán, el proceso de mantenimiento fue interrumpido y pospuesto. Además, tuvimos que ingresar manualmente los nombres de los hosts en el archivo C:\Windows\System32\drivers\etc\hosts en el servidor Veeam Backup & Replication, para garantizar la correcta reversión.
En otro cliente, toda la infraestructura de respaldo se había construido alrededor de dispositivos de cinta magnética, y solo se almacenaban cortas cadenas de archivos en disco. Cuando necesitaron recuperar varios archivos de un gran servidor de archivos, resultó que no se podía usar ninguna máquina como repositorio auxiliar para la recuperación desde la cinta, ya que ninguna tenía suficiente espacio libre. (Sobre la recuperación directamente desde la cinta magnética y utilizando un repositorio auxiliar se puede leer aquí (por ahora en inglés)).

Creo que en los tres ejemplos los usuarios, por así decirlo, estaban atrapados en una ilusión: asumieron que si la copia de seguridad se completó con éxito, no habría problemas con la recuperación. Pero, como pueden entender, esto no siempre es así, y por eso la recuperación debe prepararse con tanto cuidado como la copia de seguridad. Primero es recomendable estudiar el manual del usuario, donde se encuentra información bastante detallada sobre los diferentes tipos de recuperación. Al inicio de cada párrafo se enumeran los requisitos, acciones preparatorias y posibles limitaciones. La descripción de la recuperación desde cintas magnéticas o desde instantáneas hardware del almacenamiento del sistema se puede encontrar en las secciones de la documentación y en nuestros artículos en Habr. Además, las acciones para preparar la recuperación de objetos de aplicaciones utilizando las herramientas Veeam Explorers están descritas en la sección «Planning and preparation» (planificación y preparación) guías para cada una de las herramientas. Les recomiendo estudiarlas detenidamente; esto les ayudará a preparar correctamente el sistema para la recuperación en caso de ser necesario. En ruso, las instrucciones para la recuperación de la base de datos SQL Server se presentan aquí.

¿Por qué no se debe trabajar con réplicas desde la consola de vSphere?

En teoría, las réplicas de Veeam son máquinas virtuales normales, con las que, aparentemente, sería lógico trabajar utilizando herramientas de vSphere, en particular, el cliente de vSphere. Sin embargo, no recomendamos hacerlo, y aquí está el porqué: cambiar a una réplica en Veeam Backup & Replication es un proceso bastante complicado que requiere una ejecución estrictamente secuencial de los pasos (para que, en caso de error, se pueda retroceder un paso) y acciones finales correctas; solo mira la imagen que ilustra el proceso:

Si decides activar la réplica desde el cliente de vSphere, es muy probable que te enfrentes a una serie de problemas en el futuro:

El mecanismo para cambiar a la réplica desde Veeam Backup & replication (mostrado en el esquema) no funcionará para esta máquina.
Los datos en la base de Veeam Backup no coincidirán con el estado real de la VM. En el peor de los casos, será necesario editar la base.
Incluso puede haber pérdida de datos, como en este ejemplo: un usuario activó manualmente la réplica en el cliente de vSphere y decidió seguir trabajando con ella. Después de un tiempo, se dio cuenta de que la réplica aún se mostraba en la consola de Veeam Backup & Replication, y decidió eliminarla por no necesitarla. Hizo clic derecho sobre ella y dio la orden «Eliminar del disco». Veeam Backup & Replication eliminó inmediatamente del disco la réplica que, por cierto, ya se estaba utilizando como una VM normal y contenía datos necesarios y útiles.

Sin duda, hay situaciones en las que es necesario activar la réplica desde el cliente de vSphere; por lo general, son casos en los que el servidor de Veeam está apagado y la réplica necesita ser activada con un retraso. Pero si el servidor de Veeam está en funcionamiento, las réplicas deben manejarse desde su consola.

Tampoco se deben eliminar las réplicas utilizando el cliente de vSphere. Veeam Backup & Replication permanecerá en la ignorancia sobre dicho cambio, lo que puede llevar a errores y datos obsoletos. Si la réplica ya no es necesaria, elimínala mediante la consola de Veeam, y no como una VM desde el cliente de vSphere. Así siempre tendrás una lista actualizada de réplicas.

«¡Ojo! — actualizaciones a la vista!»

Aquí nos referimos, por supuesto, a las actualizaciones para hipervisores y diversas aplicaciones que se respaldan con Veeam. Si las miramos desde la perspectiva de Veeam Backup & Replication, las actualizaciones se pueden dividir, de manera general, en 2 categorías: grandes y significativas, que traen muchos cambios, y pequeñas.

Primero, revisemos la primera categoría.

Las actualizaciones más importantes son aquellas destinadas al hipervisor. Antes de instalar una actualización así, es fundamental asegurarse de que sea compatible con Veeam Backup & Replication. Estas actualizaciones traen numerosos cambios en las bibliotecas y en las interfaces de APIs que utiliza Veeam Backup & Replication, por lo que, para declarar oficialmente su soporte, es necesario actualizar el código de Veeam Backup & Replication y realizar pruebas exhaustivas.

También hay que tener en cuenta que, por ejemplo, VMware no brinda acceso anticipado a las últimas versiones de vSphere para los fabricantes de software, así que los desarrolladores y probadores de Veeam reciben la nueva versión al mismo tiempo que el resto de la humanidad progresista; por lo tanto, suele pasar un tiempo entre el lanzamiento de VMware y la declaración oficial de soporte. La cantidad y la diversidad de cambios necesarios son tales que es poco probable encajarlos en un simple hotfix; y el soporte oficial generalmente se declara junto con el lanzamiento de la nueva versión de Veeam Backup & Replication.

Como resultado, se presenta ese momento incómodo en el que, tras el lanzamiento de una nueva versión de vSphere, las solicitudes de soporte técnico aumentan drásticamente, porque los usuarios se lanzan a instalar la nueva versión y, por supuesto, sus respaldos dejan de funcionar de inmediato. A nosotros, el soporte técnico de Veeam, nos toca explicar a los usuarios qué fue lo que hicieron mal, solicitarles que regresen a la versión anterior (si es posible) o idear complicadas soluciones para salir del atolladero. Por lo tanto, antes de instalar una actualización importante, asegúrese de verificar su compatibilidad con el software que está utilizando, ¡se lo ruego!

Todo lo anterior se aplica también a las aplicaciones que respalda y espera restaurar con Veeam. La línea de herramientas Veeam Explorers también tiene una lista de las versiones compatibles de las aplicaciones correspondientes, que se actualiza con cada lanzamiento de Veeam Backup & Replication. Por lo tanto, antes de instalar una nueva versión de su aplicación, ya sea Exchange, Oracle o SharePoint, asegúrese de leer la sección correspondiente. de la documentación de Veeam Explorers.

A la segunda categoría, es decir, a las pequeñas actualizaciones, incluyo, por ejemplo, nuevas versiones de VMware Tools, actualizaciones acumulativas de Exchange, actualizaciones de seguridad de vSphere, etc. Por lo general, no traen modificaciones importantes y, en la mayoría de los casos, Veeam Backup & Replication no tiene problemas con ellas. (Por eso no hay anuncios públicos sobre el soporte oficial de estas en el producto.) Sin embargo, en nuestra experiencia hemos encontrado casos en los que incluso estas actualizaciones cambiaron de forma tan significativa el curso normal de las cosas que causaron errores en el funcionamiento de Veeam Backup & Replication. En tales situaciones, tras confirmar el problema, los ingenieros de Veeam se esfuerzan por lanzar rápidamente un hotfix.

A quienes dominan el inglés técnicoSi quiere estar al tanto de en qué están trabajando los ingenieros y con qué se enfrentan los arquitectos de sistemas y los especialistas de soporte técnico, le recomiendo suscribirse a nuestros foros. Cada semana se publica una newsletter "Word from Gostev" para sus suscriptores, escrita por TheRealGostev. En ella, Anton Gostev, jefe del departamento de gestión de productos, habla sobre los problemas recientemente encontrados (y no solo del lado de Veeam), los planes para nuevas versiones y noticias del mundo de IT. Si necesita más información, puede revisar los temas del foro: si alguno de los clientes encuentra un problema con el funcionamiento del producto después de alguna actualización, lo más probable es que ya haya escrito sobre ello en el foro.

Como sabrán, los parches y actualizaciones pueden causar problemas no solo con las copias de seguridad, sino también con las aplicaciones para las cuales se realizan estas copias. Aquí es donde entran en juego los laboratorios virtuales: Veeam DataLabs. Seguramente han oído hablar de la funcionalidad SureBackup, que está diseñada para verificar las copias de seguridad. Se basa precisamente en el uso de DataLabs, creando un entorno aislado donde se pueden, entre otras cosas, probar las actualizaciones antes de implementarlas en producción. Les aconsejo encarecidamente que lo hagan; les ahorrará una gran cantidad de estrés. Y si alguien aún no sabe sobre SureBackup, recomiendo leer. la documentación.

Eso es todo por hoy, ¡gracias por su atención!