Souverain

Quand on commence à s’auto-héberger, on joue d’abord avec des services pratiques : photos, favoris, Mastodon, etc. Puis, un jour, la réalité tombe :

“Et si ce serveur tombe demain, je perds tout.”

C’est à peu près à ce moment-là que j’ai décidé de m’attaquer sérieusement au sujet des sauvegardes. Et comme d’habitude, rien ne s’est passé comme prévu.

Dans cet article, je raconte comment je suis passé :

• d’une envie “propre” avec Borg et mon NAS,
• à un enfer de messages d’erreur,
• pour finalement arriver à une solution simple, robuste et automatique :
  YunoHost fait ses sauvegardes, rsync les pousse vers le NAS, et je reçois un courriel quand tout s’est bien passé (ou pas).

Contexte : un serveur YunoHost, un NAS, et beaucoup d’insultes envers mon I.A

Le décor :

• un serveur YunoHost qui héberge une belle collection de services (Immich, Mastodon, etc.) ;
• un NAS, déjà utilisé pour Jellyfin et mes sauvegardes de données ;
• un réseau relativement bien sécurisé (je n’en dirais pas plus, par mesure, justement, de sécurité).

Mon objectif était simple (en théorie) :

“Avoir une sauvegarde automatique de mon serveur YunoHost vers mon NAS, sans avoir à y penser.”

Je voulais qu’en cas de crash du serveur, je puisse restaurer sa configuration et ses applications à partir d’une sauvegarde stockée sur le NAS. Et si possible, le tout sans passer mes week-ends en ligne de commande.

Spoiler : ça ne s’est pas exactement passé comme ça au début.

Pourquoi j’ai lâché l’idée “100 % Borg”

Comme beaucoup de tutos le suggèrent, j’ai d’abord voulu utiliser l’app Borg de YunoHost et le paquet Borg disponible depuis mon NAS.

Sur le papier, c’est joli :

• Borg sur YunoHost envoie des sauvegardes chiffrées vers le NAS,
• le NAS sert de “dépôt” Borg distant,
• déduplication, snapshots, tout le cinéma.

En pratique, ça a donné :

• des erreurs du style Remote: sh: borg: command not found
• des histoires de chemins (/usr/local/bin/borg vs /usr/bin/borg),
• des bidouilles sur authorized_keys pour forcer borg serve côté NAS,
• et tout un tas de petites choses qui réclament d’être à l’aise avec SSH, la ligne de commande et la cuisine interne du constructeur de mon NAS.

À force de messages d’erreur et de “Permission denied”, j’ai fini par admettre une vérité simple :

Oui, Borg est très bien (en réalité, je ne sais pas, mais je tombais souvent sur cette solution quand je cherchais sur « l’internet »)
Non, ce n’est pas le plus simple à faire tourner proprement entre YunoHost et un NAS quand on veut rester sain d’esprit.

Et surtout : YunoHost sait déjà faire des sauvegardes très correctes tout seul. Ce qui manquait, ce n’était pas un “super format” de sauvegarde, mais un moyen simple de les synchroniser vers le NAS.

Retour au bon sens : utiliser les sauvegardes natives de YunoHost

YunoHost dispose d’un système de sauvegardes intégré :

• via l’interface, on peut créer des archives contenant :
  • la configuration système,
  • les données système,
  • et toutes les applications,
• ces sauvegardes sont stockées dans :
  /home/yunohost.backup/archives/

C’est déjà très bien. Le vrai problème n’était donc pas “comment faire une sauvegarde ?”, mais :

“Comment faire en sorte que ces sauvegardes soient automatiquement copiées sur le NAS ?”

La réponse raisonnable n’était pas “rajouter une couche Borg entre les deux”, mais un outil plus simple, plus direct, déjà fait pour ça : rsync.

Mise en place de rsync entre YunoHost et le NAS

L’idée finale est devenue très simple :

1. YunoHost continue à générer ses sauvegardes dans /home/yunohost.backup/archives/.
2. Un rsync sur le serveur copie automatiquement ce dossier vers
   /MonNAS/backups/yunohost/ sur le NAS.
