Automatización de backups en PrestaShop: Estrategias de recuperación | SysAdmin

Imagina que tu tienda PrestaShop genera 200 pedidos al día, tienes 15.000 productos con imágenes en alta resolución y una base de datos que crece sin parar. Un fallo en el servidor, un error humano al actualizar un módulo o un ataque de ransomware pueden borrar todo tu negocio en segundos. Sin un plan sólido de backup PrestaShop y recuperación desastres PrestaShop, estás jugando a la ruleta rusa con tu facturación.

En este artículo no solo vamos a hablar de la teoría. Vamos a construir, paso a paso, un sistema de automatizar backup PrestaShop que te permita dormir tranquilo. Verás scripts reales, estrategias de almacenamiento remoto y cómo orquestar una recuperación total en menos de 30 minutos.

¿Por qué el backup manual es una trampa mortal?

Hacer clic en "Exportar" desde el panel de administración de PrestaShop cada semana no es un plan de recuperación. Es una ilusión de seguridad. Los problemas principales del backup manual son:

Falta de consistencia: Olvidas hacerlo, o lo haces cuando ya es tarde.
Ventanas de error enormes: Si haces un backup semanal, puedes perder hasta 7 días de pedidos, clientes y configuraciones.
Sin verificación: El archivo ZIP puede estar corrupto y no te enteras hasta que intentas restaurarlo en medio de una crisis.
Sin almacenamiento externo: Si el backup está en el mismo servidor que la tienda, un hackeo o un fallo de disco lo borra todo junto.

[WARNING] Un backup que no se ha restaurado y verificado al menos una vez no es un backup. Es un talón de Pharmaton.

La solución es la automatización. Un cron job que ejecute un script cada noche, que comprima, cifre (opcional) y envíe tu backup PrestaShop a un destino remoto (S3, Dropbox, otro servidor FTP, etc.).

Componentes críticos de un backup PrestaShop

Antes de escribir código, debes entender qué necesitas respaldar exactamente. Una tienda PrestaShop no es solo un montón de archivos PHP.

1. Base de datos (MySQL/MariaDB)

Aquí viven los pedidos, clientes, productos, configuraciones del módulo, direcciones, etc. Es la parte más dinámica y valiosa. Una pérdida de la BD significa empezar de cero.

2. Archivos del núcleo (Core + Módulos + Temas)

Carpetas como /modules, /themes, /override, /classes, /controllers y el propio /admin. Si has personalizado algo, aquí está tu trabajo.

3. Archivos multimedia (img/)

La carpeta /img contiene las imágenes de productos, categorías, logotipos, etc. Ocupa mucho espacio, pero es fácil de regenerar parcialmente. Sin embargo, perder las imágenes originales es un dolor de cabeza enorme.

4. Archivos de configuración (config/, .htaccess, settings.inc.php)

app/config/parameters.php (o config/settings.inc.php en versiones antiguas) contiene las credenciales de la base de datos, la clave secreta, etc. El .htaccess tiene las reglas de URL amigables. Sin estos archivos, tu tienda no arranca.

Automatizar backup PrestaShop: El script definitivo

Vamos a crear un script en Bash que haga todo el trabajo sucio. Lo llamaremos prestashop_backup.sh.

Requisitos previos

Acceso SSH al servidor (usuario con permisos sudo o root).
Cliente mysqldump instalado.
Cliente aws s3 o lftp para subir a remoto (usaremos aws s3 por ser el estándar cloud).
Directorio temporal con suficiente espacio en disco (por ejemplo, /tmp/backups).

El script paso a paso

#!/bin/bash

# ============================================
# CONFIGURACIÓN - Cámbiala según tu entorno
# ============================================
PRESTASHOP_DIR="/var/www/html"
BACKUP_DIR="/tmp/prestashop_backups"
S3_BUCKET="s3://mi-bucket-backups/prestashop/"
DB_NAME="nombre_bd_prestashop"
DB_USER="usuario_bd"
DB_PASS="contraseña_segura"
DATE=$(date +"%Y-%m-%d_%H-%M-%S")
BACKUP_FILE="${BACKUP_DIR}/prestashop_full_${DATE}.tar.gz"
DB_BACKUP_FILE="${BACKUP_DIR}/prestashop_db_${DATE}.sql"

