☰

Самый эффективный способ проредить резервную копию, использующую жесткие ссылки

tag-icon • tag-icon command-line filesystems backup parallelism
Самый эффективный способ проредить резервную копию, использующую жесткие ссылки

У меня есть резервный диск, который содержит сотни резервных копий одной и той же машины с разных дат. Резервная копия была сделана с помощью rsync и жестких ссылок, т. е. если файл не изменяется, скрипт резервного копирования просто создает жесткую ссылку на файл в более старой резервной копии. Таким образом, если файл никогда не изменяется, у вас по сути одна копия на резервном диске, но, скажем, 100 жестких ссылок на него в каждом каталоге, представляющих резервную копию каждой даты (например back-1, back-2, , ... back-n). Если я хочу проредить его, я удаляю подмножество из них, но не все. Предположим, я хочу удалить back_5, back_6, ... back_10(просто в качестве примера, в моем реальном сценарии их гораздо больше). Затем я пытаюсь распараллелить его с помощью:

echo back_5 back_6 back_10 | xargs -n 1 -P 0 rm -rf

Это занимает несколько часов. Так есть ли более быстрый способ сделать это?

решение1

Я не понимаю, как вы используетеxargsтаким образом, это совсем не медленно. В моей man-странице указано, что -P — это количество процессов, а -n — это количество аргументов. Специального значения для нет -P0, поэтому оно, скорее всего, игнорируется (или, если принимается во внимание, вы получаете ноль процессов, что объясняет 24 часа ничего!). И -n1гарантирует, что вы получите одинисполнительный(2) для каждого имени файла, что является самым медленным из возможных.

Я сомневаюсь, что параллелизация этой работы принесет вам много. Я бы подумал, что просто

$ echo filenames ... | xargs rm -rf

будет достаточно. Вы можете экспериментировать со значениями, как -P4вам нравится.нетОграничивая количество аргументов командной строки, вы минимизируете вызовы /bin/rmи позволяете им последовательно проходить через кэш вашего диска.

решение2

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

Это на самом деле свидетельствует об эффективности ваших ссылок!

решение3

По моему опыту, лучшим способом ускорить резервное копирование на основе rsync+hardlink является уменьшение количества файлов.

Большое количество мелких файлов замедляет rsyncмного.

Если вы сможете организовать свои данные таким образом, чтобы каталоги с небольшими файлами, в основном предназначенные только для чтения, были выделены tarкрасным цветом, вы должны заметить значительное ускорение вашего сценария резервного копирования. (С помощью таких инструментов, как archivemount, вы затем сможете получить доступ к этим архивам, не извлекая их).

Распараллеливание сценария резервного копирования, скорее всего, не поможет или даже замедлит его (предсказуемый доступ к диску более оптимален).

решение4

Это также ответ, основанный на опыте, а не на подтвержденных достоверными данными.

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

topdir1
    |-a1
    |-b1
    |-c1

topdir2
    |-a2
    |-b2
    |-c2

topdir3
    |-a3
    |-b3
    |-c3

По моему мнению , быстрее удалить , topdir1, topdir2параллельно , а затем перейти к , , , и т. д. (Моя теория заключается в том, что многократное параллельное удаление «одних и тех же» файлов приводит к конкуренции за количество ссылок на ссылки inode, но я подчеркиваю, что не проверял это на точных данных.)topdir3a1b1c1a2b2c2

for topdir in *
do
    echo "Removing $topdir..."
    for sub in "$topdir"/*; do rm -rf "$sub" & done
    wait
    rm -rf "$topdir"
done

Связанный контент