Backup off-host para WordPress: por qué un dump local no te salva del ransomware | Drokio Blog | Drokio
backupransomwareDR
💾Backup off-host para WordPress: por qué un dump local no te salva del ransomware
Tener backup configurado y tener backup que sirve son cosas distintas. Ransomware moderno encripta también los backups locales. Cómo configurar un backup off-host real, qué provider elegir, cómo medir RTO honesto, y cómo probar que tu backup restaura — antes de necesitarlo.
Drokio··11 min de lectura
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:
Tengo configurado un script que genera dumps.
Esos dumps están guardados en algún lugar.
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:
Recon (días o semanas): obtener acceso al servidor, mapear lo que hay.
Lateral movement: encontrar el bucket donde se guardan los backups,
las credenciales del backup tool, los snapshots automáticos.
Borrado de respaldos: revocar tokens, borrar S3 objects, eliminar
snapshots con la cuenta comprometida.
Cifrado del sitio en producción: solo después de neutralizar las
vías de recuperación.
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:
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%.
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.
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
¿Tu backup vive en otro provider distinto del hosting? Si no, separá hoy.
¿Las credenciales del bucket están dentro de WordPress? Si sí, sacalas.
¿Tenés Object Lock activado? Si no, configuralo (gratis en B2 y R2).
¿Configuraste retención tier (daily/weekly/monthly/yearly)? Si no, hoy.
¿Hiciste un restore drill en el último mes? Si no, agendalo.
¿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.
¿UpdraftPlus + Google Drive cuenta como backup off-host?
Cuenta como off-host técnicamente — está fuera del host de WordPress. Pero hay caveats: si el atacante tiene acceso al wp-admin (caso típico de breach), puede ver las credenciales de UpdraftPlus + revocar el token + borrar los backups remotos antes de cifrar el sitio. La defensa real requiere que las credenciales del bucket NO vivan dentro del WordPress que estás respaldando. La separación de privilegios entre 'sitio que se respalda' y 'cuenta que tiene los backups' es la diferencia entre 'tengo backup' y 'tengo backup que sobrevive'.
¿Cuántos días de retención necesito?
Depende del tipo de incidente. Para corrupción accidental (DROP TABLE por error humano) basta 7-14 días. Para ransomware con dwell time (atacante dentro 30-60 días antes de detonar) necesitás retención de al menos 60-90 días para tener un punto pre-compromiso. Recomendación 2026: política tier — daily 14d + weekly 12 semanas + monthly 12 meses + yearly 5 años. Costo storage es bajo; valor de poder volver 6 meses atrás post-detección de breach lateral es alto.
¿Cuál es un RTO razonable para una tienda Woo de tamaño medio?
Depende del tamaño de la DB y del provider. Para una Woo con DB de 2-5 GB y backup off-host en R2/B2/S3: download 2-5 min sobre fibra empresarial, restore 5-15 min, smoke test + DNS reapunte 10-15 min. RTO realistico end-to-end sin host de cold-standby: 30-60 min. Con host stand-by: 5-10 min. La métrica que importa NO es 'cuánto tarda pg_restore' sino 'cuánto tiempo desde detect → site online de nuevo'. Documentá el end-to-end, no solo el restore.
¿Cómo pruebo que el backup funciona sin afectar producción?
Restore drill mensual contra container temporal aislado. Bajás el dump del bucket, levantás un Postgres/MariaDB nuevo en Docker, restauras, verificás conteo de tablas + rows + smoke query. NO toca producción. Tiempo: 5-15 min. Si nunca lo hiciste, la primera vez probablemente descubrís que falta una extension (pgvector, etc.) o que el dump fue parcial. Mejor descubrirlo en drill que en incidente real.
Producto mencionado
🛡️
Drokio TrustOS
Drokio no solo protege. Drokio prueba que protege.
Capa viva de protección + prueba pública: verify pages auditables, badge embebible, score honesto y revocación automática. Convierte tu seguridad en evidencia.
DPAs con hosting, CDN y plugins: el inventario de sub-procesadores que tu WordPress necesita
Cómo firmar los Data Processing Agreements correctos con tu hosting, CDN, pasarela de pago y plugins SaaS. Cláusulas que son red flags, plantilla mínima defendible y el inventario vivo que tu auditoría exige.
