¿Cada cuánto hacer backups y cómo probar la restauración sin riesgos?

Backups: cada cuánto y cómo probar la restauración

Los backups solo sirven si se restauran. En esta guía aprenderás cada cuánto hacer copias de seguridad según el tipo de sitio (corporativo, blog, eCommerce, SaaS) y cómo ensayar la restauración sin arriesgar tu web, con checklist, runbook y buenas prácticas (3-2-1-1-0, cifrado, retención y monitoreo).

Por qué los backups importan (más allá de “tener una copia”)

• Negocio: sin restauración rápida, pierdes ventas/leads y reputación.
• SEO: caídas prolongadas y errores 5xx afectan rastreo/posiciones.
• Seguridad: ransomware, fallas humanas y plugins rotos pasan… y ese día tu backup es tu seguro.

Clave: Backup ≠ Restauración. Debes ensayar el retorno a operación.

RPO y RTO: define objetivos antes de elegir frecuencia

• RPO (Recovery Point Objective): cuánto dato puedes perder (ej. 24 h, 4 h, 1 h).
• RTO (Recovery Time Objective): cuánto tiempo puedes estar caído (ej. 2 h, 30 min).

Ejemplos rápidos

• Blog estándar: RPO 24 h / RTO 2–4 h.
• eCommerce: RPO 1–4 h / RTO ≤60 min.
• SaaS: RPO ≤1 h / RTO ≤30 min.

Tipos de backup y cuándo usarlos

• Completo (Full): copia total; base confiable; úsalos 1–4 veces/mes.
• Incremental: solo cambios desde la última copia; rápido y eficiente; ideal diario/horario.
• Diferencial: cambios desde el último full; término medio.
• Snapshots de VM/volumen: instantáneos; perfectos para rollbacks rápidos (útiles, pero no sustituyen copias externas).
• PITR (Point-in-Time Recovery) para DB: permite restaurar la base a un minuto exacto (crítico en eCommerce/SaaS).

Regla 3-2-1-1-0 (copias y verificación)

• 3 copias de tus datos
• en 2 tipos de soportes distintos
• 1 fuera del sitio (off-site / cloud)
• 1 inmutable (no editable; protege de ransomware)
• 0 errores tras verificación (checksums, logs y pruebas periódicas)

Frecuencias recomendadas por tipo de sitio

Tipo de sitio	Archivos (app/tema/plugins)	Base de datos	Retención sugerida
Web corporativa	Semanal (full) + diario (incremental)	Diario	14–30 días
Blog alto tráfico	Semanal (full) + diario (inc.)	6–12 h	30–45 días
eCommerce	Semanal (full) + diario (inc.)	1–4 h o PITR	30–60 días
SaaS / App	Semanal (full) + diario (inc.) + snapshots	1 h o PITR	60–90 días

Ajusta según RPO/RTO y picos (campañas, lanzamientos). En eCommerce pre-campaña sube frecuencia y retención.

Qué respaldar exactamente

• Archivos de aplicación: core, temas/plugins (o código de tu app).
• Base de datos: imprescindible (usuarios, pedidos, contenido).
• Media: /uploads u objeto (S3-like).
• Configuraciones y llaves: .env, claves API (guardadas cifradas).
• Infraestructura: scripts de despliegue, IaC y versiones.

Buenas prácticas

• Cifrado en tránsito y en reposo.
• Permisos mínimos y rotación de llaves.
• Etiqueta backups con fecha + hash.
• Documenta dónde están, quién accede y cómo restaurar.

Cómo probar restauración sin riesgos (paso a paso)

A) Prepara un entorno seguro

1. Staging o sandbox aislado (subdominio/no index).
2. Duplica versión de PHP/DB y extensiones.
3. Importa backup completo (archivos + DB).

B) Verifica integridad

• Revisa checksums/hashes.
• Corrige permisos/propiedad de archivos.
• Re-configura URLs en DB para staging (en WordPress: siteurl/home).
• Purga cachés y regenera assets.

C) Pruebas funcionales

• Páginas clave (home, servicios, contacto).
• Formularios / checkout / login.
• eCommerce: carrito, órdenes de prueba (sandbox), emails.
• Logs de errores limpios.

D) Ensayo cronometrado (simula incidente)

• Cronometra RTO real (tiempo total de restauración).
• Verifica que el punto restaurado cumple el RPO (pérdida de datos aceptable).
• Documenta hallazgos y mejoras.

Repite esta prueba de restauración al menos mensual (eCommerce/SaaS) o trimestral (web corporativa).

Automatización, alertas y runbook de incidentes

Automatiza:

• Programaciones (cron) + rotación automática (retención por días).
• Notificaciones ante fallos de backup.
• Pruebas de integridad post-backup (checksum / validación DB).

Runbook (resumen):

1. Declara incidente (quién decide y en qué canal).
2. Identifica versión de restauración (RPO).
3. Aplica modo solo lectura si aplica (evitar corrupción).
4. Ejecuta restauración y cronometrar RTO.
5. Validaciones funcionales (checklist).
6. Post-mortem ligero + mejoras al plan.

Checklist

• RPO y RTO definidos por tipo de sitio.
• Full semanal + incrementales; DB con frecuencia adecuada o PITR.
• 3-2-1-1-0 implementado (off-site + inmutable + verificación).
• Cifrado y control de acceso/llaves documentado.
• Prueba de restauración mensual/trimestral con tiempos medidos.
• Runbook de incidentes y responsables definidos.
• Alertas ante fallos de backup y de integridad.

¿Quieres que lo dejemos a prueba de sustos? (CTA)

En CODE MITSU te ayudamos a dimensionar la frecuencia de backups, configurar retención segura 3-2-1-1-0 y ensayar restauraciones sin riesgos.
👉 Contacto

Preguntas frecuentes (FAQ)

1) ¿Los backups del proveedor de hosting son suficientes?
Úsalos, pero no dependas solo de ellos: mantén una copia off-site e inmutable bajo tu control.

2) ¿Dónde guardo los backups grandes (media)?
Almacenamiento tipo objeto (S3-like) con ciclo de vida y cifrado; evita llenar el mismo servidor.

3) ¿Cómo evitar afectar clientes al restaurar?
Ensaya en staging. Si la restauración en producción es inevitable, utiliza ventana de mantenimiento y avisos.

4) ¿Qué pasa con pedidos en eCommerce durante el incidente?
Define un modo degradado (p. ej., desactivar campañas/checkout temporal) y sincroniza con pasarela/ERP al volver.

5) ¿Cada cuánto reviso la política de backups?
Al menos trimestral o ante cambios relevantes (tráfico, stack, campañas, arquitectura).