Knowledge Base Guide

Backup y recuperación ante desastres PrestaShop: Guía completa

Estrategia práctica de copias de seguridad para PrestaShop — mysqldump, archivos, cron automatizado, almacenamiento externo, restauraciones de prueba y recuperación.

Por qué las copias de seguridad importan más de lo que cree

Todo propietario de una tienda PrestaShop piensa “a mí no me pasará” — hasta que pasa. Las copias de seguridad son la red de protección más importante que tiene su negocio en línea. Estos son escenarios reales que ocurren con frecuencia en la comunidad PrestaShop:

  • La actualización fallida: Actualiza de PS 1.7 a 8.x. El proceso se detiene a mitad de las migraciónes de base de datos. Su catálogo está parcialmente convertido, los pedidos tienen columnas no coincidentes y el back office no carga. Sin una copia de seguridad previa a la actualización, su tienda queda en el limbo
  • La tienda hackeada: Un atacante explota un módulo desactualizado, inyecta puertas traseras y modifica su .htaccess. Lo descubre días después. Como los archivos del núcleo también están modificados, no puede determinar cuáles están limpios. Solo una copia de seguridad anterior a la brecha puede restaurar la confianza
  • El desastre del hosting: El arreglo RAID de su proveedor falla. Su copia de seguridad más reciente tiene 9 días. Su respaldo estaba en el mismo servidor. Nueve días de pedidos, clientes y cambios — perdidos
  • La eliminación accidental: Alguien borra /img/p/ pensando que es un directorio temporal. Miles de fotos de productos, borradas en segundos
La pregunta no es si necesitará una copia de seguridad — es cuándo. Cada semana que opera sin copias de seguridad probadas es una apuesta con todo su negocio.

Qué respaldar

La base de datos (lo más crítico)

Su base de datos MySQL/MariaDB contiene todo lo que hace de su tienda un negocio: pedidos, cuentas de clientes, productos, configuración, reglas de carrito, datos SEO y cuentas de empleados. Si pierde sus archivos pero conserva la base de datos, puede reconstruir. Si pierde la base de datos, ha perdido los datos de su negocio.

Archivos esenciales

  • /modules/ — módulos instalados, sus configuraciónes, plantillas y recursos subidos
  • /themes/ — su tema activo y temas hijos con todas las personalizaciónes
  • /img/ — imágenes de productos, imágenes de categorías, imágenes CMS (a menudo el directorio más grande — más de 10 GB)
  • /upload/ — archivos adjuntos y archivos de productos virtuales
  • /override/ — sobrecargas personalizadas de clases del núcleo
  • /app/config/parameters.php (PS 1.7+) o /config/settings.inc.php (PS 1.6) — credenciales de la base de datos y claves de cifrado
  • /mails/ y /translations/ — si están personalizados
  • .htaccess, configuraciónes de virtual host, sobrecargas de php.ini, definiciones de cron
  • Certificados SSL — si los gestióna usted mismo (no a través de Cloudflare o su proveedor)

Lo que NO necesita

  • /var/cache/ — se regenera automáticamente
  • /var/logs/ — útil para depuración, no para recuperación
  • /vendor/ — reinstalable mediante composer install
  • /node_modules/ — nunca respalde esto
  • /var/sessions/ — datos temporales

Métodos de copia de seguridad de la base de datos

mysqldump (recomendado)

El estándar de oro para copias de seguridad de MySQL/MariaDB:

mysqldump \
  --single-transaction \
  --quick \
  --lock-tables=false \
  --routines \
  --triggers \
  --events \
  -u YOUR_DB_USER \
  -p'YOUR_DB_PASSWORD' \
  YOUR_DB_NAME > prestashop_$(date +%Y%m%d_%H%M%S).sql

Por qué importa cada parámetro:

  • --single-transaction — instantánea consistente de InnoDB sin bloquear tablas. Su tienda sigue operativa sin tiempo de inactividad
  • --quick — recupera las filas una por una en lugar de cargar tablas completas en memoria
  • --lock-tables=false — evita el bloqueo de tablas MyISAM que algunas instalaciones antiguas de PS aún utilizan
  • --routines, --triggers, --events — incluye procedimientos almacenados, triggers y eventos programados que los módulos pueden crear
Nunca omita --single-transaction en una tienda en producción. Sin este parámetro, mysqldump bloquea las tablas durante la copia de seguridad, lo que puede detener su proceso de pago durante segundos o minutos.

Exportación con phpMyAdmin

