Impossible de restaurer des backups après des mount --bind

[Pataclop]

Mon serveur YunoHost

Matériel: VPS chez Infomaniak
Version de YunoHost: 11.2.11.3
J’ai accès à mon serveur : En SSH | Par la webadmin
Êtes-vous dans un contexte particulier ou avez-vous effectué des modifications particulières sur votre instance ? : oui
Si oui, expliquer:

Description du problème

Bonjour !

Le problème de restauration des backups a été rencontré plusieurs fois sur le forum mais les solutions proposées ne conviennent pas à mon soucis ou ne marche pas.

Contexte

J’ai migré il y a quelques mois Yunohost d’un VPS Gandi à un VPS Infomaniak. Ce que je n’avais pas percuté au début c’est qu’Infomaniak fournit une vingtaine de Go pour le système (Debian) et que les 250Go il fallait les monter.
Ce que j’ai fait. Mais Yunohost reste sur les 20Go et non sur le disque de 250Go !
En cherchant dans la très bonne documentation Yunohost j’ai découvert mount --bind.
En regardant la taille des différents dossiers j’ai donc fait un mount --bind de :

• /var/lib/mysql
• /var/www/hubzilla (très gros consommateur de Go)
• /yunohost.backup

Problème rencontré

Lorsque je fait une sauvegarde d’une appli, que je supprime l’appli et que je restaure l’appli, il n’y a pas de soucis. Tout fonctionne.

Par contre si :

• je télécharge le tar.gz
• je supprime l’appli et la sauvegarde
• j’envoie le tar.gz précedemment sauvegardé et un info.json sur ma machine avec scp
• je change les droits et owner/group avec chmod et chown pour avoir les même que les sauvegardes effectuées par Yunohost

En faisant restaure j’obtiens :

Exemple de changements de droits sur une archive re-uploadé dans Yunohost :

A aucun moment je ne touche à l’archive tar.gz que j’ai sauvegardé. J’ai fouillé les logs mais c’est assez obscur pour moi et je ne sais pas trop où regarder.
Je ne sais pas non plus si le problème est présent sans les mount --bind.

Merci pour votre attention et aide éventuelle !
Bonne journée !

[rodinux]

Est-ce que tu as des logs ?
Parfois j’ai des soucis avec mount --bind en réinstallant des applications montées sur le un disque externe avec mount --bind où je dois d’abord démonter avant le montage et le réinitialisé ensuite… Sinon parfois c’est quand un dossier de l’application est encore présent que ça coince…

D’ailleurs expliqué ici

Use of bind-mount insteed of symbolic link

Le seul problème que je vois avec la méthode du bind, outre les ratés entre un dossier monté ou pas monté (dans les deux cas il existe, parfois on oublie…), c’est que certaines mises à jour d’application échouées peuvent ne pas se restaurer automatiquement, car le répertoire cible du “bind” ne peut pas être supprimé, donc la suppression de la mise à jour erroné ne se complète pas, donc pas de restoration possible. Et dans ces cas, je n’ai pas trouvé de méthode pour restaurer sans supprimer temp…

[Pataclop]

Quels logs dois-je regarder ? Je n’ai pas vu de logs en rapport avec un nom explicite à la sauvegarde, je ne sais pas simplement pas où regarder.
Qu’entends-tu par démonter ? Le disque ou le bind ?
Il faut peut être que je cherche des dossiers d’application qui n’auraient pas été supprimés et les supprimés pour voir si ça change quelque chose.

Trouver un log qui précise l’erreur 500 permettrait d’y voir plus clair c’est sur ! Je fouillerai ce soir les logs.

[rodinux]

@Pataclop

Il faut peut être que je cherche des dossiers d’application qui n’auraient pas été supprimés et les supprimés pour voir si ça change quelque chose.

Ou juste les renommer pour garder éventuellement une trace ??

[Pataclop]

Alors j’avais bien un dossier hubzilla dans /var/www. Pour pouvoir le supprimer j’ai du faire un umount /var/www/hubzilla d’abord.
Mais la restauration du backup ne marche pas mieux.

