Copias inmutables anti-ransomware: MinIO como S3 propio y Kopia en Linux y Windows

1. Introducción

Una copia de seguridad solo vale lo que vale su capacidad de sobrevivir al incidente que pretende cubrir. El ransomware moderno lo sabe: antes de cifrar los datos busca los respaldos, y si el agente de copia tiene permiso para borrar en el destino, ese permiso es exactamente el que se utiliza para destruirlos. De poco sirve entonces una copia diaria impecable si el atacante puede eliminarla con las mismas credenciales que la crearon.

La respuesta a ese problema se llama inmutabilidad, y en el mundo del almacenamiento de objetos tiene un nombre concreto: Object Lock. Es un mecanismo WORM (Write Once, Read Many): una vez escrito, un objeto no se puede modificar ni borrar hasta que expire el plazo de retención fijado, y esa regla la impone el propio almacenamiento, no la aplicación que escribe. Esta guía monta ese almacenamiento con MinIO, un servidor de objetos compatible con la API de S3 que se despliega con Docker, y respalda contra él dos equipos reales con Kopia, un motor de copias con cifrado extremo a extremo, deduplicación y soporte nativo de Object Lock.

2. Variables de esta guía

Todos los bloques usan los siguientes marcadores en MAYÚSCULAS. Sustitúyelos por los valores reales del entorno donde se aplique esta guía.

3. Arquitectura y flujo

Dos contenedores en el servidor central, y un agente de copia nativo instalado en cada equipo a respaldar. Igual que con los agentes de inventario, Kopia no vive en un contenedor: se instala sobre el sistema operativo de cada máquina, que es como se hace en un despliegue real.

   [UBUNTU SERVER]                    [WINDOWS 11]
        kopia                             kopia
          |                                  |
          |     copia cifrada por HTTPS      |
          |     (el agente inicia la conexion)
          +------------------+---------------+
                             |
                          red LAN
                             |
                             v
      +--------------------------------------------+
      |            SERVIDOR DOCKER                 |
      |   LAN: IP_HOST_DOCKER                      |
      |   WAN: IP_HOST_DOCKER_2                    |
      |                                            |
      |   [minio-proxy]  :8447 (S3)  :8448 (web)   |
      |          |                                 |
      |          v                                 |
      |   [minio]  :9000 (API S3)  :9001 (consola) |
      |          |                                 |
      |          v                                 |
      |   volumen minio-data                       |
      |   deposito "backups"                       |
      |   Object Lock = COMPLIANCE 30d             |
      +--------------------------------------------+

4. Requisitos

• Un host Linux con Docker Engine y el plugin Docker Compose (docker compose, sin guion) ya instalados, y preferiblemente con dos interfaces de red.
• Un Ubuntu Server y un Windows 11 en la misma red, que serán los equipos respaldados.
• Salida a Internet desde los tres equipos, para descargar las imágenes de Docker y los paquetes de Kopia.
• Espacio libre en el servidor para el volumen de copias. Ten presente que con Object Lock nada se borra antes de tiempo, así que el consumo solo crece durante el periodo de retención.
• Hora sincronizada en los tres equipos. La retención se calcula sobre fechas, y un reloj desviado desajusta la protección.

5. Levantar MinIO con Docker

Misma organización de siempre: cada stack en su carpeta dentro de /docker, y las credenciales en un .env aparte, nunca escritas dentro del docker-compose.yml.

sudo mkdir -p /docker/minio && cd /docker/minio

sudo nano .env

MINIO_ROOT_USER=clockworkadmin
MINIO_ROOT_PASSWORD=minio_root_pwd

Ahora el archivo del stack, en la misma carpeta:

sudo nano docker-compose.yml

services:
  minio:
    image: minio/minio:latest
    container_name: minio
    command: server /data --console-address ":9001"
    environment:
      MINIO_ROOT_USER: ${MINIO_ROOT_USER}
      MINIO_ROOT_PASSWORD: ${MINIO_ROOT_PASSWORD}
      TZ: Europe/Madrid
    volumes:
      - minio-data:/data
    healthcheck:
      test: ["CMD", "mc", "ready", "local"]
      interval: 5s
      timeout: 5s
      retries: 20
      start_period: 15s
    restart: unless-stopped

  proxy:
    image: nginx:alpine
    container_name: minio-proxy
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro
      - ./proxy-selfsigned.crt:/etc/nginx/certs/proxy-selfsigned.crt:ro
      - ./proxy-selfsigned.key:/etc/nginx/certs/proxy-selfsigned.key:ro
    ports:
      - "8447:8447"
      - "8448:8448"
    depends_on:
      minio:
        condition: service_healthy
    restart: unless-stopped

