Guías Guía

Copias de seguridad desde las que realmente se puede restaurar

Copias de seguridad PrestaShop: mysqldump, archivos, cron, almacenamiento externo, restauraciones de prueba y recuperación.

Por qué ejecutamos copias de seguridad nocturnas en cada tienda que tocamos

Llevamos publicando módulos de PrestaShop desde 2013, y hemos tenido que restaurar desde una copia de seguridad más veces de las que nos gustaría admitir. Corrupción de la base de datos tras una migración mal hecha. Un desarrollador junior que ejecutó por accidente rm -rf sobre un directorio vendor en una tienda en producción. Una instalación de módulo que dejó ps_configuration en un estado del que PrestaShop no podía pasar al cargar. Un martes memorable, a las 3 de la madrugada, en que descubrimos un mysqldump escrito a medias de la noche anterior, con la lista de tablas cortada a mitad de una fila porque el disco se había llenado. Ese es el que nos enseñó a comprobar los códigos de salida.

Pantalla Parámetros avanzados > Copia de seguridad de BD del back office de PrestaShop
Copia de seguridad de BD del back office: cree y descargue copias de la base de datos antes de cualquier cambio.

Cada tienda de desarrollo o staging que mantenemos tiene copias de seguridad nocturnas automatizadas que se envían a un almacenamiento fuera del servidor. No porque esperemos que algo falle, sino porque hemos visto fallar las cosas las veces suficientes como para conocer el coste de la alternativa.

Una copia de seguridad solo es tan buena como su última prueba de restauración con éxito. Tuvimos un cliente cuya «copia de seguridad diaria automática» del proveedor de alojamiento resultó tener tres días de antigüedad cuando la necesitamos: el cron llevaba una semana fallando en silencio. Trate las copias de seguridad no probadas como teóricas, no como reales.

Qué merece la pena respaldar de verdad

La base de datos (lo único realmente irreemplazable)

Pedidos, clientes, productos, configuración, reglas de carrito, cuentas de empleado, todo. Los archivos los podemos reinstalar desde git y desde los ZIP de los módulos. La base de datos es el negocio: si la pierde, ha perdido la tienda.

Archivos que importan

  • /modules/ (módulos instalados, configuraciones personalizadas, recursos subidos. No dé por hecho que podrá volver a descargar cada módulo) los módulos de pago vinculados a una licencia concreta pueden ser lentos de recuperar
  • /themes/: su tema activo y cualquier tema hijo. Hemos visto evaporarse semanas de trabajo de tema porque nadie respaldó themes/mypresta-rocks/
  • /img/: normalmente el directorio más grande, a menudo con más de 10 GB en una tienda madura. Fotos de productos, banners de categorías, imágenes de CMS
  • /upload/: adjuntos y archivos de productos virtuales (los que los clientes descargan tras la compra)
  • /override/: cada override personalizado que, de lo contrario, tendría que recordar y volver a escribir
  • app/config/parameters.php (PS 1.7+) o config/settings.inc.php (PS 1.6): credenciales de la BD y, más importante aún, la clave de cifrado/cookie. Pierda esto y todos los datos cifrados de la BD se convierten en basura
  • /mails/ y /translations/: solo si los ha personalizado
  • .htaccess, vhosts de nginx, overrides de php.ini, definiciones de cron

Qué omitir

  • var/cache/: se regenera solo. Respaldarlo desperdicia espacio y ralentiza las restauraciones
  • var/logs/: útil para análisis forense, inútil para la recuperación
  • vendor/: composer install lo reconstruye. (Una salvedad en nuestro caso: enviamos paquetes sincronizados a vendor/myprestarocks/, de modo que, si está en nuestro mundo, esos sí necesitan respaldarse porque no figuran en composer.json.)
  • node_modules/: nunca. Sencillamente nunca
  • var/sessions/: transitorio

