Comportement étrange du système de sauvegarde

Bonjour à toutes et à tous,

Après un essai de sauvegarde via la webadmin, je me suis retrouvé avec une erreur de non-réponse de l’API ne concernant que la fonctionnalité de sauvegarde (je peux aller et venir à ma guise sur le reste de l’interface semble-t-il, l’API plante seulement lorsque je clique sur les archives de sauvegarde).

Je suis donc passé par la moulinette : la sauvegarde a bien été créée.

J’ai relancé l’API Yunohost par la moulinette, redémarré le navigateur : aucun changement, même plantage.

Dans le doute, j’ai relancé une nouvelle sauvegarde directement par la moulinette. Tout a bien fonctionné jusqu’ici :

Info: Now creating a backup archive from the files collected…
Killed

Évidemment, il y a eu du pédalage dans le vide avant l’action “Killed”.

À nouveau : la sauvegarde a bien été enregistrée.

Cependant je m’interroge : au vu des irrégularités du mécanisme de sauvegarde, la régularité des sauvegardes est-ellle assurée ? Y a-t-il un moyen de vérifier leur intégrité ? Quelqu’un a-t-il déjà eu un problème similaire ?

Bien à vous !

Léo

L’idéal c’est que tu fournisses un log si possible par exemple celui de yunohost-api ou celui de yunohost-cli avec l’erreur pour qu’on comprenne. Je paris que la sauvegarde est présente mais que tu ne peux pas lister les sauvegardes (et donc les voir).
EN cli tu peux vérifier ce que je dis en faisant

ls -l /home/yunohost.backup/archives