volumes:
  minio-data:

6. Configurar el proxy inverso con HTTPS propio

Genera un certificado autofirmado con clave EC, válido para las dos direcciones del servidor: la de la LAN por la que llegan los agentes y la de la WAN desde la que administras.

cd /docker/minio
sudo openssl ecparam -name prime256v1 -genkey -noout -out proxy-selfsigned.key
sudo openssl req -new -x509 -key proxy-selfsigned.key -out proxy-selfsigned.crt -days 825 \
  -subj "/CN=IP_HOST_DOCKER" \
  -addext "subjectAltName=IP:IP_HOST_DOCKER,IP:IP_HOST_DOCKER_2"

Ahora la configuración de Nginx, con un bloque por cada servicio:

sudo nano nginx.conf

resolver 127.0.0.11 valid=10s;

# ---------- API S3: por aqui hablan los agentes de copia ----------
server {
    listen 8447 ssl;
    server_name IP_HOST_DOCKER;

    ssl_certificate     /etc/nginx/certs/proxy-selfsigned.crt;
    ssl_certificate_key /etc/nginx/certs/proxy-selfsigned.key;

    # Sin limite de tamano: los bloques de una copia superan el limite por defecto
    client_max_body_size 0;
    ignore_invalid_headers off;
    proxy_buffering off;
    proxy_request_buffering off;
    chunked_transfer_encoding off;

    location / {
        set $upstream_minio http://minio:9000;
        proxy_pass $upstream_minio;

        # La firma de S3 incluye la cabecera Host: debe llegar intacta
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_http_version 1.1;
        proxy_connect_timeout 300;
        proxy_send_timeout 300;
        proxy_read_timeout 300;
    }
}

# ---------- Consola web de administracion ----------
server {
    listen 8448 ssl;
    server_name IP_HOST_DOCKER_2;

    ssl_certificate     /etc/nginx/certs/proxy-selfsigned.crt;
    ssl_certificate_key /etc/nginx/certs/proxy-selfsigned.key;

    location / {
        set $upstream_console http://minio:9001;
        proxy_pass $upstream_console;

        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # La consola usa WebSockets para el estado en tiempo real
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        chunked_transfer_encoding off;
    }
}

7. Arrancar el stack y verificar

cd /docker/minio
docker compose up -d
docker compose ps

Comprueba el registro de MinIO, donde debe aparecer que la API y la consola están escuchando:

docker logs -f minio

Sal con Ctrl+C y comprueba que el proxy responde por las dos interfaces:

curl -kI https://IP_HOST_DOCKER:8447/minio/health/live
curl -kI https://IP_HOST_DOCKER_2:8447/minio/health/live

8. La consola web y el cliente mc

Abre en el navegador, desde la red de administración:

https://IP_HOST_DOCKER_2:8448

Instalar el cliente mc en el servidor Docker

El cliente se instala en el host donde corre Docker, que es la máquina desde la que se administra el almacenamiento y donde ya está el certificado generado en la sección 6. Los equipos que se respaldan no lo necesitan: allí solo va Kopia.

cd /tmp
curl -LO https://dl.min.io/client/mc/release/linux-amd64/mc
ls -lh mc
file mc

Con el fichero verificado, ya se puede instalar:

chmod +x mc
sudo mv mc /usr/local/bin/
mc --version

Antes de crear el alias, enseña a mc a confiar en el certificado autofirmado copiándolo a su almacén propio. Es más limpio que ir arrastrando la opción --insecure en cada comando:

mkdir -p ~/.mc/certs/CAs
sudo cp /docker/minio/proxy-selfsigned.crt ~/.mc/certs/CAs/minio-clockwork.crt
sudo chown $USER: ~/.mc/certs/CAs/minio-clockwork.crt

mc alias set clockwork https://IP_HOST_DOCKER:8447 MINIO_ROOT_USER MINIO_ROOT_PASSWORD
mc admin info clockwork

