Antes de poder configurar el repositorio inmutable como destino final, primero necesitamos presentarle el servidor físico (o la máquina virtual) de manera cruda a nuestro orquestador. Veeam necesita registrar el sistema operativo base para establecer la conexión cifrada y prepararlo para sus roles.
Presentar el Servidor
1. Navegar a Managed Servers En la interfaz web principal, dirígete al menú lateral izquierdo, baja hasta la sección de Infrastructure y selecciona Managed Servers. Una vez ahí, haz clic en el botón + Add en la barra superior. (Este es el inventario central donde vivirán todos los nodos de cómputo y almacenamiento que reciben órdenes de nuestro orquestador).
2. Seleccionar el Tipo de Sistema El asistente desplegará un menú con las plataformas compatibles. Seleccionaremos la opción Linux estándar. Esto le indica al motor de Veeam que nos vamos a conectar a un sistema operativo nativo (como Rocky Linux, Ubuntu o Debian) mediante credenciales de sistema o llaves SSH para administrarlo a bajo nivel.
3. Identidad y Resolución de Red (Name)
En la pantalla de New Linux Server, debemos ingresar la dirección de red de nuestro host. En el campo DNS name or IP address, ingresamos vprx-yorha-bunker.mxlit.com.
4. Autenticación Basada en Certificados (Access)
En la pantalla de Access, nos encontramos con uno de los pilares de seguridad más fuertes de esta nueva arquitectura.
Atrás quedaron los días de dejar el puerto 22 (SSH) abierto permanentemente para inyectar credenciales clásicas con un usuario y contraseña. Aquí seleccionaremos obligatoriamente la opción Connect using certificate-based authentication (recommended).
Al elegir este método, el orquestador utilizará certificados asimétricos para establecer un túnel seguro. Esto es lo que nos permite mantener la superficie de ataque al mínimo absoluto; no hay contraseñas viajando por la red ni necesidad de gestionar llaves públicas de forma manual, todo se maneja mediante el intercambio seguro del propio sistema operativo. Seleccionamos la opción y hacemos clic en Next.
5. Validación de Huella y Despliegue (Review & Summary)
Inmediatamente después de avanzar, el orquestador hará el primer “toque” de red hacia el Búnker. En este punto, el sistema te lanzará una advertencia de seguridad pidiéndote confirmar el Fingerprint (la huella digital SSH) del servidor destino.
Acepta esta alerta sin dudarlo; es el apretón de manos inicial que establece la confianza criptográfica permanente entre ambas máquinas.
Tras aceptar la huella, el asistente comenzará a inyectar y compilar automáticamente los servicios de transporte (Data Mover) y las dependencias de Linux necesarias para operar. Solo debes esperar a que la instalación de componentes finalice.
Una vez que termine el proceso, llegarás a la pantalla de Summary. Revisa que el nombre del servidor (vprx-yorha-bunker.mxlit.com) coincida con tu diseño y presiona Finish.
Agregando el Repositorio
1. Agregar el Nuevo Repositorio
Una vez que el servidor Linux ya forma parte de nuestro inventario, el siguiente paso es asignarle su función de almacenamiento. Para ello, nos dirigimos a la sección de Infrastructure en el menú lateral izquierdo, entramos a Repositories y hacemos clic en el botón + Add en la parte superior.
2. Seleccionar el Tipo: Hardened Repository
Al desplegarse las opciones de almacenamiento, es importante no irnos por la ruta del repositorio de Linux tradicional. Vamos a seleccionar directamente Hardened Repository. Al elegir esta opción, le indicamos a la plataforma que debe desplegar los servicios necesarios para habilitar la inmutabilidad, gestionando los permisos a nivel de sistema de archivos para proteger los respaldos contra modificaciones o ransomware.
3. Asignar un Nombre al Volumen
Al abrirse el asistente de configuración, el primer paso es definir cómo identificaremos este espacio dentro de la consola. Siguiendo la convención de nuestra topología, lo llamaremos Bunker Black Box. El campo de descripción se autocompleta con el usuario y la fecha exacta de creación, un detalle bastante útil para llevar un control de auditoría. Presionamos Next para avanzar a la asignación del servidor.
4. Asignar el Servidor (Server)
En la pantalla de Server, le indicaremos al asistente cuál de los equipos de nuestro inventario físico será el encargado de montar y gestionar los datos.
Al abrir el menú desplegable, verás tu orquestador principal (vbr-commander-white), pero para esta arquitectura debemos seleccionar el host aislado que agregamos previamente: vprx-yorha-bunker.mxlit.com.
Al seleccionarlo, el orquestador realiza una consulta rápida al sistema operativo a través del túnel seguro. Como puedes notar en la parte inferior de la captura, detecta automáticamente los puntos de montaje disponibles, mostrando nuestra ruta designada (/var/lib/veeam/veeam_storages/black_box_vault...) junto con el terabyte de capacidad que le asignamos. Con el servidor correcto en la mira, hacemos clic en Next para continuar con la configuración de la ruta de almacenamiento.
5. Configuración del Repositorio Inmutable
Llegamos a la pantalla más crítica de nuestra arquitectura: la definición del Hardened Repository. Aquí es donde el almacenamiento crudo se transforma en una bóveda criptográfica. Analicemos los parámetros clave para garantizar que la infraestructura ofrezca el máximo rendimiento sin sacrificar seguridad.
1. Ruta y Validación de Capacidad (Location)
Hemos apuntado el directorio directamente hacia el volumen montado en /var/lib/veeam/veeam_storages/black_box_vault/backups.
Tip de Implementación: Antes de continuar, es fundamental hacer clic en la opción Populate (a la derecha). Esta acción fuerza al orquestador a comunicarse con el appliance Linux, verificar que los permisos de lectura/escritura son correctos y calcular el espacio real del disco. Si este paso falla, es un indicador temprano de problemas de permisos en el sistema operativo; si muestra la capacidad correcta, el enlace es sólido.
2. Clonación Rápida en Volúmenes XFS (Fast Cloning)
Asegúrate de dejar habilitada la opción Use fast cloning on XFS volumes. Esta es la ventaja técnica más importante de utilizar Linux en el backend. Fast Clone aprovecha la tecnología de reflinks a nivel de bloques nativa del sistema de archivos XFS. En la práctica, cuando el servidor necesite agrupar los respaldos incrementales de la semana para generar un archivo completo (Synthetic Full), la operación tomará apenas unos segundos en lugar de horas. Aún mejor: no consumirá espacio adicional en disco, ya que el sistema simplemente crea punteros hacia los bloques de datos que ya existen.
3. Ventana de Inmutabilidad
Configurar Make recent backups immutable for: [ 7 ] days es nuestra póliza de seguro contra desastres. Siete días es el estándar de la industria para la retención a corto plazo. Esto asegura que, ante cualquier intento de cifrado por ransomware o un borrado malintencionado, exista al menos una semana entera de datos que físicamente no pueden ser alterados. Durante este periodo, ni siquiera el usuario root local tiene los privilegios necesarios para purgar estos archivos.
4. Control de Carga y Rendimiento (Load Control)
Hemos definido el límite máximo de tareas concurrentes exactamente en 4 (Limit maximum concurrent tasks to: 4). En el motor de Veeam, una “tarea” equivale al procesamiento de un disco virtual individual. Respetar este límite es vital por dos razones arquitectónicas:
- Gestión de Cómputo: Cada tarea concurrente consume aproximadamente 1 núcleo de CPU y 2 GB de RAM. Mantener este límite evita ahogar los recursos del servidor durante las ventanas de respaldo nocturnas.
- Prevención del I/O Blender: Si el almacenamiento físico subyacente utiliza discos mecánicos, enviar demasiadas tareas de escritura simultáneas satura los cabezales de lectura, lo que paradójicamente desploma la velocidad. Limitar las concurrencias mantiene un flujo de datos sostenido y secuencial.
6. El Servidor de Montaje (Mount Server)
En la fase de Mount Server, le definimos a la plataforma qué máquina será la encargada de “abrir” los archivos de respaldo cuando necesitemos extraer datos específicos.
Cuando necesitas recuperar un solo archivo de texto, o decides encender una máquina virtual directamente desde el repositorio (Instant VM Recovery), el archivo de respaldo principal (que está comprimido y cifrado) no se extrae por completo en el disco; en su lugar, se monta de forma temporal en la memoria de este servidor asignado.
Analicemos cómo configurar esta sección para sacar el máximo provecho de nuestra arquitectura 100% Linux:
- Windows mount server (Not specified): En nuestro entorno, dejaremos este campo vacío. Al estar operando con el nuevo Appliance de la v13 nativo en Linux, no necesitamos depender de un sistema operativo Windows para realizar las restauraciones. Si en algún momento requieres hacer recuperaciones granulares muy específicas a nivel de aplicación (por ejemplo, extraer un objeto de Active Directory), el motor de Veeam es lo suficientemente dinámico como para desplegar un Helper Appliance (una máquina virtual microscópica y temporal) al vuelo, hacer el trabajo y destruirla, ahorrándonos el costo y mantenimiento de una licencia de Windows Server permanente.
- Linux mount server (
vbr-commander-white.mxlit.com): Aquí es donde la topología brilla. Asignaremos directamente a nuestro orquestador maestro para esta tarea. Dado que nuestro servidor principal corre sobre Rocky Linux, cuenta con soporte nativo a nivel de kernel para leer sistemas de archivos como ext4, XFS y BTRFS (los estándares en cualquier distribución de Linux o hipervisor como Proxmox). Si el día de mañana borras por accidente el archivodocker-compose.ymlde alguno de tus contenedores, el Commander simplemente leerá los bloques inmutables de la bóveda, montará el sistema de archivos virtual y te permitirá extraer tu archivo de texto en cuestión de segundos.
⚙️ Concepto Avanzado: La Caché de Escritura (Write Cache)
La descripción de la interfaz menciona que las recuperaciones instantáneas requieren una carpeta de caché. Esto es un pilar de la inmutabilidad: cuando levantas una VM directamente desde el respaldo, el archivo alojado en tu bóveda permanece estrictamente de solo lectura. El sistema operativo de la máquina restaurada pensará que está operando normalmente, pero todas las escrituras o cambios temporales que genere mientras está encendida se desviarán hacia esta carpeta de caché administrada por el Mount Server, manteniendo la integridad total de tu copia de seguridad original.
Verifica que el servidor de Linux esté correctamente asignado en el menú desplegable y presiona Next para llegar a la pantalla de revisión final.
7. Revisión de Componentes y Escaneo de Bóveda (Review)
Llegamos a la antesala de la creación final. La pantalla de Review no es un simple trámite administrativo; es el panel donde el orquestador valida la topología lógica y determina qué servicios necesita inyectar para que la bóveda opere con todas sus capacidades.
Analicemos los dos elementos fundamentales de esta configuración:
1. El Escaneo de Respaldos Existentes (Search the repository…) En la captura, la casilla Search the repository for existing backups and import them automatically se encuentra desmarcada. Para nuestra arquitectura, esto es exactamente lo que buscamos, ya que estamos inicializando un directorio completamente limpio en nuestra bóveda inmutable.
⚙️ Escenario de Recuperación y Migración: Si en un futuro necesitas reconstruir tu servidor orquestador tras un desastre total, o si estuvieras mapeando un disco duro antiguo de tu entorno previo en versión 12 hacia este nuevo appliance, aquí es donde marcas la casilla. Al hacerlo, el motor rastrea el disco de almacenamiento, lee los metadatos de los archivos de respaldo huérfanos y los reinyecta automáticamente en la base de datos de tu nuevo servidor para devolverte el control.
2. La Inyección de Servicios (Component Status)
La tabla inferior detalla los microservicios que el orquestador requiere desplegar para gestionar los datos. En nuestro escenario, absolutamente todos los componentes marcan el estatus already exist (ya existen).
Esto sucede por un diseño de arquitectura eficiente: en el paso anterior decidimos que el propio servidor maestro (vbr-commander-white.mxlit.com) fungiera como nuestro servidor de montaje para Linux. Al ser el nodo central de nuestra red, ya cuenta con todo este arsenal instalado a nivel de sistema operativo.
Vale la pena destacar la potencia de los motores que vemos listados y que ya están listos para operar:
- Veeam Threat Hunter: Una de las defensas más agresivas de la plataforma. Es el motor de análisis heurístico que escanea silenciosamente el flujo de datos en busca de firmas de malware, ransomware y cifrado anómalo durante el proceso de respaldo, bloqueando amenazas antes de que se alojen en la bóveda.
- vPower NFS: Es el cerebro detrás del Instant VM Recovery. Este servicio permite que el orquestador emule un datastore NFS estándar, entregando los bloques de datos al hipervisor para encender máquinas virtuales pesadas directamente desde el archivo de respaldo comprimido en cuestión de segundos.
- VMware VDDK: Las librerías de desarrollo de discos virtuales (Virtual Disk Development Kit). Aunque tu clúster y cargas de trabajo operen sobre otras tecnologías de virtualización de código abierto, el appliance incluye estos binarios por defecto para garantizar una compatibilidad absoluta en arquitecturas de nube híbrida.
Una vez validado que todos los servicios internos responden correctamente y están listos para la acción, basta con presionar Next para aplicar los cambios en la base de datos.
8. Resumen y Verificación Final (Summary)
Llegamos al final del asistente. La pantalla de Summary nos presenta un reporte de auditoría completo con todos los parámetros que configuramos para nuestra bóveda inmutable. Es el momento crítico para hacer una doble validación antes de confirmar la creación de la infraestructura en la base de datos del orquestador.
Repasemos la topología que acabamos de armar:
- Identidad (Name): El repositorio quedó registrado oficialmente como
Bunker Black Box. - Arquitectura de Montaje: Confirmamos una operación 100% libre de Windows (
Not specified); todo el peso de las restauraciones granulares e instantáneas recae sobre nuestro orquestador principal en Linux (vbr-commander-white.mxlit.com). - Almacenamiento: Los datos apuntan exactamente a la ruta blindada
/var/lib/veeam/veeam_storages/black_box_vault/backups. - Control de Rendimiento: Un límite estricto de 4 tareas paralelas (
Max parallel tasks) para mantener un flujo de I/O saludable, acompañado de la función estrella Fast cloning on XFS volumes confirmada como Enabled para lograr respaldos sintéticos a velocidad hiperbólica.
🛠️ Troubleshooting en vivo: El detalle de la Inmutabilidad
Si observas detenidamente la última línea de nuestra captura de validación, notarás que el parámetro Backups immutable for quedó establecido en 7 días. Si en tu diseño de arquitectura original tenías planeado extender esta ventana de protección contra ransomware a 15 días, este es el momento exacto donde la pantalla de resumen demuestra su valor.
Es un error de capa 8 muy común: al configurar el repositorio, es fácil pasar por alto el valor predeterminado del sistema (7 días) en la pestaña anterior. Si esto te sucede, la plataforma es muy flexible para corregirlo:
- La solución inmediata: Antes de confirmar nada, simplemente haz clic en el botón Previous (Anterior) un par de veces para regresar a la pestaña de Repository, cambia el valor de 7 a 15, y vuelve a avanzar hasta el resumen.
- La solución post-despliegue: Si ya hiciste clic en Finish por inercia, no hay problema. Puedes navegar a la vista de Backup Infrastructure > Backup Repositories en tu consola, hacer clic derecho sobre el
Bunker Black Box, seleccionar Properties y modificar los días de retención en caliente. Cualquier respaldo nuevo que ingrese al volumen adoptará la nueva regla de 15 días de inmutabilidad al instante.
Una vez que te asegures de que todos los valores reflejan la estrategia exacta de tu centro de datos (ya sean 7, 15 o 30 días de blindaje), simplemente presiona el botón Finish.
9. El Resultado Final
Una vez que el asistente finaliza, la consola nos redirige a la vista principal de Backup Repositories. Es aquí donde vemos el fruto de todo nuestro trabajo de diseño y arquitectura.
Al observar la lista de infraestructuras, nuestro Bunker Black Box ya aparece registrado, en línea y listo para operar. Hay detalles críticos en este panel que validan que el despliegue técnico fue un éxito rotundo:
- El Distintivo “Hardened” (Type): Este es el indicador más importante de toda la configuración. Como se resalta en el recuadro rojo, el motor de Veeam reconoce oficialmente este volumen no como un simple destino de Linux, sino con la clasificación estricta de Hardened. Esto certifica que la comunicación asimétrica fue exitosa y que el demonio de inmutabilidad tiene control absoluto a nivel de sistema de archivos para bloquear cualquier intento de modificación o borrado prematuro.
- Capacidad y Ruta (Capacity & Path): El orquestador lee correctamente nuestro volumen de 1 TB (1023.5 GB) asignado desde el clúster de virtualización, apuntando exactamente a la ruta aislada dentro del host
vprx-yorha-bunker. - Auditoría de Creación: La columna de descripción confirma que la conexión inicial y la creación de la estructura de carpetas fue ejecutada exitosamente por nuestro administrador del sistema operativo (
veeamadmin).
🛡️ Mejores Prácticas: El Repositorio por Defecto
En la segunda fila notarás que existe un volumen llamado Default Backup Repository alojado en el orquestador principal. Este es un espacio local que el instalador crea automáticamente. Nunca utilices este repositorio por defecto para alojar las cargas de trabajo de tu entorno, ya que carece de las banderas de inmutabilidad.
La recomendación de diseño: Reserva este pequeño repositorio por defecto única y exclusivamente para almacenar los Configuration Backups (los respaldos diarios de la propia base de datos de Veeam). De esta manera, mantienes una separación lógica perfecta entre la configuración de la consola y la bóveda de datos blindada.
Conclusión
Al presentar el host subyacente de Linux de forma segura a través de la autenticación basada en certificados y asignar el almacenamiento en bloque directamente a nuestro Hardened Repository, hemos creado con éxito una bóveda blindada para nuestros datos. Aprovechar la tecnología Fast Clone de XFS garantiza respaldos sintéticos a alta velocidad sin consumo extra de capacidad, mientras que nuestro límite estricto de 4 tareas evita la degradación del rendimiento por I/O simultáneos. Con la inmutabilidad activada, nuestros respaldos ahora están físicamente protegidos contra alteraciones o ransomware, proporcionando una base sólida como una roca para nuestra estrategia de recuperación ante desastres.