Add systemd compatibility and verbose logging to Seafile MySQL backup hook

Enhance the Seafile MySQL dump hook with better debugging capabilities
and systemd service compatibility:
- Redirect all output to syslog for systemd journal integration
- Add Docker socket accessibility check before attempting dumps
- Add detailed logging at each step for troubleshooting
- Improve error handling with explicit exit codes
- Add context information (USER, PWD, HOME) for systemd debugging

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

.env.example

@@ -29,6 +29,25 @@ NTFY_URL=https://ntfy.sh/your-topic-name
 # Laisser vide si pas d'authentification
 NTFY_USER=username:password
 
+# ============================================
+# MONITORING UPTIME KUMA
+# ============================================
+
+# URL du Push Monitor Uptime Kuma
+# Obtenue depuis Uptime Kuma > Add New Monitor > Type: Push
+UPTIME_KUMA_PUSH_URL=http://uptime-kuma:3001/api/push/YOUR_KEY_HERE
+
+# ============================================
+# BASES DE DONNÉES
+# ============================================
+
+# Mot de passe MySQL pour Seafile (généralement MYSQL_ROOT_PASSWORD)
+SEAFILE_DB_PASSWORD=your-seafile-mysql-root-password
+
+# Utilisateur MySQL pour les dumps (par défaut: root)
+# Décommenter et modifier si vous utilisez un autre utilisateur
+# SEAFILE_MYSQL_USER=seafile
+
 # ============================================
 # OPTIONS AVANCÉES
 # ============================================

.gitea/workflows/deploy.yml

@@ -0,0 +1,27 @@
+name: Deploy Borgmatic Configuration
+
+on:
+  push:
+    branches:
+      - main
+
+jobs:
+  deploy:
+    runs-on: ubuntu-latest
+    name: Deploy to Production Server
+
+    steps:
+      - name: Deploy via SSH
+        uses: appleboy/ssh-action@v1.0.3
+        with:
+          host: ${{ secrets.SERVER_HOST }}
+          username: ${{ secrets.SERVER_USER }}
+          key: ${{ secrets.SSH_PRIVATE_KEY }}
+          port: ${{ secrets.SSH_PORT || 22 }}
+          script: |
+            cd /opt/borgmatic
+            echo "📥 Pulling latest changes from Git..."
+            git pull origin main
+            echo "🔧 Installing configuration..."
+            make install
+            echo "✅ Deployment completed successfully"

CHANGELOG.md

@@ -27,19 +27,9 @@ Toutes les modifications notables de ce projet seront documentées dans ce fichi
 ### Chemins sauvegardés
 
 - `/var/www` - Sites web
-- `/srv/minecraftserver` - Serveur Minecraft
-- `/srv/reddiscordbot` - Bot Discord
-- `/srv/waltercoiffure` - Application Walter Coiffure
+- `/srv/*` - Services applicatifs
 - `/etc` - Configurations système
-- `/opt/nextcloud` - Nextcloud
-- `/opt/traefik` - Reverse proxy Traefik
-- `/opt/n8n` - Automation n8n
-- `/opt/portainer` - Gestion Docker
-- `/opt/uptime-kuma` - Monitoring
-- `/opt/vaultwarden` - Gestionnaire de mots de passe
-- `/opt/mailcow-dockerized` - Serveur mail
-- `/opt/netdata` - Monitoring système
-- `/opt/gitea` - Forge Git
+- `/opt/*` - Applications tierces
 - `/home` - Répertoires utilisateurs
 
 ### Compatibilité

Makefile

@@ -1,7 +1,7 @@
 # Makefile pour Borgmatic - Agence66
 # Usage: make [commande]
 