# ============================================
# 1. Crear directorio temporal
# ============================================
mkdir -p $BACKUP_DIR

# ============================================
# 2. Backup de la base de datos
# ============================================
echo "[INFO] Realizando dump de la base de datos..."
mysqldump -u $DB_USER -p$DB_PASS --single-transaction --quick --lock-tables=false $DB_NAME > $DB_BACKUP_FILE

if [ $? -ne 0 ]; then
    echo "[ERROR] Falló el dump de la BD. Abortando."
    exit 1
fi

# ============================================
# 3. Comprimir todo (archivos + BD) en un solo tarball
# ============================================
echo "[INFO] Comprimiendo archivos y base de datos..."
tar -czf $BACKUP_FILE -C $PRESTASHOP_DIR . -C $BACKUP_DIR prestashop_db_${DATE}.sql

if [ $? -ne 0 ]; then
    echo "[ERROR] Falló la compresión. Abortando."
    exit 1
fi

# ============================================
# 4. Subir a S3 (o a cualquier almacenamiento remoto)
# ============================================
echo "[INFO] Subiendo backup a S3..."
aws s3 cp $BACKUP_FILE $S3_BUCKET --storage-class STANDARD_IA

if [ $? -ne 0 ]; then
    echo "[ERROR] Falló la subida a S3. El backup local se conserva."
    # Enviar alerta por email o Slack
else
    echo "[INFO] Backup subido correctamente a $S3_BUCKET"
    # Limpiar archivos locales para no llenar el disco
    rm -f $BACKUP_FILE $DB_BACKUP_FILE
fi

# ============================================
# 5. Limpieza de backups antiguos en local (opcional)
# ============================================
find $BACKUP_DIR -type f -name "*.tar.gz" -mtime +7 -delete
echo "[INFO] Proceso de backup completado."

Explicación de las decisiones técnicas

--single-transaction: Hace el dump sin bloquear las tablas de InnoDB. Tu tienda sigue funcionando mientras se hace el backup.
--lock-tables=false: Evita el bloqueo de tablas MyISAM.
Tarball único: Comprimimos archivos y BD juntos para tener un solo archivo que represente un punto de restauración exacto.
Subida a S3 con STANDARD_IA: Es más barato que el estándar, ideal para backups que no accedes a menudo.
Limpieza local: Borramos los backups locales de más de 7 días para no saturar el disco del servidor.

Programar el cron job

Para ejecutar este script cada noche a las 3:00 AM (hora de poco tráfico), añade esta línea al crontab del usuario root:

0 3 * * * /root/scripts/prestashop_backup.sh >> /var/log/backup_prestashop.log 2>&1

[TIP] Siempre redirige la salida a un log. Si algo falla, podrás revisar el log y actuar rápido.

Estrategia de recuperación de desastres PrestaShop

Tener el backup es solo la mitad del camino. La otra mitad es saber restaurarlo rápido y sin errores. Aquí tienes el plan de recuperación desastres PrestaShop en 4 fases.

Fase 1: Preparación del entorno limpio

Necesitas un servidor (puede ser un staging o un nuevo VPS) con la misma versión de PHP, MySQL y Apache/Nginx que tu producción. No instales PrestaShop desde cero; solo prepara la infraestructura.

Fase 2: Restauración de archivos

Descarga el backup desde S3:

aws s3 cp s3://mi-bucket-backups/prestashop/prestashop_full_2025-03-15_03-00-00.tar.gz /tmp/

Descomprime en el directorio web:

tar -xzf /tmp/prestashop_full_*.tar.gz -C /var/www/html/

Ajusta permisos (PrestaShop es muy sensible a permisos):

chown -R www-data:www-data /var/www/html/
find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;
chmod 777 /var/www/html/var/cache/ /var/www/html/var/logs/ /var/www/html/img/

Fase 3: Restauración de la base de datos

Extrae el SQL del tarball (si no lo hiciste antes):

tar -xzf /tmp/prestashop_full_*.tar.gz prestashop_db_*.sql -C /tmp/

Importa la base de datos:

