Ik gebruik een script om een ​​back-up te maken van een draaiende op Debian Stretch gebaseerde Linux Distro (NextCloudPi)

De methode in het script die de back-up maakt, gebruikt rsync.

backup()
{
  mntimg
  sync
  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}/"
..
..
}

Wanneer ik het script uitvoer, wijs ik het erop om het back-up .img-bestand op te slaan op een extern aangesloten USB-HDD-station.

Deze schijf is EXT4-geformatteerd en is gekoppeld. Ik kan er doorheen bladeren vanuit de Manjaro-bestandsverkenner. Deze is beschrijfbaar en heeft 2,3 TB vrije ruimte.

Het back-upbestand zal ongeveer 7,8 GB zijn en ik heb 22 GB vrije ruimte op de rootfs (/) op de SD-kaart waarvan ik een back-up maak.

Elke keer dat ik het script uitvoer, krijg ik een foutmelding rsync: write failed on.. no space left on device:

[email protected]:~# image-backup

Image file to create? /media/4TB2/nextcloudpi18Nov2021v3.img

Initial image file ROOT filesystem size (MB) [7526]? 7800

Added space for incremental updates after shrinking (MB) [0]? 

Create /media/4TB2/nextcloudpi18Nov2021v3.img (y/n)? y

Starting full backup (for incremental backups, run: /usr/local/bin/image-backup /media/4TB2/nextcloudpi18Nov2021v3.img)
rsync: write failed on "/tmp/img-backup-mnt/usr/src/linux-headers-4.14.93-Re4son-v7+/include/linux/suspend.h": No space left on device (28)
rsync error: error in file IO (code 11) at receiver.c(393) [receiver=3.1.2]

Unable to create backup

[email protected]:~#

Ik krijg het probleem nog steeds, zelfs als ik de rsync-optie toevoeg, --inplacedus dat loste mijn probleem niet op.

Ik deed een sudo du -sh /usr/srcen de grootte is 150 MB.
Ik heb 37.000 bestanden en 12.000 submappen in /usr/src, dus ik dacht dat ik misschien bijna geen inodes meer had, maar... Ik deed een df -ien mijn inodegebruik is 14% in de hoofdmap (/).

Het probleem lijkt bijna op het einde te gebeuren.. in dit geval wordt een 7.9GiB-bestand gemaakt. Ik heb geprobeerd dat naar een SD-kaart te flashen met etcher, maar het startte niet op.

Enig idee wat hier fout gaat? Ik heb genoeg ruimte op de rootfs voor rsync om dingen op te slaan in /tmp als dat nodig is. Maar zelfs als ik de --inplaceoptie gebruik , staat er nog steeds:rsync: write failed on "/tmp/... blah blah... No space left on device (28)

answer

Nu, op basis van uw recente opmerking, kan ik zeggen dat het hoogstwaarschijnlijk gewoon onze inodes bevat. Als je ext4 fs aanmaakt, wijst mkfs standaard inodes toe op basis van partitie/afbeeldingsgrootte. Dus hoe kleiner de afbeelding, hoe minder het aantal inodes. Je bewerkt dit script om meer inodes toe te wijzen, zoek gewoon een regel waar het mkfs.ext4 doet en verander het aantal inodes waarmee het wordt toegewezen -iof -Noptie.

Zoek deze regel in image-backup:

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

en verander het in:

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

Dit maakt 4x meer inodes dan de standaardinstellingen.

Ik denk niet dat iets op je server zo'n effect kan hebben. Hoewel schaarse bestanden ook de reden kunnen zijn, kunt u dit verminderen met de -Srsync-optie die schaarse bestanden correct afhandelt. Maar het is in strijd met de --inplaceoptie.