Проблема с дампом / восстановлением ext2
Я использую почтовый сервер с хранилищем maildir. Это означает, что создано довольно много файлов, и у меня просто закончились inode. AFAIK - нет волшебной команды для увеличения числа inode в файловой системе ext# (или я ошибаюсь?), Поэтому мне нужно сделать резервную копию и восстановить всю файловую систему. Но как мне это сделать? Я попытался создать другой раздел и сделать:
dump -f - -0 /vservers/mail | restore rf - -u -v
Хотя это, кажется, работает, это занимает гораздо больше времени, чем я готов ждать (ему удалось создать 500 пустых каталогов за 2 часа до того, как я остановил процесс; strace показал, что восстановление вызывает много бесполезных lseeks). Есть ли другой способ скопировать всю файловую систему (включая сокеты, файлы устройств, владельцев, разрешения, ACL и т. Д.)? Дополнительная информация: источник fs - это ext3, место назначения - ext4, файловые системы находятся на lvm, я хочу переместить fs - это root fs для vserver.
3 ответа
Мое альтернативное предложение для копирования файловой системы следующее. Имейте в виду, что ближе всего к этой проблеме я использую find+xargs+rm, чтобы очистить maildir, который пришел в негодность из-за бесполезного мусора, так что вы должны увидеть, куда это приведет вас через час или около того.
cd root_of_source ; find . -print0 | tar -c --null -T - -f - | tar -sxf - -C root_of_target
Функция этой конструкции
- Получить список файлов в их необработанном порядке
- Вот почему я использую find вместо tar по умолчанию... Я не знаю, что tar по умолчанию плох, я просто знаю, что find хорош,
- Передача этого списка в tar завершается нулем (чтобы любые специальные символы обрабатывались правильно).
- Возьмите вывод формата tar и распакуйте результат (без повторной сортировки ввода (-ов)) в целевом каталоге.
Независимо от используемого вами метода:
- Если эти данные начинаются и заканчиваются на одних и тех же физических дисках, ваша производительность, естественно, будет отстойной на LOT по сравнению с обычными операциями (много поисков между чтением из источника и записью в место назначения).
- Если у вас есть доступный процессор, небольшое сжатие не должно повредить и может помочь. Просто добавьте стадию 'gzip -c -1' между командами tar и -z для второй tar.
Рассматривали ли вы попытку использовать unionfs для объединения существующей файловой системы с новой, с записью в новую файловую систему?
Я никогда не использовал UnionFS самостоятельно, но то, что я слышал о нем, звучит так, как будто оно может позволить вам начать работу и снова начать записывать данные на диск, не создавая заново файловую систему, объединяя существующую файловую систему только для чтения с новой файловая система как записываемая файловая система. Могут быть проблемы с производительностью или другие проблемы, которые делают это бесполезным, но если вы просто ищете идеи и у вас есть время, пока дамп работает, вы, вероятно, можете исследовать это для работоспособного набора команд.
Кроме как dump | restore, ты можешь использовать tar | tar, или просто cp -ax или же rsync скопировать все файлы на новый фс. По моему опыту, dump | restore самый быстрый метод.
Для справки: на довольно старой и медленной машине у меня уходит 35 минут на дублирование fs с помощью dump | restore где fs имеет 420 774 inode, используя 7,8 ГБ пространства.
Для сравнения, это занимает 61 минут, используя tar | tarи 64 минуты, используя cp -ax,
Несколько месяцев назад я разместил патч, чтобы сделать dump быстрее, но это было после выпуска 0.4b44, и еще не было еще одного релиза. Вы можете найти патч в списке рассылки. Сборка 0.4b44 самостоятельно с применением этого патча может существенно изменить ситуацию. Для меня это сократило время с 35 минут до только 25. Обратная связь в списке рассылки была бы полезна.