Copias de seguridad web: qué incluir y cada cuánto

La pregunta no es «¿tengo copias de seguridad?»: casi todo el mundo cree que sí. La pregunta es «si mañana la web desaparece, ¿voy a poder recuperarla con los pedidos de esta semana, en cuánto tiempo y quién lo hace?». Ahí se cae la mayoría. Veamos qué tiene que llevar dentro una copia para que sirva el día malo, cada cuánto hacerla, cuánto tiempo guardarla y por qué la del hosting, tal cual, no cuenta como copia.

Qué es una copia completa: ficheros, base de datos y configuración

Una web moderna no es una carpeta. Son tres cosas, y una copia que solo tenga una de ellas no te devuelve nada.

Los ficheros

Todo lo que cuelga de la raíz de tu web, que en un hosting con cPanel suele ser /public_html/: el núcleo de WordPress, el tema, los plugins y, sobre todo, wp-content/uploads/, donde viven tus imágenes y tus PDF. También los ficheros que se olvidan porque empiezan por punto o no se ven: .htaccess y wp-config.php, con las credenciales de la base de datos.

La base de datos

Aquí está lo que de verdad no se puede rehacer: entradas, páginas, usuarios, pedidos, clientes, comentarios, configuración de todos los plugins. El tema se puede volver a comprar; los pedidos de marzo, no. Si tienes acceso por SSH, se exporta así:

mysqldump -u USUARIO -p NOMBRE_BASE > copia_$(date +%F).sql

Y si tienes WP-CLI disponible, que muchos hostings españoles ya incluyen:

wp db export copia_$(date +%F).sql

Desde el panel, en cPanel lo tienes en Asistente de copia de seguridad o exportando desde phpMyAdmin. Si exportas desde phpMyAdmin, elige el método «personalizado» y marca la opción de añadir DROP TABLE, porque si no, al restaurar sobre una base que ya tiene tablas te va a dar errores.

La configuración que no está en ninguno de los dos

Es la parte que nadie copia y la que más retrasa una recuperación: la zona DNS del dominio, las cuentas de correo y sus reenvíos, los registros SPF, DKIM y DMARC, los certificados y sus redirecciones, las tareas programadas del panel (cron) y las credenciales de los servicios externos. Basta con un documento con capturas y valores, guardado fuera del servidor. Si algún día hay que remontar la web en otro proveedor, te ahorra dos días.

Cada cuánto según lo que cambie tu web: blog, tienda o reservas

La frecuencia correcta no la decide un manual: la decides tú respondiendo a una pregunta incómoda, «¿cuántas horas de trabajo estoy dispuesto a perder?». Esa cantidad es tu intervalo entre copias.

Web corporativa que se toca una vez al mes. Copia semanal de todo y copia extra manual antes de cualquier cambio: actualizaciones, cambio de tema, migración. Perder una semana de una web que no cambia no duele.
Blog o web con publicación frecuente. Copia diaria de la base de datos y semanal de los ficheros. Los ficheros casi no cambian; el contenido, sí.
Tienda online o web con reservas. Copia diaria como mínimo, y si tienes volumen real de pedidos, base de datos varias veces al día. Perder los pedidos de una mañana significa llamar uno por uno a clientes que ya han pagado.
Antes de cualquier actualización importante. Siempre, sin excepción, y comprobando que la copia ha terminado bien antes de pulsar el botón de actualizar.

Una advertencia sobre las copias diarias en hosting compartido: si tu web es grande, el proceso puede tardar y consumir recursos. Comprueba en el registro que termina, no solo que empieza.

Cuánto tiempo hay que guardarlas (y por qué siete días se quedan cortos)

Aquí está el fallo más caro y el menos evidente. Muchos planes de alojamiento guardan siete días de copias en rotación. Eso cubre perfectamente el escenario «he borrado una página sin querer». No cubre el escenario que de verdad hace daño.

Cuando alguien compromete una web, no suele romperla el primer día. Deja un fichero, espera, y el problema se manifiesta semanas después, cuando Google marca el sitio o el hosting suspende la cuenta. Si en ese momento todas tus copias son de los últimos siete días, todas contienen ya la puerta trasera. Restauras, y en unos días vuelves a estar igual. Esa es la razón por la que tanta gente dice «lo restauré y volvió a pasar».

Un esquema de retención razonable para una pyme:

Copias diarias de los últimos 14 a 30 días.
Una copia semanal conservada durante 2 o 3 meses.
Una copia mensual conservada durante un año.

Ocupa poco y te da la posibilidad de volver a un punto anterior al compromiso. Aun así, restaurar una copia antigua sin averiguar por dónde entraron solo te da tiempo: hay que cerrar la puerta antes de volver a abrir la web.

Dónde guardarlas: por qué la copia del hosting no cuenta como copia

Que tu proveedor haga copias está muy bien y no hay que renunciar a ello. Pero no puede ser tu única copia, por cuatro motivos muy concretos:

Si el hosting suspende tu cuenta por malware, a veces pierdes el acceso al panel y, con él, a las copias, justo cuando más las necesitas.
Si el problema es una incidencia del propio proveedor, la copia puede estar afectada por la misma incidencia.
Si te vas de ese proveedor o hay un problema de facturación, esas copias desaparecen contigo.
Muchos planes cobran por restaurar, o la restauración solo la hace soporte y tarda lo que tarde su cola de tickets.

