Как скопировать миллионы маленьких файлов?
Я настоятельно рекомендовал бы использовать систему хранилища файлов, которая позволяет Вам создавать снимки объем и резервное копирование от снимка. Таким образом, там является мало влияния на фактический сервер, и система резервного копирования может занять свое время, делая резервное копирование без беспокойства об основной системе. Вы не упоминаете операционную систему, но что-то как ZFS или файловый сервер NetApp позволило бы это, и оба используются для этой точной функции повсеместно. Я уверен, что существуют другие файловые системы, которые предлагают это, но я знаю, что они работают.
Надеюсь, это поможет.
Я работал с сервером, который сохранил приблизительно ~20 миллионов файлов, где 95% являются меньше, чем 4k в размере и приблизительно 50% удаляются каждые 90 дней. Они используют изображение неструктурированного диска для резервного копирования. Они также создают индексный файл имен, md5 хеш и дата, созданная с помощью сценария и использования что отследить содержание.
Исходное решение для резервного копирования состояло в том, чтобы загрузить файлы как блобы в базе данных md5 подписью. Это было постепенно сокращено начиная с создания миллионов хешей md5, занял больше времени, чем просто создание необработанного резервного копирования образа.
Необходимо ли действительно создать резервную копию всех их каждый раз? Если Вы делаете возрастающими / дифференциальное резервное копирование, то только необходимо создать резервную копию изменений каждый раз, а не все включенные файлы.
Поскольку Вы посмотрели на rsync, Вы могли посмотреть на использование rsnapshot, который создает своего рода инкрементное резервное копирование.
Узкие места здесь будут файловой системой и самим жестким диском. Со многими маленькими файлами FS постоянно читает метаданные о файлах, которые могли бы быть отдельными в файл, или файлы, которые Вы читаете, не могут быть в хорошей непрерывной глыбе на диске. В любом случае головка диска должна переместиться много.
Чем быстрее Вы получаете все те маленькие файлы в большие файлы, тем быстрее Ваш полный процесс будет.
К сожалению, если все, что Вы делаете, копирует те файлы, после того как, затем имея их в единственном большом файле как архив только сделает процесс медленнее.
считайте все файлы> архив> местоположение резервирных копий
VS
считайте все файлы> местоположение резервирных копий
Оптимальные пути состояли бы в том, чтобы или скопировать все файлы однажды во вторичное местоположение и затем использовать измененные даты и размеры или архивный бит, так как Вы используете Windows, (не исследование содержания как хеши, которые все еще включили бы чтение файлов) для определения, какие файлы изменились, и копируют просто файлы к вторичному местоположению и резервному копированию оттуда. Или использовать систему, которая обходит FS, как НЕОБРАБОТАННАЯ копия как предложенный poige.
Резервное копирование Windows Server в окнах 2008 и позже делает изображения уровня громкости, таким образом, оно не делает ahve для посылки сообщения-розыгрыша через все миллионы частей метаданных файла. Это просто делает снимок (или Теневая копия тома в языке MS), затем создает резервную копию всех используемых блоков в файловой системе чтобы. Чтения последовательны, таким образом, это очень быстро, и пишет результаты в большой .vhd файл на другом объеме или сетевом ресурсе.
Существует несколько оборотных сторон: каждое резервное копирование является полным резервным копированием, нет никакого сжатия, и можно только сохранить одно "изображение" на целевую папку, если Вы идете в сетевой ресурс. Можно преодолеть последнего со сценариями и первого с другими инструментами как с 7 zip, rsync, или любым другим резервным/сжатием/дедупликацией инструментом, который может обработать необработанные файлы.
Вы, вероятно, закончите тем, что использовали командную строку wbadmin интерфейс для этого; проигнорируйте GUI, это просто слишком упрощенно для большинства вариантов использования.
Вот что мы сделали:
Мы купили NAS с сервером хранения Windows 2008 R2 на нем. Создан целевой объект ISCSI, который на самом деле является одним большим файлом (.vhd) Смонтировал цель ISCSI и переместил все файлы на виртуальный диск.
Теперь мы создаем резервную копию vhd с помощью нашего программного обеспечения для резервного копирования. Сделать резервную копию одного большого файла намного быстрее, чем множества маленьких файлов.
Вы можете установить программное обеспечение резервного копирования также на NAS и подключить к нему свой ленточный накопитель. Таким образом, вам не нужно использовать двойное хранилище (зеркальное копирование данных и резервное копирование зеркальных данных, чтобы выиграть время)