9. Crear el depósito inmutable

Aquí está el corazón de la práctica. El depósito se crea con el bloqueo de objetos activado desde el primer momento, y acto seguido se le fija una retención por defecto en modo Compliance. Se hace desde mc, en el servidor Docker:

mc mb --with-lock clockwork/backups

mc retention set --default COMPLIANCE 30d clockwork/backups

mc retention info --default clockwork/backups
mc version info clockwork/backups

Governance y Compliance: la diferencia que lo cambia todo

10. Credenciales dedicadas para los agentes

Los agentes no deben usar la cuenta administradora. Se crea un usuario propio y se le concede acceso únicamente al depósito de copias, siguiendo el principio de mínimo privilegio:

mc admin user add clockwork KOPIA_ACCESS_KEY KOPIA_SECRET_KEY

sudo nano /docker/minio/kopia-policy.json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:ListBucketVersions",
        "s3:GetBucketLocation",
        "s3:GetBucketObjectLockConfiguration",
        "s3:GetObject",
        "s3:GetObjectVersion",
        "s3:PutObject",
        "s3:PutObjectRetention",
        "s3:GetObjectRetention",
        "s3:DeleteObject"
      ],
      "Resource": [
        "arn:aws:s3:::backups",
        "arn:aws:s3:::backups/*"
      ]
    }
  ]
}

mc admin policy create clockwork kopia-backups /docker/minio/kopia-policy.json
mc admin policy attach clockwork kopia-backups --user KOPIA_ACCESS_KEY

11. Kopia en Ubuntu Server

Kopia se instala desde su repositorio oficial de paquetes. Registra primero la clave de firma y el origen:

sudo mkdir -p /etc/apt/keyrings
curl -s https://kopia.io/signing-key | sudo gpg --dearmor -o /etc/apt/keyrings/kopia-keyring.gpg
echo "deb [signed-by=/etc/apt/keyrings/kopia-keyring.gpg] http://packages.kopia.io/apt/ stable main" | sudo tee /etc/apt/sources.list.d/kopia.list
sudo apt update

sudo apt install kopia -y
kopia --version

Confiar en el certificado del servidor

Kopia usa el almacén de certificados del sistema. En lugar de copiar el fichero a mano desde el servidor, se puede pedir directamente al propio servicio y añadirlo al almacén:

openssl s_client -connect IP_HOST_DOCKER:8447 -showcerts </dev/null 2>/dev/null \
  | openssl x509 -outform PEM \
  | sudo tee /usr/local/share/ca-certificates/minio-clockwork.crt

sudo update-ca-certificates

Crear los datos de prueba

sudo mkdir -p /datos/pruebas
echo "Informe trimestral - Clockwork Computer" | sudo tee /datos/pruebas/informe.txt
echo "Listado de clientes confidencial" | sudo tee /datos/pruebas/clientes.txt
sudo dd if=/dev/urandom of=/datos/pruebas/base-datos.bin bs=1M count=20
ls -lh /datos/pruebas

Crear el repositorio con retención

Este es el comando que enlaza Kopia con el bloqueo de objetos de MinIO. Los parámetros --retention-mode y --retention-period son los que hacen que cada bloque subido nazca ya protegido:

sudo kopia repository create s3 \
  --bucket=backups \
  --endpoint=IP_HOST_DOCKER:8447 \
  --access-key=KOPIA_ACCESS_KEY \
  --secret-access-key=KOPIA_SECRET_KEY \
  --region=us-east-1 \
  --retention-mode=COMPLIANCE \
  --retention-period=30d \
  --password=KOPIA_REPO_PASSWORD

Validar el proveedor de almacenamiento

El propio Kopia sugiere al terminar una comprobación que conviene no saltarse. No se limita a probar que hay conexión: escribe bloques reales y verifica que el almacenamiento se comporta como Kopia necesita —creaciones condicionales, listados coherentes, lecturas parciales y acceso concurrente—, que es justo donde suelen fallar las implementaciones de S3 de terceros:

sudo kopia repository validate-provider

sudo kopia maintenance set --extend-object-locks true
sudo kopia maintenance set --full-interval=24h
sudo kopia maintenance info

Primera copia

sudo kopia snapshot create /datos/pruebas
sudo kopia snapshot list