Si el archivo sigue siendo enorme tras omitir esos directorios, limpie antes de hacer la copia de seguridad. Cleanup Revolution es el tipo de barrido previo a la copia que usamos para eliminar restos generados y datos operativos obsoletos que no tienen cabida en un archivo de recuperación ante desastres.

Cómo volcamos las bases de datos

mysqldump, con las opciones que importan

Esto es lo que se ejecuta en cada tienda que mantenemos:

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é cada opción es irrenunciable en una tienda en producción:

  • --single-transaction le ofrece una instantánea coherente de InnoDB sin bloqueos. Sin ella, mysqldump bloquea las tablas y su proceso de compra se cuelga durante todo el tiempo que dure el volcado. Lo hemos visto colgarse 90 segundos en un catálogo de tamaño medio: lo suficiente para que los clientes se vayan y no vuelvan jamás
  • --quick transmite las filas en flujo en lugar de cargar tablas enteras en memoria. En un ps_orders + ps_order_detail de 5 GB, esta es la diferencia entre «el volcado termina» y «mysqldump abatido por OOM»
  • --lock-tables=false importa porque algunas instalaciones antiguas de PS todavía esconden tablas MyISAM dentro de módulos: el comportamiento por defecto las bloquea
  • --routines --triggers --events: el núcleo de PrestaShop no incluye triggers, pero muchos módulos los añaden (y tenemos una regla estricta de no eliminar jamás un trigger que no hayamos escrito nosotros, porque ya nos hemos quemado). Omita estas opciones y descubrirá, en el momento de la restauración, que falta el trigger de un módulo y que la tienda se comporta de forma anómala de una manera que tarda horas en diagnosticarse

Exportación con phpMyAdmin: bien para tiendas pequeñas, penoso para las grandes

En alojamiento compartido sin SSH, esto es lo que tiene. Elija Personalizado, active gzip, marque «Añadir DROP TABLE». El límite duro: cualquier cosa por encima de 100 MB corre el riesgo de agotar el tiempo de espera, y no hay forma de reanudarla. Hemos visto exportaciones de 5 minutos cortarse a los 4:30 sin previo aviso.

La herramienta de Copia de seguridad de BD integrada en PrestaShop

En Parámetros avanzados → Copia de seguridad de BD. Cómoda para una copia rápida de «una instantánea antes de cambiar este ajuste», y nada más. Omite triggers y rutinas, puede agotar el tiempo de espera en bases de datos grandes, almacena el archivo en el mismo servidor (lo que echa por tierra casi todo el sentido de las copias de seguridad) y, en algunas versiones de PS, produce volcados que están incompletos en silencio. Úsela como complemento de una copia de seguridad de verdad, nunca como su única estrategia.

Comprima, siempre

Los volcados SQL se comprimen entre un 80 y un 90 %. Canalizarlos directamente a través de gzip ahorra disco y ancho de banda:

# Copia de seguridad + compresión en un solo paso
mysqldump --single-transaction --quick --lock-tables=false \\
  -u USER -p'PASS' prestashop | gzip > backup_$(date +%Y%m%d).sql.gz

# Restauración desde una copia comprimida
gunzip < backup_20260228.sql.gz | mysql -u USER -p'PASS' prestashop

Copia de seguridad diaria automatizada con rotación

Este es, a grandes rasgos, el script que dejamos en las tiendas que gestionamos. Siete diarias, cuatro semanales, doce 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}

# Tomar la copia de seguridad
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

# Instantánea semanal (domingo)
[ "$DAY_OF_WEEK" -eq 7 ] && cp "$BACKUP_DIR/daily/prestashop_${DATE}.sql.gz" \\
  "$BACKUP_DIR/weekly/prestashop_weekly_${DATE}.sql.gz"

# Instantánea mensual (día 1 del mes)
[ "$DAY_OF_MONTH" -eq "01" ] && cp "$BACKUP_DIR/daily/prestashop_${DATE}.sql.gz" \\
  "$BACKUP_DIR/monthly/prestashop_monthly_${DATE}.sql.gz"

