Restaurar una copia de seguridad: si no la has probado, no la tienes

«Tenemos copias diarias.» Es lo que dice casi todo el mundo, y suele ser verdad. Lo que no se suele saber es si esas copias se pueden restaurar, cuánto se tarda y qué se pierde por el camino. Eso solo se descubre de dos formas: en un simulacro tranquilo o el día que la tienda está caída. La segunda es la habitual.

Este artículo no va de cuántas copias hacer ni dónde guardarlas, sino del paso que casi nadie da: comprobar que vuelven.

Qué falla al restaurar una tienda

Estos son los problemas que más se repiten cuando una copia se usa por primera vez:

• La copia solo tiene ficheros, o solo base de datos. El hosting copia la carpeta web, pero la base de datos está en otro servidor y no entra. O al revés: hay volcados SQL diarios, pero las imágenes de producto no se copian.
• El volcado está cortado. Se generó con un límite de tiempo o de tamaño y le faltan las últimas tablas. El fichero existe, pesa bastante y nadie lo ha abierto.
• La copia es de la tienda ya infectada. Si el problema es un hackeo, las copias de las últimas semanas pueden contener la misma puerta trasera.
• Solo se guardan unos pocos días. Cuando descubres el problema, la última copia buena ya se ha borrado.
• Nadie tiene acceso. Las copias están en el panel de un hosting cuya contraseña tenía alguien que ya no está, o en una cuenta de almacenamiento a nombre de la agencia anterior.
• Restaurar tarda horas. Una tienda con un catálogo grande puede tener decenas de gigas de imágenes. Descargarlas y subirlas lleva tiempo, y nadie lo había calculado.
• La tienda restaurada no arranca. Por diferencias de versión de PHP o de MySQL entre el servidor original y el nuevo, por cachés que apuntan a rutas viejas o por una configuración con el dominio equivocado.

Lo que tiene que incluir una copia de PrestaShop

1. La base de datos completa, con un volcado consistente (no copiando los ficheros de MySQL en caliente).
2. Todos los ficheros: núcleo, módulos, tema, img/ con las imágenes de producto, download/ si vendes descargables, upload/ con los ficheros de los clientes y las facturas si se guardan en disco.
3. La configuración: el fichero de parámetros con las claves de la instalación. Sin la clave de cookies original, las contraseñas antiguas de los clientes no se podrán comprobar.
4. Lo que vive fuera de la carpeta web: tareas programadas, configuración del servidor, reglas de redirección, certificados.

Cómo hacer un simulacro sin tocar producción

Un simulacro es restaurar una copia real en un sitio distinto de la tienda, como si la tienda hubiera desaparecido. No hace falta parar nada.

1. Elige una copia al azar, no la de anoche. Si solo pruebas la última, no sabes si las de hace una semana valen.
2. Restáurala en un entorno aparte: un subdominio de pruebas protegido con contraseña, un servidor local o un hosting temporal.
3. Aísla la copia antes de abrirla. Desactiva el envío de correo, pon las pasarelas en modo de pruebas, bloquea la indexación y quita las tareas programadas. Una tienda restaurada con todo encendido puede escribir a tus clientes o cobrarles.
4. Cronometra cada paso: descargar, subir ficheros, importar la base de datos, ajustar el dominio, vaciar la caché.
5. Comprueba que funciona de verdad: portada, una categoría, una ficha con imágenes, el back-office, un pedido de prueba hasta el final, las facturas de un pedido antiguo, la búsqueda.
6. Compara con producción: número de productos, de clientes y de pedidos, y la fecha del último pedido de la copia.
7. Apunta lo que ha fallado y arréglalo en el sistema de copias, no en la copia.

Dos cifras que debes conocer

Del simulacro salen las dos respuestas que importan el día del problema:

• Cuánto puedes perder: el tiempo entre la última copia y el momento del fallo. Con copias diarias, hasta un día de pedidos, clientes y cambios en el catálogo. Si eso es demasiado, necesitas copias de la base de datos más frecuentes.
• Cuánto tardas en volver: el tiempo real que ha llevado el simulacro, más el margen de hacerlo con prisa y nervios. Si son seis horas, la tienda estará seis horas fuera.

Con esas dos cifras puedes decidir con datos si tu sistema de copias es suficiente o si necesitas otro.

Restaurar después de un hackeo

Es el caso más delicado. No basta con volver a la última copia:

• Busca cuándo empezó el problema y restaura una copia anterior, o restaura la más reciente y límpiala comparando con el núcleo y los módulos originales.
• Recupera los pedidos y clientes posteriores a la copia desde la base de datos actual, con cuidado de no traer también lo que metió el atacante.
• Cierra la vía de entrada antes de volver a abrir. Si no, la tienda restaurada estará igual de expuesta.
• Cambia todas las credenciales después de restaurar.

Apúntalo

El procedimiento de restauración tiene que estar escrito: dónde están las copias, con qué cuenta se accede, qué pasos se siguen, quién lo hace y a quién se llama si esa persona no está. El día que lo necesites no será un día tranquilo, y lo que no esté escrito se olvidará. Repite el simulacro cada pocos meses y siempre después de cambiar de hosting, de versión de PrestaShop o de PHP: una copia que restauraba bien en el servidor anterior puede no hacerlo en el nuevo.

Cómo resolverlo en PrestaShop

El Hosting plan profesional de Rekire está pensado para alojar tiendas PrestaShop. Si prefieres quedarte en tu hosting actual, con un bono de horas de soporte técnico de Rekire revisamos qué copias tienes, hacemos el simulacro de restauración en un entorno aislado (sin correo saliente, con las pasarelas en pruebas y sin indexación), medimos cuánto se tarda y qué se pierde, y te dejamos escrito el procedimiento para el día que haga falta.