Qué va a configurar
Los atacantes que entran en una red suelen intentar borrar o cifrar las copias de seguridad antes de cifrar los servidores. Por eso no basta con una copia que una cuenta de administrador robada pueda borrar. Esta guía construye con BackupZit una protección por capas: una copia principal en almacenamiento local, una copia en otro lugar y un almacenamiento donde las copias no se pueden destruir antes de que termine un periodo fijado, ni siquiera con las credenciales del almacenamiento. BackupZit es gratuito y de código abierto (AGPLv3); todo lo descrito aquí forma parte del producto gratuito.
La regla 3-2-1, y 3-2-1-1-0
La regla 3-2-1: 3 copias de sus datos, en 2 soportes distintos, 1 de ellas fuera de la empresa. La ampliación 3-2-1-1-0 añade 1 copia inmutable o sin conexión y 0 errores al verificar las copias. En BackupZit:
| Parte | En BackupZit |
|---|
| 3 copias | Los datos de producción, un trabajo de copia de seguridad y un trabajo de copia secundaria. |
| 2 soportes | Dos destinos de almacenamiento, p. ej. un NAS por SMB o SFTP y un bucket S3. |
| 1 externa | La copia va a la nube (S3, Azure Blob Storage) o a un repositorio reforzado en otro edificio. |
| 1 inmutable o sin conexión | S3 con Object Lock, un repositorio reforzado o discos USB rotativos. |
| 0 errores | Las pruebas de restauración automáticas y la verificación de todos los datos guardados, con una alerta cuando algo falla. |
Necesita una consola BackupZit con agentes en las máquinas que protege; las guías de Proxmox VE, Hyper-V e imágenes de disco de Windows muestran esos primeros pasos.
Paso 1 — Almacenamiento principal para restauraciones rápidas
En la consola abra Almacenamiento → Añadir destino de almacenamiento. Para la primera copia elija almacenamiento de la red local, para que las copias y restauraciones vayan a toda velocidad: un recurso compartido SMB en un servidor de archivos o NAS, o un servidor Linux o NAS por SFTP (su clave de host queda fijada). Dé al destino una cuenta propia que solo pueda escribir en la carpeta de copias, y no una el almacenamiento de copias al dominio de Windows.
Al guardar, la consola prueba el destino en el acto: una contraseña, clave de host o recurso compartido incorrectos se ven ahora y no en la primera copia. Probar conexión en la lista de almacenamiento repite la prueba.
Paso 2 — Añadir almacenamiento inmutable
BackupZit tiene dos tipos de almacenamiento en los que las copias no se pueden borrar ni sobrescribir antes de que termine su periodo. Lo ideal es que también esté fuera de la empresa, para que un solo destino cubra ambas cosas.
Opción A: S3 con Object Lock
- Cree el bucket con Object Lock activado — en AWS, Wasabi y Backblaze B2 es una opción al crear el bucket; en MinIO,
mc mb --with-lock.
- Añada una regla de ciclo de vida que borre las versiones no actuales tras un día (MinIO:
mc ilm rule add --noncurrent-expire-days 1 --expire-delete-marker). Borrar una copia bloqueada solo añade un marcador de borrado; la regla libera el espacio cuando terminan los bloqueos.
- En la consola añada un destino del tipo Compatible con S3 (AWS, Wasabi, Backblaze B2, MinIO, …) con el endpoint, el bucket y una clave de acceso para ese bucket.
- Marque Copias inmutables (S3 Object Lock, modo de cumplimiento) durante … días (30 por defecto) y elija un periodo al menos tan largo como la retención que quiere proteger.
Cada archivo que escriben los agentes queda entonces bloqueado en modo de cumplimiento durante ese periodo más un día: nadie — ni un atacante con las claves ni el propietario del bucket — puede borrarlo o sobrescribirlo antes. Los datos que una copia nueva reutiliza de las anteriores reciben un bloqueo prolongado, así que cada punto de restauración queda protegido durante todo el periodo. En almacenamiento inmutable la prueba de conexión solo inicia sesión y lista, y comprueba que el bucket tenga realmente Object Lock.
Azure y Google Cloud: para Azure Blob Storage active en Azure la inmutabilidad a nivel de versión con una directiva de retención basada en tiempo en el contenedor. Google Cloud Storage funciona como destino S3, pero sin la opción Object Lock; en su lugar defina una directiva de retención del bucket (y bloquéela) en Google Cloud.
Opción B: repositorio reforzado en su propio servidor Linux
Un servidor Linux dedicado ejecuta backupzit-repo (los paquetes deb y rpm se adjuntan a cada versión en GitHub):
apt install ./backupzit-repo_*.deb # o: dnf install ./backupzit-repo-*.rpm
vi /etc/backupzit-repo/repo.env # BACKUPZIT_REPO_LOCK_DAYS=30
systemctl start backupzit-repo
backupzit-repo add-key office-console # muestra la clave de acceso una sola vez
backupzit-repo fingerprint # huella del certificado
En la consola añada un destino del tipo Repositorio reforzado (backupzit-repo en Linux, inmutable) con la dirección del servidor (puerto 8500 por defecto), la clave de acceso y la huella.
- Los agentes y la consola solo pueden añadir archivos; los existentes nunca se sobrescriben.
- Cada archivo recibe el atributo inmutable (
chattr +i) durante el periodo configurado en ese servidor, más un día. Ni siquiera root puede borrarlo sin quitar antes el atributo.
- Los borrados desde los clientes — por la retención o por un atacante con la clave de acceso — solo ocultan los archivos hasta que termina su periodo.
- El periodo se configura solo en el servidor del repositorio; la consola y los agentes no pueden cambiarlo.
Tras la configuración, desactive SSH y cualquier otro acceso remoto a ese servidor y proteja su consola local, iDRAC/iLO o el acceso al hipervisor: la protección es tan fuerte como su cuenta root.
Paso 3 — Cifrado y clave de recuperación
Deje activado Cifrar las copias (AES-256) (por defecto). El contenido de los archivos, sus nombres, la estructura de carpetas y las listas de instantáneas se cifran con AES-256-GCM antes de salir del agente, y cualquier cambio en los datos se detecta. La inmutabilidad impide el borrado, el cifrado impide la lectura: necesita ambos.
Para cada destino cifrado la consola muestra una Clave de recuperación y ofrece una hoja de recuperación. Guárdela sin conexión y separada de las copias: con la clave, la ubicación del almacenamiento y sus credenciales puede restaurar incluso sin la consola; sin la clave nadie puede leer las copias, tampoco el soporte de BackupZit.
Paso 4 — Trabajo de copia y retención
Cree el trabajo en Trabajos de copia con el almacenamiento principal del paso 1. En Conservar copias configure las N más recientes y puntos de restauración diarios, semanales y mensuales; por ejemplo, 3 recientes, 7 diarias, 4 semanales y 6 mensuales conservan cerca de medio año con unos 20 puntos de restauración. La deduplicación guarda los datos sin cambios una sola vez.
Objetivo de punto de recuperación (RPO), horas indica cuánto puede envejecer la última copia correcta, p. ej. 26 para un trabajo diario. Un trabajo que lo incumple aparece en el panel y se notifica, lo que también detecta un agente desconectado durante días o una programación borrada por error.
Paso 5 — Copia externa con un trabajo de copia secundaria
Cree un segundo trabajo y elija Copia secundaria. En Copiar las copias de seleccione el trabajo del paso 4 y, como Destino de almacenamiento, el destino inmutable o externo del paso 2.
- El agente del trabajo de origen copia las copias existentes; la máquina protegida no se vuelve a leer.
- Solo se envían los datos que aún no están en el destino, cifrados de nuevo con la clave del destino.
- Tras cada copia del trabajo de origen (por defecto) mantiene la copia al día; una programación normal también sirve, p. ej. una vez por noche con una línea lenta.
- La copia tiene su propia retención, p. ej. 7 diarias en el NAS y 12 mensuales en la nube. Cada punto de restauración queda bloqueado N días desde su creación; con un bloqueo de 30 días, los puntos mensuales más antiguos ya no están protegidos. Un bloqueo más largo protege más de ellos, pero también ocupa más datos.
Las copias de archivos y de VM (Proxmox VE, Hyper-V, VMware) se restauran desde la copia secundaria igual que desde el original; las copias de imágenes de disco, con el agente de línea de comandos. Copiar ahora inicia una copia al momento.
Copia sin conexión para oficinas pequeñas: el tipo de destino Discos USB / extraíbles rotativos (copias sin conexión) encuentra los discos por su etiqueta de volumen (BZBACKUP1, BZBACKUP2 …). Dirija a él un trabajo de copia secundaria, cambie los discos p. ej. cada semana y guarde el desconectado en un lugar seguro. Si no hay ningún disco conectado, la ejecución falla con una alerta.
Paso 6 — Pruebas de restauración y verificación de datos
Una copia solo está probada cuando se ha restaurado. En Configuración → Pruebas de restauración:
- Probar automáticamente la copia más reciente de cada trabajo (semanal por defecto): una muestra aleatoria de archivos de la copia más reciente se restaura en una carpeta temporal, se verifica byte a byte con las sumas de comprobación guardadas y se borra; en las imágenes de disco se verifican bloques aleatorios. Así se ponen a prueba el acceso al almacenamiento, las credenciales, la clave y los datos.
- Verificar los datos guardados (mensual por defecto): cada fragmento de datos de cada repositorio se lee y se verifica, lo que revela pronto un disco de NAS que falla o la degradación silenciosa de datos. En S3 y Azure solo se ejecuta con También en almacenamiento en la nube (S3, Azure) activado: lo descarga todo, tenga en cuenta los costes de descarga.
- Los trabajos de VM de Proxmox pueden añadir una prueba de arranque que inicia cada VM desde la copia con la red desconectada.
Probar restauración y Verificar datos en la página de un trabajo las inician al momento. Los resultados aparecen en Actividad e Informes; una prueba fallida envía una alerta como cualquier fallo.
Paso 7 — Alertas y detección de ransomware
Una copia externa que lleva semanas fallando no es una copia. Configure Configuración → Notificaciones por correo (compruébelo con Enviar correo de prueba) y deje activado Fallos: un correo por cada ejecución fallida con el motivo — copias, copias secundarias, restauraciones y pruebas de restauración — y, si lo desea, un informe diario. Configuración → Chat y webhooks envía lo mismo a Slack, Microsoft Teams o cualquier endpoint HTTP. En el panel, Requiere atención lista los trabajos fallidos, las programaciones y RPO incumplidos, los agentes desconectados y el almacenamiento lleno al 90 % o que se llenará en 30 días.
Además, cada copia se compara con el historial reciente de su trabajo. Se marca como sospechosa cuando han cambiado muchos más archivos de lo habitual, los datos nuevos ya no se comprimen (los archivos cifrados parecen aleatorios), el número de archivos ha caído un tercio o más o la cantidad de datos nuevos se ha disparado. BackupZit envía entonces una alerta, la muestra en copias sospechosas por revisar y pausa la retención del trabajo (La retención está en pausa), de modo que las últimas copias limpias no se borran aunque sigan llegando copias dañadas. Tras revisar la máquina, haga clic en Revisado: reanudar la retención.
Paso 8 — Proteger la consola
El almacenamiento inmutable protege las copias; la consola sigue decidiendo qué se copia y qué se conserva. En Configuración → Inicio de sesión y seguridad exija la autenticación de dos factores a los administradores y active la Aprobación de cuatro ojos: borrar trabajos o destinos de almacenamiento, acortar la retención, reanudar la retención tras una copia sospechosa y desactivar la aprobación requieren entonces a un segundo usuario. Mantenga la consola en la red interna, no publique el puerto 8443 en Internet y use una VPN para la administración remota. Con Configuración → Copia de la consola, la consola se copia además a sí misma cada día en un destino de almacenamiento en red.
Después de un ataque
Si se borraron o sobrescribieron copias, lea el almacenamiento tal como estaba antes del ataque — solo lectura, en S3 con Object Lock y en el repositorio reforzado:
backupzit-agent snapshots --repo <repositorio> --as-of 2026-10-01T14:30
backupzit-agent restore --repo <repositorio> --as-of 2026-10-01T14:30 --target D:\Restore latest
En un repositorio reforzado el administrador también puede recuperar los archivos ocultos para que las copias sigan con normalidad:
backupzit-repo status
backupzit-repo undelete --since 2026-10-01T14:00
Límites que conviene conocer
- La inmutabilidad solo dura lo que dura el bloqueo. Una copia borrada desaparece de verdad cuando termina su periodo; elija el periodo pensando en cuánto tiempo podría pasar inadvertido un ataque.
- Un repositorio reforzado es tan seguro como su cuenta root y el acceso a su consola, iDRAC/iLO o hipervisor.
- SMB, SFTP y los discos locales no tienen inmutabilidad propia; combínelos con una copia inmutable o sin conexión.
- Los datos bloqueados ocupan espacio hasta que termina su bloqueo, incluso tras borrarlos; sin la regla de ciclo de vida no se libera espacio en S3.
- La inmutabilidad no limpia los datos: los archivos cifrados antes de la copia se copian cifrados. Restaure un punto anterior al ataque; la detección los conserva pausando la retención.
- Sin la clave de recuperación nadie puede leer las copias cifradas.
- La aprobación de cuatro ojos cubre la consola; los grupos de administradores de Active Directory o Entra ID deben protegerse allí.
