Мы хотим сделать резервную копию около 100 ГБ + данных, содержащих небольшие файлы (10 КБ +) каждый. Резервное копирование необходимо делать как можно быстрее на другой жесткий диск еженедельно. Какой способ резервного копирования лучше (особенно по скорости) в таком сценарии? Rsync или tar?
Определенно rsync.
Преимущество rsync в том, что он копирует только те файлы, которые были изменены.
Если у вас более 100 ГБ относительно небольших файлов, вы не хотите их копировать все каждый раз.
Примечание: первая резервная копия с rsync будет медленно, потому что все файлы копируются. Впоследствии копируются только измененные файлы, и они могут быть сжаты во время копирования.
Обязательно ознакомьтесь со всеми вариантами rsync ... много.
Tar - это архивная утилита. Вы могли бы создать tar-файл для всех 100 ГБ +, но вы не хотите переносить все это каждый раз.
Хочу добавить, хотя в целом согласен с ответом павиума и выбрал бы rsync, есть варианты в tar для инкрементных резервных копий. От мужчины:
-g, --listed-incremental F создать / перечислить / извлечь новую инкрементную резервную копию в формате GNU
-G, --incremental
create/list/extract old GNU-format incremental backup
РЕДАКТИРОВАТЬ: после недавнего комментария я подробнее расскажу, как работают обе резервные копии:
tar изначально создает большой файл, возможно, сжатый (-g gzip) со всеми зарезервированными файлами. Затем каждая инкрементная резервная копия создает новый файл только с измененными файлами, в котором также указывается, какие из них были удалены.
rsync с другой стороны, изначально создается второй зеркальный каталог с точным деревом и файлами исходного каталога без сжатия. Затем при каждой инкрементной резервной копии (-B flag), он по-прежнему имеет зеркальную копию источника, сохраняя в другом каталоге по дате все измененные файлы (как измененные, так и удаленные).
Поэтому можно понять, что у каждого метода есть свои плюсы и минусы. А tar Резервное копирование труднее поддерживать на носителе с ограниченной емкостью, как это происходит с классическим инкрементным методом. rsync не считается классическим решением для резервного копирования. Для зеркала требуется больше дискового пространства, поскольку оно не сжато. Для восстановления полной резервной копии предыдущей даты требуется больше времени.
ОБНОВЛЕНИЕ: с марта 2016 года появилась более новая альтернатива: борг резервная копия. Я очень рекомендую это. Он использует метод «дедупликации». Более подробная информация по приведенной выше ссылке.
rsync может быть несколько болезненным, если у вас очень большое количество файлов - особенно если ваша версия rsync ниже 3. С другой стороны: если вы используете tar, вы сгенерируете очень большой итоговый tar-файл (если данные не могут сильно сжиматься). Лично я бы посмотрел на rdiff-резервное копирование, но убедитесь, что вы протестировали ситуацию восстановления: rdiff-backup может потребовать очень много памяти при восстановлении.
если ваши файлы не сильно меняются - я бы проголосовал за rsync.
Вам нужна история (несколько резервных копий) или просто копия ваших данных на другом диске? Для резервного копирования 100 ГБ файлов размером 10 КБ потребуется возраст если вы не используете резервное копирование на уровне блоков. Подумайте о создании снимков на уровне блоков или о другом решении на основе уровня блоков, если вам действительно нужен быстро решение.
Взгляни на rsnapshot, это просто сценарий, который вы можете использовать в качестве переднего плана для rsync. Он будет создавать резервные копии только того, что изменилось, и чередовать ваши резервные копии.
Подумайте только об использовании возможностей RAID1 вашего контроллера, linux softraid, который вы монтируете в этом каталоге (можно даже сделать для файлов изображений с устройствами обратной связи) или использовать btrfs для файлов (имеет добавленную красоту COW Snapshots, но все еще следует учитывать экспериментальный). Эта ссылка должен дать вам несколько идей. Таким образом вы будете создавать резервные копии по ходу работы.
РЕДАКТИРОВАТЬ: Хорошо, прежде чем я получу больше (несколько рассерженных) голосов против, мне нужно уточнить: идея состоит в том, чтобы заменить один из дисков в RAID 1 пустым.
Тот, который вы выдернули, - это ваша резервная копия (сделанная в постоянное амортизированное время), а другая должна быть успешно синхронизирована. В Linux я могу сделать это полностью автоматизированным программным обеспечением, и это работает. «Горячая» синхронизация RAID может быть самым медленным из обсуждаемых методов резервного копирования, но это происходит одновременно и легко в течение одной недели. Этот ответ идеально соответствует требованиям OP, поэтому я не вижу причин для отрицательных голосов.
Однако я должен признать, что извлечение диска из горячего (то есть интенсивно загруженного) массива кажется несколько рискованным, хотя он должен работать нормально, поскольку все компоненты просто делают то, что они были созданы, чтобы делать. Если бы RAID не выполнялась ресинхронизация, вы могли бы вообще не использовать его.
Можно возразить, что это злоупотребление одноразовым отказоустойчивым механизмом для регулярного использования. Скажите это профессиональным парашютистам. Мы живем в эпоху цифровых технологий, если бы это не сработало, все бы вышло из строя.