La mayoría de negocios descubren la calidad de sus backups el día en que algo sale mal.
Una actualización de plugin rompe el sitio. Se borra un archivo. El malware cambia contenido con suficiente lentitud como para entrar en backups recientes. Se cierra una cuenta antes de que alguien descargue los datos.
El objetivo de una estrategia de backups no es crear archivos. Es restaurar el sitio a un estado útil en un plazo que el negocio pueda aceptar.
Define qué debe ser recuperable
Un sitio web es más que sus páginas visibles.
Una recuperación completa puede requerir:
- Archivos de la aplicación
- Imágenes y documentos subidos
- Contenido de la base de datos
- Configuración y ajustes del entorno
- Registros DNS
- Ajustes de enrutamiento de correo
- Detalles de SSL e integraciones de terceros
- Scripts de despliegue o código fuente personalizado
Para WordPress, la base de datos y el directorio wp-content son esenciales. La base contiene entradas, ajustes, usuarios, pedidos y muchos registros de plugins. wp-content contiene temas, plugins y medios subidos.
Si el correo se aloja por separado, los backups del sitio pueden no incluir buzones. Confírmalo en lugar de asumirlo.
Elige un objetivo de punto de recuperación
El objetivo de punto de recuperación, o RPO, es la cantidad máxima de datos recientes que el negocio puede permitirse perder.
Un sitio corporativo actualizado una vez al mes puede aceptar un backup diario. Una tienda que recibe pedidos cada hora puede necesitar un intervalo mucho más corto o una forma adicional de proteger datos transaccionales.
Pregunta: si el sitio se restaurara ahora mismo, ¿cuánta información faltante crearía un problema serio?
Esa respuesta determina la frecuencia de backups.
Elige un objetivo de tiempo de recuperación
El objetivo de tiempo de recuperación, o RTO, es cuánto tiempo puede permanecer no disponible el sitio.
Un backup en un archivo lento puede proteger los datos pero fallar el requisito de tiempo. Una restauración de un clic en el hosting puede ser rápida, mientras reconstruir un servidor e importar a mano una base grande puede tardar mucho más.
Define un objetivo realista:
- ¿Con qué rapidez debería alguien notar el fallo?
- ¿Quién decide restaurar?
- ¿Dónde están las credenciales?
- ¿Cuánto tarda la restauración real?
- ¿Qué debe probarse antes de reabrir el sitio?
El tiempo de recuperación incluye decisiones humanas, no solo velocidad de transferencia.
Usa más de un punto de restauración
Un solo backup reciente puede conservar el problema que intentas eliminar.
Malware, corrupción de datos y errores de contenido no detectados pueden existir días antes del descubrimiento. Conserva varios puntos en el tiempo para poder restaurar desde antes del incidente.
Un patrón práctico de retención podría incluir:
- Varios puntos diarios recientes
- Puntos semanales durante un periodo más largo
- Un archivo mensual para sitios importantes
El calendario exacto depende de con qué frecuencia cambia el sitio y cuánto tiempo pueden permanecer ocultos los problemas.
Mantén una copia fuera de la cuenta de hosting activa
Los backups a nivel de hosting son convenientes y deben formar parte del plan. No deben ser el único plan.
Una copia externa protege frente a:
- Borrado accidental de la cuenta de hosting
- Pérdida de acceso a la cuenta
- Un incidente a nivel de proveedor
- Disputas de facturación o propiedad
- Un error que afecte producción y snapshots locales
Guarda la copia independiente en una ubicación controlada con cifrado y restricciones de acceso. El almacenamiento de objetos en la nube es habitual, pero un archivo local gestionado con seguridad también puede servir para sitios pequeños.
No envíes backups de bases de datos por correo informal ni los dejes en un directorio público de uploads. Pueden contener registros de clientes, hashes de contraseñas, datos de pedidos y configuración de API.
Sigue el principio 3-2-1
El principio tradicional 3-2-1 es una base útil:
- Mantén tres copias de los datos importantes
- Usa dos tipos o sistemas de almacenamiento distintos
- Mantén una copia fuera del sitio
Para un sitio web, eso podría ser:
- El sitio en vivo
- Backups con historial del hosting
- Un export cifrado en almacenamiento independiente
Las copias no deberían depender todas de las mismas credenciales de cuenta.
Protege los backups
Los backups son objetivos valiosos porque concentran una copia de los datos del negocio.
Usa:
- Autenticación multifactor
- Credenciales de backup separadas
- Cifrado en tránsito y en reposo
- Acceso limitado a la retención
- Registro de actividad
- Un proceso para retirar a miembros antiguos del equipo
Cuando sea posible, usa controles de almacenamiento que impidan a un atacante borrar de inmediato todos los puntos de recuperación tras comprometer la cuenta principal.
Documenta quién puede restaurar, quién puede descargar y quién puede borrar backups de forma permanente.
Prueba la restauración
Un backup sin probar es una suposición.
Programa restauraciones de prueba en un entorno de staging o aislado. Confirma que:
- El archivo se puede leer
- La base de datos se importa
- Los medios cargan
- El login funciona
- Formularios y flujos principales operan
- Las integraciones sensibles están desactivadas en la copia de prueba
No restaures una tienda de producción en una URL pública de staging con claves de pago en vivo y automatización de correo a clientes activada. Protege el entorno de prueba y neutraliza efectos externos.
Registra cuánto tarda la prueba y cualquier ajuste manual. Eso se convierte en la primera versión de un runbook de recuperación.
Haz backup antes de cambios arriesgados
Los horarios automáticos pueden no alinearse con el mantenimiento.
Crea un punto de restauración fresco antes de:
- Actualizaciones del núcleo de WordPress
- Actualizaciones mayores de plugins o temas
- Cambios de versión de PHP
- Limpieza de base de datos
- Operaciones de buscar y reemplazar
- Migraciones de sitio
- Importaciones grandes de contenido
Etiqueta los puntos manuales cuando la plataforma lo permita. “Antes de upgrade PHP” es más útil bajo presión que una marca de tiempo sin explicación.
Separa backups del control de versiones
Git y otros sistemas de control de versiones son excelentes para código personalizado. No son backups completos del sitio.
El control de versiones suele excluir:
- La base de datos de producción
- Medios subidos
- Configuración de ejecución
- Contenido generado por clientes
- Estado de servicios externos
Usa control de versiones para el historial de código y el despliegue. Usa backups para la recuperación operativa. Un proceso maduro usa ambos.
Escribe un plan de recuperación de una página
Los pequeños negocios no necesitan un manual de cincuenta páginas. Sí necesitan una página clara que responda:
- ¿Dónde están los backups?
- ¿Quién tiene acceso?
- ¿Qué punto de restauración debe usarse?
- ¿Cómo se inicia la restauración?
- ¿Qué funciones del sitio deben probarse?
- ¿Quién comunica con los clientes?
- ¿Cuándo se declara restaurada la operación normal?
Guarda este plan en un lugar disponible cuando el sitio y el panel de hosting no lo estén.
Revisa la estrategia dos veces al año
Los sitios cambian. Un brochure se convierte en tienda. Una nueva agencia asume el mantenimiento. El correo se muda a otro proveedor. Aparece un requisito de cumplimiento.
Revisa alcance, frecuencia, retención, acceso y pruebas de restauración al menos dos veces al año—y tras cualquier cambio mayor de arquitectura.
VeyoHost incluye backups con historial en cada plan público de hosting, pero una buena recuperación combina la protección de la plataforma con un proceso de negocio independiente. Desde Colombia, revisa Hosting web en COP, Hosting WordPress en COP o pregunta por recuperar tu sitio actual.
Cuéntanos qué estás ejecutando. Te ayudamos a elegir el siguiente paso práctico.