Вопрос или проблема
Я использую rsync для резервного копирования своего домашнего каталога:
time rsync -iia --append-verify --progress --exclude cloudDrive/ /home /usr/local/share/applications /etc/yum.repos.d /home/user/cloudDrive/Backups/"2024-09-27T00:06:05+02:00" 1> /tmp/out.log 2>/tmp/err.log
Мне пришлось приостановить его, потому что он занимал слишком много времени:
real 1305m43.016s
user 0m1.691s
sys 0m5.394s
du
показывает, что размер домашнего каталога в источнике составляет 64 Г, в то время как в резервной копии он составляет 23 Г. Однако это ожидаемо, потому что я отменил резервное копирование, поэтому оно не закончилось.
При более тщательном обследовании видно, что для одной и той же директории существует большая разница в размере между резервной копией и исходным каталогом:
du -h --max-depth=1 $HOME/.android/avd
5.1G .android/avd/Medium_Phone_API_35.avd
5.7G .android/avd/Pixel_Fold_API_VanillaIceCream.avd
3.6G .android/avd/Pixel_8_Pro_API_32.avd
15G .android/avd
$ du -h --max-depth=1 $HOME/cloudDrive/Backups/2024-09-27T00\:06\:05+02\:00/home/user/.android/avd/ 2> /tmp/throwaway2.txt
5.6G /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Medium_Phone_API_35.avd
5.9G /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Pixel_Fold_API_VanillaIceCream.avd
9.6G /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Pixel_8_Pro_API_32.avd
21G /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/
Почему резервное копирование rsync на 6 ГБ больше, чем оригинальная директория?
Разница обусловлена различиями в том, как ls
и ranger
определяют размер файлов и директорий, по сравнению с тем, как это делает по умолчанию du
. Клавиатурная комбинация du
в ranger
использует du shell -p du --max-depth=1 -h --apparent-size
, тогда как du -sh
не использует --apparent-size
.
Из man du
:
–apparent-size
выводит явные размеры вместо использования устройства; хотя явный размер обычно меньше, он может быть больше из-за пустот в (“рыхлых”) файлах, внутренней фрагментации, косвенных блоков и подобного
Для /home/user/.android/avd
и /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/
:
-
ranger (du shell -p du –max-depth=1 -h –apparent-size)
- источник 21 G - назначение 21 G
-
ls -al
- источник 12 байт - назначение 22 байта
-
du -sh
- источник 15G - назначение 21G
Разница объясняется различием в использовании дискового пространства на источнике (HDD) и облачном хранилище. Явный размер — это фактический размер файла или директории, поэтому он всегда будет одинаковым на любой файловой системе. Однако использование дискового пространства файла или директории зависит от файловой системы. Аналогия такова: явный размер — это как несжатый файл или директория, тогда как использование дискового пространства — это как сжатый файл или директория, которые меньше. Хотя содержимое (размер) в байтах источника и назначения одинаково, объем занимаемого пространства меньше на локальном HDD по сравнению с пространством, которое оно занимает на диске облачного сервера.
Чтобы избежать этой разницы, следует использовать явный размер для отображения использования файлового пространства при сравнении файлов источника и назначения из rsync.
Опция -s команды ls
добавляет дополнительный столбец слева, показывающий фактический размер на диске для файлов1. Размер файла или директории на диске, показываемый ls -s
, отличается не только от du --sh
и ranger
(du –apparent size), но и размер файлов или директорий на диске ls -s
источника и назначения отличаются друг от друга, что ожидаемо по причинам, указанным выше.
ПРИМЕЧАНИЕ: Размер файла и директории на диске, показываемый ls -s
, отличается от du --apparent-size
, потому что ls -s
показывает только размер верхнего уровня содержимого директории, в то время как du является рекурсивным и показывает размер всех директорий и их поддиректорий. Размер файла и директории на диске ls -s
источника и назначения различен, вероятно, потому что источники и назначения относятся к разным файловым системам и, следовательно, имеют свои собственные способы хранения файлов на диске.
источник
$ du -h --max-depth=2 .android/avd
44K .android/avd/Medium_Phone_API_35.avd/modem_simulator
12K .android/avd/Medium_Phone_API_35.avd/tmpAdbCmds
1.9G .android/avd/Medium_Phone_API_35.avd/snapshots
64K .android/avd/Medium_Phone_API_35.avd/data
5.1G .android/avd/Medium_Phone_API_35.avd
44K .android/avd/Pixel_Fold_API_VanillaIceCream.avd/modem_simulator
0 .android/avd/Pixel_Fold_API_VanillaIceCream.avd/tmpAdbCmds
3.0G .android/avd/Pixel_Fold_API_VanillaIceCream.avd/snapshots
0 .android/avd/Pixel_Fold_API_VanillaIceCream.avd/data
5.7G .android/avd/Pixel_Fold_API_VanillaIceCream.avd
44K .android/avd/Pixel_8_Pro_API_32.avd/modem_simulator
0 .android/avd/Pixel_8_Pro_API_32.avd/tmpAdbCmds
64K .android/avd/Pixel_8_Pro_API_32.avd/data
3.6G .android/avd/Pixel_8_Pro_API_32.avd
15G .android/avd
user@fedora:~$ du -h --apparent-size --max-depth=2 .android/avd
31K .android/avd/Medium_Phone_API_35.avd/modem_simulator
42 .android/avd/Medium_Phone_API_35.avd/tmpAdbCmds
1.9G .android/avd/Medium_Phone_API_35.avd/snapshots
64K .android/avd/Medium_Phone_API_35.avd/data
5.6G .android/avd/Medium_Phone_API_35.avd
31K .android/avd/Pixel_Fold_API_VanillaIceCream.avd/modem_simulator
0 .android/avd/Pixel_Fold_API_VanillaIceCream.avd/tmpAdbCmds
3.0G .android/avd/Pixel_Fold_API_VanillaIceCream.avd/snapshots
0 .android/avd/Pixel_Fold_API_VanillaIceCream.avd/data
5.9G .android/avd/Pixel_Fold_API_VanillaIceCream.avd
32K .android/avd/Pixel_8_Pro_API_32.avd/modem_simulator
0 .android/avd/Pixel_8_Pro_API_32.avd/tmpAdbCmds
64K .android/avd/Pixel_8_Pro_API_32.avd/data
9.6G .android/avd/Pixel_8_Pro_API_32.avd
21G .android/avd
назначение
user@fedora:~$ du -h --max-depth=2 /home/user/cloudDrive/Backups/2024-09-27T00\:06\:05+02\:00/home/user/.android/avd/ 2> /tmp/throwaway2.txt
48K /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Medium_Phone_API_35.avd/modem_simulator
1.9G /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Medium_Phone_API_35.avd/snapshots
76K /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Medium_Phone_API_35.avd/data
5.5K /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Medium_Phone_API_35.avd/tmpAdbCmds
5.6G /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Medium_Phone_API_35.avd
12K /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Pixel_Fold_API_VanillaIceCream.avd/data
3.0G /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Pixel_Fold_API_VanillaIceCream.avd/snapshots
48K /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Pixel_Fold_API_VanillaIceCream.avd/modem_simulator
4.0K /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Pixel_Fold_API_VanillaIceCream.avd/tmpAdbCmds
5.9G /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Pixel_Fold_API_VanillaIceCream.avd
48K /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Pixel_8_Pro_API_32.avd/modem_simulator
4.0K /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Pixel_8_Pro_API_32.avd/tmpAdbCmds
76K /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Pixel_8_Pro_API_32.avd/data
9.6G /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Pixel_8_Pro_API_32.avd
21G /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/
$ du -h --apparent-size --max-depth=2 /home/user/cloudDrive/Backups/2024-09-27T00\:06\:05+02\:00/home/user/.android/avd/ 2> /tmp/throwaway2.txt
31K /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Medium_Phone_API_35.avd/modem_simulator
1.9G /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Medium_Phone_API_35.avd/snapshots
64K /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Medium_Phone_API_35.avd/data
42 /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Medium_Phone_API_35.avd/tmpAdbCmds
5.6G /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Medium_Phone_API_35.avd
0 /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Pixel_Fold_API_VanillaIceCream.avd/data
3.0G /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Pixel_Fold_API_VanillaIceCream.avd/snapshots
31K /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Pixel_Fold_API_VanillaIceCream.avd/modem_simulator
0 /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Pixel_Fold_API_VanillaIceCream.avd/tmpAdbCmds
5.9G /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Pixel_Fold_API_VanillaIceCream.avd
32K /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Pixel_8_Pro_API_32.avd/modem_simulator
0 /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Pixel_8_Pro_API_32.avd/tmpAdbCmds
64K /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Pixel_8_Pro_API_32.avd/data
9.6G /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Pixel_8_Pro_API_32.avd
21G /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/
Несоответствия
источник
user@fedora:~$ du -h --max-depth=2 .android/avd
44K .android/avd/Medium_Phone_API_35.avd/modem_simulator
12K .android/avd/Medium_Phone_API_35.avd/tmpAdbCmds
1.9G .android/avd/Medium_Phone_API_35.avd/snapshots
64K .android/avd/Medium_Phone_API_35.avd/data
5.1G .android/avd/Medium_Phone_API_35.avd
44K .android/avd/Pixel_Fold_API_VanillaIceCream.avd/modem_simulator
0 .android/avd/Pixel_Fold_API_VanillaIceCream.avd/tmpAdbCmds
3.0G .android/avd/Pixel_Fold_API_VanillaIceCream.avd/snapshots
0 .android/avd/Pixel_Fold_API_VanillaIceCream.avd/data
5.7G .android/avd/Pixel_Fold_API_VanillaIceCream.avd
44K .android/avd/Pixel_8_Pro_API_32.avd/modem_simulator
0 .android/avd/Pixel_8_Pro_API_32.avd/tmpAdbCmds
64K .android/avd/Pixel_8_Pro_API_32.avd/data
3.6G .android/avd/Pixel_8_Pro_API_32.avd
15G .android/avd
$ ls -asl .android/avd/
total 12
0 drwxr-xr-x. 1 user user 316 Sep 1 18:54 .
0 drwxr-xr-x. 1 user user 380 Sep 4 01:07 ..
0 drwxr-xr-x. 1 user user 710 Sep 2 17:33 Medium_Phone_API_35.avd
4 -rw-r--r--. 1 user user 134 Sep 1 00:41 Medium_Phone_API_35.ini
0 drwxr-xr-x. 1 user user 672 Sep 4 01:11 Pixel_8_Pro_API_32.avd
4 -rw-r--r--. 1 user user 132 Sep 1 18:54 Pixel_8_Pro_API_32.ini
0 drwxr-xr-x. 1 user user 738 Sep 2 03:28 Pixel_Fold_API_VanillaIceCream.avd
4 -rw-r--r--. 1 user user 169 Sep 1 01:03 Pixel_Fold_API_VanillaIceCream.ini
назначение
user@fedora:~$ du -h --max-depth=2 /home/user/cloudDrive/Backups/2024-09-27T00\:06\:05+02\:00/home/user/.android/avd/ 2> /tmp/throwaway2.txt
48K /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Medium_Phone_API_35.avd/modem_simulator
1.9G /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Medium_Phone_API_35.avd/snapshots
76K /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Medium_Phone_API_35.avd/data
5.5K /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Medium_Phone_API_35.avd/tmpAdbCmds
5.6G /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Medium_Phone_API_35.avd
12K /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Pixel_Fold_API_VanillaIceCream.avd/data
3.0G /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Pixel_Fold_API_VanillaIceCream.avd/snapshots
48K /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Pixel_Fold_API_VanillaIceCream.avd/modem_simulator
4.0K /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Pixel_Fold_API_VanillaIceCream.avd/tmpAdbCmds
5.9G /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Pixel_Fold_API_VanillaIceCream.avd
48K /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Pixel_8_Pro_API_32.avd/modem_simulator
4.0K /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Pixel_8_Pro_API_32.avd/tmpAdbCmds
76K /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Pixel_8_Pro_API_32.avd/data
9.6G /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Pixel_8_Pro_API_32.avd
21G /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/
$ ls -asl /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/
total 22
4 drwxr-xr-x. 1 user user 4096 Sep 1 18:54 .
4 drwxr-xr-x. 1 user user 4096 Sep 4 01:07 ..
4 drwxr-xr-x. 1 user user 4096 Sep 2 17:33 Medium_Phone_API_35.avd
1 -rw-r--r--. 1 user user 134 Sep 27 00:22 Medium_Phone_API_35.ini
4 drwxr-xr-x. 1 user user 4096 Sep 4 01:11 Pixel_8_Pro_API_32.avd
1 -rw-r--r--. 1 user user 132 Sep 27 00:22 Pixel_8_Pro_API_32.ini
4 drwxr-xr-x. 1 user user 4096 Sep 2 03:28 Pixel_Fold_API_VanillaIceCream.avd
1 -rw-r--r--. 1 user user 169 Sep 27 00:22 Pixel_Fold_API_VanillaIceCream.ini
источник
ranger /home/user/.android/avd/Pixel_8_Pro_API_32.avd (du shell -p du --max-depth=1 -h --apparent-size)
5.6G ./Medium_Phone_API_35.avd
5.9G ./Pixel_Fold_API_VanillaIceCream.avd
9.6G ./Pixel_8_Pro_API_32.avd
21G .
назначение
ranger /home/user/cloudDrive/Backups/2024-09-27T00:06:05+02:00/home/user/.android/avd/Pixel_8_Pro_API_32.avd (du shell -p du --max-depth=1 -h --apparent-size)
5.6G ./Medium_Phone_API_35.avd
5.9G ./Pixel_Fold_API_VanillaIceCream.avd
9.6G ./Pixel_8_Pro_API_32.avd
21G .
Ответ или решение
Проблема, с которой вы столкнулись, заключается в несоответствии размеров директорий между источником и резервной копией. Вы правильно заметили, что размер резервной копии (rsync
) больше, чем размер исходного каталога. Давайте разберемся, почему это происходит.
Причины несоответствия размеров
-
Спарс-файлы: Некоторые файлы могут быть так называемыми "спарс-файлами", которые при использовании занимают меньше места на диске, чем их фактический размер. Резервная копия может учитывать их полный размер, в то время как в исходной системе может отображаться менее значительный размер за счет отсутствующих заполнителей.
-
Файловые системы: Размер, который показывает команда
du
, зависит от файловой системы. Если исходные файлы и резервные копии хранятся на разных файловых системах (например, локальный HDD и облачное хранилище), это может привести к различиям в отведенном месте для одного и того же объема данных. Это вызвано принципами и методами, которые используют разные файловые системы для хранения и управления данными. -
Использование команды: Как вы уже заметили, вариант команды
du
может оказать влияние на результаты. Используя вариант с флагом--apparent-size
, вы получаете размер файлов без учета особенностей хранения, что в некоторых случаях может привести к неправильной интерпретации фактического использования пространства.
Как избежать несоответствий в будущих резервных копиях
-
Использование ключа
--apparent-size
: Для сравнения размеров файлов на разных системах рекомендуется использовать параметр--apparent-size
вdu
, чтобы избежать путаницы.du -h --apparent-size
-
Сравнение резервной копии и источника: Для более точного сравнения используйте одинаковые способы получения размеров для обеих сторон. Например, используйте одно и то же
du
с одинаковыми флагами и без их смешивания. -
Проверка альтернативных утилит: Существуют утилиты, такие как
ncdu
, которые могут помочь визуализировать использование пространства на более детальном уровне и возможно выявить лишние файлы или неожиданное поведение. -
Анализ содержимого: Часто полезно провести анализ содержимого резервной копии и исходного каталога на наличие дубликатов, особенно если вы используете флаг
--append-verify
, который может привести к обновлению уже существующих файлов.
Вывод
Несоответствие в размерах резервной копии и исходного каталога является результатом различных факторов, включая различные файловые системы и особенности работы с дисками. Чтобы добиться более точных результатов и избежать таких проблем в будущем, рекомендуем использовать однотипные методы для анализа и сравнения объемов данных.