Respaldos
Qué respaldar, cada cuánto, dónde guardarlo y cómo comprobar que sirve.
Una copia en la misma VPS no es un respaldo
Si se pierde el servidor —disco, proveedor, borrado accidental— se pierde con él. El respaldo tiene que salir de esa máquina. Es la única regla de esta página que no admite matices.
Qué hay que respaldar
| Qué | Dónde vive | Se respalda |
|---|---|---|
| La base de datos | PostgreSQL en la VPS | Sí. Es lo irremplazable |
| Las fotografías | Cloudflare R2 | Ya está replicado por Cloudflare |
| El código | GitHub | Ya está |
| Los secretos | Panel de Dokploy | En tu gestor de contraseñas |
Lo único que sólo existe en un sitio es la base de datos. Todo lo demás tiene ya una copia en otra parte.
Los secretos también se pierden
Si la VPS desaparece, el panel de Dokploy desaparece con ella y AUTH_SECRET,
la contraseña de la base y las claves de R2 se van con él. Restaurar la base sin
esos valores sirve de poco. Guárdalos en un gestor de contraseñas el día que los
generas, no el día que hacen falta.
Copia diaria
Generar el volcado
docker exec royalclean-db pg_dump -U royalclean -Fc royalclean \
> /tmp/royalclean-$(date +%F).dumpEl formato -Fc es el comprimido de PostgreSQL: ocupa menos y permite restaurar
tablas sueltas si hiciera falta.
Cifrarlo
El volcado lleva datos de personas: nombres, teléfonos, direcciones de propiedades y códigos de acceso. No debe viajar en claro.
gpg --symmetric --cipher-algo AES256 /tmp/royalclean-$(date +%F).dumpGuarda la frase de paso en el mismo gestor de contraseñas que el resto.
Sacarlo de la VPS
Hacia R2, que ya está contratado:
aws s3 cp /tmp/royalclean-$(date +%F).dump.gpg \
s3://royal-clean-backups/ \
--endpoint-url https://TU_ACCOUNT_ID.r2.cloudflarestorage.comUsa un bucket distinto del de la evidencia, y un token de API acotado a él. Si el token de la aplicación se filtrara, no debería dar acceso a los respaldos.
Borrar la copia local
rm -f /tmp/royalclean-*.dump /tmp/royalclean-*.dump.gpgDejarla en la VPS no aporta nada y sí añade un archivo con datos personales en un disco que puede comprometerse.
Programarlo
Como un cron job de Dokploy, a una hora de poco uso:
0 2 * * *Media hora antes del mantenimiento de las 3:00, para que no compitan.
Cuánto guardar
| Antigüedad | Qué conservar |
|---|---|
| Última semana | Todas las copias diarias |
| Último mes | Una por semana |
| Último año | Una por mes |
No es una regla sagrada: es un equilibrio entre poder volver atrás y no pagar almacenamiento indefinidamente. Ajústalo si el negocio pide otra cosa.
Restaurar
Practícalo antes de necesitarlo
Un respaldo que nunca se ha restaurado es una suposición, no un respaldo. Hazlo una vez contra una base de prueba, apunta cuánto tardaste, y repítelo cada cierto tiempo.
Traer y descifrar
aws s3 cp s3://royal-clean-backups/royalclean-2026-08-31.dump.gpg . \
--endpoint-url https://TU_ACCOUNT_ID.r2.cloudflarestorage.com
gpg --decrypt royalclean-2026-08-31.dump.gpg > royalclean.dumpDetener la aplicación
Para que nadie escriba mientras restauras. Desde Dokploy, Stop en el servicio de la aplicación.
Restaurar
docker exec -i royalclean-db pg_restore -U royalclean -d royalclean --clean \
< royalclean.dump--clean borra los objetos existentes antes de recrearlos. Es destructivo: por
eso la aplicación está detenida.
Arrancar y comprobar
curl https://crm.royalcleancr.com/api/healthY entra a la aplicación: comprueba que ves los servicios, las horas y los pagos del periodo que esperabas.
Qué NO recupera un respaldo
Conviene saberlo antes de confiar de más:
- Las fotografías no están en la base, sólo su metadata. Viven en R2, que tiene su propia durabilidad.
- Las sesiones abiertas se pierden: todo el mundo tendrá que volver a entrar. No es un problema, pero conviene avisar.
- Lo ocurrido entre el último respaldo y el fallo no está. Con una copia diaria, eso puede ser hasta un día de trabajo registrado.