Conviene rematar comprobando que la protección quedó grabada en el repositorio, y no solo en la línea de comandos que lo creó:

sudo kopia repository status

12. Programar las copias en Ubuntu Server

Una copia manual demuestra que el montaje funciona; lo que protege de verdad es la que se ejecuta sola todos los días, sin que nadie se acuerde de lanzarla. En el Ubuntu Server se resuelve con las herramientas nativas del sistema: un servicio y un temporizador de systemd, que sustituyen con ventaja al viejo cron porque dejan registro consultable de cada ejecución y sobreviven a los apagados.

El temporizador de systemd

Primero, el fichero con la contraseña del repositorio, con permisos restringidos para que solo root pueda leerlo:

sudo mkdir -p /etc/kopia
sudo tee /etc/kopia/kopia.env >/dev/null <<'EOF'
KOPIA_PASSWORD=KOPIA_REPO_PASSWORD
KOPIA_CHECK_FOR_UPDATES=false
EOF
sudo chmod 600 /etc/kopia/kopia.env

sudo nano /etc/systemd/system/kopia-backup.service

[Unit]
Description=Copia de seguridad con Kopia hacia MinIO
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
EnvironmentFile=/etc/kopia/kopia.env
Environment=HOME=/root
ExecStart=/usr/bin/kopia --config-file=/root/.config/kopia/repository.config snapshot create /datos/pruebas
ExecStartPost=/usr/bin/kopia --config-file=/root/.config/kopia/repository.config maintenance run --full

sudo nano /etc/systemd/system/kopia-backup.timer

[Unit]
Description=Copia diaria con Kopia

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now kopia-backup.timer
systemctl list-timers kopia-backup.timer
sudo systemctl start kopia-backup.service
journalctl -u kopia-backup.service -n 30 --no-pager

13. Simulacro de ransomware

Con las copias en su sitio, toca comprobar que la inmutabilidad no es una casilla marcada en una configuración sino una defensa real. El simulacro tiene tres fases, en orden de agresividad creciente.

Fase 1: el ransomware ataca los datos originales

sudo bash -c 'for f in /datos/pruebas/*; do \
  openssl enc -aes-256-cbc -pbkdf2 -in "$f" -out "$f.locked" -k "rescate123" && rm -f "$f"; \
done'
ls -l /datos/pruebas

Fase 2: el atacante intenta borrar las copias

El siguiente paso de cualquier ransomware serio es ir a por el respaldo, usando las credenciales que encuentre en el equipo comprometido. Y ahí está la gracia de hacerlo desde el propio equipo atacado, no desde el servidor: es donde estarían realmente esas credenciales, dentro de la configuración del agente de copia. Como mc se instaló en el servidor Docker, hay que ponerlo también aquí:

cd /tmp
curl -LO https://dl.min.io/client/mc/release/linux-amd64/mc
file mc
chmod +x mc
sudo mv mc /usr/local/bin/
mc --version

mc alias set atacante https://IP_HOST_DOCKER:8447 KOPIA_ACCESS_KEY KOPIA_SECRET_KEY
mc ls atacante/backups/

mc rm --recursive --force atacante/backups/
mc ls atacante/backups/

mc ls --versions atacante/backups/

Un atacante con conocimientos lo sabría e iría a por las versiones. Aquí es donde entra el bloqueo:

mc rm --recursive --force --versions atacante/backups/

La prueba está en los identificadores de versión. Si comparas las líneas Removed con los Created delete marker del paso anterior, verás que coinciden uno a uno: lo que el comando ha eliminado son los propios marcadores de borrado, que no llevan retención porque no contienen datos. Y borrar un marcador no destruye nada; al contrario, devuelve la visibilidad al objeto que ocultaba. El resto de líneas corresponde a blobs temporales que dejó la validación del proveedor de la sección 11, que tampoco estaban protegidos.

Fase 3: el atacante consigue las credenciales de administrador

Vamos al peor escenario posible dentro del almacenamiento: que el atacante llegue a la cuenta administradora de MinIO. Se usa el alias clockwork, el de la cuenta root.

Hay dos formas de resolverlo, y ambas valen. La primera es ejecutar esta fase desde el servidor Docker, donde el alias ya existe. La segunda, más coherente con el relato —el atacante ha escalado privilegios y ahora tiene las credenciales del administrador—, es darlo de alta también en el equipo atacado:

mc alias set clockwork https://IP_HOST_DOCKER:8447 MINIO_ROOT_USER MINIO_ROOT_PASSWORD
mc ls clockwork/backups/

Con el alias resuelto, los intentos con la cuenta administradora:

mc rm --recursive --force --versions clockwork/backups/
mc rb --force clockwork/backups

Lo que el administrador sí puede hacer, y por qué no le sirve de nada

Queda un último intento, el más sutil: si no puede borrar, que rebaje el plazo de retención y espere a que caduque. Este comando sí se ejecuta correctamente:

mc retention set --default COMPLIANCE 1d clockwork/backups

La demostración es inmediata: pregunta por el valor por defecto del depósito y por el de un objeto concreto ya almacenado, y compáralos:

mc retention info --default clockwork/backups
mc retention info clockwork/backups/kopia.repository

14. Restauración

Primero: comprobar si hace falta deshacer algo

La recuperación no empieza restaurando, sino mirando en qué estado quedó el repositorio. Dependiendo de hasta dónde llegara el atacante, el punto de partida es distinto, así que lo primero es preguntárselo al propio agente:

sudo kopia repository status

Si el repositorio sigue oculto: retirar los marcadores

Solo en el primer caso. Los datos nunca se fueron, únicamente quedaron tapados, y mc lo revierte deshaciendo la última operación sobre los objetos versionados:

mc undo --recursive --force clockwork/backups/
mc ls clockwork/backups/

Ahora la restauración propiamente dicha. Localiza la copia y recupérala en una carpeta nueva, para poder comparar antes de sobrescribir nada:

sudo kopia repository status
sudo kopia snapshot list /datos/pruebas
sudo kopia snapshot list --all

sudo kopia snapshot restore ID_DE_LA_COPIA /datos/restaurado
ls -lh /datos/restaurado
cat /datos/restaurado/informe.txt

15. Vigencia de los bloqueos y mantenimiento

Este es el punto que más instalaciones tiene mal configuradas, y el que decide si la protección sigue viva dentro de seis meses o se apagó sin que nadie se diera cuenta.

El bloqueo de un objeto no es perpetuo: tiene una fecha de expiración, la que se fijó al subirlo. Pasada esa fecha, el objeto vuelve a ser borrable. Como una copia útil necesita seguir protegida indefinidamente mientras se conserve, Kopia va renovando la fecha de los bloques que siguen formando parte de alguna copia activa. Esa renovación ocurre durante el mantenimiento completo, y solo si está activada la opción correspondiente:

sudo kopia maintenance info

sudo kopia maintenance run --full

El riesgo del depósito lleno

mc quota set clockwork/backups --size 100gi
mc quota info clockwork/backups

Política de conservación de copias

Independientemente de la retención del almacenamiento, Kopia decide cuántas copias conserva. Ya viene con unos valores por defecto que la propia creación del repositorio mostró en pantalla —10 últimas, 48 horarias, 7 diarias, 4 semanales, 24 mensuales y 3 anuales—, generosos y pensados para conservar mucho historial. Conviene revisarlos y ajustarlos de forma consciente, sobre todo si el espacio es limitado y no se puede liberar antes de que expire el bloqueo:

sudo kopia policy set --global \
  --keep-latest=10 \
  --keep-daily=14 \
  --keep-weekly=4 \
  --keep-monthly=6

sudo kopia policy show --global

16. Kopia en Windows 11

Con el ciclo completo demostrado en Linux —copia, programación, ataque y recuperación—, toca comprobar que el mismo repositorio da servicio a un sistema operativo distinto sin cambiar nada del servidor. Este apartado repite el recorrido entero en un Windows 11: instalación del agente, confianza en el certificado, conexión al repositorio ya existente, copia programada y restauración, incluida la de los datos que respaldó la otra máquina.

La instalación se resuelve con el gestor de paquetes integrado. Ejecuta PowerShell como administrador:

winget install Kopia.KopiaCLI --accept-package-agreements --accept-source-agreements
kopia --version

Confiar en el certificado del servidor

