En la práctica, una “copia de seguridad” que no se puede restaurar con garantías no es una copia: es una sensación de seguridad.

Las organizaciones de referencia coinciden en una idea simple: las copias deben hacerse, mantenerse y probarse. Por ejemplo, NIST en su guía sobre protección de datos frente a ransomware y pérdida de datos insiste en que los planes de backup deben ser prácticos y, sobre todo, alineados con el objetivo de recuperación (no solo con “tener copias”).
CISA también recalca la necesidad de mantener backups offline, cifrados y probar su integridad y disponibilidad con regularidad.

Nosotros lo trabajamos como un plan con cuatro partes:

  • Qué se respalda (y qué no).
  • Cuándo y con qué retención/versionado.
  • Dónde vive (y si está dentro o fuera del “radio de explosión”).
  • Cómo se restaura (procedimiento probado).

1) Qué “desastre” evita un buen plan de copias de seguridad

Un plan de backups bien diseñado convierte incidentes graves en problemas manejables cuando el origen es:

  • Ransomware o sabotaje: cifrado/borrado de datos y sistemas.
  • Errores humanos: borrado accidental, cambios en producción, “limpiezas” mal hechas.
  • Fallos de actualización: plugin/tema/core, dependencias, cambios de servidor.
  • Corrupción silenciosa: datos que se dañan sin que nadie se dé cuenta (y se arrastran).
  • Incidentes de hosting: caída, pérdida de volúmenes, misconfig, errores de proveedor.

CISA advierte que muchas variantes de ransomware intentan encontrar y borrar/cifrar backups accesibles, precisamente para forzar el pago. Por eso insiste en mantener backups offline y testear restauraciones.
Microsoft también enfatiza que los ataques apuntan a datos, backups y documentación necesaria para recuperarse sin pagar, y recomienda preparar el plan antes del incidente.

2) Historia (ficticia, basada en patrones reales): “la semana que dejó de facturar la web”

Caso ficticio: Una pyme con web corporativa + formularios de captación. Un lunes, la web carga, pero el panel de administración no. El hosting muestra consumo anómalo y el proveedor bloquea el sitio por actividad maliciosa.

El equipo descubre que se ejecutó código no autorizado y se cifraron varios archivos. Lo peor: la “copia de seguridad diaria” estaba en la misma cuenta, accesible con las mismas credenciales, y también fue borrada.

Resultado: 5 días de parón parcial (ventas/leadgen), reconstrucción manual de contenidos, pérdida de datos de formularios y, además, crisis reputacional (“¿cómo no tenían backup?”).

La diferencia entre incidente y desastre no fue la sofisticación del ataque, sino la ausencia de:

  • copia fuera del radio de explosión,
  • retención/versionado real,
  • procedimiento de restauración probado.

Este patrón encaja con la advertencia de CISA: backups accesibles pueden ser objetivo directo de ransomware.

3) Definir RPO y RTO: el marco que decide cuánto duele un incidente

Antes de hablar de herramientas, definimos dos métricas:

  • RPO (Recovery Point Objective): cuánto dato podemos permitir perder.
    Ej.: “podemos perder como máximo 4 horas de pedidos/leads”.
  • RTO (Recovery Time Objective): cuánto tiempo podemos estar caídos antes de que sea inaceptable.
    Ej.: “debemos volver online en menos de 2 horas”.

Sin RPO/RTO, todo lo demás se vuelve opinable. Con RPO/RTO, el plan se diseña con objetivos medibles:

  • frecuencia de backups (para RPO),
  • método y automatización de restauración (para RTO),
  • arquitectura (para que no se rompa bajo ataque).

4) La regla práctica: 3-2-1… y fuera del radio de explosión

La regla 3-2-1 (3 copias, 2 medios, 1 fuera) es útil como idea, pero hoy añadimos un matiz imprescindible:

La copia “fuera” debe estar fuera del radio de explosión de credenciales y acceso.

CISA recomienda mantener backups offline porque el ransomware suele intentar eliminar/cifrar backups accesibles.
En otras palabras: si el atacante llega al servidor o al panel del proveedor, no queremos que llegue también a la copia.

