¿Cómo hacer un backup completo (archivos y base de datos) en PrestaShop?

1. Qué es un backup completo de PrestaShop, sin adornos innecesarios 🧩

Un backup completo de PrestaShop incluye dos grandes piezas: los archivos del sitio y la base de datos. Uno sin el otro es un mapa sin territorio, o un escaparate sin almacén. Los archivos contienen el código, módulos, temas, imágenes y configuraciones físicas. La base de datos contiene la información dinámica: productos, categorías, clientes, pedidos, carritos, configuración de tienda, combinaciones, stock, direcciones, cupones y mucho más.

En PrestaShop 1.7, 8 y versiones recientes, buena parte de la configuración de conexión a la base de datos se encuentra en app/config/parameters.php. En instalaciones antiguas, especialmente PrestaShop 1.6, suele estar en config/settings.inc.php. Este detalle importa. En una migración o restauración, esos archivos son la llave bajo el felpudo; útil para el propietario, peligrosa si cae en malas manos.

Idea clave: si solo exportas la base de datos desde el back office, no tienes un backup completo. Tienes una parte importante, sí, pero no las imágenes de producto, ni los módulos personalizados, ni el tema, ni los archivos descargables. Sería como conservar los libros contables de una tienda después de haber perdido el local.

2. Antes de empezar: prepara el terreno para no copiar el caos 🧭

Hacer una copia de seguridad no consiste en pulsar botones con aire solemne. Conviene saber qué se está copiando, desde dónde y con qué estado de la tienda. PrestaShop es dinámico: mientras tú descargas archivos, alguien puede estar pagando un pedido; mientras exportas la base de datos, un módulo puede estar escribiendo registros. La modernidad es eso: todo ocurre al mismo tiempo, incluso lo que preferirías que esperase.

Checklist previa

• Identifica la versión de PrestaShop: 1.6, 1.7, 8.x o superior.
• Localiza el directorio raíz de la tienda: por ejemplo public_html, www, htdocs o una carpeta específica del dominio.
• Comprueba el nombre real del directorio de administración, que suele estar renombrado por seguridad: admin123xyz, gestion, etc.
• Localiza las credenciales de base de datos en app/config/parameters.php o config/settings.inc.php.
• Verifica el espacio disponible en el servidor antes de comprimir archivos.
• Si la tienda recibe pedidos constantes, programa una ventana de mantenimiento.
• Documenta versión de PHP, motor MySQL/MariaDB, módulos críticos, tema activo, integraciones de pago, ERP, CRM, marketplace y transportistas.

¿Debes activar el modo mantenimiento?

Para una copia ordinaria en una tienda pequeña, puede bastar con hacer el backup en horas de baja actividad. Para una tienda con pedidos frecuentes, integraciones externas o mucho movimiento de stock, lo prudente es activar el modo mantenimiento de PrestaShop durante unos minutos. El menú exacto cambia según versión, pero suele encontrarse en áreas como Parámetros de la tienda, Configuración o Mantenimiento.

La razón es sencilla: quieres que archivos y base de datos representen el mismo instante. Si copias la base de datos a las 10:01 y los archivos a las 10:25, mientras un módulo de pago se actualiza entre medias, tu backup puede quedar ligeramente torcido, como una mesa con una pata más corta.

Atención: si estás haciendo el backup justo antes de actualizar PrestaShop, instalar un módulo, cambiar de servidor o tocar el tema, no improvises. Haz primero la copia completa, descárgala fuera del servidor y verifica que se puede abrir. El optimismo no es una estrategia de recuperación.

3. Cómo hacer backup de los archivos de PrestaShop 📁

Los archivos de PrestaShop no son solo “la web”. Son la piel, los huesos y algunas cicatrices. Ahí viven el tema visual, los módulos, imágenes de producto, archivos descargables, personalizaciones, traducciones, documentos y configuraciones.

Carpetas y archivos que no debes olvidar

