Мы запускаем ряд веб-приложений, которые хранят много локальных данных в небольших файлах xml. Одна из частей нашей стратегии резервного копирования / восстановления - создать локальное зеркало файловой системы через VPN в центр хостинга.
VPN-соединение осуществляется только через ADSL со скоростью 12 Мбит / с, и, хотя файлов и каталогов много, фактическое количество изменяемых файлов довольно мало.
Хотя пропускная способность, вероятно, является проблемой, я вижу результаты, подобные приведенным ниже. На выполнение robocopy / MIR потребовалось 5 часов, а на фактическое выполнение копирования - всего 30 минут.
Есть ли у кого-нибудь предложения относительно способов улучшить это. Эти 5 часов теперь кажутся слишком медленными, и если мы не сможем найти способ ускорить это, нам придется придумать совершенно другое решение.
Total Copied Skipped Mismatch FAILED Extras
Dirs : 17625 6618 11007 0 0 0
Files : 1112430 1223 1111207 0 0 0
Bytes : 57.451 g 192.25 m 57.263 g 0 0 0
Times : 5:01:23 0:35:55 0:00:00 4:25:27
Speed : 93509 Bytes/sec.
Speed : 5.350 MegaBytes/min.
Ended : Fri Apr 16 05:54:23 2010
Я использую rsync для Windows для копирования через широкополосное соединение. Предположительно, это система дельта-копирования, которая копирует только изменения каждого файла, тогда как robocopy копирует весь файл, если он изменил один бит. (tbh Иногда мне интересно, действительно ли это так)
Вы также можете использовать переключатель robocopy / mon: x, чтобы он работал постоянно. Это запустится, когда robocopy увидит x изменений в файловой системе. Если его запускать очень часто, то будет внесено лишь небольшое количество изменений.
Вы можете использовать функцию репликации файлов в Windows Server, использовать путь DFS к каждой папке и установить локальную и удаленную папку в качестве цели.
Robocopy сначала должен будет перечислить все локальные и удаленные файлы, чтобы определить, какие из них необходимо передать. Скорее всего, это то, на что нужно время.
Что если вы сбросите атрибут файла архива после успешного резервного копирования:
attrib -a /s *
Затем каждый раз при записи в файл будет автоматически устанавливаться бит архива. В следующий раз вы можете указать Robocopy архивировать только файлы с установленным флагом A:
robocopy source destination /mir /a
Я не тестировал это, но считаю, что это должно быть быстрее, так как Robocopy будет обрабатывать намного меньше файлов.
Другой вариант - запустить запланированное задание на удаленном сервере (если это возможно), чтобы заархивировать всю структуру каталогов, а затем просто скопировать полученный zip-файл через VPN. XML будет хорошо сжиматься, и копирование одного файла будет намного эффективнее по ссылке с высокой задержкой.
Я поддерживаю рекомендацию Чарльза Гарджента относительно rsync. Я использую rsync через SSH с Cygwin. Если я правильно помню, доступен исполняемый файл, не зависящий от cygwin.
Одним из огромных преимуществ rsync перед robocopy является то, что на удаленной стороне будет создан агент rsync для выполнения обработки на этой стороне. Удаленный агент может проверять удаленную файловую систему без необходимости возвращать все детали файла на ваш локальный компьютер для обработки. Это намного, намного быстрее, чем robocopy, и, вероятно, именно поэтому ваша 5-часовая задержка.
Вы также можете использовать сжатие с помощью rsync поверх ssh, что может еще больше ускорить процесс.
Однако помните, что списки ACL файловой системы Cygwin и ACL Windows не работают вместе. Если вам нужна точная копия ACL, rsync может не для вас. Мне пришлось написать сценарий для запуска xcacls, чтобы «очистить» права доступа к моим файлам после их копирования.
Комментарии XYZ относительно обратной стороны использования ATTRIB полезны, однако недостаточно просто следовать команде robocopy / MIR с командой robocopy / COPY / M, чтобы выборочно сбросить биты архива. Robocopy не сбрасывает бит, если он фактически не копирует файл, и (по умолчанию) он не будет копировать «одинаковые» файлы. Следовательно,
РОБОКОПИЯ источник назначения / МИР
Источник назначения ROBOCOPY / COPY / M
оставит бит архива многих файлов в источнике без изменений. (Я бы хотел, чтобы это было неправдой.)
Маловероятно, что исходный код Robocopy будет доработан, но я бы хотел, чтобы авторы предоставили «это» для / MIR, чтобы сбросить биты архива за один раз (например, / MIR: A). Это в основном важно для инициации резервного копирования в новой системе, но в любом случае это демонстрирует, что robocopy / MIR не является «полным» решением для резервного копирования.
Просто несколько замечаний об использовании attrib -a / s для обхода недостатка robocopy. Если вы собираетесь использовать это решение, запустите его ДО того, как вы запустите полное резервное копирование. т.е. Полное резервное копирование обычно занимает много времени, и некоторые файлы могли измениться между тем, когда они были скопированы, и тем, когда вы после этого дойдете до запуска attrib, что может означать отсутствие этих изменений в более поздних копиях.
Второе замечание об этом решении заключается в том, что оно работает хорошо, только если ваши копии не фильтруются. Если вы фильтруете процессы резервного копирования или robocopy, чтобы избежать временных файлов и подобного мусора, тогда нет простого способа убедиться, что attrib просматривает только файл, на который смотрит процесс копирования. То есть; вы меняете атрибуты файлов, которые на самом деле не копируете - и это не очень хорошая идея.
Удивительно, что robocopy кажется неспособным создать традиционную полную резервную копию ... или не за один запуск. Вы можете сделать это, запустив его дважды. Один раз, чтобы скопировать все, а затем снова с помощью / M, чтобы скопировать, и на этот раз фактически сбросьте биты архива. Что за PITA.