Sur un Raspberry PI 3B+ avec comme version de YunoHost:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 10 (buster)
Release: 10
Codename: buster
Les clés id_borg_ed25519 et id_borg_ed25519.pub ont bien été créés dans /root/.ssh/
Ma question est… puis-je grâce à ces clés faire un test de connexion ssh vers le serveur qui doit accueillir le backup ??
Parce que ce test ne fonctionne pas, car il m’est demandé le mot de passe!
Et le serveur de backup (un Nas) fonctionne bien en ssh par clés avec une autre machine!
Cependant, est-ce que tu as bien borg installé sur ton NAS ? Car si ce n’est pas le cas, ça ne va pas marcher à moins que tu montes ti même le sshfs et que tu configures ton borg_ynh en mode repo “local” sur ce sshfs qui est en réalité distant…
Ok… Le “ssh -i” était le bon test… Il était de suite fonctionnel!
Par-contre je savais pas que sur le serveur du backup (le Nas), il fallait avoir installé Borg… Je l’ai donc installé!
Cette nuit, ça a donc fait le backup… Mais cela à mis à mal les ressources du Raspberry… c’est un peu con… Du coup Yunohost était en moitié plantée… J’ai été obligé de le redémarrer…
Il faut voir si avec un backup incrémentiel cela bouffe moins les ressources ?? (pour que cela soir viable)
Je ne suis pas sur un raspberry, mais la charge serveur était énorme pendant ces 6 heures (énormément de lecture et d’écriture, avec son système de dé-duplication des données, une sauvegarde est bien plus énergivore qu’une simple copie, mais pour les sauvegardes suivantes il traite beaucoup moins de fichiers).
Est ce que tu es sur que le serveur était vraiment planté ou juste croulait sous la charge ?
Quel modèle de Rpi tu as? pour quelle quantité de données ?
Est-ce que tu as de la swap en place ? Est-ce que tu peux donner des chiffres sur la consommation de ressources et/ou des logs sur les échecs qui en résulte ?
Le serveur croule tellement sous la charge que j’ai plus d’interface Web, plus de ssh… bon j’arrive quand-même à pinger son IP… et ça fait des heures… J’attends voir s’il me rend la main, pour le redémarrer proprement… Mais bon, cela se reproche du reboot hard!
Ça dépend d’énormément de choses.
J’ai un serveur bien plus puissant qu’un raspberry, avec dans les 300Go de données, et il a souffert pendant 6h.
Selon la quantité de données, leur origine, l’accès aux disques et certainement plein d’autres trucs, ça doit pouvoir être encore pire.
Par contre, ce que tu peux faire pour faire un test plus léger, c’est d’ajouter une petite app (genre custom webapp) et de ne sauvegarder qu’elle, comme ça tu pourra tester le process complet sans souffrir comme ça (car il y a peut-être réellement un soucis, je ne sais pas)
C’est un Raspberry PI 3b+
Comme j’ai plus accès au RPI en ce moment… La quantité du backup fait hier est de 28Go!
Il est vrais que hier j’avais rajouté du swap… et que la il n’a pas de swap!
Pour Borg, j’ai recommencé… désinstaller, réinstaller…
Je sais pas comment vous utiliser Borg… Mais dans la console “Diagnostic”, il était demandé de redémarrer Borg par “sudo yunohost service restart borg”… Cette commande bugge complet… Avec cette commande le swap gonfle indéfiniment… il est monté au moins à 10Go de swap (avant redémarrage hard)… Et dans les processus, il y avait une multitude de “/usr/bin/yunohost dyndns update”… Je ne sais pas si c’est normal ??
J’ai donc maintenant relancé Borg par “sudo systemctl start borg.service”… Ça a l’air de fonctionner beaucoup mieux… en tous cas le swap semble mieux se comporter… là il en est à 730Mo…
Le service n’est pas tout le temps actif, il est lancé par un timer systemd. Du coup le test du status n’a pas beaucoup de sens. Je vais chercher ce que je peux faire pour que ce status ne déclenche pas l’alerte dans le diagnostique. Tu n’es pas censé lancer le backup manuellement, bien que ce soit possible de le faire par exemple avant une mise à jour importante.
Déjà, je trouve ça bizarre de configurer 10G de swap (2G pourquoi pas, 4 ok mais 10 ça me semble démesuré). Ah moins qu’on parle ici de zram ? Dans ce cas je suis moins au points sur cette question.
Tu testes ça avec free -m ?
C’est vraiment bizarre que ça monte autant. Tu n’as pas dit quel était la quantité de données que tu sauvegardes ? Ce serait bien aussi d’avoir d’autres éléments de contexte, genre est-ce que tu as utilisé du mount --bind ou des liens symboliques ? Est-ce que le reste du diagnostique est au vert ?
Une multitude non. Mais je dois dire que personnellement je n’utilise pas le dyndns de yunohost et je n’ai pas testé borg avec. Il est possible que les processus yunohost dyndns créés toutes les 3 minutes par le cron soit en attente. A partir de là on peut imaginer que chaque processus consomme de la ram et que ça augmente tant que le processus de backup n’est pas fini…
Ok… je suis rassuré!
Question… à quelle heure il se lance ??
En réalité, j’ai commencé à mettre 2Go de swap… puis 2Go en plus… et comme ça a continué à augmenter au moment de me coucher, j’ai mis un total de 10Go, pour être tranquille… et le lendemain la Yunohost était tellement en vrac, que j’ai été obligé de faire un redémarrage hard!
Et encore il faut faire -20Go au donné occupé, car j’ai actuellent 20Go de swap (vu que ça bugge, pour les tests j’ai pris des mesures)
J’évite de trop trafiquer ma Yunohost… Donc, j’ai pas ajouté de “mount --bind”, pas ajouté de lien symbolique… et le reste du diagnostic est dans le vert!
A l’heure que tu as donné lord de l’installation, si tu as mis “Daily”, c’est à minuit.
Tu peux lancer la commande systemctl list-timers pour le savoir.
Ca explique les processus yunohost dyndns… Il me semble que la commande htop par défaut affiche plusieurs fois les mêmes processus. Du coup ça invalide probablement la théorie du dyndyns qui remplie ta ram.
Où as tu placé ton fichier de swap ? SI tu le places dans un endroits destiné à être sauvegardé ça pourrait mener au problème que tu rencontres.
Bon là, il vient de faire le backup… ça a pris 15mn, et le swap n’a pas bougé… il est resté en dessous de 400Mo… C’est vraiment la commande “sudo yunohost service restart borg” qui bugge… C’est pourtant cette commande qui est donné dans le Diagnostic!
Si non question subsidiaire… pour restaurer, c’est quoi un exemple de commande ??
Il faut faire: sudo su -
puis depuis le répertoire /root/ un:
borg extract ssh://utilisateur@LeNas.local:22/~/répertoireDuBackup/::auto_my_webapp_10_04_21_00:07
Est que c’est bien depuis le répertoire /root/ qu’il faut le faire ?
Et comment communiquer l’info du “ssh -i .ssh/id_borg_ed25519” dans la commande ? Est-ce que c’est automatique ?
Hier, j’ai fait la mise à jour proposée pour borg (je crois que c’était 1.1.13 et maintenant 1.1.16~yhn16). La mise a jour a eu l’air de planter (pacman pendant très très longtemps). J’ai arrêté le process qui me semblait planté, rebooté la machine et maintenant je remarque dans la liste des services
Le service borg est dead :-(
avec la suggestion de faire yunohost service restart borg. Et quand je fais cette commande elle ne rend jamais la main (j’imagine que c’est le même problème que pendant l’upgrade), ce qui ressemble à ce que décrit @pti-jean. Curieusement, quand j’interromps le yunohost service restart borg, le backup se fait dans la foulée!
Je suis surpris que yunohost signale un problème de “service dead”. Je comprends que c’est l’état normal d’un service systemd de type “one-shot”, mais je suis assez certain que yunohost ne trouvait pas ce service en défaut avant l’upgrade.
Pour le moment je vais laisser cela comme ça car il me semble que tout est bien en place pour faire le backup automatique la nuit prochaine.
