Файловая система смонтирована на /home, которая имеет 2.6PB дискового пространства. В настоящее время в каталоге /home разбросано более 300TB данных. Я собираюсь сделать резервную копию всех 300TB+ данныхв повседневной жизнив /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, независимо от того, хорошо ли они сжаты — или даже не сжаты вообще — или нет, за короткое время. Большое спасибо.
решение1
Поскольку вы уже определили, что не сможете создать резервную копию всего объема в 300 ГБ в течение установленного 24-часового периода, вам необходимо пересмотреть свои требования.
На уровне файлов инкрементальный инструмент, такой как star, duplicity, или даже rsync/, rsnapshotможет все еще занять больше одного дня для создания базовой резервной копии, но после этого он должен быть значительно быстрее. Очевидно, это будет зависеть от количества и размера файлов, которые изменяются в течение каждого 24-часового периода резервного копирования.
На уровне файловой системы моментальный снимок может быть достаточным для ваших нужд (хотя это не совсем резервная копия), особенно потому, что вы можете сделать настоящую резервную копию моментального снимка в свободное время, не обращая особого внимания на время, необходимое для ее завершения. Как и прежде, после того, как базовая резервная копия была создана, ваши инкрементные копии могут занять значительно меньше времени для создания.
Вы не указали, как должна храниться ваша резервная копия, но для многих небольших файлов rsnapshotможет подойти что-то вроде . (Я использую его для резервного копирования на основе файлов многих наших внутренних файловых серверов, поскольку он обеспечивает нам простой доступ к отдельным файлам для восстановления.)
Кстати, резервное копирование на другой диск на том же хосте не следует считать безопасным. Было бы гораздо лучше сделать резервное копирование на другой хост вообще. (Если /home/fs_backupэто удаленное монтирование с другого сервера, серьезно рассмотрите возможность использования duplicityили rsync/ rsnapshotдля прямого взаимодействия с удаленным хостом, а не через удаленно смонтированную файловую систему.)
решение2
Самый быстрый известный мне метод резервного копирования — это использование star(см. последнюю версию этой программы в schilytools), поскольку эта программа реализует кольцевой буфер произвольного размера, который находится между процессом файловой системы и другим процессом, который выполняет архивный ввод-вывод. Если размер FIFO выбран правильно, почти все файлы считываются с помощью одного read()системного вызова, и это делает ее (вместе с оптимизированным кодом) действительно быстрой.
Этот кольцевой буфер называется FIFOи по умолчанию использует 8MB, но может быть указан использовать любой размер. Максимальное полезное значение — половина от суммы RAMв машине.
starтакже поддерживает работу с инкрементными дампами, а полный дамп с последующим инкрементным дампом — это то, что я рекомендую для сохранения содержимого файловой системы таким образом, чтобы на последнем этапе требовалось немного времени.
Возможно, вам будет интересно взглянуть на страницу руководства:http://schilytools.sourceforge.net/man/man1/star.1.html
Обратите внимание, что в этой странице руководства рекомендуется выполнять резервное копирование не с работающей файловой системы, а с snapshotуровня файловой системы.