This page documents how to back up and restore every stateful service in the atl.chat stack, along with retention recommendations and a pre-upgrade checklist.Documentation Index
Fetch the complete documentation index at: https://docs.allthingslinux.org/llms.txt
Use this file to discover all available pages before exploring further.
Services with persistent state
All persistent data lives under thedata/ directory at the repository root, created by scripts/init.sh. Each subdirectory maps to Docker volume mounts in the compose files.
| Service | Data location | What’s stored |
|---|---|---|
| UnrealIRCd | data/irc/data/ | Runtime data, RPC socket, persistent channel DB |
| WebPanel | data/irc/webpanel-data/ | WebPanel session and configuration data |
| Atheme | data/atheme/data/ | Services database (services.db) — NickServ, ChanServ registrations |
| Prosody | data/xmpp/data/ | XMPP user accounts, rosters, MUC history |
| Prosody | data/xmpp/uploads/ | HTTP file upload storage |
| The Lounge | data/thelounge/ | User configs, chat history, installed plugins |
| TLS Certificates | data/certs/ | Private keys and certificates (shared by IRC and XMPP) |
Note: All services log to stdout, captured by Docker’s json-file logging driver. Logs are not stored indata/— usedocker compose logs <service>to view them.
Warning: The data/certs/ directory contains TLS private keys. Handle backups of this directory with the same care as any secret material.
What to back up
Critical (always back up)
- Atheme database (
data/atheme/data/services.db) — contains all user and channel registrations. Losing this means every NickServ and ChanServ registration is gone. - TLS certificates (
data/certs/) — private keys and fullchain certificates for IRC and XMPP domains. - Environment configuration (
.env) — all passwords, tokens, and domain settings.
Recommended
- Prosody data (
data/xmpp/data/) — XMPP user accounts and rosters. - The Lounge data (
data/thelounge/) — user accounts and chat history. - UnrealIRCd data (
data/irc/data/) — runtime data and persistent channel DB. - WebPanel data (
data/irc/webpanel-data/) — session data.
Optional
- XMPP uploads (
data/xmpp/uploads/) — user-uploaded files; may be large.
Backup procedures
Full stack backup (recommended)
Stop services first to ensure data consistency, then archive the entiredata/ directory:
Live backup (no downtime)
If you cannot afford downtime, back up individual directories while services are running. This is safe for most services but may produce inconsistent snapshots for Atheme if a write is in progress.Per-service backup commands
Atheme (IRC services)
The Atheme database atdata/atheme/data/services.db is the single most critical file. Atheme writes to this file periodically and on shutdown.
Prosody (XMPP)
Prosody stores data in flat files underdata/xmpp/data/. A filesystem copy is sufficient:
The Lounge
The Lounge stores user configs and chat logs indata/thelounge/:
UnrealIRCd
UnrealIRCd runtime data lives indata/irc/data/. Most state is ephemeral (connections, channels without persistent mode), but the directory may contain persistent channel DB files:
TLS certificates
Warning: Store certificate backups securely — they contain private keys.
WebPanel
Restore procedures
Full stack restore
-
Stop all services:
-
Extract the backup archive:
This restores
data/and.envto the repository root. -
Fix permissions (required after restoring from a different machine):
-
Start services:
-
Verify services are running:
Per-service restore
Atheme
-
Stop Atheme:
-
Replace the database file:
-
Fix ownership:
-
Start Atheme:
-
Verify Atheme is running:
You should see Atheme loading the database and connecting to UnrealIRCd.
Prosody
-
Stop Prosody:
-
Restore data:
-
Start Prosody:
-
Verify:
The Lounge
-
Stop The Lounge:
-
Restore data:
-
Start The Lounge:
-
Verify by opening
http://localhost:9000in your browser.
TLS certificates
-
Restore certificates:
-
Reload services that use TLS:
Automated backup script
Save this asscripts/backup.sh and run it via cron:
Retention policy
A recommended retention schedule balances storage cost with recovery flexibility:| Tier | Frequency | Retention | Purpose |
|---|---|---|---|
| Daily | Every day | Keep 7 days | Quick recovery from recent issues |
| Weekly | Every Sunday | Keep 4 weeks | Recovery from issues noticed late |
| Monthly | First of month | Keep 12 months | Long-term recovery, compliance |
Cleanup script
Add this to your cron or run manually:Tip: For production deployments, consider pushing backups to offsite storage (S3, B2, rsync to a remote host) so you are protected against host-level failures.
Test your restores
Schedule a monthly restore test on a staging environment. A backup you have never tested restoring is not a backup — it is a hope.Pre-upgrade backup checklist
Run through this checklist before upgrading any service or runningdocker compose pull:
-
Check current service status:
-
Back up the full data directory:
-
Record current image versions (so you can roll back):
-
Back up compose and config files in case templates change:
-
Verify the backup is readable:
-
Proceed with the upgrade. If something goes wrong, restore from the archive and restart:
Troubleshooting
Backup archive is empty or incomplete
Check disk space before creating backups:Restored service fails to start
Check file permissions. Thescripts/init.sh script sets correct ownership:
Atheme database corruption
If Atheme refuses to load a restoredservices.db, check the logs:
data/atheme/data/ with .bak extensions. Check if a .bak file is available as a fallback.
Verify backup integrity
Related pages
- Deployment — production deployment runbook
- Monitoring — health checks and alerting
- Troubleshooting — cross-service diagnostic commands
- Security — secret management and credential rotation
- SSL/TLS — certificate backup and renewal
- Atheme Operations — Atheme database management
- Data Model — persistent data locations and volume mounts