J’ai ensuite tenté un umount /mnt/donnees et redémarrer le serveur. Le fstab étant bien compléter pour prendre en compte les mount --bind tout redémarre bien. Mais ça ne change rien pour la sauvegarde.

Du coup j’ai épluché les fichiers de logs et j’ai enfin trouvé des messages relatifs la restauration des backup dans /var/log/yunohost/yunohost-api.log.

Voici la partie qui pourrait aider (moi perso j’y comprend rien ) :

2024-05-03 19:24:56,479 DEBUG    moulinette.actionsmap process - loading python module yunohost.backup took 0.000s
2024-05-03 19:24:56,479 DEBUG    moulinette.actionsmap process - processing action [762.6]: yunohost.backup.restore with args={'name': '20240416-hubzilla', 'system': None, 'apps': ['hubzilla'], 'force': True}
2024-05-03 19:24:56,482 INFO     yunohost.backup (unknown function) - [762.6] Préparation de l'archive pour restauration…
2024-05-03 19:24:56,484 DEBUG    yunohost.backup (unknown function) - [762.6] temporary restore directory '/home/yunohost.backup/tmp/20240416-hubzilla' already exists
2024-05-03 19:24:56,489 DEBUG    yunohost.backup (unknown function) - [762.6] Delete dir: /home/yunohost.backup/tmp/20240416-hubzilla
2024-05-03 19:24:56,490 DEBUG    yunohost.backup (unknown function) - [762.6] Extraction des fichiers nécessaires depuis l'archive…
2024-05-03 19:24:56,493 DEBUG    yunohost.backup (unknown function) - [762.6] cannot open backup archive '/home/yunohost.backup/archives/20240416-hubzilla.tar.gz'
Traceback (most recent call last):
  File "/usr/lib/python3.9/tarfile.py", line 1682, in gzopen
    t = cls.taropen(name, mode, fileobj, **kwargs)
  File "/usr/lib/python3.9/tarfile.py", line 1659, in taropen
    return cls(name, mode, fileobj, **kwargs)
  File "/usr/lib/python3.9/tarfile.py", line 1522, in __init__
    self.firstmember = self.next()
  File "/usr/lib/python3.9/tarfile.py", line 2327, in next
    tarinfo = self.tarinfo.fromtarfile(self)
  File "/usr/lib/python3.9/tarfile.py", line 1112, in fromtarfile
    buf = tarfile.fileobj.read(BLOCKSIZE)
  File "/usr/lib/python3.9/gzip.py", line 300, in read
    return self._buffer.read(size)
  File "/usr/lib/python3.9/_compression.py", line 68, in readinto
    data = self.read(len(byte_view))
  File "/usr/lib/python3.9/gzip.py", line 487, in read
    if not self._read_gzip_header():
  File "/usr/lib/python3.9/gzip.py", line 435, in _read_gzip_header
    raise BadGzipFile('Not a gzipped file (%r)' % magic)
