rsync: ошибка записи — на устройстве не осталось места (28), несмотря на использование --inplace

я использую сценарий сделать резервную копию работающего дистрибутива Linux на базе Debian Stretch (NextCloudPi)

Метод в сценарии, выполняющий резервное копирование, использует rsync.

резервный()
{
  мнтимг
  синхронизировать
  rsync -aDH --partial --numeric-id --delete --force --exclude "${MNTPATH}" --exclude '/dev' --exclude '/lost+found' --exclude '/media' - -исключить '/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}/"
..
..
}

Когда я запускаю сценарий, я указываю ему сохранить файл резервной копии .img на внешнем подключенном USB-HDD-накопителе.

Этот диск отформатирован в формате EXT4 и смонтирован. Я могу просмотреть его из проводника файлов Manjaro. Это доступно для записи и имеет 2,3 ТБ свободного места.

Файл резервной копии будет иметь размер около 7,8 ГБ, и у меня есть 22 ГБ свободного места в корневой файловой системе (/) на SD-карте, резервную копию которой я делаю.

Каждый раз, когда я запускаю скрипт, я получаю сообщение об ошибке rsync: запись не удалась... на устройстве не осталось места:

root@NEXTCLOUDPI:~# резервная копия изображения

Файл изображения создать? /media/4TB2/nextcloudpi18Nov2021v3.img

Размер исходной файловой системы ROOT (МБ) [7526]? 7800

Добавлено место для добавочных обновлений после сжатия (МБ) [0]? 

Создать /media/4TB2/nextcloudpi18Nov2021v3.img (д/н)? у

Запуск полного резервного копирования (для инкрементного резервного копирования запустите: /usr/local/bin/image-backup /media/4TB2/nextcloudpi18Nov2021v3.img)
rsync: ошибка записи в "/tmp/img-backup-mnt/usr/src/linux-headers-4.14.93-Re4son-v7+/include/linux/suspend.h": на устройстве не осталось места (28)
ошибка rsync: ошибка в файловом вводе-выводе (код 11) в Receiver.c(393) [получатель=3.1.2]

Не удалось создать резервную копию

root@NEXTCLOUDPI:~#

У меня все еще возникает проблема, даже если я добавляю опцию rsync --на месте так что это не решило мою проблему.

я сделал sudo du -sh /usr/src и размер 150MB.
У меня есть 37 000 файлов и 12 000 подпапок в /usr/src, поэтому я подумал, что, возможно, у меня заканчиваются иноды, но... дф -я и мое использование inode составляет 14% в корневом каталоге (/).

Кажется, проблема возникла ближе к концу. В этом случае создается файл размером 7,9 ГБ. Я попытался прошить это на SD-карту с помощью Etcher, но это не загрузилось.

Любые идеи, что здесь происходит не так? У меня достаточно места в rootfs для rsync, чтобы сохранять вещи в /tmp, если это необходимо. Но даже когда я использую --на месте вариант, он все еще говорит: rsync: ошибка записи на "/tmp/... бла-бла... На устройстве не осталось места (28)

Теперь, основываясь на вашем недавнем комментарии, я могу сказать, что, скорее всего, это просто запуск наших инодов. Когда вы создаете ext4 fs, mkfs по умолчанию выделяет индексные дескрипторы в зависимости от размера раздела/образа. Таким образом, чем меньше размер изображения, тем меньше количество инодов. Вы редактируете этот скрипт, чтобы выделить больше инодов, просто найдите строку, где он делает mkfs.ext4, и измените количество выделяемых им инодов с помощью -я или же -Н вариант.

Найдите эту строку в резервной копии изображения:

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

и измените его на:

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

Это сделает в 4 раза больше инодов, чем настройки по умолчанию.

Я не думаю, что что-то в вашем сервере может дать такой эффект. Хотя разреженные файлы также могут быть причиной, вы можете смягчить это с помощью -С rsync, который будет правильно обрабатывать разреженные файлы. Но это противоречит --на месте вариант.