Ejemplo de arquitectura razonable para una web:

  • Copia 1: producción (la realidad).
  • Copia 2: backup local/rápido (snapshots o backups diarios para restauración rápida).
  • Copia 3: backup externo con control de borrado/modificación (inmutable o aislado).

5) Offline e inmutable: por qué hoy es obligatorio pensar en ransomware

Dos conceptos que marcan diferencia:

5.1 Backups offline (air-gapped lógico)

No significa “cinta física” necesariamente. Significa que:

  • no están montados permanentemente como un disco accesible desde producción,
  • no comparten las mismas credenciales de administración,
  • no pueden ser borrados desde el mismo punto comprometido.

CISA lo expresa de forma muy concreta: mantener backups offline porque ransomware busca y elimina los backups accesibles.

5.2 Backups inmutables (WORM / Object Lock)

La inmutabilidad implica que, durante un periodo de retención, el backup no se puede modificar ni borrar, incluso si un actor obtiene acceso al almacenamiento. Google Cloud, por ejemplo, describe “backup vault storage” con backups “immutable” e “indelible” (no modificables y no borrables) para protegerlos contra manipulación y borrado no autorizado.

Interpretación práctica para una pyme/agencia: si el presupuesto no permite una solución enterprise, al menos necesitamos una copia con:

  • retención estricta,
  • permisos mínimos,
  • y separación de identidades.

6) Qué debemos respaldar en una web (y qué suele olvidarse)

Para que una restauración sea real, no basta con “archivos” o “base de datos” aislados: depende del tipo de web.

6.1 Mínimo viable (casi siempre)

  • Base de datos (contenido, usuarios, configuraciones).
  • Archivos de aplicación (core, temas, plugins, vendor).
  • Uploads / media (imágenes, documentos, assets de usuarios).
  • Configuración (variables de entorno, wp-config, claves, .env si existe).
  • Reglas/infra: Nginx/Apache vhost, reglas WAF, redirects, CDN config (cuando aplique).

6.2 Lo que se olvida y luego duele

  • Credenciales y llaves (en un repositorio seguro, no dentro del backup “sin control”).
  • Documentación de recuperación (pasos, accesos, contactos, dominios).
  • Histórico de contenidos si se depende de editores externos.
  • Integraciones (correo transaccional, pasarelas de pago, APIs).

Y un punto de seguridad muy frecuente en webs: los “backups residuales” expuestos en el propio servidor (zip/old/bak) pueden filtrar información sensible. OWASP WSTG alerta de que acciones administrativas o ediciones en producción pueden dejar copias olvidadas con extensiones diferentes, generando exposición seria.
Esto conecta con un principio: backups sí, pero no “tirados” en webroot ni accesibles públicamente.

7) Frecuencia, retención y versionado: cómo evitar “backups que propagan el problema”

Uno de los fallos más caros es el backup rodante sin versiones: cuando algo malo ocurre (malware, corrupción, borrado), el backup se actualiza y “copia el problema”.

CISA advierte que los backups accesibles pueden ser cifrados o borrados; pero incluso sin ransomware, la corrupción silenciosa se propaga si no hay retención/versionado.

Recomendación práctica (plantilla)

  • Diario: retención 14–30 días (para rollback rápido).
  • Semanal: retención 8–12 semanas (para problemas que tardan en detectarse).
  • Mensual: retención 6–12 meses (para incidentes y auditorías).
  • Inmutable/offsite: retención mínima acorde a RPO/RTO y riesgo (a menudo 30–90 días).

Esto se ajusta según:

  • volumen de datos,
  • criticidad,
  • obligaciones legales,
  • estacionalidad del negocio.

8) La prueba que casi nadie hace: restauraciones periódicas y simulacros

Una copia se considera “válida” cuando:

  • se restauró en un entorno controlado,
  • arranca,
  • y el negocio puede operar (login, pedidos/leads, panel, etc.).

