Как отразить файловые системы с миллионами жестких ссылок?

На данный момент у нас есть одна большая проблема: нам нужно отразить файловую систему для одного из наших клиентов. Это обычно не проблема, но вот она:

В этой файловой системе есть одна папка с миллионами жестких ссылок (да! МИЛЛИОНЫ!). rsyncтребуется более 4 дней, чтобы просто создать список файлов.

Мы используем следующие rsyncварианты:

rsync -Havz --progress serverA:/data/cms /data/

Кто-нибудь знает, как ускорить этот rsync, или использовать альтернативы? Мы не могли бы использовать, ddпоскольку целевой диск меньше исходного.

ОБНОВЛЕНИЕ: Как оригинальная файловая система, ext3мы попробуем dumpи restore. Я буду держать вас в курсе

— Томас Бергер
источник

Tricky. Сначала сожмите исходную файловую систему, затем dd?

— Биттранс

Ответы:

Вам нужно обновить обе стороны до rsync 3. Из журнала изменений:

- A new incremental-recursion algorithm is now used when rsync is talking
  to another 3.x version.  This starts the transfer going more quickly
  (before all the files have been found), and requires much less memory.
  See the --recursive option in the manpage for some restrictions.

С момента выпуска rsync 3.0.0 прошло более 2 лет, но, к сожалению, большинство корпоративных дистрибутивов основаны на более старом коде, что означает, что вы, вероятно, используете rsync 2.6.

Для справки (если у кого-то еще есть эта проблема), если вы уже запускаете rsync 3, то вы используете параметры, несовместимые с инкрементной рекурсией. Со страницы руководства:

    Some options require rsync to know the full file list, so  these
    options  disable the incremental recursion mode.  These include:
    --delete-before,   --delete-after,    --prune-empty-dirs,    and
    --delay-updates.

Кроме того, обе стороны должны запустить rsync 3 для поддержки добавочной рекурсии.

— Стивен Притчард
источник

Причард благодарит вас за это, но с инкрементными частями проблем нет, обе стороны используют rsync> 3.0. Если мы используем rsync без -H, мы получаем значительное улучшение скорости, но это не то, что нам нужно.

— Томас Бергер

Уч. Да, в этом случае вам может понадобиться поиск вариантов ускорения доступа к файловой системе (например, переключение на ext4, если вы используете ext3), переключение на более быстрые диски или уровни RAID (если это вообще возможно) и т. Д. К сожалению, вы может быть в тот момент, когда файловая система просто не может быть достаточно быстрой, и резервное копирование на уровне блоков может быть вашим единственным вариантом. У меня была эта проблема при попытке rsync пула BackupPC с одного сервера на другой.

— Стивен Притчард

Мы использовали ext * dump сейчас. Работает хорошо, и сторона восстановления даже не должна быть ext *.

Мы сделали автономное резервное копирование, размонтировав устройство и использовав его dump vf - /dev/vg0/opt | gzip -c > /mnt/backup/ext3dump.gz.

Вот последние строки, которые вы могли видеть размер, время, скорость и последние номера inode:

DUMP: dumping regular inode 47169535
DUMP: dumping regular inode 47169536
DUMP: Volume 1 completed at: Wed Jun 29 05:42:57 2011
DUMP: Volume 1 54393520 blocks (53118.67MB)
DUMP: Volume 1 took 4:16:43
DUMP: Volume 1 transfer rate: 3531 kB/s
DUMP: 54393520 blocks (53118.67MB)
DUMP: finished in 15403 seconds, throughput 3531 kBytes/sec
DUMP: Date of this level  dump: Wed Jun 29 01:24:29 2011
DUMP: Date this dump completed:  Wed Jun 29 05:42:57 2011
DUMP: Average transfer rate: 3531 kB/s
DUMP: DUMP IS DONE

— Томас Бергер
источник

Я не знаю, если это все еще верно, но у дампа были некоторые проблемы, если файловая система использовалась во время дампа. Поскольку ваша цель скорость я полагаю , вы уже отключены все другие к нему доступ, но только в том случае, .. Дайте нам знать , как вы идете

— SuperBob

Вы можете использовать LVM и сделать снимки тома, а затем rsync снимок в качестве резервной копии.

Кроме того, вы можете объединить это с другим ответом и использовать dump на томе снимка , чтобы избежать необходимости переводить исходный том в автономный режим.

— Тедди
источник

Все, что работает на уровне блоков, а не на уровне файловой системы, вероятно, будет огромным улучшением.

— Марчин

Как вы могли видеть в моем вопросе, я должен отражать через сеть, а не локально. Кроме того, LVM - это НЕ зеркало, это, как вы сказали, снимок.

— Томас Бергер

@ Томас Бергер: Я думал, что вы скопируете снимок (используя rsync) по сети. И как именно вы определяете зеркало , если снимок LVM не один?

— Тедди

Это все еще та же проблема: это займет несколько дней. В эти дни была бы огромная далта (не то, что нам это нужно), поэтому мы должны зарезервировать достаточно места, и у нас нет этого места. И зеркало является независимой копией источника. Мы должны скопировать данные от производства до разработки для клиента.

— Томас Бергер

@ Томас Бергер: Первоначально я имел в виду, что вы будете синхронизировать фактический том снимка, а не файловую систему на снимке. Однако теперь я считаю, что решение «снимок + дамп» лучше.

— Тедди