Я создал решение для инкрементного резервного копирования, которое использует RSYNC для резервного копирования нескольких наших серверов. Я использую PHP для просмотра файлов конфигурации, чтобы получить информацию для каждого сервера, для которого необходимо создать резервную копию. Затем PHP вызывает RSYNC для обработки удаленного резервного копирования серверов, постепенно.
Это отлично работает на всех наших серверах и занимает всего несколько минут ... все, кроме одного сервера. На этом сервере много данных, и кажется, что RSYNC просто зависает на нем. На создание одной инкрементной резервной копии уходит более 3 дней. Я предполагаю, что он застрял при построении списка файлов.
Когда я запускаю указанную ниже команду в папке, которую хочу сделать резервную копию, вот результаты «iused».
df -i folder/
54176307
Это просто слишком много данных для обработки RSYNC? Стоит ли искать другую альтернативу? Сервер резервного копирования в настоящее время работает на версии 3.0.8, однако все клиенты, для которых выполняется резервное копирование, работают под управлением RSYNC 2.6.9. Как вы думаете, обновление всего до 3.0.8 изменит ситуацию и сократит 3-дневное время резервного копирования для этого сервера?
Спасибо, Джейкоб
Я сомневаюсь, что само по себе обновление обеспечит то улучшение, которое вы ищете. При 72 часах вы, вероятно, захотите увеличить производительность на порядок (7,2 часа). Если вы ищете 2-3 часа, удачи без SSD и хорошей сети.
Имея 55 миллионов инодов (при условии, что примерно столько же файлов), вам придется серьезно пересмотреть свой подход. Во-первых, если вы используете вариант ext, я бы подумал о тестировании другой FS.
Во-вторых, если вы используете ext FS (скажем, ext3 / 4), первое, что я сделаю, это отключите время! При включенном atime каждый раз, когда файл читается / просматривается, файловая система должна выполнять крошечную запись на диск, поскольку atime означает «время доступа». Отключив его, вы теряете возможность видеть, когда был открыт доступ к файлу, но именно так cookie рассыпается. Если вы используете стандартный диск SATA, предположим, что вы можете выполнять 100 операций ввода-вывода в секунду (IOPS). Каждая запись доступа требует одного из них (худший случай). Это означает 100 файлов в секунду, чтобы проверить его существование, и к тому времени, когда вы его прочитаете, вы используете еще больше IOPS. 55000000/100 = 550000с = 152 часа. Как только вы обнаружите очень хорошие алгоритмы ядра для объединения IOPS, вы, вероятно, найдете свое узкое место.
В вашем / etc / fstab используйте параметр монтирования:
noatime,nodiratime
чтобы полностью отключить время. Оставьте nodiratime выключенным, чтобы оставить время доступа для каталогов отключенным. Если у вас много каталогов, я бы рекомендовал отключить его.
Бьюсь об заклад, это одно только поможет.
Вот пример fstab:
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc nodev,noexec,nosuid 0 0
# / was on /dev/sda1 during installation
UUID=66188c62-0d8c-46d8-a44f-8f673ca6ac98 / ext4 errors=remount-ro,discard,noatime,nodiratime 0 1
# swap was on /dev/sda6 during installation
UUID=c3f40312-d6f9-4bb7-b426-602a4b7a6c47 none swap sw 0 0
У меня есть несколько скриптов, которые делают что-то в этом роде. Я думаю, что правильным решением будет поискать в файловой системе вещи, которые изменились с момента последней резервной копии, а затем использовать rsync для «синхронизации», однако я этого не сделал.
Вместо этого у меня есть 2 сценария: 1, который находит каталоги верхнего уровня для резервного копирования, а другой, который выполняет резервное копирование каждого из них параллельно. Я обнаружил, что с файловым хранилищем NFS я получаю довольно высокую загрузку процессора при примерно 10 параллельных rsync. Поскольку в этот момент задание почти связано с ЦП, тогда как один rsync приближается к 7% ЦП, я использую xargs для запуска каждого отдельного задания, но для одновременного запуска 7 заданий с параметром -P.
Я могу отправить сценарий по электронной почте, если кому-то интересно. Они должны быть хорошо читаемыми.