# Rotación
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
# Añadir a crontab: se ejecuta a diario a las 3:00 de la madrugada
0 3 * * * /home/user/scripts/backup-db.sh >> /home/user/logs/backup.log 2>&1

La comprobación del código de salida y la alerta por correo son las partes que la mayoría de la gente omite. También son las partes que detectan los fallos silenciosos, y los fallos silenciosos son los únicos que importan, porque los ruidosos se arreglan a la mañana siguiente.

Archivos: tar para la foto completa, rsync para lo incremental

Tarball completo

# Copia de seguridad completa excluyendo directorios innecesarios
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/

# Solo los archivos críticos (más rápido, más pequeño)
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

Sincronización incremental con rsync

En cuanto su directorio img/ supera los 5 GB, hacer tarballs completos cada noche se vuelve un derroche. rsync solo copia lo que ha cambiado, que en un catálogo maduro suele ser un puñado de fotos de producto nuevas:

# Sincronización incremental local
rsync -avz --delete \\
  --exclude='var/cache/' --exclude='var/logs/' --exclude='var/sessions/' \\
  /var/www/html/ /home/user/backups/files/current/

# Sincronización remota (fuera del sitio: mucho más segura)
rsync -avz --delete \\
  --exclude='var/cache/' --exclude='var/logs/' \\
  -e "ssh -p 22" \\
  /var/www/html/ backupuser@remote-server:/backups/prestashop/

Un detalle con el que nos hemos quemado: --delete en rsync no perdona. Si un directorio falta en el origen por cualquier motivo (un montaje fallido, un error tipográfico en la ruta), --delete borrará tan tranquilo el directorio correspondiente en el destino. Ahora excluimos explícitamente los directorios generados en tiempo de ejecución como sitemaps/, backup/ y las rutas de subida específicas de cada módulo, porque un lado de origen estropeado no debería poder borrar datos que solo existen en la copia de seguridad.

El almacenamiento fuera del servidor es el único que cuenta

La primera regla

Si sus copias de seguridad viven en el mismo servidor que su tienda, no son copias de seguridad. Son una versión ligeramente más incómoda de «sin copia de seguridad». Un fallo de disco, un ransomware, un proveedor de alojamiento que quiebra, un rm -rf / descontrolado en la terminal equivocada: todo esto se lleva por delante el sistema principal y la «copia de seguridad» a la vez. Su copia de seguridad debe vivir en algún lugar capaz de sobrevivir a la pérdida del sistema principal.

Dónde guardamos las cosas

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

# Backblaze B2 (más barato que S3, excelente para copias de seguridad)
b2 sync /home/user/backups/ b2://your-bucket/prestashop/

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

# SCP/rsync a otro servidor
rsync -avz -e ssh /home/user/backups/ backupuser@backup-server:/backups/prestashop/

Usamos una combinación: los volcados nocturnos de la BD van a Backblaze B2 (barato, compatible con S3, con opciones en EE. UU./UE), los archivos de la tienda se sincronizan con rsync a nuestra caja TrueNAS, y las tiendas verdaderamente críticas también reciben una instantánea semanal compatible con S3 en una región distinta. Las instantáneas de contenedor en el host de Docker cubren el caso de «he roto el contenedor», pero viven en la misma máquina, así que no sustituyen a tener una copia fuera del sitio.

3-2-1

Tres copias, dos tipos de almacenamiento, una fuera del sitio. Para una tienda PrestaShop: el sitio en producción, una copia local en un disco aparte y una copia en la nube en una región distinta. Fácil de recordar, difícil de rebatir una vez que ha tenido que usarla.

Cifrado para todo lo que contenga datos de clientes

Los volcados de la base de datos contienen datos personales. Bajo el RGPD, es usted responsable de protegerlos también en las copias de seguridad, no solo en producción. Usamos cifrado simétrico GPG para todo lo que sale del propio sistema de archivos de la tienda:

# Cifrar con 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

# Descifrar y restaurar
gpg --decrypt --batch --passphrase "STRONG_PASSPHRASE" backup.sql.gz.gpg \\
  | gunzip | mysql -u USER -p'PASS' prestashop
