Sosyabot Docs

Appearance

Backups ​

Sosyabot's data lives in MongoDB. Redis can be rebuilt; uploaded media lives on local disk or S3 depending on your storage configuration.

MongoDB ​

Daily mongodump is the baseline. Retain at least 30 days; longer if your compliance posture requires it.

bash
# Daily, runs at 03:00 server local
0 3 * * * mongodump --uri "$MONGODB_URL" --gzip --archive=/backups/sosyabot-$(date +\%Y\%m\%d).gz

Restore:

bash
mongorestore --uri "$MONGODB_URL" --gzip --archive=/backups/sosyabot-20260503.gz

Redis ​

Treat Redis as ephemeral. BullMQ jobs replay from the Mongo-backed scheduled-post records on worker restart. Snapshot only if you depend on rate-limit counters or session data surviving a crash — both are recoverable in 99% of cases.

Uploaded media ​

If your Storage is configured for local disk, the file root is backend/dist/uploads/ (or wherever your config points). Back it up with rsync or your existing file-backup tool.

If you're on S3 (or an S3-compatible store like Backblaze B2 / Cloudflare R2), enable versioning and lifecycle rules at the bucket level. Sosyabot doesn't delete files unless you delete them from the Library — and even then we recommend retaining bucket versions.

Logs ​

.logs/api.log, .logs/worker.log, .logs/landing.log, .logs/docs.log are operational rather than data-bearing. Rotate with logrotate if disk is tight; back them up only if you need them for forensics.

What not to back up ​

  • The .run/ PID directory.
  • The node_modules tree (re-create with pnpm install).
  • Build outputs (backend/dist/, docs/content/.vitepress/dist/, etc. — re-create with ./service.sh build).
  • Redis dump.rdb (see above).

Disaster recovery checklist ​

  1. Provision the new host with the same Node version (NODE_BIN-pin if needed).
  2. Restore the latest mongodump archive.
  3. Copy or re-mount the uploads directory (or repoint the bucket).
  4. Copy .env (or restore from your secret store).
  5. ./service.sh install && ./service.sh build && ./service.sh start.
  6. ./service.sh health — all four components OK.
  7. Spot-check from /app: log in, pull up a recent post, verify a media asset loads.

MongoDB & Redis

service.sh

Admin → Storage