CISA lo pone como práctica directa: probar procedimientos de backup regularmente y testear disponibilidad e integridad en un escenario de recuperación.
NIST también orienta sus recomendaciones a planes efectivos, no “backups en abstracto”.

Qué probamos (mínimo)

  • Restauración de BD + uploads (suele ser el cuello de botella real).
  • Recuperación de configuración (dominio, SSL, variables).
  • Tiempo total (RTO real vs teórico).
  • Validación funcional: formularios, checkout, panel, APIs.

Cuándo probamos

  • Al implantar el plan.
  • Tras cambios mayores (migración, cambio de hosting, nueva CDN/WAF).
  • De forma periódica (mensual o trimestral según criticidad).

9) Seguridad del propio sistema de backups (porque también lo atacan)

Un error común: construir un “super backup” y dejarlo con permisos excesivos.

Controles básicos (y no negociables)

  • Separación de identidades: credenciales de backup distintas a las de producción.
  • MFA/2FA en paneles de backup/almacenamiento.
  • Principio de mínimo privilegio: el sistema de producción no debería poder borrar backups históricos.
  • Cifrado en reposo y en tránsito.
  • Registro y alertas: borrados, fallos de backup, cambios de política.

CISA recalca la importancia de backups offline y testeo; y Microsoft enfatiza proteger también la documentación y backups contra el atacante.

10) WordPress y webs de agencia: recomendaciones concretas sin romper operación

Para dueños de negocio (lo que pedimos como mínimo)

  • Un plan con RPO/RTO explícito.
  • Copia offsite con retención y protección anti-borrado.
  • Prueba de restauración al menos trimestral.
  • No guardar backups accesibles desde /public_html, /wp-content/ o rutas públicas.

Para agencias (lo que profesionaliza el servicio)

  • Backup como entregable contractual (SLA interno):
    • “backup diario + retención + restore test programado”.
  • Entornos separados:
    • producción ≠ staging ≠ copias.
  • Procedimiento estándar de recuperación:
    • quién decide, quién ejecuta, cómo se valida, cómo se comunica al cliente.

Y algo que vemos mucho: “copias” hechas manualmente como zip en servidor. OWASP WSTG advierte que esos archivos olvidados (zip/bak/old) pueden exponerse y revelar datos sensibles.
Es decir: incluso cuando “la intención era buena”, la ejecución puede crear un nuevo riesgo.

11) Checklist de implementación

Diseño

  • RPO definido (pérdida máxima de datos aceptable).
  • RTO definido (tiempo máximo de caída aceptable).
  • Inventario de componentes a respaldar (BD, uploads, config, infra).

Arquitectura

  • 1 copia rápida local (restauración rápida).
  • 1 copia externa/offsite fuera del radio de explosión.
  • Retención/versionado suficiente para detectar problemas tardíos.
  • Backups offline y/o inmutables para resistencia a ransomware.

Operación

  • Automatización y monitorización de éxito/fracaso.
  • Pruebas de restauración periódicas con validación funcional.
  • Documentación de recuperación (pasos, accesos, responsables).

Seguridad

  • MFA/2FA y mínimo privilegio en almacenamiento de backups.
  • Separación de credenciales producción vs backups.
  • Prohibido dejar “backups residuales” en webroot (zip/old/bak).

12) FAQs

“Tengo backups diarios del hosting, ¿ya está?”

No necesariamente. Muchos backups de hosting están en el mismo entorno de credenciales/infraestructura. CISA advierte que ransomware intenta borrar/cifrar backups accesibles; por eso recomienda mantenerlos offline y probar restauración.

“¿Qué es lo mínimo para no sufrir un desastre?”

  • Una copia offsite fuera del radio de explosión.
  • Retención/versionado real.
  • Prueba de restauración periódica.
    Sin pruebas, no hay garantías.

“¿Cuándo conviene inmutabilidad?”

Cuando el riesgo de ransomware o sabotaje es relevante (hoy, casi siempre) o cuando la continuidad del negocio depende de la web. Las capacidades de backups inmutables existen precisamente para resistir manipulación/borrado no autorizado.