Método recomendado: backup por SSH

Si tienes acceso SSH, úsalo. Es más rápido, más fiable y menos propenso a errores que descargar miles de archivos por FTP. El FTP, noble anciano de Internet, aún camina; pero para copias grandes se cansa como mula en cuesta.

Ejemplo para comprimir toda la tienda desde el directorio raíz:

cd /home/usuario/public_html
mkdir -p /home/usuario/backups

tar -czpf /home/usuario/backups/prestashop-archivos-$(date +%F).tar.gz .

Este comando crea un archivo .tar.gz con todo el contenido de la tienda. La opción -p ayuda a conservar permisos. El punto final . indica “todo lo que hay aquí”, incluyendo archivos ocultos como .htaccess, siempre que estés en el directorio correcto.

¿Conviene excluir caché y logs?

Depende del objetivo. Para un backup estrictamente forense, copia todo. Para un backup operativo orientado a restaurar la tienda, puedes excluir caché y logs porque suelen regenerarse y ocupan bastante espacio. En PrestaShop 1.7 y 8, la caché suele estar en var/cache. Los logs pueden estar en var/logs o en ubicaciones del hosting.

cd /home/usuario/public_html
mkdir -p /home/usuario/backups

tar --exclude='./var/cache/*' \
    --exclude='./var/logs/*' \
    -czpf /home/usuario/backups/prestashop-archivos-$(date +%F).tar.gz .

Matiz importante: excluir caché no hace que el backup sea incompleto en sentido práctico, porque PrestaShop puede regenerarla. Pero no excluyas carpetas como /img, /modules, /themes, /download o /upload salvo que sepas exactamente lo que haces.

Si no tienes SSH: SFTP, cPanel o panel del hosting

Si tu hosting no ofrece SSH, aún puedes hacer una copia decente:

• SFTP con FileZilla, Cyberduck o WinSCP: descarga todo el directorio raíz de PrestaShop, activando la visualización de archivos ocultos. Revisa la cola de transferencias fallidas.
• Administrador de archivos de cPanel, Plesk o similar: comprime la carpeta de la tienda en .zip o .tar.gz desde el servidor y luego descarga el archivo comprimido.
• Herramientas del proveedor: JetBackup, Acronis, R1Soft, snapshots del hosting o copias completas de cuenta pueden ser útiles, aunque conviene no depender solo de ellas.

El método de comprimir en el servidor y descargar un único archivo suele ser más robusto que transferir 60.000 archivos pequeños. Los archivos pequeños por FTP son como granos de arroz en una tormenta: alguno acaba en el suelo.

4. Cómo hacer backup de la base de datos de PrestaShop 🗄️

La base de datos es el diario íntimo de la tienda. Ahí están los pedidos de madrugada, los carritos abandonados, las reglas de descuento que alguien creó en 2021 y nadie se atreve a borrar, los clientes, el stock, las combinaciones de producto, la configuración de módulos, los transportistas, las URLs y, en instalaciones multitienda, una arquitectura que puede ser tan delicada como una telaraña con facturas.

Localiza las credenciales de conexión

En PrestaShop 1.7, 8 y versiones actuales, abre:

app/config/parameters.php

Busca valores similares a estos:

'database_host' => '127.0.0.1',
'database_port' => '',
'database_name' => 'nombre_basedatos',
'database_user' => 'usuario_basedatos',
'database_password' => 'contraseña',
'database_prefix' => 'ps_',

En PrestaShop 1.6, revisa:

config/settings.inc.php

Encontrarás constantes como _DB_SERVER_, _DB_NAME_, _DB_USER_, _DB_PASSWD_ y _DB_PREFIX_.

Método recomendado: mysqldump por SSH

Para bases de datos medianas o grandes, mysqldump suele ser la opción más fiable. Este comando exporta la base de datos en formato SQL:

mkdir -p /home/usuario/backups

