Backup off-host para WordPress: por qué un dump local no te salva

Hay una falacia común en operación WordPress: "tengo backup, estoy cubierto".

Esa frase confunde tres cosas distintas:

1. Tengo configurado un script que genera dumps.
2. Esos dumps están guardados en algún lugar.
3. Esos dumps me sirven cuando los necesito.

Las primeras dos son fáciles. La tercera es donde la mayoría de las operaciones WordPress se rompen — y donde el ransomware moderno apunta.

El problema que el backup local NO resuelve

Ransomware operadores entrenados de 2023 en adelante NO atacan solo el sitio en producción. El playbook típico es:

1. Recon (días o semanas): obtener acceso al servidor, mapear lo que hay.
2. Lateral movement: encontrar el bucket donde se guardan los backups, las credenciales del backup tool, los snapshots automáticos.
3. Borrado de respaldos: revocar tokens, borrar S3 objects, eliminar snapshots con la cuenta comprometida.
4. Cifrado del sitio en producción: solo después de neutralizar las vías de recuperación.
5. Demanda: negociación con el cliente que ahora NO tiene cómo restaurar.

Si tu backup vive en el mismo servidor o en una cuenta accesible desde el servidor comprometido, los pasos 2-3 son triviales para el atacante. Tu backup configurado se vuelve inútil exactamente cuando lo necesitás.

Off-host real: separación de privilegios

Un backup off-host real cumple tres condiciones:

1. Vive en un sistema separado del que se respalda

No basta con "otra carpeta del mismo servidor" o "otro disco de la misma máquina virtual". Tiene que ser otro sistema, idealmente con un proveedor de cloud distinto al hosting de tu WordPress.

Combinaciones razonables:

• WordPress en SiteGround → backup en Cloudflare R2.
• WordPress en AWS EC2 → backup en Backblaze B2.
• WordPress en Hostinger → backup en Wasabi.

La regla mental: si tu hosting fuera comprometido completamente (root access del atacante), ¿el backup sigue accesible? Si la respuesta es "depende de credenciales que viven dentro del hosting", la separación no existe.

2. Las credenciales del bucket NO viven dentro del sitio

Esto es lo que rompe a UpdraftPlus + Google Drive típico. El plugin guarda en wp-options el token OAuth para subir backups. Cualquier atacante con acceso a wp-admin puede:

• Leer el token de wp-options.
• Usarlo para borrar todos los backups de Google Drive.
• Revocar el OAuth grant.
• Recién después, encriptar el sitio.

Mitigación correcta: el backup lo dispara una entidad fuera de WordPress. Un cron del host (Linux cron / Windows Task Scheduler) que ejecuta pg_dump o mysqldump y sube con rclone usando credenciales que viven en el host, no en WordPress. WordPress no tiene acceso al bucket — solo el host del founder tiene.

3. Object Lock o write-once-read-many

Backblaze B2, Cloudflare R2, AWS S3 — todos soportan Object Lock en modo Compliance: una vez subido un objeto con retención N días, ni siquiera tu cuenta master puede borrarlo antes de que expire la retención.

Eso es la última defensa contra el caso "el atacante también consiguió las credenciales del bucket". Object Lock significa que aunque el atacante tenga las keys, NO puede destruir los backups dentro de la ventana de retención. Costo adicional: cero (en B2 y R2 está incluido).

Política de retención tier (2026)

Daily       → 14 días
Weekly      → 12 semanas
Monthly     → 12 meses
Yearly      → 5 años

Por qué:

• Daily 14d: cubre incidente accidental humano (DROP TABLE por error, deploy roto). 99% de los restores que vas a necesitar son de las últimas 2 semanas.
• Weekly 12s: cubre incidente que tardó días en detectar (defacement silencioso, plugin malicioso instalado).
• Monthly 12m: cubre dwell time típico de ransomware operators (30-60 días dentro antes de detonar). Necesitás un punto pre-compromiso aunque no sepas exactamente cuándo entraron.
• Yearly 5y: cumplimiento legal en muchas jurisdicciones (Colombia habeas data, México LFPDPPP). Compliance lo exige.

Storage costo en B2 para una Woo de 5GB de DB:

• Daily 14d × 5GB = 70 GB ≈ $0.42/mes
• Weekly 12s × 5GB = 60 GB ≈ $0.36/mes
• Monthly 12m × 5GB = 60 GB ≈ $0.36/mes
• Yearly 5y × 5GB = 25 GB ≈ $0.15/mes
• Total: ~$1.30/mes para política completa.

Por $15/año tenés cobertura tier que cubre cualquier escenario realista. Si estás pagando $X de hosting + $Y de plugin de backup + cero por retención tier, tu cálculo de seguridad está mal balanceado.

RTO honesto end-to-end

El RTO que importa NO es "cuánto tarda pg_restore". Es:

Detect → Decide → Provision → Pull → Restore → Verify → Reapunt → Live

Para una Woo de tamaño medio sin host de cold-standby:

| Fase | Tiempo realista | |---|---| | Detect (alarma + humano confirma) | 5-30 min | | Decide (plan de acción) | 5-10 min | | Provision (host nuevo si hace falta) | 10-60 min según provider | | Pull (download desde bucket) | 2-10 min según tamaño + ancho de banda | | Restore (pg_restore / mariadb-import) | 5-30 min según tamaño | | Verify (smoke test funcional) | 10-15 min | | Reapuntar DNS / config | 5-15 min | | Total | 45 min - 3 horas |

Si tu site marketing dice "RTO de minutos" sin asterisk, es marketing. RTO de minutos requiere cold-standby permanente con datos sincronizados en tiempo real — eso vale 5-10x más al mes.

Decir RTO honesto en tu plan de DR + tener backup off-host probado + restore drill mensual = posición creíble. Decir "RTO de 1 minuto" sin infraestructura para sostenerlo = humo que se rompe en el primer incidente real.

Restore drill mensual

Configurar el backup es 30% del trabajo. Probar que restaura es el otro 70%.

Procedimiento mínimo viable:

# 1. Container temporal aislado
docker run -d --name backup-drill \
  -e POSTGRES_PASSWORD=drill \
  -e POSTGRES_DB=test \
  -p 127.0.0.1:5499:5432 \
  pgvector/pgvector:pg16

# 2. Pull dump del bucket
rclone copy provider:bucket-prod/memory/<latest>.dump /tmp/

# 3. Restore
docker exec -i backup-drill pg_restore \
  -U postgres -d test --clean --if-exists < /tmp/<latest>.dump

# 4. Verify
docker exec backup-drill psql -U postgres -d test \
  -c "SELECT count(*) FROM your_critical_table;"
# espera: número > 0

# 5. Cleanup
docker rm -f backup-drill

Total: 5-10 minutos. Ejecutalo el primer lunes de cada mes. Documentá el resultado.

Drokio publica el resultado de su restore drill mensual en drokio.com/verify/drokio con SHA del dump probado. Si nuestro propio backup no restaura, el badge baja antes que vos te enteres por nosotros.

Lo que TrustOS hace con esto

Drokio TrustOS automatiza la parte de monitoreo

• verificación pública del backup off-host:

• Sub-score backup_health: si el último upload off-host está fresh (menos de 48h), score 80-100. Si stale (más de 7d), score 0 → estado del sitio baja a at_risk automáticamente.
• Verify page: cualquiera puede consultar drokio.com/verify/<slug> y ver el SHA del último backup, fecha, tamaño, bucket path.
• Evidence Vault: el hash queda público y verificable. Un auditor con acceso al artefacto puede confirmar que el backup que se promete existe efectivamente.

No reemplaza tener un buen plan de DR — lo hace público y verificable.

Resumen accionable

1. ¿Tu backup vive en otro provider distinto del hosting? Si no, separá hoy.
2. ¿Las credenciales del bucket están dentro de WordPress? Si sí, sacalas.
3. ¿Tenés Object Lock activado? Si no, configuralo (gratis en B2 y R2).
4. ¿Configuraste retención tier (daily/weekly/monthly/yearly)? Si no, hoy.
5. ¿Hiciste un restore drill en el último mes? Si no, agendalo.
6. ¿Documentaste tu RTO real end-to-end? Si decís "minutos" sin probar, es humo.

Si los 6 están en verde, dormís tranquilo. Si alguno falla, ahí está tu próxima tarea operativa.

Drokio TrustOS convierte tu backup off-host en evidencia pública verificable. Score live, hash auditable, badge que baja si algo caduca. Tu cliente, tu auditor o tu inversor lo verifican sin pedirte nada.

→ Cómo funciona TrustOS