Guarde la contraseña en un gestor de contraseñas. No en el servidor. No en el script de copia de seguridad. No en un comentario. Hemos visto en persona casos de «copia cifrada, contraseña perdida»: los archivos cifrados eran tan recuperables como ruido aleatorio.

Probar sus copias de seguridad (la parte que todo el mundo se salta)

Una copia de seguridad no probada es una conjetura. Los fallos que solo aparecen en el momento de la restauración: volcados SQL truncados porque el disco se quedó sin espacio a media escritura, archivos de cero bytes porque la contraseña de la BD se rotó hace tres semanas, volcados de MySQL 8 que no cargan en MySQL 5.7, permisos de archivo que faltan, directorios excluidos que no sabía que eran críticos, claves de cifrado cambiadas.

El escenario del «volcado incompleto» es el que nos quita el sueño. El script se ejecutó, el archivo existe, el archivo incluso tiene aproximadamente el tamaño correcto, y entonces, al restaurar, descubre que el volcado se cortó en la fila cuatro millones de ps_search_word porque /tmp se llenó.

Cómo lo probamos en la práctica

# Crear una base de datos de prueba y restaurar
mysql -u root -p -e "CREATE DATABASE prestashop_test;"
gunzip < backup.sql.gz | mysql -u root -p prestashop_test

# Verificar que los datos estén completos
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 el tarball de archivos en un contenedor de staging, cambie parameters.php para que apunte a la BD de prueba, abra la página de inicio, inicie sesión en el back office, abra un producto e intente añadirlo al carrito. Hacemos esto trimestralmente en cada tienda que mantenemos. La primera vez que lo haga en un cliente nuevo, espere encontrar algo: casi siempre lo hacemos.

Recuperación ante desastres: póngalo por escrito antes de necesitarlo

Ponga esto por escrito. Imprímalo. Guarde una copia en algún lugar donde pueda leerla cuando el servidor sea inaccesible. Aprendimos esto la vez que necesitábamos restaurar una tienda y descubrimos que la única copia del manual de procedimientos estaba en la propia tienda.

Escenario 1: la tienda está completamente caída

  1. Confirme el alcance. ¿Es el servidor, la red del proveedor, el DNS o Cloudflare? dig y traceroute antes de entrar en pánico
  2. Contacte con el proveedor de alojamiento. Consiga una estimación de tiempo. Confirme que todavía tienen sus datos
  3. Si la recuperación no llega: aprovisione un servidor nuevo con las mismas versiones de SO, PHP y MySQL. Los volcados de PHP 8.1 no se importarán limpiamente en MySQL 5.7
  4. Restaure los archivos desde su copia de seguridad fuera del sitio, no la que vivía en el servidor muerto
  5. Restaure la base de datos desde su volcado fuera del sitio más reciente
  6. Actualice el DNS si la IP cambió (y recuerde el TTL: bájelo de antemano durante las migraciones planificadas)
  7. Verifique el front office, el back office, el proceso de compra y el correo transaccional

Escenario 2: base de datos corrupta

  1. Detenga el servidor web: systemctl stop apache2 (o nginx, o su contenedor)
  2. Intente primero la reparación: 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, vacíe la caché de PrestaShop (var/cache/) y la OPcache
  5. Compare el último ps_orders.id_order con lo que recuerda. Esa es su ventana de pérdida de datos