-.PHONY: help install test backup list restore healthcheck logs status clean
+.PHONY: help install test backup list restore healthcheck logs status clean disk-usage
 
 # Couleurs pour l'affichage
 BLUE := \033[0;34m
@@ -21,7 +21,7 @@ install: ## Installe Borgmatic et configure le système
 
 test-config: ## Valide la configuration Borgmatic
 	@echo "$(BLUE)Validation de la configuration...$(NC)"
-	@borgmatic config validate
+	@sudo bash -c 'set -a && source /etc/borgmatic/.env && set +a && borgmatic config validate'
 
 test-notifications: ## Teste les notifications ntfy
 	@echo "$(BLUE)Test des notifications ntfy...$(NC)"
@@ -33,27 +33,30 @@ healthcheck: ## Vérifie la santé du système de backup
 
 dry-run: ## Simule un backup sans l'exécuter
 	@echo "$(BLUE)Simulation du backup (dry-run)...$(NC)"
-	sudo borgmatic --dry-run --verbosity 2
+	@sudo bash -c 'set -a && source /etc/borgmatic/.env && set +a && borgmatic --dry-run --verbosity 2'
 
 backup: ## Exécute un backup manuel
 	@echo "$(BLUE)Exécution du backup...$(NC)"
-	sudo borgmatic --verbosity 1 --stats
+	@sudo bash -c 'set -a && source /etc/borgmatic/.env && set +a && borgmatic --verbosity 1 --stats'
 
 backup-verbose: ## Exécute un backup manuel avec détails
 	@echo "$(BLUE)Exécution du backup (mode verbeux)...$(NC)"
-	sudo borgmatic --verbosity 2 --stats --list
+	@sudo bash -c 'set -a && source /etc/borgmatic/.env && set +a && borgmatic --verbosity 2 --stats --list'
 
 list: ## Liste toutes les archives de backup
 	@echo "$(BLUE)Archives disponibles:$(NC)"
-	@borgmatic list
+	@sudo bash -c 'set -a && source /etc/borgmatic/.env && set +a && borgmatic list'
 
 list-files: ## Liste les fichiers de la dernière archive
 	@echo "$(BLUE)Fichiers de la dernière archive:$(NC)"
-	@borgmatic list --archive latest
+	@sudo bash -c 'set -a && source /etc/borgmatic/.env && set +a && borgmatic list --archive latest'
 
 info: ## Affiche les informations sur le repository
 	@echo "$(BLUE)Informations sur le repository:$(NC)"
-	@borgmatic info
+	@sudo bash -c 'set -a && source /etc/borgmatic/.env && set +a && borgmatic info'
+
+disk-usage: ## Affiche l'espace disque utilisé et libre sur le serveur de backup
+	@sudo ./scripts/disk-usage.sh
 
 restore: ## Lance le script de restauration interactive
 	@echo "$(BLUE)Restauration interactive...$(NC)"
@@ -61,15 +64,15 @@ restore: ## Lance le script de restauration interactive
 
 check: ## Vérifie l'intégrité du repository et des archives
 	@echo "$(BLUE)Vérification de l'intégrité...$(NC)"
-	sudo borgmatic check --verbosity 1
+	@sudo bash -c 'set -a && source /etc/borgmatic/.env && set +a && borgmatic check --verbosity 1'
 
 prune: ## Nettoie les anciennes archives selon la politique de rétention
 	@echo "$(YELLOW)Nettoyage des anciennes archives...$(NC)"
-	sudo borgmatic prune --verbosity 1
+	@sudo bash -c 'set -a && source /etc/borgmatic/.env && set +a && borgmatic prune --verbosity 1'
 
 compact: ## Compacte le repository pour libérer de l'espace
 	@echo "$(YELLOW)Compactage du repository...$(NC)"
-	sudo borg compact $(BORG_REPO)
+	@sudo bash -c 'set -a && source /etc/borgmatic/.env && set +a && borg compact $${BORG_REPO}'
 
 status: ## Affiche le statut du timer systemd
 	@echo "$(BLUE)Statut du timer Borgmatic:$(NC)"
@@ -129,7 +132,3 @@ quick-setup: ## Configuration rapide (copie .env.example vers .env)
 		echo "$(YELLOW)Le fichier .env existe déjà$(NC)"; \
 	fi
 
-# Alias pratiques
-backup-now: backup ## Alias pour 'backup'
-ls: list ## Alias pour 'list'
-check-health: healthcheck ## Alias pour 'healthcheck'

QUICKSTART.md

@@ -45,13 +45,34 @@ NTFY_URL=https://ntfy.sh/votre-topic
 NTFY_USER=username:password
 ```
 
+## Configuration SSH (repository distant)
+
+Si votre repository est distant, configurez d'abord les clés SSH :
+
+```bash
+# Générer une clé SSH
+sudo ssh-keygen -t ed25519 -C "borgmatic-backup"
+# Appuyez sur Entrée 3 fois (emplacement par défaut, pas de passphrase)
+
+# Copier la clé sur le serveur
+sudo ssh-copy-id -p PORT user@backup-server.com
+
+# Tester (ne doit pas demander de mot de passe)
+sudo ssh -p PORT user@backup-server.com
+
+# Si ssh-copy-id ne fonctionne pas, méthode manuelle :
+# 1. Afficher la clé : sudo cat /root/.ssh/id_ed25519.pub
+# 2. Se connecter : ssh -p PORT user@backup-server.com
+# 3. Ajouter : echo "VOTRE_CLE" >> ~/.ssh/authorized_keys
+```
+
 ## Initialiser le repository (si nouveau)
 
 ```bash
 # Repository local
 borg init --encryption=repokey-blake2 /path/to/repo
 
-# Repository distant
+# Repository distant (SSH doit être configuré d'abord)
 borg init --encryption=repokey-blake2 ssh://user@server/path/to/repo
 
 # IMPORTANT: Sauvegarder la clé !
@@ -61,19 +82,30 @@ borg key export /path/to/repo backup-key.txt
 ## Tests
 
 ```bash
-# 1. Tester les notifications
+# 1. Valider la configuration
+sudo borgmatic config validate
+
+# 2. Tester les notifications
 ./scripts/test-notifications.sh
 
-# 2. Vérifier la santé du système
+# 3. Vérifier la santé du système
 sudo ./scripts/healthcheck.sh
 
-# 3. Test à vide (dry-run)
+# 4. Test à vide (dry-run)
 sudo borgmatic --dry-run --verbosity 2
 
-# 4. Premier backup réel
+# 5. Premier backup réel
 sudo borgmatic --verbosity 1
 ```
 
+### Explications des commandes de test
+
+- **`borgmatic config validate`** : Vérifie la syntaxe YAML et la structure de config.yaml
+- **`test-notifications.sh`** : Envoie des notifications de test via ntfy
+- **`healthcheck.sh`** : Vérifie l'installation, la config, le timer, le repository
+- **`--dry-run`** : Simule un backup complet sans rien modifier (teste la connexion au repo)
+- **Sans `--dry-run`** : Exécute un vrai backup
+
 ## Vérifier le timer
 
 ```bash
@@ -140,19 +172,35 @@ borgmatic list  # Devrait afficher vos anciennes archives
 ## En cas de problème
 
 ```bash
-# Vérifier la santé
+# 1. Valider d'abord la configuration
+sudo borgmatic config validate
+
+# 2. Vérifier la santé du système
 sudo ./scripts/healthcheck.sh
 
-# Voir les logs
+# 3. Voir les logs
 journalctl -u borgmatic.service -n 50
 
-# Tester la configuration (avec dry-run)
-borgmatic --dry-run
+# 4. Tester avec dry-run
+sudo borgmatic --dry-run --verbosity 2
 
-# Mode verbeux
-sudo borgmatic --verbosity 2
+# 5. Mode debug (très verbeux)
+sudo borgmatic --verbosity 2 --list --log-file-verbosity 2
 ```
 
+### Erreurs courantes
+
+**`repositories' is a required property`**
+- Vérifiez que `repositories:` est présent dans config.yaml
+- Vérifiez que `BORG_REPO` est défini dans .env
+
+**`Additional properties are not allowed`**
+- Vous utilisez une vieille structure de config pour Borgmatic 1.x
+- Mettez à jour vers Borgmatic 2.0+ : `sudo pipx install borgmatic --force`
+
+**`command not found: borgmatic`**
+- Créez les liens symboliques : `sudo ln -sf /root/.local/bin/borgmatic /usr/local/bin/borgmatic`
+
 ## Support
 
 Consultez le [README.md](README.md) pour plus de détails.

README.md

@@ -1,6 +1,6 @@
-# Borgmatic Backup - Agence66
+# Borgmatic Backup
 
-Configuration Borgmatic pour le backup automatique du serveur Agence66.
+Configuration Borgmatic pour le backup automatique de serveur.
 
 ## Vue d'ensemble
 
@@ -16,23 +16,14 @@ Ce dépôt contient la configuration complète pour effectuer des backups automa
 - **Notifications** via ntfy pour succès/échec
 - **Compatible** avec les backups Borg existants
 - **Sécurisé** : chiffrement, exclusions de fichiers sensibles
+- **Déploiement automatique** via Gitea Actions lors d'un push Git
 
 ## Dossiers sauvegardés
 
 - `/var/www` - Sites web
-- `/srv/minecraftserver` - Serveur Minecraft
-- `/srv/reddiscordbot` - Bot Discord
-- `/srv/waltercoiffure` - Walter Coiffure
+- `/srv/*` - Services applicatifs personnalisés
 - `/etc` - Configurations système
-- `/opt/nextcloud` - Nextcloud
-- `/opt/traefik` - Reverse proxy Traefik
-- `/opt/n8n` - Automation n8n
-- `/opt/portainer` - Gestion Docker
-- `/opt/uptime-kuma` - Monitoring
-- `/opt/vaultwarden` - Gestionnaire de mots de passe
-- `/opt/mailcow-dockerized` - Serveur mail
-- `/opt/netdata` - Monitoring système
-- `/opt/gitea` - Forge Git
+- `/opt/*` - Applications tierces (Nextcloud, Traefik, Docker, etc.)
 - `/home` - Répertoires utilisateurs
 
 ## Installation
@@ -98,6 +89,49 @@ sudo systemctl enable borgmatic.timer
 sudo systemctl start borgmatic.timer
 ```
 
+## Déploiement Automatique
+
+Ce repository inclut un workflow Gitea Actions pour déployer automatiquement les modifications sur le serveur lors d'un push Git.
+
+### Configuration du déploiement automatique
+
+1. **Générer une clé SSH de déploiement**
+   ```bash
+   ssh-keygen -t ed25519 -C "gitea-deploy-borgmatic" -f ~/.ssh/gitea-deploy-borgmatic
+   ```
+
+2. **Installer la clé publique sur le serveur**
+   ```bash
+   ssh-copy-id -i ~/.ssh/gitea-deploy-borgmatic.pub user@server
+   ```
+
+3. **Configurer les secrets dans Gitea**
+
+   Allez dans **Settings → Secrets** de votre repository et ajoutez :
+   - `SERVER_HOST` : adresse du serveur
+   - `SERVER_USER` : utilisateur SSH
+   - `SSH_PRIVATE_KEY` : contenu de `~/.ssh/gitea-deploy-borgmatic` (clé privée complète)
+   - `SSH_PORT` : port SSH (optionnel, 22 par défaut)
+
+4. **Activer Gitea Actions**
+
+   Vérifiez que Gitea Actions est activé dans votre instance Gitea (`app.ini` : `[actions] ENABLED = true`)
+
+### Utilisation
+
+Une fois configuré, chaque push sur `main` déclenche automatiquement :
+```bash
+cd /opt/borgmatic
+git pull origin main
+make install
+```
+
+Consultez l'onglet **Actions** dans votre repository Gitea pour voir le statut du déploiement.
+
+### Documentation détaillée
+
+Pour plus d'informations sur la configuration du déploiement automatique, consultez [docs/GITEA-ACTIONS.md](docs/GITEA-ACTIONS.md).
+
 ## Configuration
 
 ### Variables d'environnement (.env)
@@ -128,6 +162,37 @@ Points importants à vérifier :
 2. **Chemins** : Ajustez `source_directories` si nécessaire
 3. **Exclusions** : Personnalisez `exclude_patterns` selon vos besoins
 
+### Configuration de l'authentification SSH (repository distant)
+
+Si vous utilisez un repository distant via SSH, configurez l'authentification par clé :
+
+```bash
+# 1. Générer une clé SSH pour root (si elle n'existe pas)
+sudo ssh-keygen -t ed25519 -C "borgmatic-backup"
+# Appuyez sur Entrée pour accepter l'emplacement par défaut
+# Laissez la passphrase vide pour l'automatisation
+
+# 2. Afficher la clé publique
+sudo cat /root/.ssh/id_ed25519.pub
+
+# 3. Copier la clé sur le serveur distant
+sudo ssh-copy-id -p PORT user@backup-server.com
+
+# 4. Tester la connexion (ne doit pas demander de mot de passe)
+sudo ssh -p PORT user@backup-server.com
+```
+
+**Alternative manuelle** (si ssh-copy-id ne fonctionne pas) :
+
+```bash
+# Se connecter au serveur distant
+ssh -p PORT user@backup-server.com
+
+# Ajouter la clé publique
+echo "VOTRE_CLE_PUBLIQUE" >> ~/.ssh/authorized_keys
+exit
+```
+
 ### Initialisation du repository Borg
 
 Si vous utilisez un nouveau repository :
@@ -152,13 +217,18 @@ borg key export /path/to/repo backup-key.txt
 ### Tester la configuration
 
 ```bash
-# Valider la configuration (avec dry-run)
-borgmatic --dry-run --verbosity 2
+# 1. Valider la syntaxe du fichier de configuration
+sudo borgmatic config validate
 
-# Lister les fichiers qui seront sauvegardés
-borgmatic list --json
+# 2. Tester sans exécuter de backup (dry-run)
+sudo borgmatic --dry-run --verbosity 2
+
+# 3. Lister les fichiers qui seront sauvegardés
+sudo borgmatic list --json
 ```
 
+**Note :** `borgmatic config validate` vérifie uniquement la syntaxe YAML et la structure du fichier. Le dry-run teste la connexion au repository et simule un backup complet.
+
 ### Exécuter un backup manuel
 
 ```bash
@@ -270,6 +340,24 @@ Testez manuellement les notifications :
 
 ## Troubleshooting
 
+### Valider la configuration
+
+Avant tout, vérifiez que votre configuration est valide :
+
+```bash
+# Valider la syntaxe
+sudo borgmatic config validate
+
+# Si erreur, vérifier les détails
+sudo borgmatic config validate --verbosity 2
+```
+
+Erreurs courantes :
+
+- `repositories' is a required property` : Manque la section repositories
+- `Additional properties are not allowed` : Propriété invalide pour cette version
+- Erreurs YAML : Vérifier l'indentation (utiliser des espaces, pas des tabs)
+
 ### Le backup ne démarre pas
 
 ```bash
@@ -287,13 +375,35 @@ journalctl -u borgmatic.service -f
 
 ```bash
 # Tester la connexion SSH (si distant)
-ssh user@backup-server
+sudo ssh -p PORT user@backup-server
+
+# Vérifier les clés SSH
+sudo ls -la /root/.ssh/
 
 # Vérifier les variables d'environnement
 sudo cat /etc/borgmatic/.env
 
 # Tester Borg directement
-sudo borg list $BORG_REPO
+sudo bash -c 'source /etc/borgmatic/.env && borg list $BORG_REPO'
+```
+
+### Demande de mot de passe SSH
+
+Si borgmatic demande le mot de passe du serveur distant :
+
+```bash
+# 1. Vérifier que la clé SSH existe
+sudo ls /root/.ssh/id_ed25519
+
+# 2. Si pas de clé, en générer une
+sudo ssh-keygen -t ed25519 -C "borgmatic-backup"
+
+# 3. Copier la clé sur le serveur
+sudo ssh-copy-id -p PORT user@backup-server.com
+
+# 4. Tester
+sudo ssh -p PORT user@backup-server.com
+# Ne doit PAS demander de mot de passe
 ```
 
 ### Problème de permissions
@@ -324,25 +434,6 @@ echo $NTFY_URL
 echo $NTFY_USER
 ```
 
-## Migration depuis l'ancien script
-
-Si vous migrez depuis l'ancien script Borg :
-
-1. **Le repository existant est compatible** - pas besoin de réinitialiser
-2. **Les archives existantes restent accessibles**
-3. **Le format de nommage est identique** : `backup-YYYYMMDD-HHMM`
-4. **La rétention est la même** : 7/4/6
-
-Pour vérifier la compatibilité :
-
-```bash
-# Lister les anciennes archives
-borg list /path/to/existing/repo
-
-# Tester avec borgmatic
-borgmatic list
-```
-
 ## Ressources
 
 - [Documentation Borgmatic](https://torsion.org/borgmatic/)
@@ -359,4 +450,4 @@ Pour tout problème :
 
 ## Licence
 
-Configuration personnalisée pour Agence66.
+Configuration personnalisée pour usage personnel/professionnel.

TODO.md

@@ -2,15 +2,14 @@
 
 ## Priorité haute
 
-- [ ] Configurer le repository Borg réel (local ou distant)
-- [ ] Renseigner les vraies valeurs dans `/etc/borgmatic/.env`
 - [ ] Tester le premier backup complet
 - [ ] Vérifier que les notifications ntfy fonctionnent
 - [ ] Documenter la passphrase et sauvegarder la clé Borg
+- [ ] Configurer les secrets Gitea Actions pour le déploiement automatique
+- [ ] Tester le déploiement automatique via Git push
 
 ## Priorité moyenne
 
-- [ ] Configurer un backup du repository Borg lui-même (offsite)
 - [ ] Mettre en place un monitoring externe (healthchecks.io ou similaire)
 - [ ] Ajouter des hooks PostgreSQL/MySQL si nécessaire
 - [ ] Configurer des alertes en cas d'échec de backup
@@ -55,7 +54,7 @@
 
 ### Documentation
 
-- [ ] Vidéo tutoriel pour la restauration
+- [ ] Utiliser les commandes make dans la documentation
 - [ ] Runbook pour les situations d'urgence
 - [ ] Documentation de l'architecture de backup
 - [ ] Guide de migration vers nouveau serveur
@@ -65,7 +64,8 @@
 - [ ] Tests automatisés de la configuration
 - [ ] Simulation d'échec et vérification des alertes
 - [ ] Test de restauration automatisé
-- [ ] CI/CD pour valider les modifications de config
+- [x] CI/CD pour déploiement automatique (Gitea Actions)
+- [ ] Ajouter validation de config dans le workflow CI/CD
 
 ## Notes
 
@@ -81,17 +81,19 @@ Certains services pourraient nécessiter des stratégies de backup spécifiques
 ### Optimisations d'exclusion
 
 Ajouter ces exclusions si nécessaire :
+
 ```yaml
-- '*/venv/*'
-- '*/env/*'
-- '*/.git/objects/*'  # Si backup de repos Git
-- '*/docker/overlay2/*'
-- '*/docker/volumes/*'  # Déjà géré par les apps
+- "*/venv/*"
+- "*/env/*"
+- "*/.git/objects/*" # Si backup de repos Git
+- "*/docker/overlay2/*"
+- "*/docker/volumes/*" # Déjà géré par les apps
 ```
 
 ### Backup offsite
 
 Considérer :
+
 - BorgBase (service cloud spécialisé Borg)
 - Serveur distant dédié
 - Stockage cloud chiffré (S3, Backblaze B2)
@@ -100,10 +102,12 @@ Considérer :
 ### Rotation et rétention
 
 Configuration actuelle :
+
 - 7 daily (1 semaine)
 - 4 weekly (1 mois)
 - 6 monthly (6 mois)
 
 Considérer :
+
 - Ajouter `keep_yearly: 2` pour archives annuelles
 - Ajuster selon l'espace disque disponible

config.yaml

@@ -1,12 +1,12 @@
-# Configuration Borgmatic 2.0 pour backup serveur Agence66
+# Configuration Borgmatic 2.0 pour backup serveur
 # Compatible avec les backups Borg existants
 #
 # IMPORTANT: Nécessite Borgmatic ≥ 2.0.0 pour l'interpolation des variables d'environnement
 
 # Repository Borg - utilise la variable d'environnement
 repositories:
-    - path: "{BORG_REPO}"
-      label: serveur
+  - path: "${BORG_REPO}"
+    label: production
 
 # Chemins sources à sauvegarder
 source_directories:
@@ -34,6 +34,12 @@ exclude_patterns:
   - "**/__pycache__"
   - "*/node_modules/*"
 
+  - "/opt/nextcloud/backups"
+  #- "/opt/nextcloud/data/appdata_*/preview/*" # Miniatures d'images
+  #- "/opt/nextcloud/updater-*" # Fichiers de mise à jour
+
+  - "/opt/gitea/backups"
+
 # Un seul système de fichiers
 one_file_system: false
 
@@ -51,8 +57,8 @@ keep_daily: 7
 keep_weekly: 4
 keep_monthly: 6
 
-# Préfixe des archives
-prefix: "backup-"
+# Sélection des archives pour rétention (remplace 'prefix')
+match_archives: "sh:backup-*"
 
 # Vérifications d'intégrité
 checks:
@@ -64,18 +70,26 @@ checks:
 # Nombre d'archives à vérifier
 check_last: 3
 
-# Commandes/hooks pour notifications
-before_actions:
+# Hooks pour notifications (syntaxe Borgmatic 2.0)
+commands:
+  - before: action
+    when: [create]
+    run:
       - echo "Backup démarré"
+      - /etc/borgmatic/hooks/seafile-docker-mysql-backup.sh
 
-after_backup:
-    - echo "Exécution hook de succès"
-    - /etc/borgmatic/hooks/ntfy-success.sh "{archive_name}" "{stats}"
-
-on_error:
-    - echo "Exécution hook d'erreur"
-    - /etc/borgmatic/hooks/ntfy-error.sh "{error}"
+  - after: action
+    when: [create]
+    run:
+      - echo "Exécution hooks de succès"
+      - /etc/borgmatic/hooks/ntfy-success.sh
+      - /etc/borgmatic/hooks/uptime-kuma-success.sh
 
+  - after: error
+    run:
+      - echo "Exécution hooks d'erreur"
+      - /etc/borgmatic/hooks/ntfy-error.sh
+      - /etc/borgmatic/hooks/uptime-kuma-error.sh
 # Commandes PostgreSQL/MySQL si nécessaire
 # postgresql_databases:
 #     - name: all

docs/GITEA-ACTIONS.md

@@ -0,0 +1,216 @@
+# Déploiement Automatique avec Gitea Actions
+
+Ce document explique comment configurer le déploiement automatique de la configuration Borgmatic via Gitea Actions.
+
+## Fonctionnement
+
+Lorsque vous poussez des modifications sur la branche `main`, Gitea Actions va automatiquement :
+1. Se connecter au serveur de production via SSH
+2. Faire un `git pull` pour récupérer les derniers changements
+3. Exécuter `make install` pour installer la nouvelle configuration
+
+## Configuration Initiale
+
+### 1. Préparer une Clé SSH de Déploiement
+
+Sur votre machine locale (pas sur le serveur), créez une paire de clés SSH dédiée au déploiement :
+
+```bash
+# Générer une clé Ed25519 pour le déploiement
+ssh-keygen -t ed25519 -C "gitea-deploy-borgmatic" -f ~/.ssh/gitea-deploy-borgmatic
+
+# Afficher la clé publique
+cat ~/.ssh/gitea-deploy-borgmatic.pub
+
+# Afficher la clé privée (à copier dans les secrets Gitea)
+cat ~/.ssh/gitea-deploy-borgmatic
+```
+
+### 2. Installer la Clé Publique sur le Serveur
+
+Connectez-vous au serveur et ajoutez la clé publique :
+
+```bash
+# Sur le serveur
+mkdir -p ~/.ssh
+chmod 700 ~/.ssh
+
+# Ajouter la clé publique aux clés autorisées
+echo "VOTRE_CLE_PUBLIQUE" >> ~/.ssh/authorized_keys
+chmod 600 ~/.ssh/authorized_keys
+```
+
+Ou utilisez `ssh-copy-id` :
+
+```bash
+# Depuis votre machine locale
+ssh-copy-id -i ~/.ssh/gitea-deploy-borgmatic.pub user@server
+```
+
+### 3. Tester la Connexion SSH
+
+Vérifiez que la connexion fonctionne sans mot de passe :
+
+```bash
+ssh -i ~/.ssh/gitea-deploy-borgmatic user@server
+```
+
+Si cela fonctionne, vous pouvez continuer.
+
+### 4. Configurer les Secrets dans Gitea
+
+Dans votre repository Gitea, allez dans **Settings → Secrets** et ajoutez les secrets suivants :
+
+| Nom du Secret | Valeur | Description |
+|---------------|--------|-------------|
+| `SERVER_HOST` | `votre-serveur.example.com` ou `IP` | Adresse du serveur |
+| `SERVER_USER` | `root` ou votre utilisateur | Nom d'utilisateur SSH |
+| `SSH_PRIVATE_KEY` | Contenu de `~/.ssh/gitea-deploy-borgmatic` | Clé privée SSH (tout le fichier) |
+| `SSH_PORT` | `22` | Port SSH (optionnel, 22 par défaut) |
+
+**Important :** Pour `SSH_PRIVATE_KEY`, copiez **TOUT** le contenu du fichier, y compris les lignes `-----BEGIN OPENSSH PRIVATE KEY-----` et `-----END OPENSSH PRIVATE KEY-----`.
+
+### 5. Activer Gitea Actions
+
+Assurez-vous que Gitea Actions est activé sur votre instance Gitea :
+
+1. Dans le fichier de configuration de Gitea (`app.ini`), vérifiez :
+   ```ini
+   [actions]
+   ENABLED = true
+   ```
+
+2. Redémarrez Gitea si nécessaire
+
+3. Vérifiez qu'un runner Gitea Actions est configuré et en cours d'exécution
+
+## Structure du Workflow
+
+Le fichier `.gitea/workflows/deploy.yml` se trouve **dans ce repository** (pas dans Gitea) :
+
+```
+agence66-borgmatic/
+├── .gitea/
+│   └── workflows/
+│       └── deploy.yml    ← Workflow de déploiement
+├── config.yaml
+├── Makefile
+└── ...
+```
+
+C'est similaire à GitHub Actions qui utilise `.github/workflows/`.
+
+## Utilisation
+
+Une fois configuré, le déploiement est **automatique** :
+
+1. Faites vos modifications localement
+2. Committez et poussez :
+   ```bash
+   git add .
+   git commit -m "Update configuration"
+   git push origin main
+   ```
+3. Gitea Actions se déclenche automatiquement
+4. Consultez l'onglet **Actions** dans votre repository Gitea pour voir le statut
+
+## Vérification du Déploiement
+
+Après chaque déploiement, vous pouvez vérifier :
+
+```bash
+# Sur le serveur
+cd /opt/borgmatic
+git log -1                    # Voir le dernier commit
+sudo borgmatic config validate # Valider la configuration
+```
+
+## Déploiement Manuel (si besoin)
+
+Si vous devez déployer manuellement sans passer par Gitea Actions :
+
+```bash
+# Sur le serveur
+cd /opt/borgmatic
+git pull origin main
+make install
+```
+
+Ou utilisez le script dédié :
+
+```bash
+sudo /opt/borgmatic/scripts/deploy.sh
+```
+
+## Sécurité
+
+### Bonnes Pratiques
+
+1. **Clé SSH dédiée** : Utilisez une clé SSH spécifique pour le déploiement (ne réutilisez pas votre clé personnelle)
+2. **Permissions minimales** : L'utilisateur de déploiement ne devrait avoir accès qu'au dossier `/opt/borgmatic`
+3. **Secrets protégés** : Les secrets Gitea sont chiffrés et ne sont jamais exposés dans les logs
+4. **Restriction de commandes** : Vous pouvez limiter les commandes SSH autorisées dans `~/.ssh/authorized_keys`
+
+### Restreindre les Commandes SSH (Optionnel)
+
+Pour plus de sécurité, vous pouvez restreindre la clé de déploiement à exécuter uniquement le script de déploiement :
+
+Éditez `~/.ssh/authorized_keys` sur le serveur :
+
+```bash
+command="/opt/borgmatic/scripts/deploy.sh",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-ed25519 AAAAC3... gitea-deploy-borgmatic
+```
+
+Puis modifiez le workflow pour simplement se connecter (le script s'exécutera automatiquement).
+
+## Dépannage
+
+### Le workflow ne se déclenche pas
+
+- Vérifiez que Gitea Actions est activé dans `app.ini`
+- Vérifiez qu'un runner est en cours d'exécution
+- Consultez les logs de Gitea
+
+### Erreur d'authentification SSH
+
+```
+Permission denied (publickey)
+```
+
+- Vérifiez que la clé publique est bien dans `~/.ssh/authorized_keys` sur le serveur
+- Vérifiez les permissions : `~/.ssh` doit être 700, `authorized_keys` doit être 600
+- Vérifiez que vous avez copié **toute** la clé privée dans le secret `SSH_PRIVATE_KEY`
+
+### Le script ne trouve pas le repository
+
+```
+cd: /opt/borgmatic: No such file or directory
+```
+
+- Assurez-vous que le repository est cloné dans `/opt/borgmatic` sur le serveur
+- Vérifiez le chemin dans le workflow `.gitea/workflows/deploy.yml`
+
+### Permission denied lors de make install
+
+- Le script nécessite `sudo` pour installer les fichiers dans `/etc/borgmatic`
+- Assurez-vous que l'utilisateur de déploiement peut exécuter `make install` avec sudo
+- Ou ajoutez `sudo` dans le workflow (nécessite configuration sudoers)
+
+## Logs et Monitoring
+
+- **Logs Gitea Actions** : Consultez l'onglet "Actions" dans votre repository Gitea
+- **Logs serveur** : `journalctl -xe` pour voir les logs système
+- **Logs Git** : `cd /opt/borgmatic && git log` pour voir l'historique
+
+## Alternative : Déploiement Manuel
+
+Si vous préférez ne pas utiliser Gitea Actions, vous pouvez :
+
+1. Désactiver le workflow en renommant `.gitea/workflows/deploy.yml` en `.gitea/workflows/deploy.yml.disabled`
+2. Déployer manuellement avec : `ssh server 'cd /opt/borgmatic && git pull && make install'`
+3. Ou utiliser un simple cron job pour vérifier les mises à jour
+
+## Références
+
+- [Documentation Gitea Actions](https://docs.gitea.io/en-us/actions/)
+- [SSH Action GitHub](https://github.com/appleboy/ssh-action)

docs/RESTORE-TESTING.md

@@ -0,0 +1,714 @@
+# Guide de test de restauration Borgmatic
+
+> **"Un backup non testé n'est pas un backup"**
+
+Ce guide décrit comment tester vos backups Borgmatic pour garantir que vos données sont restaurables en cas de sinistre.
+
+## Table des matières
+
+- [Pourquoi tester ?](#pourquoi-tester)
+- [Pré-requis](#pré-requis)
+- [Niveau 1 : Test rapide (mensuel)](#niveau-1--test-rapide-mensuel)
+- [Niveau 2 : Test de service (trimestriel)](#niveau-2--test-de-service-trimestriel)
+- [Niveau 3 : Disaster Recovery complet (semestriel)](#niveau-3--disaster-recovery-complet-semestriel)
+- [Scénarios de restauration courants](#scénarios-de-restauration-courants)
+- [Checklist de vérification](#checklist-de-vérification)
+- [Troubleshooting](#troubleshooting)
+
+---
+
+## Pourquoi tester ?
+
+### Risques sans test de restauration
+
+- ❌ Backup corrompu découvert trop tard
+- ❌ Passphrase incorrecte ou perdue
+- ❌ Clés SSH manquantes ou expirées
+- ❌ Fichiers critiques exclus par erreur
+- ❌ Permissions/ownership incorrects
+- ❌ Temps de restauration inconnu (RTO)
+- ❌ Procédure non documentée
+
+### Bénéfices des tests réguliers
+
+- ✅ Confiance totale dans vos backups
+- ✅ Procédure éprouvée et documentée
+- ✅ Temps de restauration mesuré
+- ✅ Détection précoce des problèmes
+- ✅ Équipe formée en conditions réelles
+
+---
+
+## Pré-requis
+
+### Informations nécessaires
+
+Assurez-vous d'avoir accès à :
+
+```bash
+# Variables d'environnement
+BORG_REPO=ssh://USER@IP:PORT/./backups
+BORG_PASSPHRASE=votre-passphrase-sécurisée
+
+# Clés SSH
+~/.ssh/id_rsa (ou clé configurée pour le serveur de backup)
+```
+
+### Vérifications préliminaires
+
+```bash
+# 1. Vérifier la connexion au repository
+make info
+
+# 2. Lister les archives disponibles
+make list
+
+# 3. Vérifier l'intégrité du repository
+make check
+```
+
+---
+
+## Niveau 1 : Test rapide (mensuel)
+
+**Durée estimée :** 5-10 minutes
+**Fréquence recommandée :** Tous les mois
+**Objectif :** Vérifier que la restauration fonctionne
+
+### Procédure
+
+#### 1. Créer un environnement de test
+
+```bash
+# Créer un dossier de test avec horodatage
+TEST_DIR="/tmp/restore-test-$(date +%Y%m%d-%H%M)"
+mkdir -p "$TEST_DIR"
+cd "$TEST_DIR"
+```
+
+#### 2. Restaurer quelques fichiers critiques
+
+```bash
+# Restaurer la configuration Borgmatic
+borgmatic extract \
+  --archive latest \
+  --path /etc/borgmatic/config.yaml \
+  --destination "$TEST_DIR/"
+
+# Restaurer un fichier Nextcloud
+borgmatic extract \
+  --archive latest \
+  --path /opt/nextcloud/config/config.php \
+  --destination "$TEST_DIR/"
+
+# Restaurer un fichier de configuration système
+borgmatic extract \
+  --archive latest \
+  --path /etc/nginx/nginx.conf \
+  --destination "$TEST_DIR/"
+```
+
+#### 3. Vérifier les fichiers restaurés
+
+```bash
+# Vérifier que les fichiers existent
+ls -lh "$TEST_DIR/etc/borgmatic/"
+ls -lh "$TEST_DIR/opt/nextcloud/config/"
+
+# Comparer avec l'original (si toujours accessible)
+diff /etc/borgmatic/config.yaml "$TEST_DIR/etc/borgmatic/config.yaml"
+
+# Vérifier le contenu
+cat "$TEST_DIR/etc/borgmatic/config.yaml"
+```
+
+#### 4. Nettoyer
+
+```bash
+# Supprimer le dossier de test
+rm -rf "$TEST_DIR"
+echo "✅ Test rapide terminé avec succès"
+```
+
+### Checklist de validation
+
+- [ ] Les fichiers ont été restaurés sans erreur
+- [ ] Le contenu des fichiers est correct
+- [ ] Les permissions semblent correctes
+- [ ] Aucun message d'erreur dans les logs
+
+---
+
+## Niveau 2 : Test de service (trimestriel)
+
+**Durée estimée :** 30-60 minutes
+**Fréquence recommandée :** Tous les 3 mois
+**Objectif :** Vérifier la restauration complète d'un service
+
+### Scénario : Restaurer Nextcloud complet
+
+#### 1. Préparer l'environnement
+
+```bash
+TEST_DIR="/tmp/restore-nextcloud-$(date +%Y%m%d)"
+mkdir -p "$TEST_DIR"
+```
+
+#### 2. Restaurer Nextcloud
+
+```bash
+# Restaurer tous les fichiers Nextcloud
+borgmatic extract \
+  --archive latest \
+  --path /opt/nextcloud \
+  --destination "$TEST_DIR/"
+
+# Chronométrer la restauration
+time borgmatic extract \
+  --archive latest \
+  --path /opt/nextcloud \
+  --destination "$TEST_DIR/"
+```
+
+#### 3. Vérifier la restauration
+
+```bash
+# Vérifier la taille totale
+du -sh "$TEST_DIR/opt/nextcloud/"
+
+# Comparer avec la production
+du -sh /opt/nextcloud/
+
+# Vérifier la structure
+tree -L 2 "$TEST_DIR/opt/nextcloud/"
+
+# Vérifier les fichiers de configuration
+cat "$TEST_DIR/opt/nextcloud/config/config.php"
+
+# Vérifier quelques fichiers utilisateurs
+ls -lh "$TEST_DIR/opt/nextcloud/data/"
+
+# Vérifier les permissions
+ls -la "$TEST_DIR/opt/nextcloud/"
+```
+
+#### 4. Tests approfondis
+
+```bash
+# Compter les fichiers
+find "$TEST_DIR/opt/nextcloud/" -type f | wc -l
+find /opt/nextcloud/ -type f | wc -l
+
+# Vérifier les bases de données (si incluses)
+ls -lh "$TEST_DIR/opt/nextcloud/data/"*.db
+
+# Tester l'intégrité de fichiers aléatoires
+md5sum "$TEST_DIR/opt/nextcloud/data/user1/files/photo.jpg"
+```
+
+#### 5. Documenter les résultats
+
+```bash
+# Créer un rapport
+cat > "$TEST_DIR/test-report.txt" <<EOF
+Test de restauration Nextcloud
+Date: $(date)
+Archive: latest
+Durée: [À REMPLIR]
+Taille restaurée: $(du -sh "$TEST_DIR/opt/nextcloud/" | cut -f1)
+Nombre de fichiers: $(find "$TEST_DIR/opt/nextcloud/" -type f | wc -l)
+Statut: ✅ SUCCÈS / ❌ ÉCHEC
+Notes: [VOS OBSERVATIONS]
+EOF
+
+cat "$TEST_DIR/test-report.txt"
+```
+
+### Autres services à tester
+
+```bash
+# Gitea
+borgmatic extract --archive latest --path /opt/gitea --destination "$TEST_DIR/"
+
+# Mailcow
+borgmatic extract --archive latest --path /opt/mailcow-dockerized --destination "$TEST_DIR/"
+
+# Configurations système
+borgmatic extract --archive latest --path /etc --destination "$TEST_DIR/"
+```
+
+---
+
+## Niveau 3 : Disaster Recovery complet (semestriel)
+
+**Durée estimée :** 2-4 heures
+**Fréquence recommandée :** Tous les 6 mois
+**Objectif :** Simuler une catastrophe totale et restaurer sur un nouveau serveur
+
+### Scénario : "Le serveur de production a brûlé"
+
+#### Phase 1 : Préparation du nouveau serveur
+
+**Option A : VM de test locale**
+
+```bash
+# Créer une VM Ubuntu/Debian avec les mêmes specs
+# - RAM : même quantité que prod
+# - Disque : au moins la taille de vos backups
+# - Réseau : accès Internet
+```
+
+**Option B : Serveur de secours**
+
+```bash
+# Utiliser un serveur de backup/staging
+# S'assurer qu'il est vierge ou sauvegardé
+```
+
+#### Phase 2 : Installation des bases
+
+```bash
+# 1. Mettre à jour le système
+sudo apt update && sudo apt upgrade -y
+
+# 2. Installer les dépendances de base
+sudo apt install -y git curl wget vim
+
+# 3. Cloner le repo de configuration
+cd /opt
+sudo git clone https://git.example.com/agence66-borgmatic.git borgmatic
+cd borgmatic
+
+# 4. Configurer les variables d'environnement
+sudo cp .env.example /etc/borgmatic/.env
+sudo nano /etc/borgmatic/.env
+# Remplir : BORG_REPO, BORG_PASSPHRASE
+
+# 5. Configurer les clés SSH
+sudo mkdir -p /root/.ssh
+sudo cp votre-cle-ssh /root/.ssh/id_rsa
+sudo chmod 600 /root/.ssh/id_rsa
+
+# 6. Installer Borgmatic
+sudo ./install.sh
+```
+
+#### Phase 3 : Vérifier l'accès au repository
+
+```bash
+# Tester la connexion
+sudo borgmatic list
+
+# Lister les archives disponibles
+sudo borgmatic list --archive all
+
+# Choisir l'archive à restaurer (généralement la plus récente)
+ARCHIVE_NAME="backup-20251218-0301"
+```
+
+#### Phase 4 : Restauration complète
+
+**IMPORTANT : Chronométrez chaque étape pour mesurer votre RTO réel**
+
+```bash
+# Démarrer le chronomètre
+START_TIME=$(date +%s)
+
+# Restaurer TOUT
+sudo borgmatic extract \
+  --archive "$ARCHIVE_NAME" \
+  --destination /tmp/full-restore/
+
+# Calculer le temps écoulé
+END_TIME=$(date +%s)
+DURATION=$((END_TIME - START_TIME))
+echo "Durée de restauration: $((DURATION / 60)) minutes"
+```
+
+#### Phase 5 : Reconstruction des services
+
+```bash
+# 1. Copier les fichiers restaurés vers leurs emplacements
+sudo cp -a /tmp/full-restore/opt/* /opt/
+sudo cp -a /tmp/full-restore/etc/* /etc/
+sudo cp -a /tmp/full-restore/var/www/* /var/www/
+
+# 2. Installer Docker et Docker Compose
+sudo apt install -y docker.io docker-compose
+
+# 3. Restaurer les configurations Docker
+cd /opt/nextcloud && sudo docker-compose up -d
+cd /opt/mailcow-dockerized && sudo docker-compose up -d
+cd /opt/gitea && sudo docker-compose up -d
+
+# 4. Vérifier les permissions
+sudo chown -R www-data:www-data /var/www/
+sudo chown -R 1000:1000 /opt/nextcloud/data/
+
+# 5. Redémarrer les services
+sudo systemctl restart nginx
+sudo systemctl restart mysql
+```
+
+#### Phase 6 : Tests de validation
+
+```bash
+# 1. Vérifier que les services démarrent
+docker ps -a
+systemctl status nginx
+systemctl status mysql
+
+# 2. Tester l'accès web
+curl -I http://localhost
+curl -I http://localhost/nextcloud
+
+# 3. Vérifier les bases de données
+mysql -e "SHOW DATABASES;"
+
+# 4. Tester un login utilisateur
+# → Ouvrir le navigateur et tester Nextcloud, Mailcow, etc.
+
+# 5. Vérifier les données
+ls -lh /opt/nextcloud/data/
+ls -lh /var/www/html/
+```
+
+#### Phase 7 : Documentation du processus
+
+```bash
+# Créer un rapport détaillé
+cat > /tmp/disaster-recovery-report-$(date +%Y%m%d).txt <<EOF
+==========================================================
+RAPPORT DE TEST DISASTER RECOVERY
+==========================================================
+
+Date du test: $(date)
+Serveur de test: [NOM/IP]
+Archive utilisée: $ARCHIVE_NAME
+
+CHRONOLOGIE
+-----------
+1. Préparation serveur: [DURÉE]
+2. Installation bases: [DURÉE]
+3. Restauration fichiers: $((DURATION / 60)) minutes
+4. Reconstruction services: [DURÉE]
+5. Validation: [DURÉE]
+
+DURÉE TOTALE (RTO): [DURÉE TOTALE]
+
+SERVICES TESTÉS
+---------------
+[ ] Nextcloud - Statut: ✅/❌
+[ ] Mailcow - Statut: ✅/❌
+[ ] Gitea - Statut: ✅/❌
+[ ] Nginx - Statut: ✅/❌
+[ ] Autres: [LISTE]
+
+PROBLÈMES RENCONTRÉS
+--------------------
+1. [PROBLÈME 1]
+   Solution: [SOLUTION]
+
+2. [PROBLÈME 2]
+   Solution: [SOLUTION]
+
+AMÉLIORATIONS IDENTIFIÉES
+--------------------------
+1. [AMÉLIORATION 1]
+2. [AMÉLIORATION 2]
+
+LEÇONS APPRISES
+---------------
+1. [LEÇON 1]
+2. [LEÇON 2]
+
+PROCHAINES ACTIONS
+------------------
+[ ] Mettre à jour la documentation
+[ ] Corriger les problèmes identifiés
+[ ] Former l'équipe sur la procédure
+[ ] Planifier le prochain test
+
+VALIDATION
+----------
+Testé par: [NOM]
+Validé par: [NOM]
+Signature: _________________
+
+EOF
+
+cat /tmp/disaster-recovery-report-$(date +%Y%m%d).txt
+```
+
+---
+
+## Scénarios de restauration courants
+
+### 1. Fichier supprimé accidentellement
+
+```bash
+# Lister les archives contenant le fichier
+borgmatic list --path /opt/nextcloud/data/user/important.pdf
+
+# Restaurer depuis une archive spécifique
+borgmatic extract \
+  --archive backup-20251215-0301 \
+  --path /opt/nextcloud/data/user/important.pdf \
+  --destination /tmp/restore/
+
+# Copier le fichier restauré
+cp /tmp/restore/opt/nextcloud/data/user/important.pdf /opt/nextcloud/data/user/
+```
+
+### 2. Base de données corrompue
+
+```bash
+# Restaurer le dump de base de données
+borgmatic extract \
+  --archive latest \
+  --path /opt/mailcow-dockerized/backup/mysql \
+  --destination /tmp/restore/
+
+# Importer la base de données
+mysql < /tmp/restore/opt/mailcow-dockerized/backup/mysql/dump.sql
+```
+
+### 3. Configuration cassée
+
+```bash
+# Restaurer l'ancienne configuration
+borgmatic extract \
+  --archive backup-20251210-0301 \
+  --path /etc/nginx/nginx.conf \
+  --destination /tmp/restore/
+
+# Comparer et restaurer
+diff /etc/nginx/nginx.conf /tmp/restore/etc/nginx/nginx.conf
+sudo cp /tmp/restore/etc/nginx/nginx.conf /etc/nginx/nginx.conf
+sudo systemctl restart nginx
+```
+
+### 4. Rollback complet d'un service
+
+```bash
+# Arrêter le service
+cd /opt/nextcloud && docker-compose down
+
+# Sauvegarder l'état actuel
+mv /opt/nextcloud /opt/nextcloud.broken
+
+# Restaurer depuis une archive antérieure
+borgmatic extract \
+  --archive backup-20251201-0301 \
+  --path /opt/nextcloud \
+  --destination /opt/
+
+# Redémarrer
+cd /opt/nextcloud && docker-compose up -d
+```
+
+---
+
+## Checklist de vérification
+
+### Avant la restauration
+
+- [ ] Archive de backup identifiée
+- [ ] Espace disque suffisant (au moins 2x la taille du backup)
+- [ ] BORG_PASSPHRASE disponible
+- [ ] Clés SSH configurées
+- [ ] Accès au repository Borg validé
+- [ ] Services arrêtés si restauration en production
+- [ ] Backup de l'état actuel effectué
+
+### Pendant la restauration
+
+- [ ] Chronométrage des étapes
+- [ ] Logs de restauration sauvegardés
+- [ ] Vérification des erreurs en temps réel
+- [ ] Documentation des problèmes rencontrés
+
+### Après la restauration
+
+- [ ] Fichiers/dossiers présents
+- [ ] Permissions correctes
+- [ ] Ownership correct (user:group)
+- [ ] Taille des données cohérente
+- [ ] Services démarrent correctement
+- [ ] Accès web fonctionnel
+- [ ] Bases de données accessibles
+- [ ] Tests fonctionnels réussis
+- [ ] Logs vérifiés
+- [ ] Rapport de test complété
+
+---
+
+## Troubleshooting
+
+### Erreur : "Permission denied"
+
+```bash
+# Solution : Utiliser sudo
+sudo borgmatic extract ...
+
+# Vérifier les permissions du repository
+ls -la /etc/borgmatic/
+```
+
+### Erreur : "Repository not found"
+
+```bash
+# Vérifier BORG_REPO
+echo $BORG_REPO
+
+# Tester la connexion SSH
+ssh -p 23 u516154@u516154.your-storagebox.de
+
+# Vérifier la clé SSH
+ssh-add -l
+```
+
+### Erreur : "Passphrase incorrect"
+
+```bash
+# Vérifier BORG_PASSPHRASE
+echo $BORG_PASSPHRASE
+
+# Charger depuis .env
+source /etc/borgmatic/.env
+```
+
+### Restauration très lente
+
+```bash
+# Utiliser des options de performance
+borgmatic extract --archive latest --path /opt/nextcloud --threads 4
+
+# Vérifier la bande passante réseau
+iftop
+nload
+```
+
+### Fichiers manquants après restauration
+
+```bash
+# Vérifier qu'ils n'étaient pas exclus
+grep -r "exclude" /etc/borgmatic/config.yaml
+
+# Lister tous les fichiers de l'archive
+borgmatic list --archive latest --short > /tmp/archive-files.txt
+grep "nextcloud" /tmp/archive-files.txt
+```
+
+### Permissions incorrectes
+
+```bash
+# Restaurer les permissions originales
+sudo chown -R www-data:www-data /opt/nextcloud/data/
+sudo chmod -R 755 /opt/nextcloud/
+```
+
+---
+
+## Bonnes pratiques
+
+### 1. Planification des tests
+
+Créez un calendrier de tests :
+
+```
+Janvier    : Test rapide
+Février    : Test rapide
+Mars       : Test rapide + Test service (Nextcloud)
+Avril      : Test rapide
+Mai        : Test rapide
+Juin       : Test rapide + Test service (Mailcow) + DR complet
+Juillet    : Test rapide
+...
+```
+
+### 2. Documentation continue
+
+Après CHAQUE test :
+
+- Mettre à jour ce document avec les leçons apprises
+- Noter les durées réelles
+- Documenter les problèmes et solutions
+- Partager avec l'équipe
+
+### 3. Automatisation
+
+Créer des scripts pour les tests fréquents :
+
+```bash
+# Script de test rapide automatisé
+./scripts/test-restore-quick.sh
+
+# Script de rapport automatique
+./scripts/generate-restore-report.sh
+```
+
+### 4. Formation de l'équipe
+
+- Faire tourner les personnes qui effectuent les tests
+- Documenter la procédure comme si vous la lisiez pour la première fois
+- Simuler des pannes sans prévenir (test surprise)
+
+### 5. Amélioration continue
+
+À chaque test, posez-vous :
+
+- Qu'est-ce qui pourrait être plus rapide ?
+- Qu'est-ce qui manque dans la documentation ?
+- Quels fichiers critiques ne sont pas backupés ?
+- Comment réduire le RTO (temps de restauration) ?
+
+---
+
+## Métriques importantes
+
+### RTO (Recovery Time Objective)
+
+**Temps maximum acceptable pour restaurer le service**
+
+Mesurez lors de vos tests :
+
+- Restauration fichiers uniquement : **\_** minutes
+- Restauration + redémarrage services : **\_** minutes
+- Disaster Recovery complet : **\_** heures
+
+### RPO (Recovery Point Objective)
+
+**Quantité de données qu'on peut accepter de perdre**
+
+Avec backup quotidien à 3h :
+
+- RPO : Maximum 24 heures de données perdues
+
+Si critique, envisager :
+
+- Backups plus fréquents (2x/jour)
+- Réplication en temps réel
+- Snapshots supplémentaires
+
+---
+
+## Conclusion
+
+**Un test de restauration régulier est la SEULE façon de garantir que vos backups fonctionnent.**
+
+N'attendez pas la catastrophe pour découvrir que vos backups sont inutilisables.
+
+### Prochaines étapes
+
+1. [ ] Planifier votre premier test rapide (cette semaine)
+2. [ ] Calendrier de tests pour l'année
+3. [ ] Former au moins une autre personne à la procédure
+4. [ ] Automatiser les tests simples
+5. [ ] Documenter votre RTO/RPO réel
+
+---
+
+**Date de dernière mise à jour :** 2025-12-18
+**Version :** 1.0
+**Mainteneur :** Agence66

docs/SSH-SETUP.md

@@ -0,0 +1,238 @@
+# Configuration SSH pour Borgmatic
+
+Guide complet pour configurer l'authentification SSH par clé pour les backups distants.
+
+## Pourquoi utiliser des clés SSH ?
+
+- **Automatisation** : Pas de mot de passe à saisir manuellement
+- **Sécurité** : Plus sécurisé qu'un mot de passe
+- **Requis** : Nécessaire pour que le timer systemd fonctionne automatiquement
+
+## Configuration étape par étape
+
+### 1. Générer une clé SSH
+
+```bash
+# Se connecter en root
+sudo su -
+
+# Générer une clé Ed25519 (recommandé)
+ssh-keygen -t ed25519 -C "borgmatic-backup@$(hostname)"
+
+# Ou RSA si Ed25519 n'est pas supporté
+ssh-keygen -t rsa -b 4096 -C "borgmatic-backup@$(hostname)"
+```
+
+**Réponses aux questions** :
+
+```
+Enter file in which to save the key (/root/.ssh/id_ed25519): [Entrée]
+Enter passphrase (empty for no passphrase): [Entrée - laisser vide]
+Enter same passphrase again: [Entrée]
+```
+
+**Important** : Laissez la passphrase **vide** pour permettre l'automatisation.
+
+### 2. Vérifier que la clé a été créée
+
+```bash
+ls -la /root/.ssh/
+# Vous devriez voir :
+# id_ed25519      (clé privée - à garder secrète)
+# id_ed25519.pub  (clé publique - à copier sur le serveur)
+```
+
+### 3. Copier la clé sur le serveur distant
+
+#### Méthode automatique (recommandée)
+
+```bash
+# Syntaxe générale
+ssh-copy-id -p PORT user@backup-server.com
+
+# Exemples
+ssh-copy-id -p 22 backup@backup.example.com
+ssh-copy-id -p 2222 user@192.168.1.100
+```
+
+Saisissez le mot de passe du serveur **une dernière fois**.
+
+#### Méthode manuelle
+
+Si `ssh-copy-id` ne fonctionne pas :
+
+```bash
+# 1. Afficher votre clé publique
+cat /root/.ssh/id_ed25519.pub
+
+# 2. Se connecter au serveur distant
+ssh -p PORT user@backup-server.com
+
+# 3. Sur le serveur distant, ajouter la clé
+mkdir -p ~/.ssh
+chmod 700 ~/.ssh
+echo "VOTRE_CLE_PUBLIQUE_ICI" >> ~/.ssh/authorized_keys
+chmod 600 ~/.ssh/authorized_keys
+exit
+```
+
+### 4. Tester la connexion
+
+```bash
+# Tester sans mot de passe
+ssh -p PORT user@backup-server.com
+
+# Si ça fonctionne, vous êtes connecté directement !
+# Tapez 'exit' pour revenir
+```
+
+**Si on vous demande toujours un mot de passe** :
+- Vérifiez les permissions : `chmod 600 /root/.ssh/id_ed25519`
+- Vérifiez le serveur : `ssh -v -p PORT user@backup-server.com` (mode verbeux)
+
+## Cas spécifiques
+
+### Serveurs avec interface web
+
+Certains fournisseurs de stockage backup proposent une interface web pour gérer les clés SSH :
+
+1. Connectez-vous à l'interface web de votre fournisseur
+2. Cherchez la section "SSH Keys" ou "Authentification"
+3. Cliquez sur "Add SSH key" ou équivalent
+4. Collez le contenu de `/root/.ssh/id_ed25519.pub`
+5. Sauvegardez
+
+### Serveur VPS/Dédié
+
+Pour un serveur standard avec accès SSH :
+
+```bash
+# Copie standard avec ssh-copy-id
+sudo ssh-copy-id -p 22 user@backup-server.com
+
+# Ou méthode manuelle
+ssh -p PORT user@backup-server.com
+mkdir -p ~/.ssh
+chmod 700 ~/.ssh
+echo "VOTRE_CLE_PUBLIQUE" >> ~/.ssh/authorized_keys
+chmod 600 ~/.ssh/authorized_keys
+exit
+```
+
+## Configuration avancée
+
+### Utiliser une clé SSH spécifique
+
+Si vous voulez utiliser une clé dédiée uniquement pour Borgmatic :
+
+```bash
+# 1. Générer une clé dédiée
+ssh-keygen -t ed25519 -f /root/.ssh/borgmatic_ed25519 -C "borgmatic-only"
+
+# 2. Copier cette clé spécifique
+ssh-copy-id -i /root/.ssh/borgmatic_ed25519.pub -p PORT user@backup-server.com
+
+# 3. Configurer dans /etc/borgmatic/.env
+echo 'BORG_RSH="ssh -i /root/.ssh/borgmatic_ed25519"' >> /etc/borgmatic/.env
+```
+
+### Config SSH personnalisée
+
+Créez `/root/.ssh/config` :
+
+```
+Host backup-server
+    HostName backup.example.com
+    Port 22
+    User backupuser
+    IdentityFile /root/.ssh/borgmatic_ed25519
+    StrictHostKeyChecking accept-new
+```
+
+Puis dans votre repository :
+
+```yaml
+repositories:
+    - path: ssh://backup-server/./backups
+      label: serveur
+```
+
+## Vérification et troubleshooting
+
+### Vérifier que tout fonctionne
+
+```bash
+# 1. Test SSH
+ssh -p PORT user@backup-server.com
+# ✅ Doit se connecter SANS demander de mot de passe
+
+# 2. Test Borg
+source /etc/borgmatic/.env
+borg list $BORG_REPO
+# ✅ Doit lister les archives SANS demander de mot de passe
+
+# 3. Test Borgmatic
+make dry-run
+# ✅ Doit fonctionner SANS demander de mot de passe
+```
+
+### Problèmes courants
+
+**"Permission denied (publickey)"**
+
+```bash
+# Vérifier les permissions de la clé privée
+chmod 600 /root/.ssh/id_ed25519
+
+# Vérifier que la clé est bien copiée sur le serveur
+ssh -v -p PORT user@backup-server.com 2>&1 | grep "Offering public key"
+```
+
+**"Host key verification failed"**
+
+```bash
+# Ajouter le serveur aux known hosts
+ssh-keyscan -p PORT backup-server.com >> /root/.ssh/known_hosts
+```
+
+**Borgmatic demande toujours le mot de passe**
+
+```bash
+# Vérifier que SSH fonctionne bien sans mot de passe
+ssh -p PORT user@backup-server.com
+
+# Vérifier les variables d'environnement
+sudo cat /etc/borgmatic/.env | grep BORG_RSH
+```
+
+## Sécurité
+
+### Bonnes pratiques
+
+1. **Clé dédiée** : Utilisez une clé SSH spécifique pour les backups
+2. **Restrictions** : Limitez la clé aux commandes Borg uniquement (côté serveur)
+3. **Rotation** : Changez les clés régulièrement (annuellement)
+4. **Backup** : Sauvegardez votre clé privée en lieu sûr
+
+### Limiter les commandes autorisées (serveur)
+
+Sur le serveur de backup, dans `~/.ssh/authorized_keys` :
+
+```bash
+command="borg serve --restrict-to-path /path/to/repo",restrict ssh-ed25519 AAAAC3... borgmatic-backup
+```
+
+Cela limite la clé SSH à **uniquement** exécuter Borg sur ce chemin spécifique.
+
+## Automatisation avec le timer systemd
+
+Une fois la clé SSH configurée, le timer systemd fonctionnera automatiquement :
+
+```bash
+# Le service systemd utilisera automatiquement la clé SSH de root
+systemctl status borgmatic.timer
+
+# Les backups s'exécuteront à 3h du matin sans intervention
+```
+
+✅ **Configuration terminée !** Les backups automatiques peuvent maintenant fonctionner sans intervention manuelle.

hooks/ntfy-error.sh

@@ -1,7 +1,7 @@
 #!/bin/bash
 #
 # Hook Borgmatic - Notification d'erreur via ntfy
-# Arguments: $1 = error message
+# Borgmatic 2.0 utilise des variables d'environnement
 #
 
 # Charger les variables d'environnement
@@ -9,7 +9,12 @@ if [ -f /etc/borgmatic/.env ]; then
     source /etc/borgmatic/.env
 fi
 
-ERROR_MSG="${1:-Erreur inconnue}"
+# Récupérer les dernières lignes d'erreur depuis les logs
+ERROR_MSG=$(journalctl -u borgmatic.service -n 10 --no-pager | tail -5 | sed 's/^.*borgmatic: //')
+
+if [ -z "$ERROR_MSG" ]; then
+    ERROR_MSG="Erreur inconnue - vérifiez les logs"
+fi
 
 # Envoyer notification d'erreur
 curl -s -u "$NTFY_USER" \
@@ -19,6 +24,7 @@ curl -s -u "$NTFY_USER" \
     -d "Le backup a échoué !
 Erreur: ${ERROR_MSG}
 Date: $(date '+%Y-%m-%d %H:%M:%S')
+Repository: ${BORG_REPO}
 Vérifiez les logs: journalctl -u borgmatic.service -n 50" \
     "$NTFY_URL"
 

hooks/ntfy-success.sh

@@ -1,7 +1,7 @@
 #!/bin/bash
 #
 # Hook Borgmatic - Notification de succès via ntfy
-# Arguments: $1 = archive_name, $2 = stats
+# Borgmatic 2.0 utilise des variables d'environnement
 #
 
 # Charger les variables d'environnement
@@ -9,12 +9,18 @@ if [ -f /etc/borgmatic/.env ]; then
     source /etc/borgmatic/.env
 fi
 
-ARCHIVE_NAME="${1:-inconnu}"
-STATS="${2:-}"
+# Récupérer le nom de la dernière archive créée
+# Borgmatic 2.0 expose BORG_REPO et autres variables d'environnement
+ARCHIVE_NAME=$(borgmatic list --last 1 --short 2>/dev/null | tail -1)
+if [ -z "$ARCHIVE_NAME" ]; then
+    ARCHIVE_NAME="dernière archive"
+fi
 
-# Extraire la taille depuis les stats si disponible
-# Borgmatic passe les stats en JSON, on peut parser ou utiliser directement
-SIZE="voir logs pour détails"
+# Récupérer la taille du backup
+BACKUP_SIZE=$(borgmatic info --archive "$ARCHIVE_NAME" 2>/dev/null | grep -E "Original size|This archive" | head -1 | awk '{print $(NF-1), $NF}')
+if [ -z "$BACKUP_SIZE" ]; then
+    BACKUP_SIZE="taille inconnue"
+fi
 
 # Envoyer notification de succès
 curl -s -u "$NTFY_USER" \
@@ -23,7 +29,8 @@ curl -s -u "$NTFY_USER" \
     -H "Tags: white_check_mark,backup" \
     -d "Backup terminé avec succès.
 Archive: ${ARCHIVE_NAME}
-Date: $(date '+%Y-%m-%d %H:%M:%S')" \
+Date: $(date '+%Y-%m-%d %H:%M:%S')
+Taille: ${BACKUP_SIZE}" \
     "$NTFY_URL"
 
 echo "Notification de succès envoyée à ntfy"

hooks/seafile-docker-mysql-backup.sh

@@ -0,0 +1,91 @@
+#!/bin/bash
+# Hook Borgmatic - Dump MySQL Seafile dockerisé avant backup
+
+set -e  # Arrêter en cas d'erreur
+
+BACKUP_DIR="/opt/seafile/backups/mysql"
+DATE=$(date +%Y%m%d-%H%M)
+SEAFILE_CONTAINER="seafile"     # Nom de votre conteneur Seafile
+MYSQL_CONTAINER="seafile-mysql" # Ou le nom de votre conteneur MySQL
+
+# Log pour debug systemd
+exec 1> >(logger -t seafile-backup -p user.info)
+exec 2> >(logger -t seafile-backup -p user.error)
+
+echo "[$(date)] Démarrage dump MySQL Seafile..."
+echo "Contexte: USER=$USER, PWD=$PWD, HOME=$HOME"
+
+# Créer le répertoire de backup
+mkdir -p "$BACKUP_DIR"
+echo "✓ Répertoire de backup: $BACKUP_DIR"
+
+# Charger les identifiants depuis .env
+if [ -f /etc/borgmatic/.env ]; then
+  source /etc/borgmatic/.env
+  echo "✓ Variables chargées depuis /etc/borgmatic/.env"
+else
+  echo "⚠️  /etc/borgmatic/.env non trouvé"
+fi
+
+# Utilisateur MySQL (par défaut root, configurable via .env)
+MYSQL_USER="${SEAFILE_MYSQL_USER:-root}"
+
+# Vérifier que le mot de passe est défini
+if [ -z "$SEAFILE_DB_PASSWORD" ]; then
+  echo "❌ SEAFILE_DB_PASSWORD n'est pas défini dans /etc/borgmatic/.env"
+  exit 1
+fi
+echo "✓ Utilisateur MySQL: $MYSQL_USER"
+echo "✓ Mot de passe MySQL défini"
+
+# Vérifier l'accès à Docker
+echo "Test accès Docker..."
+if ! docker info >/dev/null 2>&1; then
+  echo "❌ Impossible d'accéder à Docker (socket /var/run/docker.sock)"
+  exit 1
+fi
+echo "✓ Docker accessible"
+
+# Vérifier que le conteneur existe et tourne
+echo "Recherche du conteneur $MYSQL_CONTAINER..."
+if ! docker ps --format '{{.Names}}' | grep -q "^${MYSQL_CONTAINER}$"; then
+  echo "❌ Conteneur $MYSQL_CONTAINER non trouvé ou arrêté"
+  echo "Conteneurs disponibles:"
+  docker ps --format "  - {{.Names}}"
+  exit 1
+fi
+echo "✓ Conteneur $MYSQL_CONTAINER trouvé"
+
+# Dump unique avec toutes les bases
+DUMP_FILE="$BACKUP_DIR/seafile-all-$DATE.sql"
+echo "→ Lancement du dump MySQL vers: $DUMP_FILE"
+echo "→ Commande: docker exec $MYSQL_CONTAINER mysqldump -u $MYSQL_USER ..."
+
+# Utiliser une approche sans redirection 2>&1 qui peut bloquer
+set +e  # Désactiver temporairement set -e pour capturer le code de sortie
+timeout 300 docker exec "$MYSQL_CONTAINER" mysqldump \
+  -u "$MYSQL_USER" -p"${SEAFILE_DB_PASSWORD}" \
+  --single-transaction --quick --databases \
+  ccnet_db seafile_db seahub_db > "$DUMP_FILE" 2>&1
+DUMP_EXIT_CODE=$?
+set -e
+
+echo "→ Code de sortie mysqldump: $DUMP_EXIT_CODE"
+
+if [ $DUMP_EXIT_CODE -eq 0 ] && [ -f "$DUMP_FILE" ] && [ -s "$DUMP_FILE" ]; then
+  SIZE=$(du -h "$DUMP_FILE" | cut -f1)
+  echo "✓ Dump créé: seafile-all-$DATE.sql ($SIZE)"
+else
+  echo "❌ Échec du dump (code sortie: $DUMP_EXIT_CODE)"
+  [ -f "$DUMP_FILE" ] && echo "Taille fichier: $(stat -f %z "$DUMP_FILE" 2>/dev/null || stat -c %s "$DUMP_FILE") bytes"
+  exit 1
+fi
+
+# Nettoyer les anciens dumps (garder 7 jours)
+DELETED=$(find "$BACKUP_DIR" -name "*.sql" -mtime +7 -delete -print | wc -l)
+if [ "$DELETED" -gt 0 ]; then
+  echo "🗑️  $DELETED ancien(s) dump(s) supprimé(s)"
+fi
+
+echo "[$(date)] ✅ Dump MySQL Seafile terminé avec succès"
+exit 0

hooks/uptime-kuma-error.sh

@@ -0,0 +1,28 @@
+#!/bin/bash
+#
+# Hook Borgmatic - Ping Uptime Kuma en cas d'erreur
+# Borgmatic 2.0 utilise des variables d'environnement
+#
+
+# Charger les variables d'environnement
+if [ -f /etc/borgmatic/.env ]; then
+    source /etc/borgmatic/.env
+fi
+
+# Vérifier que l'URL Uptime Kuma est configurée
+if [ -z "$UPTIME_KUMA_PUSH_URL" ]; then
+    echo "UPTIME_KUMA_PUSH_URL non configuré, ping ignoré"
+    exit 0
+fi
+
+# Ping Uptime Kuma avec status=down
+curl -s "${UPTIME_KUMA_PUSH_URL}?status=down&msg=Backup%20failed&ping=" > /dev/null 2>&1
+
+if [ $? -eq 0 ]; then
+    echo "Ping Uptime Kuma envoyé (error)"
+else
+    echo "Erreur lors du ping Uptime Kuma"
+    exit 1
+fi
+
+exit 0

hooks/uptime-kuma-success.sh

@@ -0,0 +1,28 @@
+#!/bin/bash
+#
+# Hook Borgmatic - Ping Uptime Kuma en cas de succès
+# Borgmatic 2.0 utilise des variables d'environnement
+#
+
+# Charger les variables d'environnement
+if [ -f /etc/borgmatic/.env ]; then
+    source /etc/borgmatic/.env
+fi
+
+# Vérifier que l'URL Uptime Kuma est configurée
+if [ -z "$UPTIME_KUMA_PUSH_URL" ]; then
+    echo "UPTIME_KUMA_PUSH_URL non configuré, ping ignoré"
+    exit 0
+fi
+
+# Ping Uptime Kuma avec status=up
+curl -s "${UPTIME_KUMA_PUSH_URL}?status=up&msg=Backup%20successful&ping=" > /dev/null 2>&1
+
+if [ $? -eq 0 ]; then
+    echo "Ping Uptime Kuma envoyé (success)"
+else
+    echo "Erreur lors du ping Uptime Kuma"
+    exit 1
+fi
+
+exit 0

install.sh

@@ -13,7 +13,7 @@ YELLOW='\033[1;33m'
 NC='\033[0m' # No Color
 
 echo -e "${GREEN}==================================================${NC}"
-echo -e "${GREEN}Installation de Borgmatic - Agence66${NC}"
+echo -e "${GREEN}Installation de Borgmatic${NC}"
 echo -e "${GREEN}==================================================${NC}"
 echo ""
 
@@ -127,9 +127,8 @@ echo -e "${YELLOW}📋 Copie des fichiers de configuration...${NC}"
 cp config.yaml /etc/borgmatic/config.yaml
 chmod 600 /etc/borgmatic/config.yaml
 
-# Scripts de hooks
-cp hooks/ntfy-success.sh /etc/borgmatic/hooks/
-cp hooks/ntfy-error.sh /etc/borgmatic/hooks/
+# Scripts de hooks - copier tous les fichiers .sh
+cp hooks/*.sh /etc/borgmatic/hooks/
 chmod +x /etc/borgmatic/hooks/*.sh
 
 echo -e "${GREEN}✅ Fichiers de configuration copiés${NC}"

scripts/disk-usage.sh

@@ -0,0 +1,43 @@
+#!/bin/bash
+#
+# Script d'affichage de l'espace disque du serveur de backup
+# Usage: ./disk-usage.sh
+#
+
+set -e
+
+# Couleurs
+BLUE='\033[0;34m'
+YELLOW='\033[1;33m'
+NC='\033[0m'
+
+# Charger et exporter les variables d'environnement
+if [ -f /etc/borgmatic/.env ]; then
+    set -a
+    source /etc/borgmatic/.env
+    set +a
+elif [ -f .env ]; then
+    set -a
+    source .env
+    set +a
+fi
+
+echo -e "${BLUE}Espace disque sur le serveur de backup:${NC}"
+echo ""
+
+# Statistiques du repository Borg
+echo -e "${YELLOW}Espace utilisé par le repository Borg (toutes archives):${NC}"
+borgmatic info 2>/dev/null | awk '/Original size.*Compressed size.*Deduplicated size/{header=$0; next} /All archives:.*[GT]B/{if(header) print header; print; exit}'
+
+echo ""
+
+# Espace libre sur le serveur distant
+echo -e "${YELLOW}Espace libre sur le serveur distant:${NC}"
+USER_HOST=$(echo $BORG_REPO | sed "s|ssh://||" | sed "s|:.*||")
+PORT=$(echo $BORG_REPO | grep -o ":[0-9]*/" | sed "s|[:/]||g")
+
+if [ -n "$PORT" ]; then
+    ssh -p $PORT $USER_HOST "df -h ~/ | tail -1"
+else
+    ssh $USER_HOST "df -h ~/ | tail -1"
+fi

scripts/healthcheck.sh

@@ -13,18 +13,22 @@ YELLOW='\033[1;33m'
 BLUE='\033[0;34m'
 NC='\033[0m'
 
-# Charger les variables d'environnement
+# Charger et exporter les variables d'environnement
 if [ -f /etc/borgmatic/.env ]; then
+    set -a
     source /etc/borgmatic/.env
+    set +a
 elif [ -f .env ]; then
+    set -a
     source .env
+    set +a
 fi
 
 ERRORS=0
 WARNINGS=0
 
 echo -e "${BLUE}==================================================${NC}"
-echo -e "${BLUE}Healthcheck Borgmatic - Agence66${NC}"
+echo -e "${BLUE}Healthcheck Borgmatic${NC}"
 echo -e "${BLUE}==================================================${NC}"
 echo ""
 
@@ -193,7 +197,7 @@ if journalctl -u borgmatic.service -n 1 &> /dev/null; then
     fi
 
     # Chercher des erreurs récentes
-    ERROR_COUNT=$(journalctl -u borgmatic.service --since "24 hours ago" -p err --no-pager 2>/dev/null | wc -l)
+    ERROR_COUNT=$(journalctl -u borgmatic.service --since "24 hours ago" -p err --no-pager 2>/dev/null | grep -v "^-- No entries --$" | wc -l)
     if [ "$ERROR_COUNT" -gt 0 ]; then
         echo -e "${RED}❌ ${ERROR_COUNT} erreurs dans les dernières 24h${NC}"
         ((ERRORS++))

scripts/restore.sh

@@ -13,11 +13,15 @@ YELLOW='\033[1;33m'
 BLUE='\033[0;34m'
 NC='\033[0m'
 
-# Charger les variables d'environnement
+# Charger et exporter les variables d'environnement
 if [ -f /etc/borgmatic/.env ]; then
+    set -a
     source /etc/borgmatic/.env
+    set +a
 elif [ -f .env ]; then
+    set -a
     source .env
+    set +a
 else
     echo -e "${RED}❌ Fichier .env non trouvé${NC}"
     exit 1

scripts/test-notifications.sh

@@ -1,6 +1,6 @@
 #!/bin/bash
 #
-# Script de test des notifications ntfy
+# Script de test des notifications (ntfy et Uptime Kuma)
 # Usage: ./test-notifications.sh
 #
 
@@ -12,13 +12,18 @@ BLUE='\033[0;34m'
 NC='\033[0m'
 
 # Charger les variables d'environnement
-if [ -f /etc/borgmatic/.env ]; then
+if [ -r /etc/borgmatic/.env ]; then
     source /etc/borgmatic/.env
-elif [ -f .env ]; then
+elif [ -r .env ]; then
     source .env
 else
-    echo -e "${RED}❌ Fichier .env non trouvé${NC}"
-    echo "Créez un fichier .env avec NTFY_URL et NTFY_USER"
+    echo -e "${RED}❌ Fichier .env non trouvé ou non lisible${NC}"
+    echo ""
+    echo "Solutions:"
+    echo "  1. Exécutez ce script avec sudo"
+    echo "  2. Créez un fichier .env local dans le dossier du projet"
+    echo "     cp .env.example .env && nano .env"
+    echo ""
     exit 1
 fi
 
@@ -98,13 +103,75 @@ else
     exit 1
 fi
 
+echo ""
+echo -e "${BLUE}==================================================${NC}"
+echo -e "${BLUE}Test des notifications Uptime Kuma${NC}"
+echo -e "${BLUE}==================================================${NC}"
+echo ""
+
+# Vérifier si Uptime Kuma est configuré
+if [ -z "$UPTIME_KUMA_PUSH_URL" ]; then
+    echo -e "${YELLOW}⚠️  UPTIME_KUMA_PUSH_URL non configuré${NC}"
+    echo "Ignoré - configurez UPTIME_KUMA_PUSH_URL dans .env pour tester Uptime Kuma"
+else
+    echo -e "${YELLOW}Configuration:${NC}"
+    echo "  URL: ${UPTIME_KUMA_PUSH_URL}"
+    echo ""
+
+    # Test 4: Ping Uptime Kuma (succès)
+    echo -e "${YELLOW}📤 Test 4: Ping Uptime Kuma (status=up)...${NC}"
+    RESPONSE=$(curl -s -w "\n%{http_code}" "${UPTIME_KUMA_PUSH_URL}?status=up&msg=Test%20success&ping=")
+
+    HTTP_CODE=$(echo "$RESPONSE" | tail -1)
+    if [ "$HTTP_CODE" -eq 200 ]; then
+        echo -e "${GREEN}✅ Ping Uptime Kuma (success) envoyé avec succès${NC}"
+    else
+        echo -e "${RED}❌ Échec (HTTP $HTTP_CODE)${NC}"
+        echo "$RESPONSE"
+    fi
+
+    sleep 2
+
+    # Test 5: Ping Uptime Kuma (erreur)
+    echo -e "${YELLOW}📤 Test 5: Ping Uptime Kuma (status=down)...${NC}"
+    RESPONSE=$(curl -s -w "\n%{http_code}" "${UPTIME_KUMA_PUSH_URL}?status=down&msg=Test%20error&ping=")
+
+    HTTP_CODE=$(echo "$RESPONSE" | tail -1)
+    if [ "$HTTP_CODE" -eq 200 ]; then
+        echo -e "${GREEN}✅ Ping Uptime Kuma (error) envoyé avec succès${NC}"
+    else
+        echo -e "${RED}❌ Échec (HTTP $HTTP_CODE)${NC}"
+    fi
+
+    sleep 2
+
+    # Test 6: Remettre le statut à "up"
+    echo -e "${YELLOW}📤 Test 6: Remettre Uptime Kuma à up...${NC}"
+    RESPONSE=$(curl -s -w "\n%{http_code}" "${UPTIME_KUMA_PUSH_URL}?status=up&msg=Test%20complete&ping=")
+
+    HTTP_CODE=$(echo "$RESPONSE" | tail -1)
+    if [ "$HTTP_CODE" -eq 200 ]; then
+        echo -e "${GREEN}✅ Statut remis à up${NC}"
+    else
+        echo -e "${RED}❌ Échec (HTTP $HTTP_CODE)${NC}"
+    fi
+fi
+
 echo ""
 echo -e "${GREEN}==================================================${NC}"
 echo -e "${GREEN}✅ Tous les tests de notification ont réussi !${NC}"
 echo -e "${GREEN}==================================================${NC}"
 echo ""
-echo "Vérifiez que vous avez reçu 3 notifications sur votre appareil:"
+echo -e "${YELLOW}Vérifications:${NC}"
+echo ""
+echo -e "${BLUE}Ntfy:${NC}"
 echo "  1. Notification de test simple"
 echo "  2. Notification de succès de backup"
 echo "  3. Notification d'erreur de backup"
 echo ""
+if [ -n "$UPTIME_KUMA_PUSH_URL" ]; then
+    echo -e "${BLUE}Uptime Kuma:${NC}"
+    echo "  4. Monitor devrait montrer un changement up → down → up"
+    echo "  5. Vérifiez l'historique dans le dashboard Uptime Kuma"
+    echo ""
+fi