3. Le tout, via SSH avec une clé, sans mot de passe.

Générer une clé SSH dédiée

Plutôt que d’utiliser une clé générique, j’ai créé une clé dédiée à rsync, côté serveur :
ssh-keygen -t ed25519 -f /root/.ssh/id_rsync_ed25519 -N ""

Résultat :

• clé privée : /root/.ssh/id_rsync_ed25519
• clé publique : /root/.ssh/id_rsync_ed25519.pub

On récupère ensuite le contenu de la clé publique :

cat /root/.ssh/id_rsync_ed25519.pub

Cette ligne (qui commence par ssh-ed25519) sera installée sur le NAS.

Autoriser la clé sur le compte du NAS

Sur le NAS, j’utilise un utilisateur admin (par exemple « micheline ») avec :

• accès SSH activé,
• droits en lecture/écriture sur le dossier de sauvegarde du NAS, par exemple : /MonNAS/backups/yunohost.

Dans l’interface de mon NAS :

1. Activer les dossiers personnels (“homes”) si ce n’est pas déjà fait.
2. Ouvrir le gestionnaire de fichiers → homes/micheline.
3. Créer un dossier .ssh si nécessaire.
4. Dans .ssh, ajouter (ou créer) le fichier authorized_keys.
5. Coller dedans la clé publique issue du serveur.

Résultat : le serveur YunoHost peut se connecter en SSH à micheline@NAS sans mot de passe, avec cette clé.

On vérifie depuis le serveur :

ssh -i /root/.ssh/id_rsync_ed25519 micheline@192.168.1.69

si l’adresse IP du NAS est différente, on adapte.
Si on arrive directement sur un prompt micheline@NAS:~$ sans mot de passe, c’est bon.

Attention : Sur mon NAS, il a fallu que j’active aussi l’option rsync, je précise, car j’ai essayé les étapes suivantes sans le faire et je tournais en rond. Une fois activée, le reste se déroulait sans problème (et sans énervement).

Tester rsync à la main

Une fois SSH fonctionnel, la commande rsync devient (depuis le serveur, en root) :

rsync -av -e "ssh -i /root/.ssh/id_rsync_ed25519" \
/home/yunohost.backup/archives/ \
micheline@192.168.1.69:/MonNAS/backups/yunohost/

• -a : archive : préserve les dates, droits, etc.
• -v : verbeux : on voit ce qui se passe
• -e "ssh -i ..." : dit à rsync d’utiliser cette clé précise pour SSH

La première fois, rsync copie toutes les archives.
Les fois suivantes, il ne recopie que ce qui a changé (ou ce qui est nouveau)

Automatiser la sauvegarde : cron + courriel de confirmation

Copier à la main, c’est bien pour tester. Automatiser, c’est mieux.

Planifier rsync avec cron :

Sur le serveur, on édite la crontab de root : sudo crontab -e

Et on ajoute une ligne, par exemple pour lancer la synchro tous les mardis à 10h :

0 10 * * 2 rsync -av --delete -e "ssh -i /root/.ssh/id_rsync_ed25519" /home/yunohost.backup/archives/ micheline@192.168.1.69:/MonNAS/backups/yunohost/ >> /var/log/rsync-yunohost-backups.log 2>&1

Ici :

• 0 10 * * 2 → mardi à 10h (0 = dimanche, 1 = lundi, 2 = mardi, etc.)
• –delete → le dossier sur le NAS reste un miroir de celui sur le serveur (si on supprime une vieille archive sur le serveur, elle disparaît aussi sur le NAS).
• la sortie est loggée dans /var/log/rsync-yunohost-backups.log.

Se faire envoyer un courriel si tout s’est bien passé (et aussi en cas d’échec) :

Dernier luxe 💎 : non seulement recevoir un courriel quand la sauvegarde est terminée sans erreur, mais aussi être prévenu si ça casse avec le détail du log.

