Cuando le explico a un cliente que su web será estática, suele sentir un alivio inmediato: sin base de datos, sin panel de administración expuesto, sin plugins que actualizar cada semana. Y es cierto, una web estática elimina buena parte de los problemas de seguridad con los que viven las webs en WordPress o Joomla.
Pero ese alivio tiene una trampa. A veces se convierte en "entonces no hace falta preocuparse por las copias de seguridad". Y eso no es verdad.
De dónde vengo
He tenido clientes con webs en Joomla y WordPress que fueron hackeadas. En algunos casos fue un plugin sin actualizar, en otros un panel con una contraseña débil. Lo que se repite en todas esas historias es el momento posterior: alguien pregunta "¿tenemos una copia limpia?", y la respuesta no siempre es que sí. Cuando la hay, a menudo es antigua, o está en el mismo servidor que se ha comprometido, o nadie sabe cómo restaurarla.
Con sitios estáticos no he vivido una situación así. Pero no creo que sea porque las copias no importen, sino porque el sistema es más sencillo y los riesgos son otros.
Qué riesgos quedan en una web estática
Al quitar la base de datos y el panel de administración, desaparece la puerta de entrada más habitual de los atacantes. Pero siguen existiendo:
- Errores humanos. Un archivo borrado, una carpeta sobrescrita, una publicación que rompe el sitio. Son los fallos más frecuentes y los menos dramáticos, hasta que no tienes forma de volver atrás.
- Fallos del alojamiento. Un servidor que se estropea, un proveedor que cierra, una migración que sale mal.
- Acceso comprometido. Si alguien se hace con tus credenciales de FTP, de tu cuenta de alojamiento o de tu dominio, no hace falta explotar ningún fallo: puede cambiar lo que quiera.
- Pérdida de quien lo hizo. El desarrollador cambia de trabajo, se jubila o desaparece, y con él, el único sitio donde estaba el código original.
- Lo que no es la web. El dominio, los registros DNS y el correo no están en los archivos de la web, y perderlos duele igual.
Qué hay que copiar de verdad
Una confusión frecuente es pensar que la copia es "la web publicada". En una web estática, lo que se publica es el resultado de un proceso: contenido, plantillas, imágenes y configuración pasan por un generador, y de ahí sale el sitio final.
Si solo guardas el sitio final, tienes una foto: puedes volver a ponerla, pero no puedes cambiar un texto sin pelearte con archivos generados. Lo que de verdad conviene proteger es el origen:
- El contenido y las plantillas.
- Las imágenes originales, no solo las optimizadas.
- La configuración del generador.
- La documentación de cómo se compila y se publica.
- Los datos externos: registros DNS, configuración de correo y credenciales (en un gestor de contraseñas, no en un papel).
El sitio publicado es útil como segunda capa, porque permite poner la web otra vez en pie en minutos mientras reconstruyes lo demás.
La regla 3-2-1
Es la pauta clásica y sigue funcionando:
- 3 copias de lo que importa (la original y dos más).
- En 2 soportes o lugares distintos (por ejemplo, un servidor y un servicio en la nube).
- Con 1 fuera del sitio principal, para que un fallo en un único lugar no se lo lleve todo.
Una copia en el mismo servidor que la web no es una copia, es un duplicado que se pierde con el original.
Cómo lo hago yo
En mis proyectos, el origen vive en un repositorio Git. Eso da algo que una simple copia no da: el historial. Si un cambio rompe algo, se puede volver a cualquier punto anterior y ver quién cambió qué y cuándo.
Además, el alojamiento donde se publica la versión final ya compilada tiene copias de seguridad diarias. Así hay dos capas independientes: el origen, versionado, y el resultado publicado, copiado cada día.
No es una receta universal y no la presento como tal. Lo importante es que haya más de una capa y que ninguna dependa del mismo punto de fallo. Un repositorio solo en el ordenador de quien hizo la web no basta; tampoco una copia diaria que sigue en el mismo servidor.
Una copia no probada es una esperanza
Es la parte que más se olvida. Hacer copias es fácil; saber restaurarlas no lo es tanto. Conviene comprobar de vez en cuando, al menos una vez al año, que:
- La copia existe y es reciente.
- Se puede abrir y contiene lo que debería.
- Sabes cuánto tardarías en volver a tener la web online.
- Alguien más, además de ti, sabe cómo hacerlo.
Parece un ejercicio innecesario hasta el día que lo necesitas.
Qué preguntar a quien te hace la web
Si encargas una web, hay cuatro preguntas que cambian mucho el panorama, y las respuestas deben ser concretas:
- ¿Dónde está el código fuente y quién tiene acceso a él? Si la respuesta es "en mi ordenador", no es una respuesta tranquilizadora.
- ¿Qué copias existen y cada cuánto se hacen? Tanto del origen como de lo publicado.
- ¿Qué pasa si tú no estás? ¿Podría otra persona seguir con el proyecto con lo que hay documentado?
- ¿Quién guarda las claves del dominio, el alojamiento y el correo? Esto debe quedar siempre a nombre del cliente. Si dudas de qué debe ofrecer un alojamiento, te ayuda No todos los alojamientos web son iguales.
Una estrategia mínima para un negocio pequeño
Si no quieres complicarte, con esto ya estás mejor que la mayoría:
- Pide el código de tu web y guárdalo tú. Una copia propia, aunque no la entiendas.
- Comprueba que tu alojamiento hace copias y cada cuánto. Pregunta si se pueden restaurar tú sin pedir ayuda.
- Guarda las credenciales en un gestor de contraseñas y, con una persona de confianza, el modo de acceso de emergencia.
- Anota el dominio, el proveedor y la fecha de renovación. Un dominio caducado es una pérdida total.
- Prueba la restauración una vez al año. Anota la fecha en el calendario.
El seguro que esperas no usar
Las copias de seguridad tienen un problema de imagen: no hacen nada visible mientras todo va bien. Pero una web, aunque sea estática, representa años de textos, fotos y decisiones. Que sea mucho más difícil de romper que otras no quiere decir que no pueda perderse. Y, como casi todo lo que protege, vale mucho más la primera vez que lo necesitas que todas las anteriores juntas.
