Sauvegarder et restaurer Gitea

gitea dump sauvegarde l’intégralité d’une instance — dépôts Git, base de données, configuration, fichiers LFS — en une seule archive ZIP. Le service peut rester actif pendant la sauvegarde. La restauration est manuelle mais déterministe.

Cette procédure a été testée sur Gitea 1.25.5 avec SQLite3 comme base de données. Les étapes sont identiques pour PostgreSQL ou MySQL, sauf pour la restauration de la base.

Ce que contient une sauvegarde

L’archive générée par gitea dump contient :

Contenu	Chemin source	Rôle
Dépôts Git	REPOSITORY ROOT	Tous les dépôts bare
Base de données	data/gitea.db	Données applicatives (users, issues, PRs…)
Fichiers LFS	data/lfs/	Objets Git LFS
Configuration	app.ini	Paramètres de l’instance
Paquets	data/packages/	Registre de paquets
Données	data/	Autres données (avatars, attachements…)

Glissez pour voir

SQLite vs PostgreSQL

Avec SQLite (base par défaut), gitea dump inclut directement le fichier .db. Avec PostgreSQL ou MySQL, Gitea génère un fichier SQL (gitea-db.sql). Dans les deux cas, la commande dump suffit — pas de pg_dump séparé nécessaire.

Préparer le répertoire de backup

# Créer le répertoire dédié aux archives
sudo mkdir -p /var/lib/gitea/backups
sudo chown git:git /var/lib/gitea/backups
sudo chmod 750 /var/lib/gitea/backups

Créer une sauvegarde

La sauvegarde s’exécute en tant qu’utilisateur git, avec la variable d’environnement GITEA_WORK_DIR pointant vers le répertoire de travail.

# Backup avec le service actif (pas d'interruption)
sudo -u git GITEA_WORK_DIR=/var/lib/gitea \
  gitea dump \
  --config /etc/gitea/app.ini \
  --work-path /var/lib/gitea \
  --file /var/lib/gitea/backups/gitea-$(date +%Y%m%d-%H%M%S).zip \
  --type zip

La commande affiche la progression et se termine par :

Finish dumping in file /var/lib/gitea/backups/gitea-20260328-194600.zip

Vérifiez le contenu de l’archive :

sudo -u git unzip -l /var/lib/gitea/backups/gitea-20260328-194600.zip | head -20

Formats d'archive

gitea dump supporte plusieurs formats via --type : zip (par défaut), tar.gz, tar.bz2, tar.xz. Le format tar.gz est plus compact pour les gros dépôts.

Automatiser avec cron

Ajoutez une tâche cron pour l’utilisateur git afin d’automatiser les sauvegardes quotidiennes.

# Éditer la crontab de l'utilisateur git
sudo crontab -u git -e

Ajoutez cette ligne pour un backup quotidien à 2h00 du matin :

# Backup Gitea quotidien à 2h00 — conservation 30 jours
0 2 * * * GITEA_WORK_DIR=/var/lib/gitea /usr/local/bin/gitea dump \
  --config /etc/gitea/app.ini \
  --work-path /var/lib/gitea \
  --file /var/lib/gitea/backups/gitea-$(date +\%Y\%m\%d).zip \
  --type zip \
  && find /var/lib/gitea/backups -name "gitea-*.zip" -mtime +30 -delete

Vérifiez que la crontab est visible :

sudo crontab -u git -l

Restaurer depuis une sauvegarde

La restauration recrée une instance identique à partir de l’archive. Elle suppose que Gitea est déjà installé (binaire + service systemd), mais non configuré (pas d’app.ini).

1. Arrêter le service

   sudo systemctl stop gitea.service

2. Vider les répertoires de données existants

   Opération destructive

   Cette étape supprime toutes les données actuelles. Ne la faites qu’après avoir confirmé que vous restaurez depuis la bonne archive.

   sudo rm -rf /var/lib/gitea/data
   sudo rm -rf /etc/gitea/app.ini

3. Extraire l’archive

   # Créer un répertoire temporaire pour l'extraction
   sudo -u git mkdir -p /tmp/gitea-restore
   sudo -u git unzip /var/lib/gitea/backups/gitea-20260328-194600.zip \
     -d /tmp/gitea-restore

4. Restaurer la configuration

   sudo cp /tmp/gitea-restore/app.ini /etc/gitea/app.ini
   sudo chown root:git /etc/gitea/app.ini
   sudo chmod 660 /etc/gitea/app.ini    # 660 pour le 1er démarrage post-restauration

5. Restaurer les dépôts Git

   sudo -u git cp -r /tmp/gitea-restore/repos/* \
     /var/lib/gitea/data/gitea-repositories/

6. Restaurer la base de données (SQLite)

   sudo -u git cp /tmp/gitea-restore/data/gitea.db \
     /var/lib/gitea/data/gitea.db

7. Restaurer les données (LFS, paquets, avatars)

   sudo -u git cp -r /tmp/gitea-restore/data/* /var/lib/gitea/data/
   sudo chown -R git:git /var/lib/gitea/data

8. Redémarrer et vérifier

   sudo systemctl start gitea.service
   sleep 5
   sudo systemctl is-active gitea.service
   # active
   
   curl -o /dev/null -s -w "%{http_code}\n" http://localhost:3000/
   # 200

9. Durcir les permissions

   sudo chmod 640 /etc/gitea/app.ini
   sudo chmod 750 /etc/gitea
   sudo systemctl restart gitea.service

10. Nettoyer les fichiers temporaires

    rm -rf /tmp/gitea-restore

Sauvegarder vers un stockage distant

Pour une stratégie robuste, transférez les archives vers un stockage distant après chaque backup.

# Exemple avec rsync vers un serveur distant
rsync -az --progress \
  /var/lib/gitea/backups/ \
  backup-user@backup.example.com:/backups/gitea/

# Exemple avec rclone vers S3 / Backblaze B2 / etc.
rclone copy /var/lib/gitea/backups/ remote:bucket/gitea-backups/

À retenir

• gitea dump sauvegarde tout (dépôts + base + config + LFS) en une seule commande
• Le service peut rester actif pendant le backup — pas d’interruption de service
• La restauration nécessite que Gitea soit déjà installé mais non initialisé
• Les tokens SECRET_KEY et INTERNAL_TOKEN sont dans l’archive — protégez-la
• Conservation recommandée : 30 jours de backups quotidiens + 4 semaines de backups hebdomadaires

Prochaines étapes

Mettre à jour Gitea Upgrade binaire avec backup préalable obligatoire.

Configuration initiale Sécuriser app.ini après une restauration.

×

📖 Voir la documentation →