On ajoute simplement, à la fin de la ligne cron, une logique “succès OU échec” avec && et || :

0 10 * * 2 rsync -av --delete -e "ssh -i /root/.ssh/id_rsync_ed25519" /home/yunohost.backup/archives/ micheline@192.168.1.69:/MonNAS/backups/yunohost/ >> /var/log/rsync-yunohost-backups.log 2>&1 && echo "Rsync OK sur serveur vers NAS" | mail -s "Backup YunoHost OK" mon@courriel.ovh || mail -s "Backup YunoHost ÉCHEC" mon@courriel.ovh < /var/log/rsync-yunohost-backups.log

• Si rsync réussit (code de retour 0) → le courriel “Backup YunoHost OK” est envoyé.
• Si rsync échoue → le && est ignoré, on tombe sur le || et on reçoit un courriel “Backup YunoHost ÉCHEC” avec le contenu complet du fichier de log en pièce jointe textuelle.

On peut évidemment tester manuellement la commande (sans cron) pour vérifier que le courriel part bien avant de laisser tourner ça en automatique.

Ce que cette configuration change pour la sécurité de mon homelab

À la fin de ce parcours, j’ai :

• un serveur YunoHost qui fait des sauvegardes propres dans /home/yunohost.backup/archives/ ;
• un NAS qui reçoit automatiquement une copie de ces sauvegardes via rsync + SSH ;
• une tâche cron qui tourne toutes les semaines, sans que j’aie besoin de m’en occuper ;
• un courriel automatique qui confirme que la synchro s’est bien passée ou pas.

Combiné au reste de la configuration, ça me place sur un niveau de sécurité très correct pour un homelab familial.

Surtout, j’ai une solution :

• que je comprends,
• que je peux expliquer,
• et que je peux réparer si un jour quelque chose casse.

Limites et pistes d’amélioration

Tout n’est pas parfait, et c’est normal.

Les points encore perfectibles :

• Sauvegarde hors-site :
  si la maison brûle ou se fait cambrioler, serveur + NAS peuvent disparaître ensemble. La prochaine étape “sérieuse” serait d’avoir une copie des sauvegardes sur un support externe rangé ailleurs, ou sur un stockage distant chiffré.
• Test de restauration complet :
  je sais que mes archives existent, qu’elles voyagent, qu’elles sont versionnées. Le vrai crash test, ce sera de restaurer YunoHost sur une machine de test à partir de ces fichiers.
• Réduction de la surface d’attaque :
  j’héberge beaucoup de services, mais mécaniquement, plus il y en a, plus il y a de risque.

Conclusion

Ce que je retiens de cette histoire, c’est que :

• vouloir “le truc parfait” (Borg partout, dépôt distant, etc.) peut vite devenir un cauchemar quand on mélange YunoHost, son NAS et ses spécificités ;
• utiliser ce que YunoHost sait déjà faire bien (ses propres sauvegardes) et ajouter une brique simple comme rsync est souvent la solution la plus intelligente (pour moi);
• quelques commandes bien ciblées (générer une clé, configurer rsync, poser une ligne cron) sont parfois un meilleur investissement que des heures à se battre avec une usine à gaz.

Aujourd’hui, si mon serveur tombe, je sais qu’il existe quelque part, sur mon NAS, une copie à jour de ses sauvegardes.
Et chaque mardi matin, un courriel arrive pour me dire :

“C’est bon, on a tout.”

Et ça, c’est un niveau de tranquillité qui vaut largement quelques insultes balancées à mon I.A en cours de route.

Pour finir, si vous êtes tombé sur cet article parce que vous galérez vous aussi avec vos sauvegardes YunoHost + NAS, n’hésitez pas à laisser un commentaire : si vous avez des questions, si vous voyez une amélioration possible, si vous n’êtes pas d’accord avec ma manière de faire ou si vous repérez une grosse bêtise technique, dites-le. Je ne prétends pas avoir “la” vérité, seulement partager une solution qui fonctionne pour moi, donc tous les retours (même les plus piquants) sont les bienvenus.