Я делаю резервную копию Linux-сервера через SMB на NAS. Я монтирую NAS локально и затем синхронизирую много данных (около 100 ГБ). Я считаю, что на это уходит очень много времени: более 12 часов. Я ожидал, что после копирования все будет намного быстрее, поскольку день ото дня почти ничего не меняется.
Есть ли способ ускорить это?
Я подумал, что, возможно, rsync думает, что работает с локальными жесткими дисками и использует контрольную сумму вместо сравнения времени / размера? Но я не нашел способа принудительно сравнивать время и дату. Что еще я могу проверить?
Я думаю, вы неправильно понимаете алгоритм rsync и то, как его следует применять.
Преимущество Rsync в производительности достигается за счет выполнения дельта-передач, то есть перемещения только измененных битов в файле. Чтобы определить измененные биты, файл должен быть прочитан исходным и целевым хостами и сравнены контрольные суммы блоков, чтобы определить, какие биты изменились. Это «волшебная» часть rsync - сам алгоритм rsync.
Когда вы монтируете целевой том с помощью SMB и используете rsync для копирования файлов из того, что Linux «видит» как локальный источник и локальное место назначения (оба установлены на этом компьютере), большинство современных версий rsync переключаются в режим копирования «весь файл». , и выключите алгоритм дельта-копирования. Это «выигрыш», потому что при включенном алгоритме дельта-копирования rsync будет читать весь целевой файл (по сети от NAS), чтобы определить, какие биты файла изменились.
«Правильный способ» использования rsync - это запустить сервер rsync на одном компьютере и клиент rsync на другом. Каждая машина будет читать файлы из своего собственного локального хранилища (что должно быть очень быстро), согласовывать, какие биты файлов были изменены, и передавать только эти биты. Они так, как вы используете rsync-значения сфабрикованного «cp». Вы могли бы сделать то же самое с помощью cp, и это, вероятно, было бы быстрее.
Если ваше устройство NAS поддерживает запуск сервера (или клиента) rsync, значит, вы в деле. Если вы просто собираетесь смонтировать его на исходном компьютере через SMB, то вы можете просто использовать cp для копирования файлов.
Похоже, ваша проблема - это временные метки, о чем говорится на этой странице:
http://www.goodjobsucking.com/?p=16
Предлагаемое решение - добавить
--modify-window=1
к параметрам rsync.
Да, вы можете ускорить это. Вам нужно сделать так, чтобы источник или адресат выглядел как удаленный компьютер, например, указав его как "localhost:".
Вы заявили, что монтируете общий ресурс SMB локально. Это делает источник или назначение похожим на локальный путь к rsync. На странице руководства rsync указано, что копии, в которых исходный и конечный пути являются локальными, будут копировать весь файл. Об этом говорится в параграфе для параметра "--whole-file" на странице руководства. Поэтому дельта-алгоритм не используется. Используя "localhost:"обходной путь восстановит функциональность дельта-алгоритма и ускорит передачу.
Думал, что брошу сюда свои 2p.
Мой брат только что установил сетевой накопитель Buffalo в своей офисной сети. Сейчас он изучает внешние резервные копии, так что если офис сгорит, по крайней мере, у него все еще будут все его деловые документы в другом месте (за много сотен миль).
Моим первым препятствием было получить VPS, который у него есть (небольшой виртуальный частный сервер Linux, ничего особенного), для подключения в качестве пользователя VPN к его широкополосному маршрутизатору (он использует для этого DrayTek), чтобы он сам мог быть частью его VPN, и поэтому он может получить доступ к NAS напрямую и в безопасном режиме. Получил это отсортировано и работает блестяще.
Следующая проблема заключалась в передаче файлов с NAS на VPS-сервер. Я начал с монтирования Samba и столкнулся с той же (или даже хуже) проблемой, которую вы описали. Я выполнил пробный запуск rsync, и потребовалось более 1 часа 30 минут, чтобы понять, какие файлы он собирался передать, потому что, как говорит Эван, при этом методе другой конец не является rsync, поэтому ему приходится выполнять много файлов системные вызовы / чтение на монтировке Samba (через PPTP / туннелированное соединение, с временем прохождения туда и обратно около 40 мс). Совершенно неработоспособный.
Вряд ли я знал, что Buffalo на самом деле запускает демон rsync, поэтому при его использовании весь пробный запуск занимает всего 1 минуту 30 секунд для 87k файлов общим объемом 50 ГБ. Очевидно, что передача 50 ГБ файлов (с NAS, подключенного к широкополосному каналу с исходящей пропускной способностью всего 100 к / с) - это совсем другое дело (это займет несколько дней), но после завершения начальной rsync любые инкрементные резервные копии должны быть осветление смазки (его данные не будут сильно меняться ежедневно).
Я предлагаю использовать достойный NAS, поддерживающий rsync, по причинам, о которых Эван сказал выше. Это решит все ваши проблемы.
Пахнет, как будто у вас более дешевый NAS. Это также может быть связано с пропускной способностью вашей сети ...
«Стандартные» потребительские NAS действительно слабы, когда дело доходит до интенсивного ввода-вывода, что вы и пытаетесь здесь сделать. Это также может быть дешевый коммутатор, соединяющий ваш компьютер и NAS, который недостаточно силен для правильной обработки всех пакетов.
попробуйте это думаю, что хотя бы дает вам на 10% больше скорости вашего получения http://www.thegeekstuff.com/2009/09/linux-remote-backup-using-rsnapshot-rsync-utility/
Есть два потенциальных источника проблемы: либо вы используете неверные параметры командной строки, либо у вашего NAS есть проблемы с метками времени (или и то, и другое :-). Пожалуйста, проверьте эту ветку "rsync to NAS каждый раз копирует все" для получения дополнительной информации.