- Matériel: VM Debian(x64) / sur Atom 4cpu(1.92 GHz) 2 dédiés à la VM, 4 Go de ram 2 dédiés à la VM, dd: 2x 500g
- Version de YunoHost: 3.8.5.9 (stable).
- J’ai accès à mon serveur :** Par la webadmin aussi bien local que par le nom de domaine (y compris depuis extérieur donc) et par SSH (en local uniquement)
- Modification : j’ai changé la version du php utilisée par défaut, 7.3 au lieu de 7.0
Description du problème
- Il m’est impossible d’arriver à la fin d’une sauvegarde de Nextcloud avec ses données, que cela soit via l’interface web ou en ssh via un terminal.
Inévitablement, le processus semble bloqué-planté, perdant au bout d’une demi-heure environ la connexion au serveur (par le Web ou en SSH), et le gestionnaire de machine virtuelle témoigne de l’absence d’activité de la VM.
-
Après un redémarrage forcé, je retrouve divers fichiers dans le répertoire temporaire de sauvegarde et un fichier classique de sauvegarde mais sans son fichier json et surtout avec une taille légèrement réduite par rapport à la dernière sauvegarde (8giga au lieu de 10 attendus).
-
Pour pouvoir revenir à la section sauvegarde de yunohost depuis l’interface web, je suis contraint de supprimer le ficher de sauvegarde planté, à défaut je reste sur “pac-man” indéfiniment.
-
Les sauvegardes de YunoHost et de Nextcloud-sans-les-données(que le core) passent sans problème, j’ai par aillieurs à minima 450g de libre (les données nextcloud font environ 10g).
-
Je ne peux pas hélas publier les fichiers logs, je n’ai rien des actions effectuées aujourd’hui (les sauvegardes de yunohost et de nextcloud-core) ayant en revanche le message suivant:
Le fichier YAML de métadonnées associé aux logs est corrompu : ‘/var/log/yunohost/categories/operation/20201108-095401-app_install-archivist.yml’
Erreur : Fichier YAML corrompu en lecture depuis /var/log/yunohost/categories/operation/20201108-095401-app_install-archivist.yml (raison : expected ‘’, but found ‘’
in “”, line 1, column 13:
‘’a’’r’******’g’ …
^) -
Je précise enfin que la semaine dernière la sauvegarde avec semsiblement les mêmes données est passée comme une fleur et alors même que j’avais déjà changé la version de php utilisée par défaut (qui en revanche semble bloquer la mise à jour phpMyAdmin mais je ne pense pas que cela soit lié, le signalant au cas où).
Je n’ai fait aucune mise à jour entre la sauvegarde de la semaine dernière et aujourd’hui.
Y-a-t il une possibilité de baisser la priorité du processus de backup, m’interrogeant sur la possibilité d’un freeze (très) long en raison de la saturation de la “machine” vers la fin du processus? (Précisant néanmoins que le reste du temps la VM est plutot fluide et réactive).
Dans tous les cas, merci de votre aide 
Edit: j’ai supprimé tous les fichiers relatifs à archivist dans les logs pour ne plus avoir le message d’erreur. Néanmoins, il n’y a toujours aucun événement mentionné dans le journal pour aujourd’hui.
Edit-bis: ajout du diagnostic:
=================================
Système de base (basesystem)
=================================
[INFO] L’architecture du serveur est oracle amd64
[INFO] Le serveur utilise le noyau Linux 4.9.0-14-amd64
[INFO] Le serveur utilise Debian 9.13
[INFO] Le serveur utilise YunoHost 3.8.5.9 (stable)
- yunohost version : 3.8.5.9 (stable)
- yunohost-admin version : 3.8.3.5 (stable)
- moulinette version : 3.8.1.3 (stable)
- ssowat version : 3.8.0.3 (stable)
=================================
Connectivité Internet (ip)
=================================
[SUCCESS] La résolution de nom de domaine fonctionne !
[SUCCESS] Le serveur est connecté à Internet en IPv4 !
- IP globale : xx.xx.xx.xx
- IP locale : 192.168.0.100
[SUCCESS] Le serveur est connecté à Internet en IPv6 !
- IP globale : xx:xx:xx:xx:xx:xx
- IP locale : fe80::a00:27ff:fe31:79fe
=================================
Enregistrements DNS (dnsrecords)
=================================
[SUCCESS] Les enregistrements DNS sont correctement configurés pour le domaine maindomain.tld (catégorie basic)
[SUCCESS] Les enregistrements DNS sont correctement configurés pour le domaine maindomain.tld (catégorie mail)
[SUCCESS] Les enregistrements DNS sont correctement configurés pour le domaine maindomain.tld (catégorie xmpp)
[SUCCESS] Les enregistrements DNS sont correctement configurés pour le domaine maindomain.tld (catégorie extra)
=================================
Exposition des ports (ports)
=================================
=================================
Web (web)
=================================
=================================
E-mail (mail)
=================================
[SUCCESS] Le serveur de messagerie SMTP peut envoyer des e-mails (le port sortant 25 n'est pas bloqué).
[ERROR] Le DNS inverse n'est pas correctement configuré en IPv4. Certains e-mails seront peut-être refusés ou considérés comme des spam.
- DNS inverse actuel : XXX-XXX-XXX-XXX.subs.proxad.net
Valeur attendue : maindomain.tld
- Vous devez d’abord essayer de configurer le DNS inverse avec maindomain.tld dans votre interface de routeur Internet ou votre interface d’hébergement. (Certains hébergeurs peuvent vous demander de leur envoyer un ticket de support pour cela).
- Certains fournisseurs ne vous laisseront pas configurer votre DNS inversé (ou leur fonctionnalité pourrait être cassée …). Si vous rencontrez des problèmes à cause de cela, envisagez les solutions suivantes :
- Certains FAI fournissent l’alternative de à l’aide d’un relais de serveur de messagerie bien que cela implique que le relais pourra espionner votre trafic de messagerie.
- Une alternative respectueuse de la vie privée consiste à utiliser un VPN *avec une IP publique dédiée* pour contourner ce type de limites. Voir https://yunohost.org/#/vpn_advantage
- Enfin, il est également possible de changer de fournisseur
[ERROR] Votre IP ou domaine xx.xx.xx.xx est sur liste noire sur SPFBL.net RBL
- La raison de la liste noire est : "https://matrix.spfbl.net/xx.xx.xx.xx"
- Après avoir identifié la raison pour laquelle vous êtes répertorié et l'avoir corrigé, n’hésitez pas à demander le retrait de votre IP ou domaine sur https://spfbl.net/en/dnsbl/
[SUCCESS] 0 e-mails en attente dans les files d'attente de messagerie
=================================
État des services (services)
=================================
[SUCCESS] Le service avahi-daemon est en cours de fonctionnement !
[SUCCESS] Le service dnsmasq est en cours de fonctionnement !
[SUCCESS] Le service dovecot est en cours de fonctionnement !
[SUCCESS] Le service fail2ban est en cours de fonctionnement !
[SUCCESS] Le service metronome est en cours de fonctionnement !
[SUCCESS] Le service mysql est en cours de fonctionnement !
[SUCCESS] Le service nginx est en cours de fonctionnement !
[SUCCESS] Le service nslcd est en cours de fonctionnement !
[SUCCESS] Le service php7.0-fpm est en cours de fonctionnement !
[SUCCESS] Le service php7.3-fpm est en cours de fonctionnement !
[SUCCESS] Le service postfix est en cours de fonctionnement !
[SUCCESS] Le service redis-server est en cours de fonctionnement !
[SUCCESS] Le service rspamd est en cours de fonctionnement !
[SUCCESS] Le service slapd est en cours de fonctionnement !
[SUCCESS] Le service ssh est en cours de fonctionnement !
[SUCCESS] Le service yunohost-api est en cours de fonctionnement !
[SUCCESS] Le service yunohost-firewall est en cours de fonctionnement !
=================================
Ressources système (systemresources)
=================================
[SUCCESS] Le système dispose encore de 1.4 GiB (70%) de RAM sur 2.0 GiB.
[SUCCESS] Le système dispose de 976 MiB de swap !
- Merci d'être prudent et conscient que si vous hébergez une partition SWAP sur une carte SD ou un disque SSD, cela risque de réduire drastiquement l’espérance de vie du périphérique.
[SUCCESS] L’espace de stockage / (sur le périphérique /dev/mapper/system-root) a encore 372 GiB (89%) espace restant (sur 418 GiB) !
[SUCCESS] L’espace de stockage /boot (sur le périphérique /dev/sda1) a encore 143 MiB (66%) espace restant (sur 215 MiB) !
=================================
Configurations système (regenconf)
=================================
[WARNING] Le fichier de configuration /etc/ssh/sshd_config semble avoir été modifié manuellement.
- C’est probablement OK si vous savez ce que vous faites ! YunoHost cessera de mettre à jour ce fichier automatiquement ... Mais attention, les mises à jour de YunoHost pourraient contenir d’importantes modifications recommandées. Si vous le souhaitez, vous pouvez inspecter les différences avec 'yunohost tools regen-conf ssh --dry-run --with-diff' et forcer la réinitialisation à la configuration recommandée avec 'yunohost tools regen-conf ssh --force'