Backups & Restore des services individuels
Cette page est dédier à la sauvegarde et restoration des services sur le serveur.
Services
As of 25/08/08 → 20 GiB approximatly. It should not grow very fast, since it is mostly configuration files and a text wiki.
Large Media is backed up seperatly when necessary:
- jellyfin
- navidrome
Stop containers before making backups.
This is safer for data.
Otterwiki ✅
OtterWiki being a flatfile wiki, we can back it up by simply copying the
/mnt/data/otterwiki folder and restoring it.
Forgejo ✅
Backup
Based on the documentation and this analysis of gitea backups, we can run
docker compose exec -u git forgejo forgejo dump --file /tmp/forgejo-dump.zip
Then copy out the file and rename it at the same time:
docker compose cp forgejo:/tmp/forgejo-dump.zip /mnt/data/backups/forgejo/forgejo-backup-$(date +%Y%m%d-%H%M%S).zip
Pour finir, on supprime l'archive du dossier /tmp dans le container:
docker compose exec forgejo rm /tmp/forgejo-dump.zip
Restore
Move all relevant files to their location in the mounted volumes:
docker compose up # Arreter un peu après. C'est pour générer la structure de dossiers. unzip forgejo-dump-1610949662.zip cd forgejo-dump-1610949662 mv app.ini $FORGEJO_DATA_DIR/gitea/conf/app.ini mv data/* $FORGEJO_DATA_DIR/gitea/data/ mv log/* $FORGEJO_DATA_DIR/gitea/log/ mv repos/* $FORGEJO_DATA_DIR/git/repositories/ chown -R docker:docker $FORGEJO_DATA_DIR/ # Je garde les commandes ci-dessous comme archives. La db se trouve déjà dans data/. # De fait, on peut s'arrêter là, et on a pas besoin du dump, car sqlite3 est en format single file. # sqlite3 # sqlite3 $DATABASE_PATH <gitea-db.sql # Commandes pour d'autres types de DB: # mysql # mysql --default-character-set=utf8mb4 -u$USER -p$PASS $DATABASE <gitea-db.sql # postgres # psql -U $USER -d $DATABASE < gitea-db.sql
Jellyfin
Backup and Restore → jellyfin.org
Stop the container completly, then copy the config folder (maybe nothing else ?)
→ /mnt/data/jellyfin/config
Kavita
Backups → wiki.kavitareader.com
Backups are already generated, in /mnt/data/kavita/config/backups.
Navidrome
Automated Backup → navidrome.org
Backup
Backup can be automated via config file or env variables. Location is
/mnt/data/navidrome/backup.
Alternatively, we can also directly start a backup from inside the container:
sudo docker compose run <service_name> backup create # service_name is usually `navidrome`
We can also prune old backups with:
sudo docker compose run <service_name> backup prune # service_name is usually `navidrome`
Restore
When you restore a backup, the existing data in the database is wiped and the data in the backup gets copied into the database.
Note: YOU MUST BE SURE TO RUN THIS COMMAND WHILE THE NAVIDROME APP IS NOT RUNNING/LIVE.
Restore a backup by running the navidrome backup restore command. :::warning Attention Restoring a backup should ONLY be done when the service is NOT running. You’ve been warned. :::
Miniflux ✅
Backups
postgresql dump restore → postgresql.org
Miniflux stores all it's data in a PostgreSQL db.
We can dump it with:
docker compose exec -T db pg_dump -U miniflux miniflux > miniflux_backup.sql
Restore
Start the db service:
docker compose up -d db
Then run the dump restoration command:
cat ./miniflux_backup.sql | podman-compose exec -T db psql -U miniflux miniflux
Then start the miniflux service:
docker compose up -d miniflux
Readeck ⚠️
# docker exec -i readeck sh -c 'readeck export "/readeck/readeck_backup_$(date +%Y%m%dT%H%M%S).zip"' docker compose exec app readeck export -config config.toml export.zip
to import, do the same and specifying the config file.
Needs to be recuring via cron job or script. Could also be built by script that does the overall backup, since backup is quick.
The export tool with docker compose exec currently does not work.
Caddy
It is sufficient to backup the /mnt/data/caddy. The most important folders
inside are:
./Caddyfile./html/
To restore, the both should be in the same folder, for the Caddyfile contains the paths to the different root folders for the websites hosted.
OpenWebUI
We do not backup the ollama models. We only handle the openwebui data.
Dir structure:
├── audit.log ├── cache/ ├── uploads/ ├── vector_db/ └── webui.db
- Cold backup approach - Stops the container before backup for data integrity
- Copies the entire
/webuifolder including:- webui.db (main database with chats, users, settings)
- uploads/ (uploaded files)
- cache/ (cached data)
- vector_db/ (RAG/Knowledge embeddings)
Medama
n.a.
Missing or broken installs
- archivebox
- bookstack
- etherpad
- synapse