mysqldump --single-transaction \
          --quick \
          --routines \
          --triggers \
          --events \
          --default-character-set=utf8mb4 \
          -u usuario_basedatos \
          -p nombre_basedatos > /home/usuario/backups/prestashop-db-$(date +%F).sql

Después puedes comprimir el archivo:

gzip /home/usuario/backups/prestashop-db-$(date +%F).sql

O hacerlo en una sola línea:

mysqldump --single-transaction --quick --routines --triggers --events --default-character-set=utf8mb4 \
-u usuario_basedatos -p nombre_basedatos | gzip > /home/usuario/backups/prestashop-db-$(date +%F).sql.gz

Qué significan esas opciones

Sobre InnoDB y MyISAM: --single-transaction es especialmente útil con tablas InnoDB. Si tu tienda conserva tablas MyISAM antiguas o de módulos viejos, puede que necesites una ventana de mantenimiento o bloqueo de tablas para máxima consistencia. PrestaShop moderno trabaja habitualmente con InnoDB, pero los módulos de terceros a veces son arqueología con PHP.

Exportar con phpMyAdmin

Si no tienes SSH, phpMyAdmin puede servir, especialmente para bases de datos pequeñas o medianas.

1. Accede a phpMyAdmin desde el panel de hosting.
2. Selecciona la base de datos de PrestaShop.
3. Haz clic en Exportar.
4. Elige método Personalizado, no solo rápido si quieres controlar opciones.
5. Formato: SQL.
6. Marca todas las tablas correspondientes a tu instalación. El prefijo suele ser ps_, aunque puede variar.
7. Activa opciones como Agregar sentencia DROP TABLE si vas a restaurar sobre una base existente.
8. Selecciona compresión gzip si está disponible.
9. Exporta y descarga el archivo.

phpMyAdmin es cómodo, pero tiene techo: límites de tiempo, memoria, tamaño de descarga y paciencia humana. En bases grandes, puede fallar a mitad de camino con la discreción de una vela apagándose. Si tu base pesa cientos de megabytes o varios gigabytes, usa SSH o una herramienta del hosting.

Exportar desde el panel del hosting

Muchos proveedores permiten descargar la base de datos desde cPanel, Plesk, DirectAdmin u otras plataformas. Es válido si el sistema genera un dump SQL completo. Aun así, verifica el archivo. “El hosting hace backups” es una frase tranquilizadora, como “el paraguas está en algún lugar”; útil solo si sabes dónde y si no está roto.

5. ¿Sirve el backup desde el back office de PrestaShop? Sí, pero no como único salvavidas ⚙️

PrestaShop incluye, según versión y configuración, una opción para realizar copias de la base de datos desde el panel de administración. Puede aparecer en rutas como Parámetros avanzados > Base de datos > Copia de seguridad DB o similares. Es una herramienta práctica para exportaciones puntuales de la base de datos.

Pero hay que decirlo sin ceremonias: no es un backup completo. No copia archivos de la tienda, imágenes, módulos, temas, archivos descargables ni personalizaciones en disco.

No confundas “backup de base de datos” con “backup de tienda”. Si mañana desaparece tu carpeta /img, el SQL no dibujará mágicamente las fotografías de tus productos. Sería hermoso, casi bíblico, pero no.

Cuándo usarlo

• Antes de cambios menores en configuración.
• Como copia adicional rápida de la base de datos.
• Para tiendas pequeñas donde el tamaño no provoca errores de tiempo de ejecución.

Cuándo no basta

• Antes de actualizar PrestaShop.
• Antes de cambiar de servidor.
• Antes de instalar o actualizar módulos críticos.
• Cuando necesitas restaurar la tienda completa.
• Cuando has personalizado el tema, módulos u overrides.

6. Verificar el backup: la diferencia entre tener una copia y tener una esperanza 🔍

