Erreur sauvegarde Nextcloud - Impossible d'ajouter des fichiers

:fr: Modèle de message (français)

Matériel: Vieil ordinateur
Version de YunoHost: 3.6.5.3
J’ai accès à mon serveur : En SSH et Par la webadmin et En direct avec un clavier/écran
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : non

Description du problème

J’ai d’abord voulu faire une sauvegarde comme d’habitude, par la webadmin. J’ai obtenu le message d’erreur suivant.

ERROR Impossible d'ajouter des fichiers '/home/yunohost.app/nextcloud/data' (nommés dans l'archive : 'apps/nextcloud/backup/home/yunohost.app/nextcloud/data') à sauvegarder dans l'archive compressée '/home/yunohost.backup/archives/20191111-100153.tar.gz'

J’ai ensuite essayé, avec succès, de sauvegarder tout sauf Nextcloud.
Enfin, je me suis connecté à mon serveur en ssh et j’ai fait un sudo yunohost backup create --apps nextcloud --debug

dont voici la fin du log

5254 INFO [################++..] > Backing up data directory...
12713 INFO Création d'une archive de sauvegarde à partir des fichiers collectés …
12713 DEBUG Création de l’archive tar de la sauvegarde …
1679528 ERROR Impossible d'ajouter des fichiers '/home/yunohost.app/nextcloud/data' (nommés dans l'archive : 'apps/nextcloud/backup/home/yunohost.app/nextcloud/data') à sauvegarder dans l'archive compressée '/home/yunohost.backup/archives/20191111-100153.tar.gz'
Traceback (most recent call last):
  File "/usr/lib/moulinette/yunohost/backup.py", line 1814, in backup
    tar.add(path['source'], arcname=path['dest'])
  File "/usr/lib/python2.7/tarfile.py", line 2032, in add
    recursive, exclude, filter)
  File "/usr/lib/python2.7/tarfile.py", line 2032, in add
    recursive, exclude, filter)
  File "/usr/lib/python2.7/tarfile.py", line 2032, in add
    recursive, exclude, filter)
  File "/usr/lib/python2.7/tarfile.py", line 2032, in add
    recursive, exclude, filter)
  File "/usr/lib/python2.7/tarfile.py", line 2032, in add
    recursive, exclude, filter)
  File "/usr/lib/python2.7/tarfile.py", line 2032, in add
    recursive, exclude, filter)
  File "/usr/lib/python2.7/tarfile.py", line 2032, in add
    recursive, exclude, filter)
  File "/usr/lib/python2.7/tarfile.py", line 2025, in add
    self.addfile(tarinfo, f)
  File "/usr/lib/python2.7/tarfile.py", line 2054, in addfile
    copyfileobj(fileobj, self.fileobj, tarinfo.size)
  File "/usr/lib/python2.7/tarfile.py", line 274, in copyfileobj
    raise IOError("end of file reached")
IOError: end of file reached
1679788 DEBUG action [868.1] executed in 1679.268s
1679789 DEBUG lock has been released
1679789 ERROR Impossible de créer la sauvegarde

Est-ce que quelqu’un saurait comment résoudre mon problème afin de pouvoir de nouveau sauvegarder mon nextcloud?

Merci par avance,

Thatoo

Salut à toi,
As-tu vérifié la place qu’il restait sur le disque/partition accueillant tes sauvegardes?

Bonjour,
Aucun soucis de ce côté là, il reste 125 GB pour une sauvegarde qui tournait jusqu’alors dans les 16-17 Go.
Le plus étrange c’est que ça semble s’arrêter toujours vers la fin, après 16Go.
Merci pour l’idée.

tu fais régulièrement le ménage en supprimant les plus vieilles sauvegardes? Parce que 16 Go la sauvegarde multiplié par 10, ça dépasse déjà les 125 Go

Non, le disque externe des sauvegardes fait 500Go, il reste 125Go de libre.
Je pourrais faire le ménage mais étant donné qu’il reste encore 125Go, je n’en voyais pas l’utilité.
Pour toi, c’est important de garder plus de marge encore que 125Go?