Ta question plus globale est intéressante, concernant la régularité des sauvegardes à moins d’utiliser archivist_ynh ou borg_ynh il n’y a pas de “régularité” c’est juste une action lancé manuellement (ou configuré avec un cron éventuellement.

Pour l’intégrité, le seul vrai moyen de vérifier une sauvegarde c’est de la remonter (comme le propose fallback_ynh), par contre techniquement on peut préter un point d’attention en vérifiant que les fichiers info.json, backup.csv et les db.sql sont bien présents dans l’archive, idem pour les fichiers important. A l’heure actuel yunohost ne vérifie pas cette intégrité.

J’ai déjà eu un problème avec un script de backup (un vieux odoo) déficient qui lançait un warning à la place d’une erreur et ne faisait pas la sauvegarde du dump postgresql… Du coup j’avais tout sauf la base (le plus important quoi).
J’ai également eu quelques fois des backup sans le fichier backup.csv du coup les données étaient bien sauvegardées mais yunohost ne pouvait pas restaurer automatiquement, il fallait dans ce cas le faire à la main.

A noter que si une app échoue le backup va continuer pour sauvegarder les autres apps, ce comportement peut être traître si on ne s’en rend pas compte.

1 Like

Petit complément, les scripts de backup sont vérifiés par la CI des apps, donc si l’app à un level correct (genre 7) et ben en théorie elle se restore correctement (mais le test est fait sans données…).

Bref du coup mon soucis avec mon vieux odoo est arrivé parce que j’ai déployé un trucs qui n’était pas level 7 et qui comportait un bug sur le backup.

Pour des infos précises sur les apps qui ne se restaure pas: https://dash.yunohost.org/appci/branch/stable (en gros c’est les level 3 ou moins).

C’est toi qui a killed (avec CTRL+C ) ?

Si tu as besoins d’info en temps réels tu peux utiliser l’option --debug

Où est-ce que je pourrais trouver ça ?

Si je peux lister les sauvegardes sans problème, elles sont bien reconnues.
Par contre je viens de m’apercevoir que si je vérifie à la main dans

/home/yunohost.backup/archives/

…, elles n’ont pas de fichier json, seulement le tar.gz.

D’ailleurs à ce propos :

Je n’ai toujours eu que des .tar.gz et des .json dans mes sauvegardes Yunohost…

Je n’ai pas pu vérifier celles qui ne se restaureront pas (même si, à en croire ton lien, celles qui pourraient poser problème ne sont pas critiques dans mon cas) mais les infos de suivi du backup en ligne de commande listent bien chaque app et aucune ne semble poser de problème à la sauvegarde.

Non, c’est la sortie standard de Yunohost quand un truc tourne dans le vide je suppose.

Un peu plus d’infos avec l’option --debug :

55059 DEBUG + '[' 0 -eq 0 ']'
55060 DEBUG + exit 0
74448 INFO Now creating a backup archive from the files collected…
74453 DEBUG Creating the backup tar archive…
Killed

Quand je dis, qu’il faut vérifier la présence de backup.csv des db.sql et de info.json, je parle de vérifier en listant le contenu de chaque archive avec la commande tar (sans décompresser).

tar -ztvf backup.tar.gz | grep "backup.csv"
tar -ztvf backup.tar.gz | grep "info.json"
tar -ztvf backup.tar.gz | grep "db.sql"

C’est normal qu’il y ai juste un tar.gz et un info.json.

Ca ce n’est pas normal, il y a un mécanisme de récupération qui va essayer de récupérer le info.json dans l’archive mais c’est pas idéal, (et il faut qu’il soit présent). Il y a probablement un bug qui reste à trouver…

Killed ça veut dire que le processus a été tué. Peut être à cause d’un problème de manque de mémoire ram/swap ? SI c’est le cas, si l’opération est tuée en cours de route, le backup sera pas exploitable je pense, ou à moitié et seulement en faisant une restauration totalement manuelle.

Tu peux vérifier en l’hypothése de la mémoire ram, en lançant l"opération de backup avec en parrallè l’utilisation de la commande htop ou top ou free -m pour voir si il arrive à cours de ram…

Mes sauvegardes ratées ne contiennent aucun de ces trois fichiers.

Ma RAM n’est pas en cause, elle ne sature pas lors du plantage.

D’autres idées ? Peut-être que le problème survient au moment de la génération du .json ?
J’avoue que là, à part une copie à la main des fichiers, je ne sais pas quoi faire.


Pour info : le problème de l’API qui lâche lors de la consultation par la webadmin vient du fait qu’elle ne sait pas quoi faire des sauvegardes ratées et ne parvient pas à les charger (une optimisation à faire à ce niveau ?).

Oui le cas n’est pas géré visiblement, il y a effectivement quelques choses à améliorer.

Pour le reste j’avoue ne pas trop savoir comment régler ce soucis, peut être que tu peux tenter des sauvegardes séparées de chaque app, peut être ainsi identifiears tu que c’est tel app ou tel partie du système qui déclenche le problème.
A partir de cette info on pourrait essayer de cherche plus finalement ce qui déclenche la fin du processus car killed c’est pas une erreur classique…

Quelqu’un a des idées de ce qui peut killer un processus en dehors du manque de ram et d’une action d’un utilisateur ?

Ok par habitude j’ai été regarder si ce n’était pas nginx qui tuait de lui-même la sauvegarde un peu longue de mon install (je l’ai mise sur 900 puis ai redémarré nginx) mais ça n’a pas changé grand chose, certaines sauvegardes ont foiré, d’autres non.
L’une d’elles m’a signalé l’absence du paquet gpg (vois pas le rapport mais admettons : il sert peut-être à stocker en chiffré des identités/mdp ?).
Je l’ai donc installé puis ai relancé le serveur et là… tout fonctionne !

Donc je ne saurais dire exactement ce qui posait problème, peut-être un peu tout ça, sachant que j’ai eu sur ma route toutes sortes de messages d’erreurs :

  • le “Killed” avant la fin des sauvegardes ;
  • des “l’API ne répond pas” en veux-tu en voilà ;
  • des “Impossible de récupérer la session” à tire-larigot ;
  • des “Yunohost a rencontré une erreur interne” à foison !^^

Bon courage à ceux qui sont dans la même galère !

C’est vraiment bizarre…
GPG est utilisé par moulinette (via la dépendance python-gnupg ). C’est peut être une app qui a besoin de gpg pour faire son backup ?

Est-ce que tu as installé une de ces apps ?

  • minetest
  • wisemapping
  • turtl
  • rainloop
  • yacy
  • osmw
  • onlyoffice
  • gitlab-runner
  • mailman3

Ces apps utilises gpg pour gérer les clé d’ajout d’un dépot tiers

J’avais installé Rainloop il y a un moment, désinstallé depuis. Il ne fait censément pas partie de mes sauvegardes.

Bon pour contourner ton soucis, je t’encourage à utiliser borg_ynh et borgserver_ynh (potentiellement sur la même machine même si c’est pas l’idéal).

Je suppose que le soucis que tu rencontres est lié à la taille du tar gz à générer.

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.