Backups y recuperación web
Copias de seguridad web: qué guardar, cada cuánto hacerlas y cómo saber si funcionan
Tener un archivo llamado “backup” no significa que tu web pueda recuperarse. Una copia útil debe responder a cinco preguntas: qué contiene, de cuándo es, dónde está guardada, cuántas versiones existen y cómo se restaura. Esta guía se centra en diseñar copias de seguridad que realmente sirvan cuando ocurre una incidencia.
Esta página trata de backups y recuperación, no de mantenimiento web en general
Dentro de este clúster existen varias intenciones distintas:
- mantenimiento web responde a quien quiere contratar revisiones preventivas y continuidad técnica;
- qué hacer si una web deja de funcionar es un protocolo ante una caída;
- cómo proteger una web frente a hackeos se centra en prevención;
- esta guía responde exclusivamente a cómo debería plantearse una copia de seguridad para poder recuperar una web.
Una copia de seguridad web es una versión recuperable del proyecto en un momento concreto
El objetivo no es acumular archivos comprimidos. El objetivo es poder regresar a un estado anterior cuando se pierden datos, una actualización falla, una migración sale mal o una incidencia modifica el proyecto.
Para que un backup sea útil debe conservar las piezas necesarias para reconstruir la web o recuperar aquello que se ha perdido.
Y hay una diferencia importante: backup no es lo mismo que sincronización. Si un sistema replica inmediatamente un archivo dañado o eliminado, esa sincronización también puede copiar el problema. Una estrategia de backup conserva versiones anteriores.
¿Qué debe incluir la copia de seguridad de una página web?
Depende de cómo esté construida. En una web WordPress típica existen dos grupos separados: archivos y base de datos.
WordPress explica en su documentación oficial que descargar los archivos del servidor no significa haber copiado también la base de datos, porque normalmente se almacenan en sistemas diferentes.
Archivos
Pueden incluir:
- imágenes y documentos subidos;
- tema;
- plugins;
- código propio;
- archivos de configuración necesarios;
- otros recursos que no puedan reconstruirse fácilmente.
Base de datos
En una web dinámica puede contener contenido, configuraciones, usuarios, formularios almacenados, pedidos, reservas u otra información generada por la aplicación.
Una web estática
Si el proyecto es únicamente HTML, CSS, JavaScript e imágenes y no utiliza base de datos, la copia puede ser mucho más sencilla.
Servicios que no forman parte directamente de la web
Correo, DNS, cuentas de proveedores, APIs o herramientas SaaS pueden necesitar su propia estrategia. Que estén contratados junto al hosting no significa que entren automáticamente dentro del backup de los archivos de la página.
¿Cada cuánto tiempo debería hacerse un backup?
La respuesta correcta no es “diario”, “semanal” o “mensual” para todo el mundo. La frecuencia debería depender principalmente de cuánto cambia la información entre una copia y la siguiente.
| Tipo de proyecto | Qué cambia | Frecuencia orientativa a valorar |
|---|---|---|
| Landing o web corporativa que apenas cambia | Pocos cambios de contenido. | Mensual puede ser suficiente en muchos casos, además de copias antes de cambios importantes. |
| Web corporativa activa | Contenido, formularios o ajustes frecuentes. | Semanal o mensual según el ritmo real de cambios. |
| Ecommerce | Pedidos, clientes, stock y estados. | Diaria o más frecuente si perder un día de datos sería inaceptable. |
| Reservas, membresías o usuarios | Datos generados continuamente. | Según el máximo de información que el negocio puede permitirse perder. |
| Antes de actualización, migración o cambio técnico importante | El riesgo viene del cambio que se va a realizar. | Copia específica inmediatamente antes de intervenir. |
Estas frecuencias son referencias prácticas, no una norma universal. Una tienda con dos pedidos al mes y otra con cientos al día no deberían tener la misma política únicamente porque ambas utilizan WooCommerce.
La pregunta clave: ¿cuánta información podrías permitirte perder?
Esta pregunta ayuda más que elegir una frecuencia por costumbre.
Imagina que haces una copia cada siete días. Si el servidor falla justo antes de la siguiente copia, podrías perder casi una semana de cambios.
Entonces pregúntate:
- ¿perder una semana de cambios sería aceptable?
- ¿qué ocurre si se pierden pedidos?
- ¿se podrían reconstruir formularios recibidos?
- ¿hay datos en otro sistema que permitan recuperar parte de la información?
- ¿cuánto tiempo puede estar la web fuera de servicio mientras restauramos?
Si perder un día de datos es demasiado, una copia semanal claramente no es suficiente.
En cambio, si una landing lleva tres meses sin cambiar, copiarla todos los días puede aportar muy poco valor adicional.
Copia completa, incremental y diferencial: qué cambia entre ellas
INCIBE distingue tres métodos habituales que pueden combinarse según almacenamiento, frecuencia y facilidad de recuperación.
Copia completa
Guarda todo el conjunto seleccionado. Suele ser sencilla de entender y restaurar, pero consume más espacio y tiempo.
Copia incremental
Guarda únicamente lo que cambió desde la última copia, sea completa o incremental. Reduce almacenamiento, pero para restaurar pueden necesitarse varias copias encadenadas.
Copia diferencial
Guarda los cambios realizados desde la última copia completa. Normalmente necesita más espacio que una incremental, pero simplifica la recuperación porque suele bastar con la copia completa y la última diferencial.
Para el propietario de una web no es imprescindible dominar estas técnicas. Lo importante es saber qué sistema utiliza su proveedor y si la restauración completa está realmente resuelta.
No dependería de una única copia guardada en el mismo lugar que la web
Si la única copia vive dentro de la misma cuenta de hosting y esa cuenta se elimina, se corrompe o queda comprometida, podrías perder a la vez la web y su backup.
Una referencia conocida para aumentar resiliencia es la estrategia 3-2-1:
- mantener tres copias de la información contando la original;
- utilizar al menos dos ubicaciones o medios diferentes;
- conservar al menos una copia separada o fuera del entorno principal.
No todas las webs sencillas necesitan montar una infraestructura compleja, pero el principio es útil: un mismo incidente no debería poder destruir todas las copias a la vez.
También revisaría quién puede acceder a los backups, porque una copia puede contener la misma información sensible que el sistema original.
Conservar varias versiones importa porque la copia más reciente también puede estar dañada
Imagina que un problema empezó hace veinte días y nadie lo detectó hasta hoy. Si conservas únicamente la copia de anoche, es posible que esa copia ya contenga el mismo problema.
Por eso una política de backup debe pensar también en retención: cuántas versiones se conservan antes de eliminar las antiguas.
La cantidad depende de:
- frecuencia de las copias;
- espacio disponible;
- cuánto tarda normalmente un problema en detectarse;
- cantidad y valor de los datos;
- obligaciones aplicables al proyecto;
- facilidad para reconstruir información antigua.
“Tenemos backup” y “tenemos histórico suficiente” son dos afirmaciones diferentes.
Un backup no está realmente validado hasta comprobar que puede restaurarse
Este es uno de los puntos más importantes. El archivo puede existir y aun así estar incompleto, corrupto o depender de elementos que nadie guardó.
NIST insiste actualmente en que una gestión efectiva de backups no se limita a crearlos regularmente: también debe incluir pruebas y revisiones dentro de los procedimientos de recuperación.
Una comprobación debería responder:
- ¿podemos localizar la copia que necesitamos?
- ¿sabemos a qué fecha corresponde?
- ¿contiene archivos y base de datos cuando ambos son necesarios?
- ¿tenemos credenciales y documentación para restaurar?
- ¿la copia puede abrirse o importarse?
- ¿la web recuperada funciona después de restaurarla?
- ¿formularios, usuarios, pedidos o funciones críticas siguen operativos?
No hace falta restaurar la web de producción cada semana para demostrarlo. La prueba puede realizarse de forma controlada según el nivel de riesgo del proyecto.
Haz una copia específica antes de actualizaciones, migraciones o cambios con riesgo
La copia periódica y la copia previa a una intervención cumplen objetivos diferentes.
Si vas a actualizar varios plugins, cambiar PHP, migrar de servidor, modificar código importante o importar información, conviene disponer de una versión reciente justo antes del cambio.
WordPress recomienda hacer una copia antes de actualizar precisamente porque una actualización puede generar problemas inesperados.
Esa copia permite relacionar con claridad: antes del cambio funcionaba / después del cambio apareció el problema.
8 errores frecuentes con las copias de seguridad web
1. Copiar solo los archivos y olvidar la base de datos
En muchas webs dinámicas perderías contenido y datos esenciales.
2. Guardar la única copia en el mismo hosting
El mismo incidente podría afectar al original y al backup.
3. Tener únicamente la última versión
El problema puede llevar días o semanas dentro de la copia sin haberse detectado.
4. No saber de qué fecha es cada backup
En una emergencia puedes terminar restaurando una versión demasiado antigua o posterior al inicio del problema.
5. Dar por hecho que el hosting lo copia todo
Hay que comprobar qué cubre realmente el proveedor, cuánto tiempo conserva las copias y si la restauración está incluida.
6. Nunca probar la restauración
Descubrir que el backup no funciona durante una caída es demasiado tarde para diseñar el procedimiento.
7. Hacer copias con una frecuencia que no corresponde al negocio
Copiar una tienda una vez al mes puede implicar demasiada pérdida de datos. Copiar una landing invariable cada pocos minutos puede ser innecesario.
8. Pensar que tener backup significa estar protegido contra hackeos
Las copias ayudan a recuperar. No sustituyen actualizaciones, control de accesos ni otras medidas de prevención.
Si la web ya está caída, no restaures automáticamente la copia más reciente
Antes de sobrescribir el estado actual conviene saber:
- qué provocó el fallo;
- cuándo empezó;
- qué fecha tiene la copia;
- qué datos recientes se perderían;
- si la copia también contiene el problema;
- si podemos conservar el estado actual antes de restaurar.
Especialmente en ecommerce, reservas o sistemas con usuarios, restaurar una base de datos antigua puede eliminar información válida.
Para actuar ante una caída, sigue la guía sobre qué hacer si tu página web deja de funcionar .
Checklist: una copia de seguridad web fiable debería responder estas 10 preguntas
- ¿Qué exactamente estamos copiando?
- ¿Necesitamos archivos, base de datos o ambos?
- ¿Cada cuánto cambia la información?
- ¿Cuántos datos podemos permitirnos perder?
- ¿Dónde se guarda la copia?
- ¿Existe al menos una versión separada del entorno principal?
- ¿Cuántas versiones conservamos?
- ¿Quién puede acceder a los backups?
- ¿Hemos probado que pueden restaurarse?
- ¿Sabemos qué hacer y a quién acudir cuando necesitemos recuperar?
¿No sabes qué copias tiene ahora mismo tu web o si podrían restaurarse?
Podemos revisar cómo está planteado el mantenimiento técnico, qué sistema de copias existe y si la frecuencia tiene sentido para el tipo de proyecto. Si lo que necesitas es una política más avanzada de continuidad o ciberseguridad, se valora como una necesidad diferente.
Preguntas frecuentes sobre copias de seguridad web
¿Qué debe incluir una copia de seguridad de una página web?
Depende de la tecnología. En una web dinámica normalmente hay que proteger tanto los archivos como la base de datos y, cuando corresponda, configuraciones necesarias para reconstruir el entorno. En WordPress, copiar solo los archivos no equivale a copiar también la base de datos.
¿Cada cuánto tiempo debería hacerse una copia de seguridad web?
La frecuencia debería depender de cuánto cambia la web y de cuánta información estarías dispuesto a perder. Una web corporativa que cambia poco puede necesitar copias menos frecuentes que una tienda online con pedidos diarios, usuarios o reservas.
¿Es suficiente guardar el backup en el mismo hosting?
Es mejor que no sea la única copia. Si el problema afecta al propio hosting, a la cuenta o al almacenamiento, podrías perder tanto la web como su copia. Mantener al menos una copia separada del entorno principal aumenta la capacidad de recuperación.
¿Una copia de seguridad evita que hackeen la web?
No. Un backup no evita un ataque. Su función es ayudar a recuperar archivos y datos después de una incidencia. Para reducir el riesgo de compromiso hacen falta otras medidas de seguridad y mantenimiento.
¿Cómo sé si una copia de seguridad funciona?
La forma fiable de comprobarlo es verificar que la copia está completa y realizar pruebas de restauración de forma periódica o dentro de un procedimiento controlado. Que un archivo de backup exista no demuestra por sí solo que pueda recuperarse correctamente.
¿Cuántas versiones de una copia conviene conservar?
No existe un número universal. Conviene conservar varias versiones cuando existe el riesgo de descubrir tarde un problema, porque la copia más reciente podría contener ya el error, malware o datos dañados. La retención debe adaptarse al ritmo de cambios y al riesgo del proyecto.
¿Hay que hacer una copia antes de actualizar una web?
Es una buena práctica antes de cambios con riesgo de afectar al funcionamiento, especialmente actualizaciones importantes, migraciones o modificaciones de componentes relacionados. WordPress recomienda realizar una copia antes de actualizar.