Un Veeam Hardened Repository es un repositorio de copias sobre Linux en el que los archivos, durante un número de días que usted fija, no se pueden modificar ni borrar. Ni siquiera con la contraseña del administrador de Veeam. Por eso esta guía explica qué es, cómo se monta, qué exige al hardware, cuántos días de inmutabilidad elegir y cuánto disco necesita un caso real a tres años.
Además, está escrita en dos niveles. Si usted aprueba la compra del equipo, el cálculo del caso y la tabla de discos le bastan. En cambio, si lo va a instalar, encontrará los requisitos exactos de la documentación vigente y las condiciones que obligan a elegir un método de copia concreto.
La serie y el caso común
En concreto, esta es la cuarta de siete guías que comparten el mismo caso: el clúster de Proxmox de tres nodos, con siete máquinas protegidas y 902 GiB de datos. Por eso el repositorio que se dimensiona aquí es el que usarán los trabajos de la quinta guía.
- Qué es y para qué sirve, con el mapa de protección.
- Licencias: instancias, ediciones y Community Edition.
- Instalación: appliance, puertos y workers de Proxmox.
- Hardened Repository: copias inmutables en discos locales (esta guía).
- Backup job: métodos, retención GFS y copia fuera de sede.
- Instant Recovery: restaurar en minutos.
- SureBackup: verificar las copias e informar.
Qué es un Veeam Hardened Repository
Es un servidor Linux que Veeam usa como destino de las copias, con dos defensas añadidas. La primera es la inmutabilidad: durante el periodo fijado, los archivos de copia no se pueden mover, modificar ni borrar, aunque sí copiar. La segunda es la forma de autenticarse: el servidor de copias no guarda credenciales que un atacante pueda reutilizar para entrar al repositorio.
Para esa segunda defensa hay dos métodos. Por un lado, las credenciales de un solo uso: sirven una vez, para desplegar el componente de Veeam, y no se guardan en ninguna parte. Por otro, la autenticación por certificados, disponible cuando el repositorio se monta con el appliance de infraestructura de Veeam. En cualquier caso, dentro del repositorio solo pueden correr como administrador los procesos del propio componente de transporte.
Por qué importa: las copias son el primer objetivo
Un ataque de cifrado moderno no empieza por los datos, sino por las copias: si la empresa no puede restaurar, pagar parece la única salida. Lo explicamos con casos reales en la guía de respaldo inmutable ante el ransomware. Por eso, un repositorio en el que basta la contraseña del servidor de copias para borrarlo todo no protege de ese escenario.
En cambio, con un repositorio endurecido de Veeam, aunque alguien tome el control del servidor de copias, las copias dentro del periodo de inmutabilidad siguen ahí. Es decir, la inmutabilidad no evita el ataque, pero garantiza que exista algo desde donde volver.
Dos formas de montar el Veeam Hardened Repository
| Aspecto | Veeam Infrastructure Appliance | Linux configurado a mano |
|---|---|---|
| Sistema | Veeam JeOS desde una ISO | La distribución que usted elija, compatible |
| Mínimos | 2 núcleos, 8 GB, dos discos de 120 GB | Los de cualquier repositorio de Veeam |
| Autenticación | Por certificados; SSH no se usa | Credenciales de un solo uso |
| Discos | Los adicionales se unen al segundo disco | Volumen XFS que usted prepara |
| Dominio | No se puede unir | No debe unirse |
| Mantenimiento | Actualización desde el menú de arranque | Parches del sistema a su cargo |
Para una empresa mediana, el appliance simplifica el trabajo. Además, reduce las decisiones que pueden salir mal: trae el sistema mínimo, no admite SSH para este rol y obliga a la autenticación multifactor si no hay una cuenta de responsable de seguridad. Por eso es la opción del caso, instalada en un servidor físico llamado repo-01.
Requisitos del Veeam Hardened Repository
La documentación de la compilación 13.1.1.18 fija estas condiciones. Para reducir la superficie de ataque, recomienda además un equipo físico con discos locales:
- Almacenamiento de bloques. Discos locales o conectados por iSCSI o Fibre Channel. No sirven un recurso NFS ni uno SMB.
- Sistema de archivos XFS. Tiene que admitir archivos inmutables, y XFS se recomienda por rendimiento y por la clonación de bloques.
- RAID 6 o 60 para los datos, con caché de escritura diferida y bandas de 128 o 256 KB. Para el sistema, RAID 1 en SSD de al menos 100 GB.
- Caché interna de los discos desactivada, para no perder escrituras en un corte.
- Red redundante hacia el servidor de copias.
- Un solo servidor de copias. El repositorio no se comparte entre dos instalaciones de Veeam.
- Nada de Veeam Agent para Linux instalado en el repositorio.
Si elige Linux configurado a mano, hay tres detalles más. La carpeta de las copias debe pertenecer a la cuenta con la que se conecta Veeam, con permisos 0700 y sin bit pegajoso. Además, la ruta no puede contener enlaces simbólicos. Y el cortafuegos debe ser firewalld, ufw o iptables; si no hay ninguno, los puertos se abren a mano.
El periodo de inmutabilidad: cuántos días
Al añadir el repositorio, el asistente pide el periodo de inmutabilidad, que admite de 7 a 9.999 días. La cifra no se elige al azar: tiene que cubrir el tiempo que puede pasar entre que alguien entra en la red y que alguien se da cuenta. Por eso, en el caso se fijan 14 días, igual que los 14 puntos diarios de la retención corta.
Sin embargo, la inmutabilidad impone una condición al método de copia. Como un archivo inmutable no se puede fusionar ni borrar antes de tiempo, el repositorio solo admite el incremental con fulls periódicos, activos o sintéticos. Es decir, no admite el forever forward incremental, que fusiona el primer full cada noche, ni el incremental inverso, que además ya no existe para trabajos nuevos en la versión 13.
Cómo convive con la retención
La retención dice cuántos puntos se conservan; la inmutabilidad, cuánto tiempo no se pueden tocar. Cuando un punto sale de la retención pero sigue inmutable, el repositorio lo guarda hasta que vence el plazo. En la práctica, eso añade hasta una semana más de cadena: en el caso, unos 99 GiB. Por otra parte, los archivos de metadatos no pueden ser inmutables, porque se actualizan en cada pasada, así que para importar una copia se usan los archivos de full.
Fast clone en XFS: la cifra que decide los discos
Cada semana, el trabajo crea un full sintético a partir de los incrementales. Sin clonación de bloques, ese full se escribe entero: 451 GiB más cada sábado. En cambio, con el fast clone de XFS, el full nuevo apunta a los bloques que ya existen y solo escribe lo que cambió. Por lo tanto, la diferencia entre activar la casilla y no activarla se mide en discos.
Para el caso, se supone que la compresión y la deduplicación reducen los datos a la mitad, y que cada máquina cambia de forma distinta. Por ejemplo, la base del ERP cambia el 8 % cada día, pero casi siempre sobre los mismos bloques, así que en un mes solo el 25 % de sus bloques es nuevo. Estas son las cuentas, con los supuestos a la vista:
| Pieza de la retención | Sin fast clone | Con fast clone |
|---|---|---|
| Full comprimido | 451 GiB por cada full | 451 GiB una vez |
| 14 incrementales diarios | 198,5 GiB | 198,5 GiB |
| 4 puntos semanales | 4 fulls | 94,2 GiB de bloques nuevos |
| 12 puntos mensuales | 12 fulls | 637,9 GiB de bloques nuevos |
| Trabajo diario | 8.768 GiB | 1.382 GiB |
El resultado es contundente: el fast clone ahorra el 84 % del espacio del trabajo diario. Además, el hardened repository de Veeam lo aprovecha sin configuración extra, siempre que el volumen sea XFS y se marque la opción al añadirlo.
Cuánto disco necesita el caso a tres años
Al trabajo diario se suman dos piezas. Por un lado, la cadena del ERP cada cuatro horas, que programa la quinta guía: 271 GiB con siete días de retención. Por otro, la semana extra que retiene la inmutabilidad: 99 GiB. Después se aplica el crecimiento y la regla de no pasar del 80 %, las mismas que usamos en la guía del servidor NAS:
| Paso | Con fast clone | Sin fast clone |
|---|---|---|
| Necesidad hoy | 1.752 GiB (1,71 TiB) | 9.138 GiB |
| A tres años, con 22 % anual | 3,11 TiB | 16,2 TiB |
| Capacidad útil mínima, sin pasar del 80 % | 3,88 TiB | 20,25 TiB |
Con esa cifra, el arreglo se elige solo. En RAID 6 se pierden dos discos por la paridad doble, como explica la guía de niveles de RAID, y la capacidad útil queda así:
| Arreglo en RAID 6 | Capacidad útil | ¿Cubre 3,88 TiB? |
|---|---|---|
| 4 discos de 2 TB | 3,64 TiB | No |
| 4 discos de 4 TB | 7,28 TiB | Sí, con holgura |
| 6 discos de 2 TB | 7,28 TiB | Sí, con más discos en paralelo |
| 6 discos de 4 TB | 14,55 TiB | Sí, para retenciones más largas |
En definitiva, con fast clone bastan cuatro discos de 4 TB. Sin él, harían falta más de 20 TiB útiles, es decir, un equipo cinco veces mayor para guardar exactamente las mismas copias.
Por qué no sirve un NAS por NFS ni backup-01
La tentación es usar lo que ya existe. Sin embargo, un recurso NFS o SMB queda excluido por diseño, porque el repositorio necesita almacenamiento de bloques para hacer inmutables los archivos. Un NAS sí podría entregar un volumen por iSCSI, pero entonces quien administre el NAS puede borrar ese volumen entero, con copias inmutables o sin ellas.
Por su parte, backup-01 falla por otra razón: es una máquina virtual dentro del mismo clúster que protege. Por eso la primera guía la retira y repo-01 es un servidor físico, en la red de copias y fuera del dominio.
La tercera copia, fuera de la sede
El repositorio endurecido cubre la segunda copia de la regla 3-2-1, pero vive en el mismo edificio. Por eso falta la tercera: una copia en almacenamiento de objetos en la nube, también con inmutabilidad. Esa copia no la hace el trabajo principal, sino un backup copy job, y en el caso ocupa 1,25 TiB. Su programación, su tiempo de subida y su retención están en la quinta guía. Además, si la copia fuera de sede también va a un repositorio endurecido, su inmutabilidad exige activar la retención GFS.
Errores frecuentes con el repositorio endurecido de Veeam
| Error | Qué provoca | Qué hacer |
|---|---|---|
| Montarlo sobre NFS | No se admite | Discos locales o iSCSI |
| Formatear en ext4 o sin reflink | Sin fast clone, cinco veces más disco | XFS con la opción marcada |
| Unirlo al dominio | Una credencial robada del dominio llega al repositorio | Fuera del dominio |
| Dejar SSH abierto para siempre | Una puerta más para entrar | Solo para diagnóstico y luego cerrarlo |
| Periodo de inmutabilidad corto | El ataque se descubre cuando las copias ya vencieron | Al menos la retención corta |
| Configurar forever forward incremental | El trabajo no se puede guardar en este repositorio | Incremental con fulls sintéticos |
Preguntas frecuentes sobre el Veeam Hardened Repository
¿Qué pasa si el servidor de copias se pierde?
Las copias siguen en el repositorio. Se reinstala el servidor, se restaura su configuración y, si hiciera falta, se importan las copias desde los archivos de full.
¿Puedo acortar el plazo de inmutabilidad después?
Las copias ya escritas conservan su plazo hasta que vence. Por eso conviene elegir bien el número desde el principio.
¿El repositorio puede hacer de proxy o de otro rol?
Por seguridad, la documentación lo limita a una excepción de otra plataforma que este caso no usa. También admite funcionar como repositorio de aplicaciones, aunque el fabricante advierte que combinar los dos roles aumenta la superficie de ataque.
¿Dónde están los requisitos oficiales?
Están en la página de requisitos y limitaciones del centro de ayuda, y el periodo de 7 a 9.999 días, en la del asistente del repositorio.
En resumen: el repositorio endurecido de Veeam en cuatro ideas
En resumen, un Veeam Hardened Repository guarda copias que nadie puede borrar durante el plazo fijado, ni siquiera desde el servidor de copias. Además, exige Linux, almacenamiento de bloques y el incremental con fulls periódicos. El fast clone de XFS decide el tamaño: en el caso, cuatro discos de 4 TB en lugar de más de 20 TiB. Y la inmutabilidad añade una semana de cadena que hay que contar.
Con el destino listo, falta decidir qué se copia, cuándo y cuánto se conserva. Eso es el backup job, el tema de la quinta guía.
Cómo lo aborda KHARONTE
Dentro de nuestra línea de continuidad y respaldo diseñamos, implementamos y administramos Veeam Backup con respaldo local, en el almacenamiento en red o en la nube: dimensionamos el repositorio con sus datos reales, fijamos la inmutabilidad y comprobamos que las copias restauran. No vendemos equipos de almacenamiento: le decimos qué pedir y lo dejamos funcionando.
Además, el respaldo puede ir solo o junto al resto de nuestros servicios administrados de TI. Si quiere conocer todas las líneas, estos son nuestros servicios de TI para empresas.
Hablemos de la TI de su empresa
Cuéntenos qué necesita su operación y le enviamos una propuesta por escrito. Cada línea del portafolio se contrata por separado.