Para hosting compartido sin SSH: seleccione su base de datos, haga clic en Export, elija el método Custom, active la compresión gzip, marque “Add DROP TABLE” y exporte. Limitación: puede agotar el tiempo de espera en bases de datos de más de 100 MB.

Copia de seguridad integrada de PrestaShop

Disponible en Advanced Parameters → DB Backup. Conveniente para una instantánea rápida antes de un cambio, pero tiene limitaciones serias: omite triggers/routines, puede agotar el tiempo en bases de datos grandes, almacena la copia en el mismo servidor, y algunas versiones de PS producen volcados incompletos. Úselo solo como complemento.

Compresión y automatización

Los volcados SQL se comprimen un 80-90%. Siempre canalice a través de gzip:

# Backup + compress in one step
mysqldump --single-transaction --quick --lock-tables=false \
  -u USER -p'PASS' prestashop | gzip > backup_$(date +%Y%m%d).sql.gz

# Restore from compressed backup
gunzip < backup_20260228.sql.gz | mysql -u USER -p'PASS' prestashop

Copia de seguridad diaria automatizada con rotación

Este script conserva 7 copias diarias, 4 semanales y 12 mensuales:

#!/bin/bash
# /home/user/scripts/backup-db.sh

DB_USER="your_db_user"
DB_PASS="your_db_password"
DB_NAME="prestashop"
BACKUP_DIR="/home/user/backups/database"
DATE=$(date +%Y%m%d_%H%M%S)
DAY_OF_WEEK=$(date +%u)
DAY_OF_MONTH=$(date +%d)

mkdir -p "$BACKUP_DIR"/{daily,weekly,monthly}

# Take the backup
mysqldump --single-transaction --quick --lock-tables=false \
  --routines --triggers \
  -u "$DB_USER" -p"$DB_PASS" "$DB_NAME" \
  | gzip > "$BACKUP_DIR/daily/prestashop_${DATE}.sql.gz"

if [ $? -ne 0 ]; then
    echo "BACKUP FAILED at $(date)" | mail -s "BACKUP FAILED" your@email.com
    exit 1
fi

# Weekly snapshot (Sunday)
[ "$DAY_OF_WEEK" -eq 7 ] && cp "$BACKUP_DIR/daily/prestashop_${DATE}.sql.gz" \
  "$BACKUP_DIR/weekly/prestashop_weekly_${DATE}.sql.gz"

# Monthly snapshot (1st of month)
[ "$DAY_OF_MONTH" -eq "01" ] && cp "$BACKUP_DIR/daily/prestashop_${DATE}.sql.gz" \
  "$BACKUP_DIR/monthly/prestashop_monthly_${DATE}.sql.gz"

# Rotation
find "$BACKUP_DIR/daily/"   -name "*.sql.gz" -mtime +7   -delete
find "$BACKUP_DIR/weekly/"  -name "*.sql.gz" -mtime +28  -delete
find "$BACKUP_DIR/monthly/" -name "*.sql.gz" -mtime +365 -delete
# Add to crontab — runs daily at 3:00 AM
0 3 * * * /home/user/scripts/backup-db.sh >> /home/user/logs/backup.log 2>&1

Métodos de copia de seguridad de archivos

Copia de seguridad completa con tar

# Full backup excluding unnecessary directories
tar -czf prestashop_files_$(date +%Y%m%d).tar.gz \
  --exclude='var/cache/*' --exclude='var/logs/*' \
  --exclude='var/sessions/*' --exclude='node_modules' \
  /var/www/html/

# Critical files only (faster, smaller)
tar -czf prestashop_critical_$(date +%Y%m%d).tar.gz \
  /var/www/html/{modules,themes,img,upload,override,mails,.htaccess} \
  /var/www/html/app/config/parameters.php

Copia de seguridad incremental con rsync

Para tiendas grandes, rsync copia solo los archivos modificados — ideal para el enorme directorio /img/:

# Local incremental sync
rsync -avz --delete \
  --exclude='var/cache/' --exclude='var/logs/' --exclude='var/sessions/' \
  /var/www/html/ /home/user/backups/files/current/

# Remote sync (off-site — much safer)
rsync -avz --delete \
  --exclude='var/cache/' --exclude='var/logs/' \
  -e "ssh -p 22" \
  /var/www/html/ backupuser@remote-server:/backups/prestashop/

Las imágenes de productos en /img/p/ rara vez cambian una vez subidas, lo que hace que rsync sea extremadamente eficiente — después de la copia completa inicial, las sincronizaciones diarias transfieren solo las imágenes recién añadidas.