non effectivement, pas la peine de faire le ménage dans ce cas. Par contre, peut-être que lors du processus de sauvegarde, des fichiers soient stockés dans un répertoire temporaire sur une autre partition (genre /tmp) qui elle est un peu juste? Ne connaissant pas précisément le mécanisme de sauvegarde de yunohost, ce n’est qu’une hypothèse…

C’est ça. J’espère qu’un connaisseur passera dans le coin :smiley:

peux-tu copier coller la réponse à la commande mount

ok

    sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
    proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
    udev on /dev type devtmpfs (rw,nosuid,relatime,size=3946700k,nr_inodes=986675,mode=755)
    devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
    tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=791596k,mode=755)
    /dev/sda4 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
    securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
    tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
    tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
    tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
    cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
    pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
    efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
    cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
    cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
    cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
    cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
    cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
    cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
    cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
    cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
    cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
    systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=25,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=9524)
    mqueue on /dev/mqueue type mqueue (rw,relatime)
    debugfs on /sys/kernel/debug type debugfs (rw,relatime)
    hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
    /dev/sdb1 on /media/backup-yuno-lep type ext4 (rw,relatime,data=ordered)
    /dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
    tmpfs on /run/user/111 type tmpfs (rw,nosuid,nodev,relatime,size=791596k,mode=700,uid=111,gid=115)
    fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
    gvfsd-fuse on /run/user/111/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=111,group_id=115)
    tmpfs on /run/user/1007 type tmpfs (rw,nosuid,nodev,relatime,size=791596k,mode=700,uid=1007,gid=1007)

Je ne m’attendais pas à autant de disque monté…
Celui des sauvegarde est comme son nom l’indique un peu

/dev/sdb1 on /media/backup-yuno-lep

il me semble que les sauvegardes yunohost sont stockées dans /home/yunohost.backup/archives
ça veut dire, si je comprends bien, que tu déplaces ensuite tes sauvegardes vers /media/backup-yuno-lep, c’est bien ça?
Que donne la commande df -h ?

j’ai suivi le tuto d’ici https://yunohost.org/backup_fr pour réaliser les sauvegardes sur un HDD externe.
Il me semble en fait avoir créé un symlink de /home/yunohost.backup/archives vers /media/backup-yuno-lep mais c’était il y a plus d’un an donc je ne suis plus certain et comme yunohost.org est down, je ne peux pas vérifier…

df -h

Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
udev               3,8G       0  3,8G   0% /dev
tmpfs              774M     77M  697M  10% /run
/dev/sda4          256G     56G  188G  23% /
tmpfs              3,8G     84K  3,8G   1% /dev/shm
tmpfs              5,0M    4,0K  5,0M   1% /run/lock
tmpfs              3,8G       0  3,8G   0% /sys/fs/cgroup
/dev/sdb1          458G    332G  103G  77% /media/backup-yuno-lep
/dev/sda1          197M     16M  182M   8% /boot/efi
tmpfs              774M    4,0K  774M   1% /run/user/111
tmpfs              774M       0  774M   0% /run/user/1007

Ce qui me fait remarquer que la webadmin se trompe sur /dev/sdb1 de 22Go puisqu’elle m’annonce 125Go.

ok, pour vérifier que ton lien symbolique est toujours en place, place toi dans /home/yunohost.backup et fais un ls -l
Normalement, tu devrais voir ton lien symbolique archives > /media/backup-yuno-lep

oui, c’est bon

ls -l
total 4
lrwxrwxrwx 1 root  root   47 févr. 20  2019 archives -> /media/backup-yuno-lep/yunohost_backup_archives
drwxrwxr-x 2 admin root 4096 nov.  11 21:36 tmp

ok et as-tu vérifié s’il ne restait pas quelque chose dans le dossier tmp juste ne dessous?

$ cd /home/yunohost.backup/tmp
$ ls -l
total 0

rien…

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