У нас есть два больших сервера хранения (+100 ТБ), один работает на ZFS, другой - на XFS, мы намерены использовать XFS в качестве нашего рабочего сервера и использовать ZFS в качестве сервера резервного копирования (снимки <3). Теперь проблема в том, чтобы синхронизировать этих зверей ... (синхронизировать как в ежедневной синхронизации)
Самый простой вариант - использовать rsync, но, к сожалению, структура каталогов глубокая и повсюду полна жестких ссылок. Это означает, что нам нужно будет выполнить «глобальное» сканирование, которое займет много времени ... Кроме того, большая часть данных создается и никогда не изменяется. Так что rsync может просто не подходить.
Я заглянул в inotify, что кажется относительно дешевым, и, поскольку мы выполняем синхронизацию только ежедневно, мы сможем разгрузить в удобное время ... к сожалению, если мы будем смотреть только на созданные файлы, мы скопируем жесткие ссылки как данные, которые удвоят количество хранилища, используемого в нашей резервной копии ... (в основном нет возможности выполнить проверку -H из rsync)
Единственный оставшийся вариант, о котором я мог подумать, - это реорганизовать наше хранилище для использования каталога на основе даты, к сожалению, перемещение такого количества данных - это не то, что мы предпочли бы ...
Есть ли другие варианты?
Для справки:
Когда я ссылаюсь на ZFS как на медленную, я вижу, что ls занимает секунды ...
Вам действительно следует использовать ZFS с обеих сторон в сочетании с процедурой создания снимков / репликации на уровне блоков, например Саноид.
Без этого вы застрянете в файловых операциях и столкнетесь с болью при сканировании файлов с помощью rsync.
Насколько быстро «достаточно быстро»?
Вы делаете это один раз в день, поэтому я подозреваю, что если это займет 2-3 часа, этого будет достаточно.
В этом случае "rsync -avP" должно быть всем, что вам нужно. Новейшие версии обрабатывают большие каталоги, глубокие иерархии и не требуют столько оперативной памяти, как более старые версии.
Если файлы не изменились, «rsync -a» будет таким же быстрым, как «ls -lR». Вы не можете работать быстрее, чем "ls -lR", потому что он выполняет lstat () для каждого файла в системе.
Тесты «ls -lR» и «rsync -a». Если они работают медленнее, чем вы думаете, посмотрите на https://serverfault.com/a/746868/6472 За советом.
Если вам нужно что-то более быстрое, чем эталонный тест «ls -lR», вам придется либо написать что-то, что использует «inotify», либо использовать какую-то блочную систему. В частности, использование ZFS в обеих системах позволит вам использовать систему экспорта / импорта снимков, встроенную в ZFS.
Я бы принял стратегию из двух частей ... и в конце я предлагаю третью часть, которая является необязательной.
Часть 1. Использование inotify: напишите программу, которая использует inotify для регистрации файлов, которые были созданы, удалены и изменены. Напишите другую программу, которая читает журнал, удаляет все дубликаты и создает резервные копии этих файлов (и удаляет удаленные файлы). Это будет нелегко. Программирование inotify сложное. Журнал не может быть простым текстовым файлом, поскольку имена файлов могут включать символы новой строки. Если система выйдет из строя во время записи журнала, вам понадобится иметь дело с частично записанными именами файлов.
Часть 2: Еженедельный rsync на всякий случай. Каждые несколько дней выполняйте команду «rsync -a --delete», чтобы перехватить все пропущенные файлы. Решение в части 1 несовершенно. Если ваша программа не успевает за inotify, она может пропустить некоторые файлы. Если машина перезагружается, журнал созданных / удаленных / измененных файлов может потерять самые последние элементы. Ошибки и другие проблемы также могут привести к отсутствию некоторых файлов.
Необязательная часть 3. После того, как вы проработаете это в течение нескольких недель и исправите все ошибки, вы все равно обнаружите, что rsync иногда находит пропущенные файлы. Обещаю, что это произойдет. inotify - это "лучший способ". Итак, на этом этапе вы поймете, что поддержание кода в Части 1 и Части 2 - это в два раза больше работы, чем вы ожидали. Чтобы решить эту проблему, выбросьте код, который вы написали в части 1, потому что rsync - это все, что вам действительно нужно в первую очередь.