Недавно я установил дешевый жесткий диск емкостью 2 ТБ на сервере для резервного копирования файлов, резервные копии которых также создаются в другом месте. По сути, это привод переполнения. Остальные диски на сервере настроены как 1 ТБ в массиве Raid 6. Этот единственный диск я настроил как Raid 0 для удобства.
По сути, я перемещал около 700 ГБ данных с диска Raid 6 на диск Raid 0, потому что диск Raid 6 был почти заполнен. Итак ... 2 ТБ должно быть более чем достаточно, верно?
Данные представлены в виде данных, синхронизированных с удаленного сервера, при этом 6 дней инкрементных резервных копий обрабатываются стандартным способом «жесткой связи», чтобы гарантировать, что я только сохраняю / передаю изменения, а не выполняю резервное копирование всех данных каждый день.
Однако поведение, которое я наблюдаю, заключается в том, что данные, которые хранились примерно на 700 ГБ на дисках Raid 6, быстро раздуваются, чтобы почти заполнить диск 2 ТБ, как если бы я не использовал жесткие ссылки.
Вчера я удалил около 300 ГБ данных, которые больше не нужны, и за ночь хранилище было заполнено на 97%.
Кто-нибудь знает, что происходит? Диск действительно «заполнен», или это просто плохой расчет жесткого связывания?
Все диски отформатированы как Ext4.
** редактировать **
Подробная информация о процессе резервного копирования:
Каждый день задание cron копирует backup0 в backup1, используя cp -al backup0 backup1. Предыдущие резервные копии перемещены mv backup1 backup2и т. д. до выполнения rsync.
backup5 удаляется каждый день. После этого удаленный сервер rsyncs к backup0 (таким образом обновляя только измененные файлы). Таким образом, 5 дней инкрементного резервного копирования. По сути, именно так работает программное обеспечение, такое как backintime.
** Второе редактирование **
Я только что удалил резервную копию 3 в резервную копию 5, и она освободила около 2 третей диска. Итак, проблема, похоже, в том, как рассчитывается хранилище. (Я использую df -h для мониторинга хранилища).
Остается вопрос ... будет ли диск считаться «полным», даже если на нем должно быть достаточно места, когда он достигнет «100%».
С помощью cp -al не обязательно, просто используйте mv и rsync.
См. Статью журнала Admin: "Инкрементное резервное копирование в Linux":
"В большинстве современных дистрибутивов Linux есть довольно свежий rsync, который включает очень полезную опцию --link-dest =. Эта опция позволяет rsync сравнивать копию файла с существующей структурой каталогов и позволяет вам указать rsync копировать только измененные файлы ( инкрементное резервное копирование) относительно указанного каталога и использовать жесткие ссылки для других файлов. ".
В этой статье показано, как работает и что делает приведенный ниже сценарий, в частности, номера inode одинаковы в каждой резервной копии (что позволяет сэкономить место):
"... обратите внимание, что номер inode первого файла одинаков в обоих резервных копиях, что означает, что файл действительно сохраняется только один раз с жесткой ссылкой на него, что экономит время, место и деньги. Из-за жесткой ссылки, никаких дополнительных данных не требуется. Чтобы лучше понять это, вы можете запустить команду stat для файлов в двух каталогах резервных копий. ".
Видеть GNU cp команда:
-a, --archive
Сохраняйте как можно больше структуры и атрибутов исходных файлов в копии (но не пытайтесь сохранить внутреннюю структуру каталогов; то есть «ls -U» может перечислить записи в скопированном каталоге в другом порядке). Попытайтесь сохранить контекст безопасности SELinux и расширенные атрибуты (xattr), но игнорируйте любые ошибки и не печатайте соответствующее диагностическое сообщение. Эквивалентно -dR --preserve = все с сокращенной диагностикой
-l, --link
Делайте жесткие ссылки вместо копий некаталогов.
и Rsync на Samba.org команда:
-a, --archive
Архивный режим; равно -rlptgoD (без -H, -A, -X)
-H, --жесткие ссылки
Сохранить жесткие ссылки
-v, --verbose
Увеличить многословие
также см GNU's du команда:
-h, --человечески читаемый
Добавьте букву размера к каждому размеру, например "M" для мебибайт. Используются степени 1024, а не 1000; «M» означает 1 048 576 байт. Этот параметр эквивалентен --block-size = Human-readable. Используйте параметр --si, если вы предпочитаете степень 1000.
-s, --summarize
Отображать только сумму для каждого аргумента.
Вам понадобится что-то вроде этого:
rm -rf backup.3
mv backup.2 backup.3
mv backup.1 backup.2
mv backup.0 backup.1
rsync -avh --delete --link-dest= backup.1/ source_directory/ backup.0/
Первые несколько раз вы запускаете сценарий из-за всего резервного копирования. файлов не существует, вы увидите некоторые ошибки, но как только он заселен все будет без ошибок. Использовать du -sh и сравните это с lsвывод, как в ls -s.
Остается вопрос ... будет ли диск считаться «полным», даже если на нем должно быть достаточно места, когда он достигнет «100%».
Предполагая, что запущенная вами прикладная программа и утилита, которую вы используете для проверки оставшегося места на диске обе используйте правильный системный вызов, чтобы проверить оставшееся место, затем оба сообщат правильное значение, все, что близко к нулю, считается «полным», потому что временные файлы различаются по размеру и постоянно создаются и удаляются в активной операционной системе. Никогда приблизившись к нулю, вы, вероятно, вылетите и при перезагрузке возникнут ошибки запуска.