Escenario 3: hackeado, archivos modificados

  1. Ponga el sitio fuera de línea. Ahora, no después de «echar un vistazo»
  2. Preserve las pruebas: tar -czf hacked_site.tar.gz /var/www/html/: querrá esto para el análisis forense y posiblemente para las fuerzas del orden
  3. Encuentre el punto de entrada: 
    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. El truco: normalmente no sabe exactamente cuándo se produjo la brecha. Cruce las marcas de tiempo modificadas con las fechas de sus copias de seguridad y elija algo más antiguo que la modificación sospechosa más temprana; una línea base de integridad de archivos de Security Revolution o de su propio script de hashes hace que esa comparación dependa menos de la suposición
  5. Revise la BD en busca de cuentas de administrador fraudulentas (SELECT * FROM ps_employee WHERE date_add > '...') y configuración alterada (filas de ps_configuration tocadas recientemente)
  6. Rote todas las credenciales: BD, contraseñas de administrador, FTP, claves SSH, claves de la API de Webservice, SMTP del correo
  7. Actualice el núcleo de PrestaShop y cada módulo a sus versiones actuales antes de volver a poner la tienda en marcha
  8. Vigile durante dos a cuatro semanas. Los atacantes dejan varias puertas traseras: hemos limpiado tiendas en las que la tercera no salió a la luz hasta un mes después

Escenario 4: alguien borró la carpeta de un módulo

  1. Extraiga solo lo que falta: 
    tar -xzf prestashop_files_backup.tar.gz \\
  --directory /var/www/html/ var/www/html/modules/your_module_name/
  2. Si el módulo se desinstaló correctamente a través del back office (tablas de la BD y configuración eliminadas), restaure también la BD o reinstale el módulo desde el ZIP original
  3. Vacíe la caché, corrija los permisos si la restauración se ejecutó con el usuario equivocado

RTO y RPO: defínalos con honestidad

  • RTO: cuánto tiempo puede permitirse estar caído. Un RTO de 4 horas significa que su proceso completo de restauración se completa en menos de 4 horas. Un RTO de 15 minutos exige un sistema en espera activa (hot standby), no copias de seguridad
  • RPO: cuántos datos puede permitirse perder. Copias de seguridad diarias = hasta 24 horas de pedidos perdidos. Una tienda que hace más de 100 pedidos al día debería apuntar a un RPO de 1 a 4 horas mediante la reproducción de binlogs

Con 100 pedidos al día y un valor medio de 50 EUR, una hora de inactividad cuesta unos 200 EUR solo en ingresos directos, sin contar el impacto en el SEO ni la avalancha de solicitudes de reembolso.

Recuperación a un punto temporal con binlogs

Las copias de seguridad diarias dejan un hueco: si su importación masiva salió mal a las 14:00 y su última copia de seguridad fue a las 3:00, ha perdido 11 horas de pedidos. Los registros binarios (binlogs) de MySQL le permiten reproducir cada transacción confirmada hasta un momento concreto.

Activar 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';"  # Debería mostrar ON

Volver a un minuto concreto

# 1. Restaurar la copia de seguridad completa más reciente (de las 3:00)
gunzip < daily_backup.sql.gz | mysql -u root -p prestashop

# 2. Reproducir los binlogs hasta el momento ANTERIOR al problema (p. ej., las 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 recupera el estado de la base de datos de un minuto antes del incidente. Los dos casos en los que realmente lo hemos usado: una importación de productos mal hecha que arrasó las descripciones de 8000 referencias, y una actualización de módulo que ejecutó una migración con una cláusula WHERE ausente.

Los binlogs cuestan disco. Una tienda con mucho tráfico genera cientos de MB al día. Siete días de retención es nuestro valor por defecto: lo suficientemente largo para cubrir la mayoría de incidentes de «lo descubrimos el lunes», lo suficientemente corto para no llenar el disco.

No confíe en las copias de seguridad de su proveedor de alojamiento

Los proveedores anuncian «copias de seguridad diarias». La realidad, según nuestra experiencia:

  • «Copias de seguridad periódicas» a menudo significa semanales, a veces semanales con una interpretación generosa de «semanal»
  • Las solicitudes de restauración pueden costar entre 50 y 200 EUR cada una y tardar de 24 a 48 horas en atenderse
  • La restauración granular (una tabla, un archivo) casi nunca es una opción: es todo o nada
  • La retención suele ser de 2 a 3 copias, así que, para cuando detecta un problema, puede que la versión limpia ya haya desaparecido
  • La mayoría de las condiciones de servicio incluyen un «no nos hacemos responsables de la pérdida de datos»: lea las suyas