Un backup no verificado es una promesa. Y las promesas, en tecnología, deberían pagar impuestos. La única copia de seguridad que merece confianza es aquella que se puede abrir, comprobar y restaurar en un entorno de prueba.

Comprobaciones rápidas por SSH

Para verificar que el archivo comprimido de la base de datos no está corrupto:

gzip -t /home/usuario/backups/prestashop-db-2026-01-15.sql.gz

Para listar el contenido del archivo de archivos:

tar -tzf /home/usuario/backups/prestashop-archivos-2026-01-15.tar.gz | head

Para generar sumas de verificación:

cd /home/usuario/backups
sha256sum prestashop-archivos-2026-01-15.tar.gz > prestashop-archivos-2026-01-15.sha256
sha256sum prestashop-db-2026-01-15.sql.gz > prestashop-db-2026-01-15.sha256

Comprobaciones manuales mínimas

• El archivo de archivos pesa una cantidad razonable para tu tienda.
• El dump SQL no pesa 0 KB.
• El archivo SQL contiene instrucciones CREATE TABLE e INSERT INTO.
• El final del dump no muestra errores ni cortes inesperados.
• La carpeta /img está incluida.
• La carpeta /modules está incluida.
• La carpeta /themes está incluida.
• El archivo .htaccess está incluido si tu servidor lo usa.
• Los archivos de configuración sensibles están incluidos pero protegidos.

La prueba reina: restaurar en staging

Lo profesional es restaurar el backup en un entorno de pruebas: un subdominio, una carpeta protegida por contraseña, una máquina local con DDEV, Docker, MAMP, Laragon o un hosting secundario. No hace falta hacerlo todos los días, pero sí periódicamente y antes de cambios grandes.

Una copia que restaura bien en staging es como una llave que has probado en la cerradura. No “parece” que abre. Abre.

Frecuencia recomendada de prueba: en ecommerce con ventas constantes, verifica restauración al menos una vez al trimestre y siempre antes de migraciones o actualizaciones mayores. En tiendas pequeñas, cada seis meses puede ser aceptable, aunque dependerá del riesgo asumible.

7. Cómo restaurar un backup completo de PrestaShop 🧯

Restaurar no es simplemente “subir lo que bajé”. Hay orden. Hay dependencias. Hay pequeños demonios con nombres como permisos, caché, dominio, rutas y versión PHP.

Escenario habitual de restauración

1. Preparas un servidor o entorno con versión compatible de PHP, extensiones necesarias y MySQL/MariaDB.
2. Subes el archivo comprimido de los archivos de PrestaShop.
3. Descomprimes en el directorio correcto.
4. Creas una base de datos vacía.
5. Importas el dump SQL.
6. Ajustas credenciales en app/config/parameters.php o config/settings.inc.php.
7. Revisas la tabla de URLs de tienda.
8. Vacías caché.
9. Regeneras .htaccess si procede.
10. Pruebas front office, back office, carrito, checkout, pago, emails, imágenes y facturas.

Restaurar archivos por SSH

cd /home/usuario/public_html
tar -xzpf /home/usuario/backups/prestashop-archivos-2026-01-15.tar.gz

Si estás restaurando sobre una carpeta existente, cuidado. Sobrescribir archivos en producción sin limpiar o sin copia previa puede dejar residuos de versiones anteriores. A veces conviene mover la carpeta antigua y desplegar en una nueva:

mv public_html public_html_antiguo
mkdir public_html
cd public_html
tar -xzpf /home/usuario/backups/prestashop-archivos-2026-01-15.tar.gz

Restaurar base de datos

Si el dump está comprimido:

gunzip -c /home/usuario/backups/prestashop-db-2026-01-15.sql.gz | mysql -u usuario_basedatos -p nombre_basedatos

Si no está comprimido:

mysql -u usuario_basedatos -p nombre_basedatos < /home/usuario/backups/prestashop-db-2026-01-15.sql

Actualizar dominio y ruta de la tienda

