rsync: write failed - Nu a mai rămas spațiu pe dispozitiv (28) în ciuda utilizării --inplace

Eu folosesc un scenariu pentru a face o copie de rezervă a unei distribuții Linux bazate pe Debian Stretch (NextCloudPi)

Metoda din scriptul care face backup folosește rsync.

backup()
{
  mntimg
  sincronizare
  rsync -aDH --partial --numeric-ids --delete --force --exclude "${MNTPATH}" --exclude '/dev' --exclude '/lost+found' --exclude '/media' - -exclude „/mnt” \
--exclude '/proc' --exclude '/run' --exclude '/sys' --exclude '/tmp' --exclude '/var/swap' --exclude '/etc/udev/rules.d/ 70-persistent-net.rules' \
--exclude '/var/lib/asterisk/astdb.sqlite3-journal' „${OPTIONS[@]}” / „${MNTPATH}/”
..
..
}

Când rulez scriptul, îl direc pentru a salva fișierul de rezervă .img pe o unitate USB-HDD atașată extern.

Această unitate este formatată EXT4 și este montată.. Pot să o răsfoiesc din exploratorul de fișiere Manjaro. Acesta este inscriptibil și are 2,3 TB spațiu liber.

Fișierul de rezervă va avea aproximativ 7,8 GB și am 22 GB spațiu liber pe rootfs (/) de pe cardul SD pe care îl fac backup.

De fiecare dată când rulez scriptul primesc o eroare rsync: scrierea eșuată pe... nu a mai rămas spațiu pe dispozitiv:

root@NEXTCLOUDPI:~# imagine-backup

Fișier imagine de creat? /media/4TB2/nextcloudpi18Nov2021v3.img

Dimensiunea sistemului de fișiere ROOT a fișierului imagine inițială (MB) [7526]? 7800

S-a adăugat spațiu pentru actualizări incrementale după micșorarea (MB) [0]? 

Creați /media/4TB2/nextcloudpi18Nov2021v3.img (da/n)? y

Se pornește backup complet (pentru backup incremental, rulați: /usr/local/bin/image-backup /media/4TB2/nextcloudpi18Nov2021v3.img)
rsync: scrierea eșuată pe „/tmp/img-backup-mnt/usr/src/linux-headers-4.14.93-Re4son-v7+/include/linux/suspend.h”: nu a mai rămas spațiu pe dispozitiv (28)
eroare rsync: eroare în fișierul IO (cod 11) la receiver.c(393) [receiver=3.1.2]

Nu se poate crea backup

root@NEXTCLOUDPI:~#

Încă întâmpin problema chiar dacă adaug opțiunea rsync --la loc deci asta nu mi-a rezolvat problema.

am facut o sudo du -sh /usr/src iar dimensiunea este de 150 MB.
Am 37.000 de fișiere și 12.000 de subfoldere în /usr/src, așa că mă gândeam că poate rămân fără inoduri, dar... am făcut o df -i iar utilizarea mea inode este de 14% în directorul rădăcină (/).

Problema pare să se întâmple aproape de sfârșit.. în acest caz este creat un fișier de 7,9 GiB. Am încercat să-l flash pe un card SD cu Etcher, dar nu a pornit.

Aveți idei despre ce nu merge bine aici? Am suficient spațiu pe rootfs pentru ca rsync să salveze lucrurile în /tmp dacă este necesar. Dar chiar și atunci când folosesc --la loc opțiune încă mai spune: rsync: scrierea eșuată pe „/tmp/... bla, bla... Nu a mai rămas spațiu pe dispozitiv (28)

Acum, pe baza comentariului tău recent, pot spune că cel mai probabil doar rulează inode. Când creați ext4 fs în mod implicit, mkfs alocă inoduri în funcție de dimensiunea partiției/imaginei. Deci, cu cât dimensiunea imaginii este mai mică, cu atât numărul de inoduri este mai mic. Editați acest script pentru a aloca mai multe inoduri, doar găsiți o linie în care face mkfs.ext4 și schimbați numărul de inode pe care îl alocă -i sau -N opțiune.

Găsiți această linie în imagine-backup:

    mkfs.ext4 -q -b 4096 „${LOOP}p2” > /dev/null

si schimba-l in:

    mkfs.ext4 -q -b 4096 -i 4096 „${LOOP}p2” > /dev/null

Acest lucru va face de 4 ori mai multe inoduri decât setările implicite.

Nu cred că ceva din serverul tău poate produce un asemenea efect. Deși fișierele rare ar putea fi și motivul, îl puteți atenua cu ajutorul -S opțiunea rsync care va gestiona corect fișierele rare. Dar intră în conflict cu --la loc opțiune.