Verifíquelo: pregunte al proveedor qué se respalda, con qué frecuencia, dónde y durante cuánto tiempo. Después solicite una restauración de prueba a un directorio temporal. Si no pueden o no quieren, ya tiene su respuesta. Tuvimos un cliente cuyas «copias de seguridad diarias» resultaron ser una instantánea semanal obsoleta, algo que solo descubrimos cuando pedimos una restauración a un sitio de staging y el archivo que nos devolvieron tenía 11 días.

Trate las copias de seguridad del proveedor como un extra, nunca como su estrategia principal. Sus datos, su responsabilidad.

La lista de comprobación que tenemos clavada en la pared

Diario (automatizado)

  • ☐ La copia de seguridad de la BD se ejecuta por cron y produce un archivo con tamaño distinto de cero y código de salida 0
  • ☐ La copia está comprimida y copiada fuera del servidor
  • ☐ La rotación diaria conserva 7 días

Semanal (automatizado)

  • ☐ Se ejecuta la copia de seguridad de archivos (completa o con rsync)
  • ☐ Se conserva la instantánea semanal de la BD (guardar 4)
  • ☐ Sincronización fuera del sitio verificada

Mensual (automatizado + una comprobación manual de 10 minutos)

  • ☐ Se conserva la instantánea mensual de la BD (guardar 12)
  • ☐ Revise los registros de cron: ¿las copias de seguridad siguen ejecutándose?
  • ☐ ¿El almacenamiento fuera del sitio tiene archivos recientes?
  • ☐ ¿Hay espacio en disco en el destino de las copias de seguridad?

Trimestral (manual, en el calendario)

  • ☐ Restauración de prueba completa a un entorno de staging
  • ☐ Los recuentos coinciden: productos, pedidos, clientes
  • ☐ El inicio de sesión en el back office funciona, los productos se muestran, el proceso de compra funciona
  • ☐ Anote cuánto tardó la restauración: ese es su RTO real
  • ☐ Revise y actualice el documento de recuperación ante desastres

Antes de cualquier cambio importante

  • ☐ Copia de seguridad manual antes de actualizar el núcleo de PrestaShop
  • ☐ Copia de seguridad manual antes de instalar o actualizar módulos
  • ☐ Copia de seguridad manual antes de importaciones masivas o migraciones
  • ☐ Copia de seguridad manual antes de cambios en la configuración del servidor

Seguridad

  • ☐ Las copias de seguridad que contienen datos de clientes están cifradas
  • ☐ La contraseña está en un gestor de contraseñas, no en el servidor
  • ☐ El almacenamiento fuera del sitio usa claves SSH o tokens de API con alcance limitado
  • ☐ Los scripts de copia de seguridad leen las credenciales de ~/.my.cnf, no en línea
  • ☐ Los archivos de copia de seguridad tienen chmod 600

Consejo: credenciales fuera de los scripts

# Crear ~/.my.cnf para que los scripts de copia no contengan contraseñas en texto plano
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

# Ahora mysqldump funciona sin las opciones -u ni -p
mysqldump --single-transaction --quick --lock-tables=false prestashop | gzip > backup.sql.gz

El mínimo que aceptaríamos en una tienda que gestionemos

Volcados diarios automatizados de la BD con retención de 7 días. Copias de seguridad de archivos semanales. Al menos una copia fuera del sitio. Una restauración de prueba trimestral que alguien haga de verdad. Un plan de recuperación ante desastres por escrito que viva en algún lugar que no sea el servidor en producción. Cualquier cosa más allá de eso (reproducción de binlogs, copias cifradas fuera del sitio, multirregión) escala con el valor de la tienda.

El momento de montar esto es ahora, en una tranquila tarde de martes. No a las 3 de la madrugada después de que una migración salga mal.

Lecturas relacionadas

Preguntas relacionadas

Volver arriba