Dónde almacenar las copias de seguridad

NO en el mismo servidor

Este es el error número uno en copias de seguridad. Si sus respaldos están en el mismo servidor, un fallo de disco, un ransomware o la quiebra del proveedor de hosting lo elimina todo simultáneamente. Las copias de seguridad deben existir en al menos una ubicación física separada.

Opciones de almacenamiento remoto

# Amazon S3
aws s3 sync /home/user/backups/ s3://your-bucket/prestashop/ --storage-class STANDARD_IA

# Backblaze B2 (cheaper than S3, excellent for backups)
b2 sync /home/user/backups/ b2://your-bucket/prestashop/

# Google Cloud Storage
gsutil cp backup.sql.gz gs://your-bucket/prestashop/database/

# SCP/rsync to another server
rsync -avz -e ssh /home/user/backups/ backupuser@backup-server:/backups/prestashop/

La regla 3-2-1

Mantenga 3 copias de sus datos en 2 tipos de almacenamiento diferentes con 1 copia fuera del sitio. Para PrestaShop: su tienda en producción + una copia de seguridad local en un disco separado + una copia de seguridad en la nube en una región diferente.

Cifrado de copias de seguridad (GDPR)

Las copias de seguridad de la base de datos contienen datos personales de clientes. Según el GDPR, debe proteger estos datos también en las copias de seguridad:

# Encrypt with GPG
mysqldump --single-transaction --quick --lock-tables=false \
  -u USER -p'PASS' prestashop | gzip \
  | gpg --symmetric --cipher-algo AES256 --batch --passphrase "STRONG_PASSPHRASE" \
  > backup_$(date +%Y%m%d).sql.gz.gpg

# Decrypt and restore
gpg --decrypt --batch --passphrase "STRONG_PASSPHRASE" backup.sql.gz.gpg \
  | gunzip | mysql -u USER -p'PASS' prestashop
Almacene su frase de cifrado en un gestor de contraseñas — por separado de las copias de seguridad. Si pierde la frase, las copias cifradas serán permanentemente irrecuperables.

Prueba de sus copias de seguridad

Una copia de seguridad que no ha probado no es una copia de seguridad. Fallos comunes que solo aparecen durante una restauración real: volcados SQL truncados (límite de espacio en disco), archivos de 0 bytes (contraseña de BD expirada), incompatibilidades de versión de MySQL, permisos de archivos faltantes, directorios críticos excluidos o claves de cifrado modificadas.

Cómo probar

# Create a test database and restore
mysql -u root -p -e "CREATE DATABASE prestashop_test;"
gunzip < backup.sql.gz | mysql -u root -p prestashop_test

# Verify data completeness
mysql -u root -p prestashop_test -e "
  SELECT COUNT(*) AS products FROM ps_product;
  SELECT COUNT(*) AS orders FROM ps_orders;
  SELECT COUNT(*) AS customers FROM ps_customer;
  SELECT MAX(date_add) AS latest_order FROM ps_orders;
"

Para una prueba completa: extraiga la copia de seguridad de archivos, actualice parameters.php, cargue el sitio, verifique que la página de inicio muestre las imágenes, que el Back Office funcione, que los productos se muestren correctamente y que el proceso de pago funcione. Programe esto trimestralmente.

Plan de recuperación ante desastres

Escriba estos procedimientos y guárdelos en un lugar accesible incluso cuando su servidor no esté disponible.

Escenario 1: Tienda completamente caída (fallo del servidor)

  1. Confirme el alcance — ¿su servidor, la red del proveedor o el DNS?
  2. Contacte al proveedor de hosting; obtenga un tiempo estimado y confirme el estado de los datos
  3. Si es irrecuperable: aprovisione un nuevo servidor con versiones coincidentes de SO/PHP/MySQL
  4. Restaure los archivos desde su copia de seguridad remota (no la que estaba en el servidor caído)
  5. Restaure la base de datos desde su copia de seguridad externa más reciente
  6. Actualice el DNS si la IP cambió
  7. Verifique el front office, el back office, el proceso de pago y el correo electrónico

Escenario 2: Base de datos corrupta

  1. Detenga el servidor web: systemctl stop apache2
  2. Intente reparar primero: mysqlcheck -u root -p --auto-repair prestashop
  3. Si la reparación falla, restaure desde la copia de seguridad: 
    mysql -u root -p -e "DROP DATABASE prestashop; CREATE DATABASE prestashop;"