Si restauras en otro dominio, subdominio o carpeta, revisa la tabla ps_shop_url, teniendo en cuenta que el prefijo ps_ puede ser distinto.

SELECT * FROM ps_shop_url;

Campos relevantes:

• domain: dominio sin protocolo, por ejemplo www.ejemplo.com.
• domain_ssl: dominio para HTTPS.
• physical_uri: ruta física, por ejemplo / o /tienda/.

Ejemplo de actualización:

UPDATE ps_shop_url
SET domain = 'staging.ejemplo.com',
    domain_ssl = 'staging.ejemplo.com',
    physical_uri = '/'
WHERE id_shop_url = 1;

Vaciar caché después de restaurar

En PrestaShop 1.7 y 8, puedes eliminar la caché manualmente:

rm -rf var/cache/prod/*
rm -rf var/cache/dev/*

En instalaciones antiguas, la caché puede estar en cache/smarty/compile, cache/smarty/cache u otras rutas. Después accede al back office y revisa Parámetros avanzados > Rendimiento para limpiar caché desde la interfaz si está disponible.

Permisos de archivos

Los permisos dependen del hosting, usuario web y configuración del servidor. Como orientación común:

• Directorios: 755 o 775 según entorno.
• Archivos: 644 o similar.
• Archivos sensibles de configuración: permisos restrictivos siempre que el servidor lo permita.

find /home/usuario/public_html -type d -exec chmod 755 {} \;
find /home/usuario/public_html -type f -exec chmod 644 {} \;

No apliques permisos a ciegas si tu hosting usa reglas específicas, PHP-FPM con usuario dedicado, contenedores o despliegues con Git. La seguridad no consiste en memorizar números, sino en entender quién debe leer, escribir y ejecutar.

8. Automatizar backups de PrestaShop: cron, retención y copias externas 🤖

El backup manual tiene un problema filosófico: depende de que alguien se acuerde. Y la memoria humana, aunque entrañable, compite mal contra una tarea cron bien escrita. Automatizar no significa desentenderse; significa reducir el número de ocasiones en que el azar participa en la administración de tu ecommerce.

Regla 3-2-1 para ecommerce

La clásica regla 3-2-1 sigue siendo sensata:

• 3 copias de los datos importantes.
• 2 soportes o ubicaciones diferentes.
• 1 copia fuera del servidor principal, idealmente externa y cifrada.

Guardar el backup dentro de public_html es una mala idea. Guardarlo sin cifrar y con nombre evidente, peor. Hay historias de terror en las que un atacante no solo roba la tienda, sino también el archivo backup_tienda_final_ahora_si.zip. La humanidad no aprende, pero al menos nombra sus desastres con ternura.

Ejemplo de script básico de backup

Este ejemplo crea copia de archivos y base de datos, comprime, conserva unos días y guarda fuera del directorio público. Debes adaptarlo a tus rutas y credenciales. Para no escribir la contraseña dentro del script, puedes usar un archivo ~/.my.cnf protegido.

#!/bin/bash

FECHA=$(date +%F-%H%M)
ROOT="/home/usuario/public_html"
BACKUP_DIR="/home/usuario/backups"
DB_NAME="nombre_basedatos"
DB_USER="usuario_basedatos"

mkdir -p "$BACKUP_DIR"

tar --exclude="$ROOT/var/cache/*" \
    --exclude="$ROOT/var/logs/*" \
    -czpf "$BACKUP_DIR/prestashop-archivos-$FECHA.tar.gz" \
    -C "$ROOT" .

mysqldump --single-transaction \
          --quick \
          --routines \
          --triggers \
          --events \
          --default-character-set=utf8mb4 \
          -u "$DB_USER" \
          -p \
          "$DB_NAME" | gzip > "$BACKUP_DIR/prestashop-db-$FECHA.sql.gz"

sha256sum "$BACKUP_DIR/prestashop-archivos-$FECHA.tar.gz" > "$BACKUP_DIR/prestashop-archivos-$FECHA.sha256"
sha256sum "$BACKUP_DIR/prestashop-db-$FECHA.sql.gz" > "$BACKUP_DIR/prestashop-db-$FECHA.sha256"

find "$BACKUP_DIR" -type f -mtime +14 -name "prestashop-*" -delete

Usar ~/.my.cnf para evitar contraseñas en comandos

Crea un archivo en el usuario del sistema:

nano ~/.my.cnf

Contenido:

[client]
user=usuario_basedatos
password=contraseña_basedatos
host=localhost

Protege el archivo:

chmod 600 ~/.my.cnf

Entonces puedes ejecutar:

mysqldump --single-transaction --quick --routines --triggers --events nombre_basedatos | gzip > backup.sql.gz

Programar con cron

Ejemplo para ejecutar cada madrugada a las 03:30:

30 3 * * * /home/usuario/scripts/backup-prestashop.sh >> /home/usuario/backups/backup.log 2>&1

Frecuencia recomendada

Cifrado de backups

Un backup de PrestaShop puede contener datos personales: nombres, emails, direcciones, teléfonos, pedidos, identificadores fiscales según país y configuración. Bajo normativas como el RGPD, no es un souvenir técnico; es información sensible. Cifrar las copias externas es una práctica prudente.

Ejemplo con gpg:

gpg -c --cipher-algo AES256 prestashop-db-2026-01-15.sql.gz

Ejemplo con openssl:

openssl enc -aes-256-cbc -salt -pbkdf2 \
-in prestashop-archivos-2026-01-15.tar.gz \
-out prestashop-archivos-2026-01-15.tar.gz.enc

Importante: si cifras backups, guarda la clave o frase de paso en un gestor seguro. Perder la clave convierte tu copia en una piedra elegante. Muy segura, sí. También inútil.

Dónde guardar las copias externas

• Almacenamiento S3 compatible: Amazon S3, Wasabi, Backblaze B2, Cloudflare R2.
• Google Drive, OneDrive o Dropbox mediante herramientas como rclone.
• Servidor externo por SFTP o rsync.
• Sistema profesional de backup del hosting, siempre con restauraciones probadas.

No basta con que exista una copia. Debe estar fuera del servidor principal. Si un malware cifra tu hosting y tus backups viven en el mismo lugar, habrás guardado el extintor dentro del incendio.

9. Errores frecuentes al hacer copias de seguridad en PrestaShop 🚫

Copiar solo la base de datos

Sirve para parte de la recuperación, pero no conserva módulos, temas, imágenes ni archivos personalizados. Es el error más común y uno de los más caros.

Olvidar archivos ocultos

El archivo .htaccess puede contener reglas esenciales de URL amigables, redirecciones y parámetros de seguridad. Algunos clientes FTP no lo muestran por defecto.

Guardar backups en carpeta pública

Un archivo .zip accesible desde navegador puede exponer toda la tienda. Nunca almacenes copias en public_html sin protección real.

No probar la restauración

El backup que nunca se restaura es una superstición con extensión .tar.gz. Verifica, aunque sea en staging.

Ignorar la multitienda

En PrestaShop multitienda, dominios, rutas, configuraciones por tienda y datos compartidos exigen especial cuidado. Revisa ps_shop y ps_shop_url.

No coordinar con integraciones externas

ERP, marketplaces, pasarelas de pago y transportistas pueden seguir enviando datos durante el backup. En tiendas complejas, planifica la ventana de copia.

Errores más sutiles

• Exportar con codificación incorrecta: puede provocar caracteres rotos en nombres, direcciones o descripciones.
• No incluir triggers o rutinas: raro en tiendas estándar, pero posible en desarrollos personalizados.
• Descargar por FTP sin revisar transferencias fallidas: una carpeta incompleta puede parecer correcta hasta que faltan imágenes o módulos.
• Restaurar sobre una versión PHP incompatible: PrestaShop 1.6, 1.7 y 8 tienen requisitos distintos. El servidor también forma parte del ecosistema.
• No documentar cambios manuales: ajustes en php.ini, cron jobs, reglas Nginx, workers o certificados SSL pueden quedar fuera del backup.
• Conservar demasiadas copias con datos personales: la retención debe equilibrar seguridad operativa y obligaciones legales.

10. Seguridad, privacidad y cumplimiento: el backup también puede ser una fuga de datos 🔐

Un backup completo de PrestaShop suele contener datos personales. Aunque PrestaShop no debería almacenar datos completos de tarjetas si usas pasarelas externas correctamente configuradas, sí puede incluir información sensible de clientes y pedidos. Eso exige controles.

Buenas prácticas de seguridad

• Cifra las copias almacenadas fuera del servidor.
• Limita el acceso a backups solo a personal autorizado.
• Usa contraseñas fuertes y autenticación multifactor en paneles de hosting y almacenamiento externo.
• No envíes backups completos por email.
• Define una política de retención: por ejemplo, diarios 14 días, semanales 8 semanas, mensuales 6-12 meses.
• Registra quién accede a las copias y cuándo, si el entorno lo requiere.
• Elimina backups antiguos de forma segura.
• Revisa contratos y encargos de tratamiento si terceros gestionan copias con datos personales.

Hay una antítesis inevitable: el backup es protección y riesgo al mismo tiempo. Te salva de perder datos, pero también concentra esos datos en un paquete transportable. Es una bóveda; si la dejas abierta, es una invitación.

11. Backup antes de actualizar PrestaShop o módulos: ritual breve, beneficio enorme 🧪

Actualizar PrestaShop, cambiar de tema o instalar módulos puede mejorar seguridad y rendimiento. También puede romper compatibilidades con la elegancia de una copa cayendo en una cena silenciosa. Antes de tocar una tienda en producción, prepara una copia completa.

Secuencia profesional antes de cambios importantes

1. Activar modo mantenimiento o programar ventana de baja actividad.
2. Hacer backup completo de archivos.
3. Hacer backup completo de base de datos.
4. Descargar copias fuera del servidor.
5. Verificar integridad de archivos comprimidos.
6. Restaurar en staging si el cambio es relevante.
7. Aplicar actualización en staging.
8. Probar checkout, pagos, transportistas, emails, impuestos, stock, imágenes, búsqueda y SEO.
9. Solo entonces repetir en producción.

Un pequeño rodeo, sí. Pero la línea recta hacia el desastre siempre ha sido muy eficiente.

12. Una breve digresión: el backup no es glamour, pero es cultura técnica ☕

Una vez vi a un dueño de tienda celebrar el rediseño de su ecommerce con una tarta. No era una tienda enorme, pero vendía bien. Había globos, café malo de oficina y una alegría honesta, de esas que no necesitan métricas. Tres días después, un módulo de filtro por facetas dejó la tienda en blanco. Nadie había hecho backup. La tarta, recordémoslo, sí estaba fotografiada desde seis ángulos.

No cuento esto para burlarme. Bueno, quizá un poco; la ironía también tiene su función pedagógica. Lo cuento porque la cultura técnica de un negocio no se mide solo en diseños bonitos o campañas de Black Friday, sino en la capacidad de volver a ponerse en pie cuando algo falla. La resiliencia no se anuncia en un banner. Se prepara en silencio.

13. Receta rápida para usuarios con SSH ⚡

Si ya sabes lo que haces y necesitas una secuencia compacta, aquí tienes una versión resumida. Sustituye rutas, usuario y base de datos por los tuyos.

mkdir -p /home/usuario/backups

cd /home/usuario/public_html

tar --exclude='./var/cache/*' \
    --exclude='./var/logs/*' \
    -czpf /home/usuario/backups/prestashop-archivos-$(date +%F).tar.gz .

mysqldump --single-transaction \
          --quick \
          --routines \
          --triggers \
          --events \
          --default-character-set=utf8mb4 \
          -u usuario_basedatos \
          -p nombre_basedatos | gzip > /home/usuario/backups/prestashop-db-$(date +%F).sql.gz

gzip -t /home/usuario/backups/prestashop-db-$(date +%F).sql.gz
tar -tzf /home/usuario/backups/prestashop-archivos-$(date +%F).tar.gz | head

Recuerda: esta receta no sustituye una estrategia completa. Sirve para una copia puntual. Para un entorno profesional necesitas automatización, copias externas, cifrado, retención y pruebas de restauración.

Preguntas frecuentes sobre backups en PrestaShop ❓

¿Cada cuánto debo hacer una copia de seguridad de PrestaShop?

Depende del ritmo de cambios. Si recibes pedidos a diario, la base de datos debería copiarse al menos una vez al día. En tiendas con mucho volumen, cada hora o mediante soluciones de recuperación punto en el tiempo. Los archivos pueden copiarse diariamente o cada vez que cambien módulos, tema, imágenes o código.

¿Puedo hacer backup solo desde el panel de administración?

Puedes exportar la base de datos desde el back office en algunas versiones, pero eso no incluye archivos. Para una copia completa necesitas también descargar o comprimir el directorio de PrestaShop.

¿Qué pesa más: archivos o base de datos?

Normalmente los archivos pesan más por las imágenes de producto, temas, módulos y archivos descargables. La base de datos puede crecer mucho si hay miles de pedidos, logs de módulos, carritos antiguos, estadísticas o integraciones que almacenan información adicional.

¿Debo copiar la caché?

No es imprescindible para restaurar, porque PrestaShop puede regenerarla. Excluir var/cache reduce tamaño y evita arrastrar archivos temporales. Aun así, si buscas una instantánea absolutamente literal del servidor, puedes incluirla.

¿Qué hago si phpMyAdmin falla al exportar?

Usa mysqldump por SSH, solicita al hosting una exportación desde consola o utiliza herramientas específicas para bases grandes. phpMyAdmin no es ideal para dumps pesados.

¿Dónde están los datos de conexión de la base de datos?

En PrestaShop 1.7 y superiores, normalmente en app/config/parameters.php. En PrestaShop 1.6, en config/settings.inc.php.

¿Un snapshot del hosting sustituye mi backup manual?

Puede ser parte de la estrategia, pero no debería ser la única. Necesitas acceso real a la copia, posibilidad de descargarla, conocer su frecuencia y haber probado restauraciones. El backup que controla exclusivamente un tercero puede ser suficiente hasta el día en que necesitas algo más preciso.

¿Qué debo probar después de restaurar?

Back office, front office, imágenes, carrito, checkout, método de pago, transportistas, impuestos, correos, facturas, URLs amigables, búsqueda, módulos críticos, rendimiento y logs de error. Una tienda restaurada que no puede cobrar pedidos todavía no está restaurada del todo.

Lista maestra para un backup completo de PrestaShop ✅

• Modo mantenimiento activado si hay riesgo de cambios durante la copia.
• Archivos comprimidos desde el directorio raíz correcto.
• Incluidos /img, /modules, /themes, /override, /download, /upload y archivos ocultos.
• Base de datos exportada con mysqldump, phpMyAdmin o herramienta fiable del hosting.
• Codificación compatible, preferiblemente utf8mb4.
• Dump SQL comprimido y comprobado.
• Checksum generado para verificar integridad.
• Copia descargada fuera del servidor principal.
• Copia externa cifrada si contiene datos personales.
• Retención definida y eliminación de copias antiguas.
• Restauración probada en staging periódicamente.
• Documentación de PHP, MySQL/MariaDB, cron jobs, módulos críticos y configuración especial.