Быстрое резервное копирование большой файловой системы

В / home смонтирована файловая система с хранилищем 2.6PB. В настоящее время в каталоге / home хранится 300 ТБ + данных. Я собираюсь ежедневно делать резервные копии всех данных объемом 300 ТБ + в / home / fs_backup, но обнаружил, что следующая команда через tar очень медленная:

 cd /home/fs_backup && tar -cpf backup.tar.gz --exclude="/home/fs_backup" --one-file-system "/home" 

Я предполагаю, что это может дать только 10 ГБ / мин, что означает, что все данные 300 ТБ + не могут быть зарезервированы за 24 часа. Любая идея, как я мог бы «сделать копию» текущих данных в / home, независимо от того, хорошо ли они сжаты – или даже вообще не сжаты – или не за короткое время. Большое спасибо.

Поскольку вы уже определили, что не можете сделать резервную копию всего объема в 300 ГБ в течение установленного 24-часового периода, вам необходимо пересмотреть свои требования.

На уровне файлов инкрементному инструменту, такому как star , rsnapshot или даже rsync / rsnapshot может потребоваться больше, чем один день для создания базовой резервной копии, но после этого он должен быть значительно быстрее. Очевидно, это будет зависеть от количества и размера файлов, которые изменяются в течение каждого 24-часового периода резервного копирования.

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

Вы не указали, как должна храниться ваша резервная копия, но для многих небольших файлов лучше rsnapshot что-то вроде rsnapshot . (Я использую его для резервного копирования на основе файлов многих наших внутренних файловых серверов, поскольку он позволяет нам получить простой доступ к отдельным файлам в целях восстановления.)

Кстати, резервное копирование на другой диск на том же хосте на самом деле не должно рассматриваться как безопасное резервное копирование. Было бы гораздо лучше полностью выполнить резервное копирование на другой хост. (Если /home/fs_backup – это удаленное монтирование с другого сервера, серьезно подумайте об использовании rsnapshot или rsync / rsnapshot для прямой связи с удаленным хостом, а не через удаленно смонтированную файловую систему.)

Самым быстрым из известных мне способов создания резервных копий является использование star (см. Последнюю версию этой программы в schilytools ), поскольку эта программа реализует кольцевой буфер произвольного размера, который находится между процессом файловой системы и другим процессом, который выполняет архивный ввод-вывод. , Если размер FIFO выбран правильно, почти все файлы читаются с использованием одного системного вызова read() и это делает его (вместе с оптимизированным кодом) действительно быстрым.

Этот кольцевой буфер называется FIFO и по умолчанию использует 8MB , но может быть предписано использовать любой размер. Максимальное полезное значение составляет половину объема RAM в машине.

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

Вы можете взглянуть на страницу руководства: http://schilytools.sourceforge.net/man/man1/star.1.html

Обратите внимание, что на этой странице руководства рекомендуется делать резервные копии не из действующей файловой системы, а из snapshot на уровне файловой системы.