Copias de seguridad web: un plan de recuperación para que tu web resista

La llamada suele llegar un lunes por la mañana. «La web no carga», «sale una página en blanco», «el hosting dice que nos han suspendido la cuenta». Lo primero que preguntamos en el estudio es siempre lo mismo: ¿tenéis copia de seguridad? Y la respuesta más frecuente es «creo que el hosting hace copias». A veces es verdad y la web vuelve en una hora. Otras, la copia más reciente tiene tres meses, o está en el mismo servidor que ha fallado, o nadie sabe cómo restaurarla.

Una copia de seguridad solo vale lo que vale su restauración. Esa idea es la que ordena toda esta guía. No se trata de acumular archivos comprimidos en una carpeta, sino de tener un plan que responda a una pregunta muy concreta: si mañana la web desaparece, ¿cuánto tardo en recuperarla y cuánta información pierdo por el camino?

La buena noticia es que montar un plan sólido para una web corporativa o una tienda pequeña cuesta poco y se hace una sola vez. Vamos por partes.

01Dos números que ordenan el plan: RPO y RTO

Antes de elegir herramientas conviene fijar dos objetivos. Son términos del mundo de la continuidad de negocio, pero se entienden muy rápido:

• →RPO (Recovery Point Objective), punto de recuperación: cuánta información puedes permitirte perder, medida en tiempo. Si haces una copia diaria a las tres de la madrugada y la web cae a las seis de la tarde, pierdes como mucho quince horas de cambios.
• →RTO (Recovery Time Objective), tiempo de recuperación: cuánto tiempo puede estar la web fuera de servicio antes de que el problema sea serio para el negocio.

Ponerles número cambia la conversación. A una web corporativa que se actualiza una vez al mes, perder un día de cambios no le afecta y una recuperación en unas horas es razonable. A una tienda online, perder un día de pedidos supone clientes que pagaron y no constan en ningún sitio. Ahí el RPO baja a minutos u horas y el RTO a menos de una hora.

Son orientaciones del estudio, no normas. Lo útil es acordarlas con el negocio y escribirlas, porque de ellas dependen la frecuencia, las herramientas y el presupuesto.

02Qué hay que copiar (más de lo que parece)

Una web no es solo una carpeta de archivos. Para poder reconstruirla completa necesitas:

1. 01La base de datos. Contenidos, usuarios, pedidos, ajustes. En WordPress, todo lo que no es imagen o código vive aquí.
2. 02Los archivos subidos. Imágenes, PDF, vídeos que el equipo ha ido añadiendo (en WordPress, wp-content/uploads).
3. 03El código. Tema, plugins o la aplicación a medida. Si el proyecto está en Git, el repositorio ya es una copia del código, como contamos en la guía de Git y despliegue continuo.
4. 04La configuración del servidor. Versiones de PHP o Node, reglas de redirección, tareas programadas, variables de entorno (guardadas de forma segura).
5. 05Los registros DNS. Una exportación de la zona del dominio, con los registros de la web y del correo. Si cambias de proveedor con prisas, tenerla ahorra muchísimos problemas. Lo explicamos en la guía de dominio y DNS.
6. 06Las credenciales de acceso, guardadas en un gestor de contraseñas compartido: hosting, registrador del dominio, CDN, servicios integrados.

El correo electrónico merece un comentario aparte: si está en Google Workspace o Microsoft 365, la copia de los buzones se gestiona en esa plataforma, con sus propias herramientas, y conviene revisarla también.

03La regla 3-2-1 aplicada a una web

La regla 3-2-1 es el estándar de referencia en copias de seguridad desde hace años, y se traduce muy bien al mundo web:

• →3 copias de los datos: la web en producción más dos copias.
• →2 soportes o sistemas distintos: por ejemplo, las copias del propio hosting y un almacenamiento de objetos de otro proveedor.
• →1 copia fuera de la infraestructura principal: en otro proveedor y, a ser posible, en otra región.