En Linux el certificado se descargaba del propio servicio con openssl; en Windows es más cómodo traerlo por SCP, porque Windows 10 y 11 incluyen el cliente de OpenSSH de serie y scp funciona directamente desde PowerShell sin instalar nada. Pedirá la contraseña del usuario del servidor:

scp USUARIO_SERVIDOR@IP_HOST_DOCKER:/docker/minio/proxy-selfsigned.crt "$env:USERPROFILE\Downloads\proxy-selfsigned.crt"

Antes de instalarlo, conviene mirar qué se ha traído. Este paso confirma de un vistazo que el fichero es el certificado correcto y no otra cosa:

Get-PfxCertificate -FilePath "$env:USERPROFILE\Downloads\proxy-selfsigned.crt" | Format-List Subject, Issuer, NotAfter, Thumbprint

Ya se puede añadir al almacén de entidades de certificación de confianza del equipo:

Import-Certificate -FilePath "$env:USERPROFILE\Downloads\proxy-selfsigned.crt" -CertStoreLocation Cert:\LocalMachine\Root

Conectar al repositorio existente

kopia repository connect s3 --bucket=backups --endpoint=IP_HOST_DOCKER:8447 --access-key=KOPIA_ACCESS_KEY --secret-access-key=KOPIA_SECRET_KEY --region=us-east-1 --password=KOPIA_REPO_PASSWORD

New-Item -ItemType Directory -Force -Path C:\datos\pruebas
"Contrato de mantenimiento - Clockwork Computer" | Out-File C:\datos\pruebas\contrato.txt
"Presupuesto 2026" | Out-File C:\datos\pruebas\presupuesto.txt
kopia snapshot create C:\datos\pruebas
kopia snapshot list

kopia snapshot list --all

Programar la copia diaria con el Programador de tareas

$kopia = (Get-Command kopia).Source

$accion = New-ScheduledTaskAction -Execute $kopia -Argument "snapshot create C:\datos\pruebas"
$disparo = New-ScheduledTaskTrigger -Daily -At 02:00
$opciones = New-ScheduledTaskSettingsSet -StartWhenAvailable -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries

Register-ScheduledTask -TaskName "Kopia - Copia diaria" -Action $accion -Trigger $disparo -Settings $opciones -User $env:USERNAME -RunLevel Highest

Start-ScheduledTask -TaskName "Kopia - Copia diaria"
Get-ScheduledTaskInfo -TaskName "Kopia - Copia diaria"

Restaurar en Windows y desde Windows

El procedimiento es idéntico al de Linux: se localiza la copia por su identificador y se recupera en una carpeta nueva.

kopia snapshot list C:\datos\pruebas
kopia snapshot restore ID_DE_LA_COPIA C:\datos\restaurado
Get-ChildItem C:\datos\restaurado

17. Tabla de puertos y componentes

18. Errores comunes y cómo resolverlos

19. Notas de ampliación

El montaje de esta guía cubre lo necesario para tener copias inmutables funcionando y verificadas en dos sistemas operativos. Para un uso continuado conviene ampliar con:

• Un segundo destino fuera del emplazamiento, que es lo que completa la regla 3-2-1-1-0. Kopia admite varios repositorios, y MinIO puede replicar un depósito hacia otra instalación en otra ubicación.
• Alertas de copia fallida, porque el peor fallo de un sistema de respaldo es el que no avisa. Kopia puede lanzar acciones tras cada ejecución, y un temporizador que falla es un evento que el sistema de monitorización debería recoger.
• Integración con el SIEM, enviando el resultado de cada copia y los intentos de borrado rechazados por MinIO. Un rm denegado sobre el depósito de copias es, en sí mismo, un indicador de compromiso de primer nivel.
• Apertura automática de tickets en la mesa de ayuda cuando una copia falle dos días seguidos, para que el aviso no se quede en un correo que nadie lee.
• Cifrado y custodia de la contraseña del repositorio en un gestor de contraseñas propio, fuera de los equipos respaldados. Sin ella no hay restauración posible, y guardarla en la máquina que se respalda es un contrasentido.
• Endurecimiento del servidor de copias, que a estas alturas es el activo más valioso de la infraestructura: acceso administrativo restringido, sin servicios adicionales, y a poder ser en una red separada del resto.
• Pruebas de restauración periódicas y documentadas. Una copia que nunca se ha restaurado es una hipótesis, no una copia de seguridad.