La mayoría de los e-comerciantes piensan que están respaldados. La mayor parte no lo está realmente. En las auditorías que realizamos, 6 tiendas de cada 10 no tienen una copia de seguridad restaurable en menos de 4 horas, 3 de cada 10 tienen copias corruptas o incompletas, y aproximadamente 1 de cada 10 no tiene ninguna copia explotable desde hace más de un mes — a menudo sin saberlo.
El coste de un incidente sin copia de seguridad funcional es entre 24 h y varias semanas de parada, datos de clientes perdidos, y a veces el cese de actividad. Este artículo describe la estrategia de copia de seguridad que debería tenerse en 2026 en una tienda PrestaShop: la regla 3-2-1, el cifrado, la rotación, y sobre todo — la restauración probada.
Por qué las copias de seguridad por defecto no son suficientes
«Mi alojador hace copias de seguridad» es la frase que vuelve más a menudo. Cierto en general, e insuficiente en la práctica:
- Las copias de seguridad del alojador están en el mismo centro de datos. Un incendio mayor (OVH Estrasburgo 2021), un ataque ransomware, o un compromiso del panel de administración del alojador, y las copias arden con los datos.
- La retención es corta. 7 a 14 días para las ofertas estándar. Si descubres un defacement o una corrupción 3 semanas después, la copia infectada ya ha reemplazado la copia sana.
- ¿La copia incluye realmente todo? Muchos alojadores hacen copia de la base pero no de los archivos, o a la inversa. Y los uploads (imágenes producto, facturas PDF, exportaciones) a veces se olvidan.
- La restauración nunca se prueba. El día D, se descubre que el procedimiento de restauración no funciona, o tarda 36 horas, o pide el acceso a un panel que se ha perdido.
- Sin cifrado. Una copia no cifrada alojada en un tercero es el conjunto de tu base de clientes expuesto en caso de fuga en el proveedor.
La regla 3-2-1: referencia industrial desde hace 30 años
Formulada por el fotógrafo Peter Krogh en 2005 para las copias de seguridad digitales, adoptada por el INCIBE (España), CISA (EE.UU.) y casi la totalidad de los frameworks de seguridad IT:
3 copias de los datos, en 2 soportes diferentes, de las cuales 1 fuera del sitio.
Concretamente para una tienda PrestaShop:
- Copia 1: la producción (tu servidor de prod).
- Copia 2: copia local o en el mismo alojador (rápida de restaurar para los incidentes menores).
- Copia 3: copia fuera del sitio, en un proveedor de almacenamiento tercero (S3, Backblaze B2, Wasabi, Dropbox).
La copia fuera del sitio es la última línea de defensa contra los desastres mayores (incendio, ransomware, quiebra alojador).
Qué hay que respaldar en una tienda PrestaShop
1. La base de datos completa
Todas las tablas, no solo las tablas de negocio. Un dump mysqldump con las opciones --single-transaction --quick --routines --triggers para la coherencia y la inclusión de procedimientos almacenados y triggers.
2. Los archivos subidos
La carpeta /img/ (imágenes producto, categorías, fabricantes), /upload/ (archivos adjuntos a los productos), /download/ (productos virtuales y sus entregables), y todos los directorios de módulos de terceros que almacenan archivos (facturas PDF, exportaciones contables, logs).
3. El código y los módulos
Incluso si tienes Git, hacer copia del código en producción permite capturar las modificaciones hotfix no versionadas y el estado exacto de los módulos instalados. Incluye /modules/, /themes/, /override/, y la raíz PrestaShop excepto /var/cache/.
4. La configuración del sistema
Archivos app/config/parameters.php, .htaccess, configuraciones Nginx/Apache, certificados SSL, crontabs. A menudo olvidados, son críticos para rejugar una instalación desde cero.
5. Los emails salientes y logs recientes
Para las obligaciones legales (RGPD, contabilidad), conservar una copia de los logs recientes y de los emails transaccionales. No sistemático, pero útil.
El cifrado ya no es opcional
Una copia de seguridad no cifrada almacenada en un proveedor tercero es un riesgo RGPD mayor: si el proveedor está comprometido, toda tu base de clientes se fuga en claro. Artículo 32 del RGPD: obligación de implementar «medidas técnicas apropiadas», lo que incluye el cifrado en reposo para las copias que contienen datos personales. La AEPD ha sido clara en sus directrices 2024-2025: es una práctica de referencia esperada.
El estándar en 2026: AES-256 con una clave almacenada separadamente de las copias de seguridad. Nunca almacenar la clave de cifrado con las copias — si no, el cifrado no sirve para nada.
La rotación: cuántas versiones conservar
Cuanto más se conserva, mejor — pero cuesta. Estrategia GFS (Grandfather-Father-Son) probada:
- Copias diarias conservadas 7 días.
- Copias semanales conservadas 4 semanas.
- Copias mensuales conservadas 12 meses.
- Copias anuales conservadas 5 a 7 años (según las obligaciones contables locales — en España, la AEAT exige 6 años de conservación de documentación fiscal).
Con esta estrategia, puedes restaurar a cualquier día de los 7 últimos días, cualquier semana del último mes, cualquier mes del último año. Cubre el 99 % de los escenarios de recuperación.
La restauración probada: la única copia que cuenta
Una copia no probada es una superstición, no una copia. La regla absoluta:
Prueba la restauración en un entorno de staging al menos una vez por trimestre.
Esta prueba debe verificar:
- ¿La copia está completa (todas las tablas, todos los archivos)?
- ¿El dump es restaurable sin error?
- ¿El sitio funciona tras la restauración (páginas categoría, carrito, checkout, BO)?
- ¿Cuánto tiempo lleva la restauración completa (RTO: Recovery Time Objective)?
- ¿Cuál es la pérdida de datos máxima (RPO: Recovery Point Objective)?
En las tiendas que hacen esta prueba trimestral, el tiempo de restauración cae de 6-8 horas a 1-2 horas en algunas iteraciones. Y las discrepancias (tabla faltante, permiso erróneo, archivo corrupto) se detectan antes del incidente, no durante.
Nuestro módulo dfbackup: copia de seguridad llave en mano
Implementar esta estrategia a mano requiere el mantenimiento de un script de dump, de un sistema de cifrado, de una rotación y de una subida al almacenamiento S3. Nuestro módulo dfbackup para PrestaShop 8 y 9 empaqueta toda la stack:
- Copia planificada BDD + archivos por cron, intervalo configurable (diario, semanal).
- Cifrado AES-256 con clave separada, almacenable fuera del servidor.
- Destinos múltiples: S3 (y compatibles: Wasabi, Backblaze B2, Scaleway), FTP/SFTP, Dropbox.
- Rotación GFS automatizada: conservación parametrable por nivel.
- Restauración 1-clic desde el BO, con staging opcional.
- Notificaciones por email o webhook en caso de fracaso o de éxito.
- Logs detallados de cada copia (volumen, duración, hash de verificación).
- Compatible multi-shop, multi-idioma, y con retención diferenciada según el perímetro.
Por 129 €, instalas una estrategia de copia de seguridad conforme RGPD e industrializada, sin depender de tu alojador.
Cuánto cuesta no estar respaldado
En una tienda que genera 90 k€ de facturación mensual, una parada de 48 h cuesta directamente 6 000 € en facturación no realizada. Añade los costes indirectos: reconquista de clientes perdidos, comentarios negativos en SAV, impacto SEO si la parada dura (Google puede desindexar si el sitio permanece 404 más de unos días), pérdida de confianza partners. Total realista: 15 a 30 k€ por una parada de 48 h. Por un mes de parada, hablamos de la viabilidad de la empresa.
El coste de una estrategia de copia robusta: 130 € de módulo + 5 a 20 €/mes de almacenamiento S3. La relación coste/riesgo está fuera de debate.
FAQ
¿Las copias incrementales son suficientes?
Solas no. Una copia incremental depende de la copia completa anterior. Si la copia completa está corrupta, toda la cadena incremental es inutilizable. La regla: una copia completa semanal o mensual, completada por incrementales diarias. No al contrario.
¿Cuánto tiempo debe llevar una restauración?
El RTO aceptable depende de la criticidad. Para una tienda e-commerce activa: menos de 4 horas para una restauración completa es el objetivo. Por debajo de 2 horas con un procedimiento rodado y un almacenamiento próximo. Más allá de 8 horas, hay un problema de estrategia o de herramientas.
¿Hay que respaldar los archivos y la base juntos o separadamente?
Juntos, idealmente en una ventana temporal estrecha (10-15 minutos). Una base y archivos desincronizados (por ejemplo, base respaldada por la mañana, archivos por la tarde) crean incoherencias en la restauración: productos en la base que no tienen imagen, facturas referenciadas que no existen en archivo.
¿El almacenamiento cloud (S3) es conforme RGPD?
Sí, si el proveedor está en la UE o propone las Cláusulas Contractuales Tipo (CCT) para las transferencias fuera de la UE. AWS, Scaleway, OVH Object Storage, Backblaze son conformes con configuración apropiada. El cifrado antes de la subida garantiza que incluso un proveedor comprometido no da acceso a nada utilizable.
¿Qué diferencia con una replicación en tiempo real?
La replicación (master-slave MySQL, por ejemplo) protege contra una avería material, no contra los errores humanos o las corrupciones lógicas. Si un script elimina 10 000 productos por error, la réplica aplica la eliminación instantáneamente. La copia versionada guarda una versión sana anterior. Las dos son complementarias, no sustituibles.
Para ir más allá
La copia de seguridad es un eslabón de una cadena más amplia: seguridad, monitorización, gestión de incidentes. Un sitio bien respaldado pero mal monitorizado pierde de todas formas datos entre el incidente y su detección.