Мы использовали tar для резервного копирования и сжатия (gzip) выбранных каталогов на нашем файловом сервере с очень хорошими результатами до недавнего времени.
Каждая из наших резервных копий хранится на зеркальных (RAID) жестких дисках и одновременно выгружается в корзину Amazon S3 для внешнего хранения.
Поскольку в последнее время размер наших данных быстро увеличивался, увеличились и наши резервные копии. На этой неделе наши резервные копии загружаются круглосуточно и без выходных, чтобы синхронизировать свежие резервные копии за последние 7 дней, и все еще не завершены. Улучшение соединения решило бы некоторые из этих проблем (чего мы не можем сделать в настоящий момент), но я думаю, что лучше создать реальное решение, чем искать обходной путь.
Какая альтернативная стратегия, которая удерживает нас от файлов с многозначными гигабайтами и по-прежнему позволяет нам использовать tar, можем ли мы использовать резервное копирование наших каталогов, которое уменьшило бы полосу пропускания, необходимую для синхронизации файлов?
Вот коммерческая рекомендация. Кактус Одинокий Деготь представляет собой полный пакет резервного копирования, который генерирует архивные файлы, которые можно извлечь и просмотреть с помощью tar, даже когда записано на ленту. Это удобно, потому что вам не нужно программное обеспечение для восстановления архива. Это мое идеальное решение для резервного копирования автономных серверов Linux.
Lone-Tar теперь имеет онлайн-компонент, который может интегрироваться со встроенным пакетом внешнего хранилища или удаленным сервером Linux. Поскольку это пакет программного обеспечения для резервного копирования, он поддерживает правильный каталог и может содержать ПОЛНОЕ, ДОПОЛНИТЕЛЬНОЕ и ВЫБОРНОЕ резервное копирование.
Используйте rsync поверх ssh. Если вы хотите сохранить исторические версии, вы можете установить -b и связанные параметры. Если вы женаты на tar, вы можете использовать флаг -z, если вы еще этого не сделали. Вы можете пойти дальше, воспользовавшись битом «архив» в файловой системе, используя параметр команда дампа так что, как и при обычном использовании rsync, будут скопированы только файлы, которые изменились с момента последнего дампа или синхронизации.
Здесь много неизвестных переменных. Каков размер ваших резервных копий, каковы ограничения вашей пропускной способности, хотите ли вы инкрементное или полное резервное копирование и т. Д.
Несколько предложений в любом случае:
Используйте rsync поверх ssh при использовании сжатия (опция -C). Rsync значительно уменьшит объем данных, необходимых для передачи при каждой резервной копии. Сжатие также уменьшит требуемую полосу пропускания.
Если пропускная способность ограничена, рассмотрите возможность резервного копирования на локальные диски. Если вам нужны резервные копии вне офиса, вы всегда можете отправить их по почте. По мере увеличения объема хранилища вам действительно не следует исключать этот вариант как допустимый, поскольку пропускная способность не увеличилась до необходимого уровня.
[править] Я заметил, что вы добавляете тег. Предоставляет ли корзина Amazon S3 поддержку моментальных снимков? Это позаботится об инкрементальном аспекте.