La verdadera razón por la que tus copias de seguridad no son copias de seguridad

Todos los sitios de WordPress afirman tener copias de seguridad. La mayoría de esas copias no lo son de verdad. Son carpetas de archivos comprimidos guardadas en el mismo servidor que el sitio en producción, nunca probadas, a menudo incompletas y silenciosamente condenadas a fallar justo cuando más se necesitan.

Una copia de seguridad que nunca se ha restaurado no es una copia: es una esperanza. Una copia almacenada en la misma máquina que el sitio en producción no es una copia: es un duplicado. Después de suficientes historias de terror en las que un negocio creía tener copias y descubrió demasiado tarde que no las tenía, los criterios de lo que cuenta como una copia de seguridad real están más claros que nunca.

Los cuatro rasgos de una copia de seguridad real

1. Externa. Almacenada en un lugar geográfica e infraestructuralmente separado del sitio en producción. Si el servidor en producción arde, la copia debe sobrevivir. «Guardada en otra carpeta del mismo hosting» no es externa. Guardada en S3, Google Cloud, Dropbox o un proveedor completamente distinto, sí lo es.
2. Completa. Incluye tanto la base de datos como los archivos (subidas, temas, plugins). Las copias solo de base de datos pueden restaurar el contenido, pero no el sitio visual. Las copias solo de archivos pueden restaurar el aspecto, pero no las entradas. Una copia real contiene ambos, tomados en el mismo momento.
3. Reciente. Diaria para un sitio que se actualiza con frecuencia. Semanal es el mínimo para un sitio de catálogo. Una copia de hace tres meses es técnicamente una copia, pero significa perder cada interacción con clientes desde entonces.
4. Probada. El rasgo que más se omite. Una copia que nunca se ha restaurado nunca ha demostrado que funciona. Prueba las restauraciones al menos cada trimestre. Lleva la copia a un entorno de staging y confirma que el sitio arranca correctamente. La primera vez que descubras que tu copia está corrupta no debería ser el día en que la necesitas.

La regla 3-2-1, aplicada a WordPress

La regla 3-2-1 de copias de seguridad del sector de las TI se aplica limpiamente a los sitios WordPress. Tres copias de los datos (el sitio en producción más dos copias). Dos tipos de soporte diferentes (almacenamiento en servidor más almacenamiento en la nube). Una copia externa (en una ubicación completamente distinta).

Para un sitio WordPress típico de una empresa australiana, esto podría verse así: sitio en producción en hosting australiano gestionado, copia diaria a UpdraftPlus en Google Drive, copia semanal a Amazon S3 en otra región. Tres copias, dos proveedores, una totalmente externa.

Los fallos de copia de seguridad más habituales

• Copia solo en el hosting. La copia del proveedor va bien hasta que el proveedor tiene una caída o suspende tu cuenta. Muchas empresas descubren, en medio de una disputa con el hosting, que la copia que creían tener está bloqueada tras una cuenta a la que no pueden acceder.
• El plugin falló en silencio. La programación diaria del plugin de copias dejó de ejecutarse hace seis meses. Nadie lo notó porque nadie lo comprobaba. La copia lleva seis meses desactualizada antes de que alguien se dé cuenta.
• Faltan tablas de la base de datos. Una copia mal configurada que excluye las tablas de WooCommerce o las de plugins personalizados. La copia parece una copia, pero le faltan los datos más importantes.
• La copia es demasiado grande para restaurarla. La copia se completó, pero el archivo es tan grande que restaurarlo dentro de los límites de tiempo de espera de PHP del hosting resulta imposible. Los datos están preservados, pero no son realmente accesibles sin intervención manual.

Qué implica realmente una restauración

Una prueba de restauración real, de principio a fin, lleva unos 30 minutos. Levanta una instalación limpia de WordPress en una URL de staging. Descarga la copia más reciente. Restáurala. Recorre el sitio, confirma que la página de inicio carga, comprueba que hay una entrada reciente, envía el formulario de contacto, prueba una transacción si hay comercio electrónico. Si todo eso funciona, la copia es real.

La primera vez que la mayoría de las empresas hace esto, descubre al menos un problema con su proceso de copias. La segunda vez, los problemas suelen estar resueltos. La cuarta vez, el equipo empieza a confiar en las copias, y esa confianza está ganada.

Un hábito trimestral, no una configuración puntual

La higiene de las copias de seguridad no es un proyecto de una sola vez. Es un hábito trimestral. Cada tres meses, restaura la copia más reciente en staging y confirma que el sitio arranca limpio. Cada seis meses, audita los destinos de las copias para asegurarte de que el almacenamiento no está lleno y las credenciales no han caducado.

Esta es una de las partes del mantenimiento de WordPress menos emocionantes y más importantes. Los planes de mantenimiento de Defyn incluyen la prueba de restauración trimestral como elemento estándar de la lista de comprobación, una de las razones por las que los clientes con contrato casi nunca sufren una pérdida de datos catastrófica. Las copias se han probado. Funcionan de verdad.