mysql -u root -p nueva_bd_prestashop < /tmp/prestashop_db_*.sql

Verifica que el usuario de la BD en app/config/parameters.php tenga los mismos permisos. Si cambiaste la contraseña, edita el archivo manualmente.

Fase 4: Verificación y post-restauración

Test de funcionalidad básica: Accede al front-office, busca un producto, añádelo al carrito y simula un pedido.
Test de administración: Entra al back-office, comprueba que los módulos están activos y que no hay errores de CSS/JS.
Limpieza de caché: Borra la caché de Smarty y la de Symfony desde el back-office o manualmente:
```
rm -rf /var/www/html/var/cache/prod/* /var/www/html/var/cache/dev/*
```

[INFO] Si usas un CDN como CloudFlare, purga la caché después de la restauración para que los clientes vean la versión correcta.

Automatizar la recuperación: Script de restauración

Para ir un paso más allá, puedes crear un script que automatice toda la restauración en un servidor limpio. Aquí tienes un esqueleto:

#!/bin/bash

# Script de restauración automática
# Ejecutar SOLO en un servidor vacío o de staging

S3_BUCKET="s3://mi-bucket-backups/prestashop/"
PRESTASHOP_DIR="/var/www/html"
DB_NAME="prestashop_restored"
DB_USER="root"
DB_PASS="root_password"

# 1. Descargar el backup más reciente
LATEST=$(aws s3 ls $S3_BUCKET --recursive | sort | tail -n 1 | awk '{print $4}')
aws s3 cp "s3://mi-bucket-backups/$LATEST" /tmp/latest_backup.tar.gz

# 2. Restaurar archivos
tar -xzf /tmp/latest_backup.tar.gz -C $PRESTASHOP_DIR

# 3. Crear BD e importar
mysql -u $DB_USER -p$DB_PASS -e "CREATE DATABASE IF NOT EXISTS $DB_NAME"
tar -xzf /tmp/latest_backup.tar.gz prestashop_db_*.sql -C /tmp/
mysql -u $DB_USER -p$DB_PASS $DB_NAME < /tmp/prestashop_db_*.sql

# 4. Ajustar parámetros de conexión a BD (si cambió)
sed -i "s/database_host:.*/database_host: 'localhost'/" $PRESTASHOP_DIR/app/config/parameters.php
sed -i "s/database_name:.*/database_name: '$DB_NAME'/" $PRESTASHOP_DIR/app/config/parameters.php

# 5. Permisos y caché
chown -R www-data:www-data $PRESTASHOP_DIR
rm -rf $PRESTASHOP_DIR/var/cache/*

echo "[INFO] Restauración completada. Revisa la tienda en tu navegador."

Buenas prácticas y alertas finales

Política de retención de backups

No guardes todos los backups para siempre. Define una política:

Diarios: 7 días.
Semanales: 4 semanas.
Mensuales: 12 meses.

Esto lo puedes gestionar con reglas de ciclo de vida en S3 o con un script que borre los antiguos.

Probar la recuperación periódicamente

[WARNING] Una vez al mes, al menos, haz una restauración completa en un entorno de staging. No esperes a tener un desastre real para descubrir que tu backup de base de datos está corrupto.

Monitoreo y alertas

Tu script de backup debería notificarte si falla. Puedes usar:

Email: con mail o sendmail.
Slack: usando webhooks.
Telegram: con una simple llamada a su API.

Seguridad del backup

Cifrado: Si almacenas en la nube, considera cifrar el tarball con gpg o openssl antes de subirlo.
Acceso restringido: Las credenciales de la BD en el script no deben estar en texto plano. Usa variables de entorno o un archivo de configuración con permisos 600.

Conclusión

La automatización de backups y recuperación de desastres en PrestaShop no es un lujo, es una necesidad operativa para cualquier tienda que genere ingresos. Con un script de 30 líneas, un cron job y un bucket S3, puedes pasar de tener una vulnerabilidad crítica a tener un sistema robusto que te permita restaurar tu negocio en minutos.

No dejes para mañana lo que puedas automatizar hoy. Implementa este sistema, pruébalo y duerme tranquilo sabiendo que tu PrestaShop copia seguridad está a salvo, incluso si el servidor se prende fuego.