gunzip < latest_backup.sql.gz | mysql -u root -p prestashop
  4. Reinicie el servidor web, limpie la caché de PrestaShop
  5. Evalúe la pérdida de datos — verifique los IDs de pedidos y las marcas de tiempo para identificar la brecha

Escenario 3: Hackeada — archivos modificados

  1. Ponga el sitio fuera de línea inmediatamente
  2. Preserve la evidencia: tar -czf hacked_site.tar.gz /var/www/html/
  3. Identifique el vector de ataque: 
    find /var/www/html/ -name "*.php" -mtime -7 -ls
grep -rl "eval(base64_decode" /var/www/html/
grep -rl "shell_exec" /var/www/html/modules/
  4. Restaure los archivos desde una copia de seguridad fechada antes de la brecha
  5. Verifique la base de datos en busca de cuentas de administrador no autorizadas y cambios de configuración sospechosos
  6. Cambie TODAS las credenciales: contraseña de la BD, contraseñas de administradores, FTP, claves SSH, claves API
  7. Actualice el núcleo de PrestaShop y todos los módulos
  8. Monitoree de cerca durante 2-4 semanas — los atacantes a menudo dejan múltiples puertas traseras

Escenario 4: Eliminación accidental de módulo/tema

  1. Extraiga solo el directorio eliminado de su copia de seguridad de archivos: 
    tar -xzf prestashop_files_backup.tar.gz \
  --directory /var/www/html/ var/www/html/modules/your_module_name/
  2. Si el módulo fue desinstalado desde el Back Office (tablas de la BD eliminadas), restaure también la base de datos o reinstale desde el ZIP original
  3. Limpie la caché de PrestaShop

RTO y RPO

  • RTO (Recovery Time Objective) — tiempo de inactividad máximo aceptable. Un RTO de 4 horas significa que su proceso de restauración debe completarse en menos de 4 horas. Un RTO de 15 minutos requiere infraestructura de conmutación automática
  • RPO (Recovery Point Objective) — pérdida de datos máxima aceptable. Copias de seguridad diarias = RPO de 24 horas. Las tiendas de alto volumen (cientos de pedidos al día) deben aspirar a un RPO de 1-4 horas

Calcule su coste: 100 pedidos/día a 50 EUR de media = ~200 EUR/hora en ingresos perdidos durante el tiempo de inactividad, además del daño a la confianza y al SEO.

Recuperación a un punto en el tiempo

Las copias de seguridad diarias dejan una brecha: si el problema ocurrió hace 2 horas y su última copia fue hace 20 horas, pierde 20 horas de datos. Los logs binarios de MySQL resuelven esto.

Habilitar el registro binario

# /etc/mysql/mysql.conf.d/mysqld.cnf
[mysqld]
log_bin = /var/log/mysql/mysql-bin
binlog_expire_logs_seconds = 604800
max_binlog_size = 100M
binlog_format = ROW
systemctl restart mysql
mysql -u root -p -e "SHOW VARIABLES LIKE 'log_bin';"  # Should show ON

Recuperación a un momento específico

# 1. Restore the most recent full backup (from 3:00 AM)
gunzip < daily_backup.sql.gz | mysql -u root -p prestashop

# 2. Replay binlogs up to the moment BEFORE the problem (e.g., 14:29)
mysqlbinlog \
  --start-datetime="2026-02-28 03:00:00" \
  --stop-datetime="2026-02-28 14:29:00" \
  /var/log/mysql/mysql-bin.000042 /var/log/mysql/mysql-bin.000043 \
  | mysql -u root -p prestashop

Esto le proporciona el estado exacto de la base de datos un minuto antes del incidente. Casos de uso: eliminaciones masivas accidentales, importaciones fallidas o recuperación de pedidos realizados entre la última copia de seguridad y un fallo de módulo.

Los binlogs añaden uso de disco — una tienda con mucha actividad genera cientos de MB por día. Configure binlog_expire_logs_seconds para equilibrar la capacidad de recuperación con el espacio en disco. Siete días es un valor predeterminado adecuado.

Copias de seguridad del proveedor de hosting: confíe pero verifique

La mayoría de los proveedores anuncian “copias de seguridad diarias”, pero la realidad suele ser diferente:

  • “Copias de seguridad regulares” puede significar semanales, no diarias
  • La restauración puede costar entre 50 y 200 EUR por solicitud y tardar de 24 a 48 horas
  • Normalmente no puede restaurar archivos o tablas individuales — es todo o nada
  • La retención suele limitarse a 2-3 copias
  • Muchos Términos de Servicio incluyen cláusulas de “no responsable por la pérdida de datos”

