Decir “tenemos backup” no siempre significa estar tranquilo. La pregunta real es otra: ¿ese backup se puede restaurar rápido, completo y sin improvisar?
En portales institucionales, un respaldo debe incluir archivos, base de datos, configuración relevante, versión de PHP, módulos, temas, certificados si aplica, tareas cron y una nota mínima de cómo volver a levantar el sitio. Una carpeta comprimida sin contexto puede servir, pero también puede volverse un rompecabezas.
Lo que debe quedar claro
Cada backup debería responder: fecha, sitio, ruta, base de datos, tamaño, responsable, método usado y ubicación. Si además se documenta el comando o la herramienta utilizada, mucho mejor.
He visto casos donde el backup existía, pero nadie sabía de qué día era, si incluía uploads, si correspondía al ambiente correcto o si la base era compatible con el código. En emergencia, esas dudas cuestan tiempo.
Probar la restauración
La única forma de confiar en un backup es probarlo. No necesariamente en producción. Puede ser en un subdominio, servidor temporal, ambiente local o contenedor. Lo importante es confirmar que el sitio abre, que el login funciona, que los archivos cargan y que no hay errores grandes en logs.
En Drupal y WordPress, también revisaría rutas de archivos, permisos, caché, .htaccess, conexión a base de datos y versión de PHP. Muchos errores aparecen por diferencias de entorno, no por el backup en sí.
Backup antes de tocar
Antes de actualizar módulos, plugins, PHP, tema o servidor, el backup no es opcional. Es el cinturón de seguridad. Puede que no se use, pero cuando se necesita, cambia todo.
Un buen respaldo no es el que ocupa más espacio. Es el que permite volver a operar.
Desarrollo, soporte y mejora para portales que deben funcionar bien
Portales institucionales, WordPress, Drupal, Laravel, seguridad web, hosting, SSL, landings, CMS y soporte técnico continuo.