Copias de seguridad y qué hacer cuando algo se cae

Qué hay que salvar

Tres cosas, y solo la primera es irrecuperable:

Qué	Dónde	Si lo pierdes
La base de datos	Postgres	Lo has perdido todo: pedidos, clientes, productos
Las imágenes subidas	static/ del backend	Fichas sin fotos, y no se regeneran
Caché y colas	Redis	Nada. Se rehace solo

Con Docker son los volúmenes db, static y redis.

Copia de la base

pg_dump -Fc "$DATABASE_URL" > tienda-$(date +%F).dump

Formato comprimido (-Fc) porque permite restaurar partes sueltas.

Ponlo en un cron diario y guárdalo fuera del servidor. Una copia en la misma máquina no protege del caso que más pasa: que se pierda la máquina.

Restaurar:

pg_restore --clean --no-owner -d "$DATABASE_URL" tienda-2026-08-04.dump

Antes de cada migración

Cualquier actualización que toque la base merece una copia justo antes, aunque tengas la diaria. La diaria es de esta madrugada; la migración es de ahora.

pg_dump -Fc "$DATABASE_URL" > pre-migracion-$(date +%F-%H%M).dump
npm run preparar          # aplica lo que falte del esquema y prepara la tienda

preparar lleva un cerrojo en Postgres: dos servidores arrancando a la vez no se pisan aplicando la misma migración. Y no borra nada: si algo falla, la base se queda como estaba y la copia sigue ahí por si acaso.

Las imágenes viven fuera del código

Las fotos que se suben desde el panel van a la carpeta static/, que en el contenedor es un volumen aparte. Es a propósito: si vivieran junto al código, cada actualización se las llevaría por delante. Cuando hagas copia, copia también ese volumen — la base de datos guarda las URLs, no las imágenes.

Vigilar que sigue en pie

Un backend caído de madrugada no avisa solo. Un comprobador cada pocos minutos que mire si la tienda responde y la reinicie si no, cuesta diez líneas y evita la llamada del cliente preguntando por qué su web lleva horas dando error.

Dos cosas que ayudan si usas pm2:

• Espera creciente entre reinicios. Si la base de datos se reinicia —las actualizaciones automáticas del sistema lo hacen de madrugada—, el backend se cae y sin espera se relanza en bucle decenas de veces por incidente.
• Rotación de logs, o el fichero crece sin tope hasta llenar el disco.

Lo que casi nadie mira hasta que duele

• ¿Se restaura de verdad la copia? Una copia que nunca se ha probado no es una copia, es un fichero.
• ¿Está fuera del servidor?
• ¿Cuánto tiempo de datos aceptas perder? Eso decide si la copia es diaria o cada hora.