Para verificar: Pregunte a su proveedor qué se respalda, con qué frecuencia, dónde se almacenan las copias de seguridad y cuántas se conservan. Luego solicite una restauración de prueba en un directorio temporal. Revise su panel de control en busca de fechas de copia de seguridad — si la más reciente tiene 3 semanas, tiene un problema.

El hosting compartido tiene limitaciones adicionales: las copias de seguridad pueden omitir cuentas de más de 10 GB, puede no tener acceso SSH para mysqldump, y la restauración siempre sobrescribe su estado actual. Complemente con exportaciones de phpMyAdmin y descargas FTP periódicas de los directorios críticos.

Trate las copias de seguridad de su proveedor como una red de seguridad adicional, nunca como su estrategia principal. Sus datos, su responsabilidad.

Lista de verificación completa de copias de seguridad

Imprima esto y revíselo trimestralmente.

Diario (automatizado)

  • ☐ La copia de seguridad de la base de datos se ejecuta vía cron y produce un archivo de tamaño mayor que cero
  • ☐ La copia se comprime y se envía al almacenamiento remoto/externo
  • ☐ Las copias diarias antiguas se rotan (conservar 7 días)

Semanal (automatizado)

  • ☐ Se ejecuta la copia de seguridad completa o incremental de archivos
  • ☐ Se conserva la instantánea semanal de la base de datos (conservar 4 semanas)
  • ☐ Se sincroniza la copia de almacenamiento remoto

Mensual (automatizado + revisión manual)

  • ☐ Se conserva la instantánea mensual de la base de datos (conservar 12 meses)
  • ☐ Verificar que las tareas cron siguen ejecutándose (revisar los logs)
  • ☐ Verificar que el almacenamiento remoto tiene archivos recientes
  • ☐ Comprobar el espacio en disco del almacenamiento de copias de seguridad

Trimestral (manual)

  • ☐ Restauración de prueba completa en un entorno de staging
  • ☐ Verificar que los recuentos de registros coincidan con producción (productos, pedidos, clientes)
  • ☐ Confirmar que el inicio de sesión del Back Office, la visualización de productos y el proceso de pago funcionan
  • ☐ Documentar el tiempo de restauración
  • ☐ Revisar y actualizar su plan de recuperación ante desastres

Antes de cualquier cambio importante

  • ☐ Copia de seguridad manual antes de actualizaciones del núcleo de PrestaShop
  • ☐ Copia de seguridad manual antes de instalaciones/actualizaciones de módulos
  • ☐ Copia de seguridad manual antes de migraciónes de base de datos o importaciones masivas
  • ☐ Copia de seguridad manual antes de cambios en la configuración del servidor

Seguridad

  • ☐ Las copias de seguridad con datos de clientes están cifradas
  • ☐ La frase de cifrado se almacena en un gestor de contraseñas (no en el servidor)
  • ☐ El almacenamiento remoto utiliza autenticación fuerte (claves SSH o tokens API)
  • ☐ Los scripts de copia de seguridad usan ~/.my.cnf en lugar de contraseñas en línea
  • ☐ Los archivos de copia de seguridad tienen permisos chmod 600 (solo lectura del propietario)

Consejo: almacenamiento seguro de credenciales

# Create ~/.my.cnf so backup scripts don't contain plaintext passwords
cat > ~/.my.cnf << 'EOF'
[mysqldump]
user=your_db_user
password=your_db_password
[mysql]
user=your_db_user
password=your_db_password
EOF
chmod 600 ~/.my.cnf

# Now mysqldump works without -u and -p flags
mysqldump --single-transaction --quick --lock-tables=false prestashop | gzip > backup.sql.gz

Reflexiones finales

Como mínimo, toda tienda PrestaShop necesita: copias de seguridad diarias automatizadas de la base de datos con retención de 7 días, copias de seguridad semanales de archivos, al menos una copia externa, pruebas de restauración trimestrales y un plan de recuperación ante desastres por escrito. Todo lo demás — recuperación a un punto en el tiempo, copias cifradas, almacenamiento en múltiples regiones — se escala según el valor de su tienda.

El momento de configurar las copias de seguridad es hoy. Una hora de configuración ahora puede salvar todo su negocio en el futuro.

More guides available

Browse our knowledge base for more practical PrestaShop tutorials, or reach out if you need help.

Browse Knowledge Base Contact Us
Volver arriba