У меня есть несколько компьютеров с файловой системой ext4, которые я хочу сделать резервную копию на файловом сервере, который также является ext4. Проблема в том, что при использовании rsync есть некоторые расхождения в размерах файлов, и я заметил, что это связано с разреженными файлами.
Проблема в том, что я хочу создать точную копию rsync файловой системы, используя rsync по сети, чтобы сохранять еженедельные резервные копии, на случай, если мне нужно восстановить, и восстановленные данные должны быть того же размера, что и на ПК.
Создание тестовых файлов, 1 разреженный и 1 нет:
mkdir testing
dd if=/dev/zero of=testing/sparse-file.img bs=1 count=0 seek=5M
cp testing/sparse-file.img testing/non-sparse-file.img --sparse=never
Rsync с разреженной опцией и без нее:
mkdir testa testb
rsync testing/* testa
rsync --sparse testing/* testb
Полученные результаты:
du -h
5.1M ./testing
4.0K ./testb
11M ./testa
16M .
тестирование имеет 1 файл размером 5 МБ и один разреженный файл, testb если оба файла стали разреженными, Testa если оба файла стали не разреженными
Но как заставить rsync поддерживать разреженность файлов? Таким образом, файловая система будет иметь точно такой же размер в восстановленной системе.
Я хочу быть уверенным, что при восстановлении моей системы я точно знаю, насколько велики будут восстановленные данные, с опцией sparse моя восстановленная система будет более разреженной, чем была изначально (я думаю, это приемлемо), и с опцией non-sparse это приведет к непредсказуемому увеличению восстановленной системы.
Я думаю, вы понимаете, что проблема существует, когда ее нет.
Если у вас много разреженных файлов, было бы очевидно, что восстановление потеряет разреженность и заставит ваш диск заполниться.
Но если исходный файл не был разреженным, а восстановленный файл разрежен, проблем нет. Блоки, отсутствующие в разреженном файле, при чтении возвращают ноль. Файлы, которые изначально не были резервными, содержат достаточно большие блоки нулей, которые являются разреженными блоками в копии. Для любого приложения, читающего файл, результат будет одинаковым. За исключением того, что чтение разреженных блоков происходит быстрее, потому что память просто заполняется нулями, а не читается с дисков. Таким образом, вы можете рассматривать разреженные файлы как для оптимизации дискового пространства, так и для оптимизации времени доступа. Вы даже можете регулярно проверять свои файлы и пытаться преобразовать их в разреженные файлы, если считаете, что это того стоит.
Долгое время не было возможности определить, размещен ли блок файла на диске или нет. В последнее время в некоторых файловых системах Linux появилась поддержка поиска разреженных блоков в файле. Если ваши приложения действительно зависят от информации о разреженности, вы можете извлечь ее в другой файл, включить его в резервную копию и восстановить эту разреженность позже.
Но большинство приложений, которые создают разреженные файлы, не заботятся о содержимом разреженных блоков. Блоки никогда не писались, иначе они не были бы редкими. Приложение знает, что данные в этих блоках не следует ожидать.
Так почему вы думаете, что это должно быть проблемой?