В настоящее время я использую традиционный метод rsync + cp -al для создания инкрементных резервных копий / резервных копий моментальных снимков нашего дерева серверов. Резервные копии поступают на пару башен с восемью дисками, подключенных к машине резервного копирования (машина Sandy Bridge с 16 ГБ ОЗУ, работающая под управлением CentOS 5.5) через четыре соединения eSATA (четыре диска на соединение). Каждый диск представляет собой обычный диск емкостью 2 ТБ, поэтому у нас есть 32 ТБ дискового пространства, подключенного к машине резервного копирования. С его помощью мы выполняем резервное копирование около 20 ТБ данных на серверах.
Проблема в том, что каждое ежедневное резервное копирование занимает более 24 часов, и в реальном времени убивает не сам rsync, а время, необходимое для выполнения cp -al дерева локально на машине резервного копирования. На создание теневой копии дерева уходит более 12 часов, и, насколько я могу судить, отставание по производительности находится на диске (вверху показано, что процессор использует много оперативной памяти, но не так много процессора и в основном в непрерывном режиме). -сон)
У нас есть данные сервера, разделенные на четыре основных тома (и несколько второстепенных), и каждое из этих резервных копий выполняется параллельно (с некоторыми смещениями в cron, чтобы попытаться сначала выполнить cp некоторых дисков). На резервном диске есть два тома, оба тома LVM с чередованием по 16 ТБ каждый.
Очевидно, мне нужно улучшить производительность, потому что в нынешнем виде он непригоден.
Первый вопрос: когда выйдет CentOS 6 с поддержкой btrfs, существенно ли увеличит производительность создание снимков подобъемов с помощью btrfs?
Второй: есть ли способ с помощью ext3 или чего-то еще, поддерживаемого в CentOS 5 или 6, чтобы `` побудить '' его поместить каталоги / inodes в одну часть тома (которая может оказаться частью, которая находится на SSD , через LVM) а файлы в другом? Это, по-видимому, решит проблему, но я не знаю способов намекнуть на ext3 таким образом.
Вы можете попробовать использовать --link-dest и связанные параметры вместо следующих rsync с участием cp -al. См. Страницу руководства и уроки, подобные этому для подробностей.
Вы можете немного увеличить скорость, отключив журнал ext3, хотя я бы не рекомендовал это, поскольку это увеличивает вероятность повреждения резервных копий, если что-то пойдет не так во время обновления.
Если ваши резервные копии включают каталоги с большим количеством файлов, вы можете обнаружить, что переформатирование в ext4 или использование параметра dir_index с ext3 может улучшить ситуацию, но в обоих случаях вам может потребоваться переформатирование, чтобы увидеть все преимущества, просто перемонтируйте файловую систему с новыми параметрами. не будет преобразовывать существующие структуры.
Рассмотрите возможность использования rdiff-резервное копирование вместо rsync + cp. Он автоматически обрабатывает старые копии файлов, поэтому вам не нужно выполнять cp.
Со страницы rdiff-backup:
«Целевой каталог является копией исходного каталога, но дополнительные обратные различия хранятся в специальном подкаталоге этого целевого каталога, поэтому вы все равно можете восстановить файлы, потерянные некоторое время назад».