Compare commits
29 Commits
66e4cd166f
...
main
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
14cbfab07b | ||
|
|
0ae8cb9e0e | ||
|
|
9c29cc1bdc | ||
|
|
671347b39d | ||
|
|
c8d62e79dc | ||
|
|
20a4364fd6 | ||
|
|
ef82bca68e | ||
|
|
96cb54d1c6 | ||
|
|
21355eceff | ||
|
|
07a98d5617 | ||
|
|
b816e25caa | ||
|
|
9a5ea36901 | ||
|
|
636f5987c7 | ||
|
|
1afde7afc3 | ||
|
|
9b10a325dc | ||
|
|
cecc224dea | ||
|
|
6f968f73c4 | ||
|
|
9c03ebf8e2 | ||
|
|
b2beeb3334 | ||
|
|
25b0a2fcfa | ||
|
|
e764d1dc3d | ||
|
|
6f3b3888a2 | ||
|
|
fa78f80d73 | ||
|
|
24d3e7d914 | ||
|
|
615192ceda | ||
|
|
2b087414ba | ||
|
|
9164e0273e | ||
|
|
df7dfe72a2 | ||
|
|
b215d8c325 |
19
.env.example
19
.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
|
||||
# ============================================
|
||||
|
||||
27
.gitea/workflows/deploy.yml
Normal file
27
.gitea/workflows/deploy.yml
Normal file
@@ -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"
|
||||
14
CHANGELOG.md
14
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é
|
||||
|
||||
29
Makefile
29
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'
|
||||
|
||||
@@ -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.
|
||||
|
||||
171
README.md
171
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.
|
||||
|
||||
24
TODO.md
24
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
|
||||
|
||||
92
config.yaml
92
config.yaml
@@ -1,38 +1,44 @@
|
||||
# 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:
|
||||
- /var/www
|
||||
- /srv/minecraftserver
|
||||
- /srv/reddiscordbot
|
||||
- /srv/waltercoiffure
|
||||
- /etc
|
||||
- /opt/nextcloud
|
||||
- /opt/traefik
|
||||
- /opt/n8n
|
||||
- /opt/portainer
|
||||
- /opt/uptime-kuma
|
||||
- /opt/vaultwarden
|
||||
- /opt/mailcow-dockerized
|
||||
- /opt/netdata
|
||||
- /opt/gitea
|
||||
- /home
|
||||
- /var/www
|
||||
- /srv/minecraftserver
|
||||
- /srv/reddiscordbot
|
||||
- /srv/waltercoiffure
|
||||
- /etc
|
||||
- /opt/nextcloud
|
||||
- /opt/traefik
|
||||
- /opt/n8n
|
||||
- /opt/portainer
|
||||
- /opt/uptime-kuma
|
||||
- /opt/vaultwarden
|
||||
- /opt/mailcow-dockerized
|
||||
- /opt/netdata
|
||||
- /opt/gitea
|
||||
- /home
|
||||
|
||||
# Patterns d'exclusion
|
||||
exclude_patterns:
|
||||
- "*.log"
|
||||
- "*/cache/*"
|
||||
- "*/tmp/*"
|
||||
- "**/__pycache__"
|
||||
- "*/node_modules/*"
|
||||
- "*.log"
|
||||
- "*/cache/*"
|
||||
- "*/tmp/*"
|
||||
- "**/__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,31 +57,39 @@ 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:
|
||||
- name: repository
|
||||
frequency: 2 weeks
|
||||
- name: archives
|
||||
frequency: 1 month
|
||||
- name: repository
|
||||
frequency: 2 weeks
|
||||
- name: archives
|
||||
frequency: 1 month
|
||||
|
||||
# Nombre d'archives à vérifier
|
||||
check_last: 3
|
||||
|
||||
# Commandes/hooks pour notifications
|
||||
before_actions:
|
||||
- echo "Backup démarré"
|
||||
# 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
|
||||
|
||||
216
docs/GITEA-ACTIONS.md
Normal file
216
docs/GITEA-ACTIONS.md
Normal file
@@ -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)
|
||||
714
docs/RESTORE-TESTING.md
Normal file
714
docs/RESTORE-TESTING.md
Normal file
@@ -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
|
||||
238
docs/SSH-SETUP.md
Normal file
238
docs/SSH-SETUP.md
Normal file
@@ -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.
|
||||
@@ -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"
|
||||
|
||||
|
||||
@@ -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"
|
||||
|
||||
91
hooks/seafile-docker-mysql-backup.sh
Normal file
91
hooks/seafile-docker-mysql-backup.sh
Normal file
@@ -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
|
||||
28
hooks/uptime-kuma-error.sh
Executable file
28
hooks/uptime-kuma-error.sh
Executable file
@@ -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
|
||||
28
hooks/uptime-kuma-success.sh
Executable file
28
hooks/uptime-kuma-success.sh
Executable file
@@ -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
|
||||
@@ -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}"
|
||||
|
||||
43
scripts/disk-usage.sh
Executable file
43
scripts/disk-usage.sh
Executable file
@@ -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
|
||||
@@ -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++))
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user