Muchos equipos la amplían a 3-2-1-1-0: una copia inmutable o desconectada (que nadie, ni siquiera alguien con las credenciales de la web, puede modificar o borrar durante un tiempo) y cero errores en las verificaciones de restauración.

Los almacenamientos de objetos compatibles con S3 (Amazon S3, Backblaze B2, Wasabi, Scaleway, OVHcloud y otros) permiten activar el versionado y el bloqueo de objetos (object lock), que es precisamente lo que convierte una copia en inmutable. Si tu web trata datos personales, elige una ubicación dentro de la Unión Europea, y así simplificas el cumplimiento del RGPD.

04Herramientas según el tipo de web

No hay una herramienta universal, pero sí combinaciones que funcionan bien.

WordPress

• →Plugins de copia como UpdraftPlus, BlogVault o Jetpack VaultPress Backup: programan copias de base de datos y archivos y las envían a un almacenamiento externo. Los que hacen copias incrementales y las procesan en sus propios servidores cargan menos tu web.
• →Copias del hosting gestionado: muchos proveedores especializados en WordPress hacen copias diarias automáticas con restauración en un clic. Es una buena primera capa.
• →WP-CLI para exportar la base de datos desde tareas programadas del servidor, cuando quieres control total.

Webs a medida y servidores propios

Para un VPS o servidor dedicado, la combinación que más usamos es un volcado de base de datos más una herramienta de copias incrementales, cifradas y con deduplicación, como restic o BorgBackup, enviando a un almacenamiento de objetos externo. Un ejemplo simplificado de tarea nocturna:

#!/bin/sh
# Volcado de la base de datos (MySQL/MariaDB) sin bloquear tablas InnoDB
mysqldump --single-transaction --routines miweb_db | gzip > /var/backups/db/miweb.sql.gz
# Copia incremental y cifrada de base de datos, archivos subidos y configuración
restic -r s3:https://s3.eu-central-1.example.com/copias-miweb backup \
  /var/backups/db /var/www/miweb/shared/uploads /etc/nginx/sites-available
# Retención: 14 diarias, 8 semanales, 12 mensuales
restic -r s3:https://s3.eu-central-1.example.com/copias-miweb forget \
  --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --prune

Para PostgreSQL el equivalente es pg_dump, y los servicios de base de datos gestionados suelen ofrecer copias con recuperación a un momento concreto (point-in-time recovery), muy útil para tiendas.

Plataformas SaaS

Si tu tienda está en Shopify o tu web en un constructor como Webflow, la plataforma se encarga de la infraestructura, pero los datos siguen siendo tuyos. Conviene exportar periódicamente productos, clientes y pedidos, o usar una aplicación de copias del propio ecosistema, para poder deshacer un cambio masivo erróneo en el catálogo.

05Retención: cuántas copias guardar y durante cuánto tiempo

Guardar solo la copia de ayer tiene un riesgo poco evidente: si un problema tarda una semana en detectarse (un plugin que corrompe datos poco a poco, un contenido borrado sin querer, una intrusión silenciosa), todas tus copias recientes ya lo incluyen. La solución es un esquema escalonado, conocido como abuelo-padre-hijo:

• →Copias diarias de las últimas 2 semanas.
• →Copias semanales de los últimos 2 meses.
• →Copias mensuales de los últimos 12 meses.

Con unas treinta copias cubres un año entero con buena resolución reciente, y como las herramientas modernas deduplican (solo guardan lo que cambia), el espacio que ocupan es mucho menor de lo que parece.

06Ensayar la restauración: la parte que convierte copias en tranquilidad

Este es el paso que casi nadie hace y el que más valor aporta. Una vez cada trimestre (o cada mes en una tienda), restauramos una copia completa en un entorno aparte y comprobamos que la web funciona. El procedimiento:

1. 01Elige una copia al azar, no siempre la de anoche.
2. 02Crea un entorno limpio: un subdominio de pruebas o un servidor temporal, protegido con contraseña y con noindex.
3. 03Restaura la base de datos, los archivos y la configuración siguiendo el documento de recuperación, tal como está escrito.
4. 04Comprueba la portada, varias páginas interiores, las imágenes, el formulario de contacto y, en una tienda, el último pedido registrado.
5. 05Anota el tiempo total y cualquier paso que faltara en el documento.
6. 06Actualiza el documento con lo aprendido y destruye el entorno de prueba.

El tiempo que anotas es tu RTO real. Si es mayor que el objetivo, ya sabes dónde mejorar: automatizar un paso, tener la configuración del servidor como código o elegir un proveedor con restauración más rápida.

El documento de recuperación

Es una página, no un manual. Debe poder seguirlo alguien del equipo un domingo sin llamarte. Incluye dónde están las copias y cómo acceder a ellas, dónde está la clave de cifrado, los pasos de restauración en orden, a quién avisar (hosting, cliente, equipo) y cómo comprobar que todo funciona. Guárdalo fuera del servidor de la web, evidentemente.

07El día que hace falta: restaurar con calma

Cuando la web cae de verdad, el plan ya está hecho y solo queda seguirlo. Lo que mejor funciona es separar el diagnóstico de la restauración, porque con prisa es fácil restaurar encima de la única pista que explicaba el problema.

• →Primero, una foto del estado actual. Antes de tocar nada, copia la web tal y como está, aunque esté rota. Si ha habido una intrusión, ahí están los rastros; si era un fallo de una actualización, ahí ves qué cambió.
• →Después, decide desde qué copia restaurar. En un fallo técnico, la más reciente. En una intrusión, la última anterior a la fecha de entrada, que los registros del servidor ayudan a localizar.
• →Restaura primero en pruebas si el RTO lo permite, comprueba y luego pasa a producción. En una tienda, cruza los pedidos de la pasarela de pago con los de la copia para recuperar los que falten.
• →Por último, cierra la causa: actualiza el componente que falló, cambia contraseñas y anota en el documento de recuperación lo que has aprendido.

Comunicar también forma parte de la recuperación. Un aviso breve en redes o una página de mantenimiento bien diseñada transmiten control y mantienen la confianza mientras trabajas.

08Ejemplo resuelto: el plan de una tienda pequeña

Para ilustrar cómo encaja todo, este es el planteamiento que solemos proponer a una tienda online con unos pocos pedidos al día, alojada en un hosting gestionado de WordPress. Las cifras son ilustrativas y se ajustan en cada caso:

• →Objetivos acordados: RPO de 1 hora para pedidos, RTO de 2 horas.
• →Capa 1: copias diarias automáticas del hosting, con retención de 30 días.
• →Capa 2: plugin de copias incrementales con copia de la base de datos cada hora y de los archivos cada día, enviadas a un almacenamiento de objetos en la UE, cifradas y con versionado activado.
• →Capa 3: copia mensual inmutable con bloqueo de objetos durante 90 días.
• →Extras: exportación de la zona DNS y documento de recuperación en el gestor de contraseñas del equipo.
• →Verificación: restauración de prueba trimestral y alerta por correo si una copia falla.

Para una tienda de este tamaño, el coste de almacenamiento suele quedarse en unos pocos euros al mes. Lo que de verdad cuesta es la primera configuración y el hábito de probar, y eso es justo lo que se resuelve con un buen contrato de mantenimiento.

09Copias como parte del cuidado de la web

Las copias de seguridad son a la web lo que el seguro a un local: se notan poco mientras todo va bien y lo cambian todo el día que algo pasa. Combinadas con actualizaciones al día, un certificado bien configurado (lo tratamos en la guía de HTTPS y certificados SSL) y un flujo de publicación ordenado, forman la base de una web que aguanta.

En SIMA las incluimos, con su restauración de prueba, en todos nuestros planes de mantenimiento web. Si quieres saber cuánto tardarías hoy en recuperar tu web, escríbenos y hacemos juntos la prueba.