Ese último punto conviene mirarlo antes de firmar, no el día del incidente. Es una de las preguntas que recogemos en la guía de cómo elegir hosting para tu empresa sin que te den gato por liebre, junto al precio real de la renovación y a quién actualiza qué.

Lo mínimo sensato es tener, además de la del hosting, una copia en un sitio bajo tu control: un disco externo en la oficina, un almacenamiento en la nube o un servicio de copias independiente. Y descargar de vez en cuando el fichero completo a un ordenador, aunque sea a mano una vez al mes. Un archivo .zip en un disco de tu despacho no es elegante, pero funciona.

La regla 3-2-1 traducida a una empresa pequeña

La regla clásica dice: tres copias de los datos, en dos soportes distintos, con una de ellas fuera de las instalaciones. Traducido a una empresa de diez personas y sin departamento técnico:

Copia 1: la web en producción, que es el original.
Copia 2: las copias automáticas del hosting o de tu plugin de copias, que están en el mismo entorno.
Copia 3: una copia en un servicio o disco totalmente ajeno al hosting, a la que tú tienes acceso sin depender de nadie.

Y la parte que nadie hace: al menos una copia tiene que estar donde un ataque a tu web no llegue. Si tu servidor sube las copias a la nube con unas credenciales guardadas en el propio servidor, quien entre puede borrarlas también. Usa credenciales de solo escritura, o descarga las copias desde fuera en lugar de subirlas desde dentro.

Copias y RGPD: qué datos de clientes te llevas en el fichero

Es fácil olvidarlo: dentro de esa copia van nombres, correos, teléfonos, direcciones de envío y, en algunos casos, más. La copia es un tratamiento de datos personales como cualquier otro, y eso tiene tres consecuencias prácticas:

El sitio donde la guardas importa. Si es un servicio en la nube, ese proveedor es encargado del tratamiento y debe estar recogido en tu documentación, igual que el hosting o la agencia.
Protégela. Una copia de seguridad es una base de datos completa de tus clientes en un solo fichero. No la dejes en una carpeta accesible desde el navegador ni en un pendrive sin cifrar en la guantera del coche. Ese fichero descuidado es una brecha esperando a ocurrir.
No las guardes eternamente. Un esquema de retención definido (por ejemplo, el de arriba) es también la forma de justificar cuánto tiempo conservas esos datos y por qué.

Un matiz que confunde a mucha gente: si un cliente ejerce su derecho de supresión, se le borra de los sistemas activos. No se te exige reventar las copias históricas para localizarlo, pero sí que ese dato no vuelva a la vida si algún día restauras. Anótalo en tu procedimiento.

Cinco señales de que tu copia no sirve para nada

Repasa esta lista con la tuya. Si marcas alguna, tienes trabajo:

Nunca la has restaurado. Es la señal más grave y la más común. Una copia sin una restauración de prueba es una hipótesis; cómo hacer esa prueba sin tocar la web en producción lo explicamos en cómo probar que tu copia de seguridad se restaura de verdad.
Está en el mismo servidor. Si el atacante o el fallo llegan al servidor, llegan a la copia.
No incluye la base de datos, o no incluye los ficheros. Tener solo una mitad es tener nada.
No sabes cuándo se hizo la última. Si nadie mira el registro, el proceso puede llevar meses fallando en silencio: cuota llena, credenciales caducadas, plugin desactivado tras una actualización.
Depende de una persona. Si solo el informático que te la montó sabe dónde están y cómo se restauran, y ese informático no coge el teléfono un sábado, la copia no está a tu disposición.

Este último punto es más habitual de lo que parece cuando la web la lleva un tercero. Los accesos, la ubicación de las copias y el compromiso de restauración deberían estar por escrito desde el primer día; qué exigir exactamente lo detallamos en el artículo sobre qué mirar al contratar una agencia web en materia de seguridad. Y si quieres ver dónde encaja todo esto dentro del resto de la configuración, la guía de configuración segura de una web: hosting, HTTPS, correo y DNS pone las copias en su sitio dentro del orden completo.

Lo que puedes hacer hoy en media hora

Entra en el panel de tu hosting y averigua tres datos: si hay copias, de cuántos días y si restaurar tiene coste. Descarga a tu ordenador una copia completa de ficheros y base de datos, aunque sea a mano. Y anota en un documento las cuentas de correo, la zona DNS y las tareas programadas. Con eso ya estás mejor que la mayoría, y no has gastado un euro.

Ahora bien, una copia solo te salva si te enteras del problema a tiempo. Si un fichero extraño aparece hoy y tú lo descubres dentro de cinco semanas porque Google te marca, para entonces la copia limpia puede haber caducado. Con Pulse te enteras del problema antes de tener que tirar de copia: vigila los cambios en tus ficheros y el estado de la web las 24 horas, desde 19 euros al mes, y te avisa el día que algo cambia, no el mes que viene.

Seguir leyendo en esta sección

Ver todo en Hosting, certificados y copias → · Mapa completo del sitio