gzip.BadGzipFile: Not a gzipped file (b'./')

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/yunohost/backup.py", line 2003, in mount
    tar = tarfile.open(
  File "/usr/lib/python3.9/tarfile.py", line 1629, in open
    return func(name, filemode, fileobj, **kwargs)
  File "/usr/lib/python3.9/tarfile.py", line 1686, in gzopen
    raise ReadError("not a gzip file")
tarfile.ReadError: not a gzip file

[jarod5001]

@Pataclop

cannot open backup archive '/home/yunohost.backup/archives/20240416-hubzilla.tar.gz'

Que donne
ls -lh /home/yunohost.backup/archives/20240416-hubzilla.tar.gz

Est ce que le fichier est “gros”?

Et

gunzip -t /home/yunohost.backup/archives/20240416-hubzilla.tar.gz

Pour tester l’intégrité du fichier.

Sinon pour les montages, il faut démonter tout et vérifier si les dossiers où le disque externe doit être monté sont bien vides. Sinon il faut déplacer leurs contenus puis remonter tout et revérifier…

[Pataclop]

Le fichier fait 6Go, mais d’autres sauvegardes de moins d’1G0 ayant le même problème.

La première commande donne :

pataclop@bierzilla:~$ ls -lh /home/yunohost.backup/archives/20240416-hubzilla.tar.gz
-rw-rw-rw- 1 root root 6.5G May  1 22:04 /home/yunohost.backup/archives/20240416-hubzilla.tar.gz

La deuxième :

pataclop@bierzilla:~$ gunzip -t /home/yunohost.backup/archives/20240416-hubzilla.tar.gz 
gzip: /home/yunohost.backup/archives/20240416-hubzilla.tar.gz: not in gzip format
pataclop@bierzilla:~$ file /home/yunohost.backup/archives/20240416-hubzilla.tar.gz 
/home/yunohost.backup/archives/20240416-hubzilla.tar.gz: POSIX tar archive

Mmmh, le fait de télécharger l’archive puis de la recopier via scp peut-il altérer les archives ?

Edit :
Du coup j’ai tenté une décompression-recompression

pataclop@bierzilla:~$ tar -xvf /home/yunohost.backup/archives/20240416-132802.tar.gz -C /home/yunohost.backup/archives/20240416-132802/
pataclop@bierzilla:~$ tar -cvzf /home/yunohost.backup/archives/20240416-132802.tar.gz /home/yunohost.backup/archives/20240416-132802
pataclop@bierzilla:~$ file /home/yunohost.backup/archives/20240416-132802.tar.gz 
/home/yunohost.backup/archives/20240416-132802.tar.gz: gzip compressed data, from Unix, original size modulo 2^32 2660614144

j’ai un nouveau message relatif au json.

Et le log :

2024-05-04 21:19:21,282 DEBUG    moulinette.actionsmap process - loading python module yunohost.backup took 0.000s
2024-05-04 21:19:21,282 DEBUG    moulinette.actionsmap process - processing action [762.45]: yunohost.backup.restore with args={'name': '20240416-132802',>
2024-05-04 21:19:21,282 INFO     yunohost.backup (unknown function) - [762.45] Préparation de l'archive pour restauration…
2024-05-04 21:19:21,283 DEBUG    yunohost.backup (unknown function) - [762.45] temporary restore directory '/home/yunohost.backup/tmp/20240416-132802' alr>
2024-05-04 21:19:21,287 DEBUG    yunohost.backup (unknown function) - [762.45] Delete dir: /home/yunohost.backup/tmp/20240416-132802
2024-05-04 21:19:21,287 DEBUG    yunohost.backup (unknown function) - [762.45] Extraction des fichiers nécessaires depuis l'archive…
2024-05-04 21:20:04,960 DEBUG    yunohost.backup (unknown function) - [762.45] unable to retrieve 'info.json' inside the archive
NoneType: None

[jarod5001]

Le log dit qu’il n’y a pas de fichier json à l’intérieur de l’archive. Là, je suis dans l’impossibilité d’aider. Je n’ai pas encore décortiqué de fichier de sauvegarde pour comprendre son architecture (je devrais).
Si tu as une ancienne sauvegarde, tu peux voire le contenu du fichier json et en créer dans la sauvegarde qui coince.

[rodinux]

Exact, quand on télécharge une sauvegarde via la webadmin on a pas le .info.json, via scp il faut penser aussi à récupérer le fichier avec le même nom en .info.json

[Pataclop]

Je viens de résoudre mon problème (qui n’a finalement rien à voir avec le mount --bind).

Premier point : quand on télécharge depuis le webadmin une archive de sauvegarde le .tar.gz enregistré n’est PAS un .tar.gz mais un .tar.

En le renvoyant sur le serveur à l’emplacement /home/yunohost.backup/archives/ il faut le décompresser via un tar -xvf, puis copier le info.json et le mettre aussi à l’emplacement /home/yunohost.backup/archives/ avec le nom de l’archive devant le .info.json.

Jusqu’ici c’est ce que j’avais fait. L’erreur vient de la recompression en .tar.gz. En téléchargeant l’archive et en l’ouvrant je me suis rendu compte que l’archive contenait l’arborescence du serveur yunohost.

Avec un :

tar -cvzf /home/yunohost.backup/archives/nom-archive.tar.gz -C /home/yunohost.backup/archives/nom-archive .

Tout est rentré dans l’ordre.

Merci à vous pour les commandes Linux que je ne connaissais pas et qui m’ont permis de décortiquer tout ça !