Я хотел сделать резервную копию всего моего сервера, который размещен. Поэтому я использовал dd и gzip, чтобы уменьшить размер файла. Диск был 500 ГБ, но с использованием менее 5%. Мне удалось dd
весь раздел в gzip-файл размером 200 ГБ через Интернет до моего дома за 8 часов. Сейчас я пытаюсь распаковать файл в раздел на новый диск. Это заняло более 8 часов, и, конечно, я не могу определить прогресс.
Могу ли я сделать это лучше в следующий раз?
Вы не хотите (ab) использовать dd
таким образом. Это приведет к потере времени на копирование 95% диска, который не используется, и вы получите испорченный образ, если он будет подключен для чтения / записи в то время. Если вы хотите сделать резервную копию системы, лучше всего убедиться, что вы отключили все службы, которые могли бы выполнять запись на диск, и использовали tar
.
Самый простой способ посмотреть на ход работающего процесса gzip - просто посмотреть на размер записанного файла, возможно, в сочетании с watch
, если вы хотите обновления в реальном времени. Если вы имеете дело с разделами, это, конечно, нелегко.
Альтернативой для оценки прогресса является использование iotop
. iotop
покажет вам скорость, с которой данные записываются на диск каждым процессом в системе, ваш процесс gzip
, скорее всего, будет отображаться сверху и даст вам количество обработанных данных в секунду. Затем просто умножьте МБ / с на продолжительность процесса (см. Колонку ps auxw
НАЧАТЬ), и вы получите приблизительное представление о том, сколько времени это займет.
Что касается дальнейших запусков резервного копирования: Используйте rsync
, если вы хотите скопировать данные с одного компьютера в сети на другой. rsync
обрабатывает сжатие и дельты, поэтому вам нужно только передать данные, которых у вас еще нет, что делает его очень быстрым для регулярных обновлений. rsync также имеет опции --backup
и --backup-dir
, которые можно использовать для создания не только копий, но и надлежащих резервных копий, которые отслеживают удаленные файлы.
А при выполнении дизкимажей partimage
является хорошей альтернативой dd
, поскольку в отличие от dd
partimage
поддерживает файловую систему и будет копировать только блоки, фактически используемые файловой системой, а не пустые неиспользованные блоки Таким образом, он может создавать гораздо меньшие образы дисков в большинстве пустых файловых систем. Но это не очень хороший инструмент для резервного копирования по сети, используйте вместо него rsync
.
Вот статья, которую я видел с некоторыми тестами для gzip и некоторыми другими алгоритмами сжатия: http://tukaani.org/lzma/benchmarks.html . Я предполагаю, что время распаковки зависит от скорости вашего процессора. Кроме того, если вы посмотрите на тесты, кажется, что декомпрессия почти всегда быстрее, чем сжатие.
Редактировать:
В ответ на ваш последний вопрос о других способах резервного копирования вашего сервера я нашел эту статью, в которой рассказывается о различных методах резервного копирования: http://www.techrepublic.com/ блог / 10things / 10-выдающий-Linux-резервное копирование-утилита / 895 . Я не уверен, какой у вас есть доступ к серверу, но если это обычный коммерческий хост, вы можете спросить техподдержку, как вам следует это сделать.
Ваш хостер должен предоставить вам план резервного копирования и (наиболее предпочтительно) веб-интерфейс для средств резервного копирования и восстановления. Лучше всего спросить их, позволяют ли они вам получить доступ к копии автоматической резервной копии.
Как правило, распаковка в gzip должна выполняться быстрее, чем сжатие. Я подозреваю, что проблема здесь в том, что целевой диск медленнее, чем диск, с которого он был сжат: или, возможно, вы читаете и пишете на тот же физический диск, что вызывает много запросов.
Другие ответы верны, что обычно лучше делать резервные копии файлов, чем необработанное устройство.
Чтобы увидеть прогресс, я бы установил pv
, а затем сказал что-то вроде этого:
zcat /tmp/myimg.gz |pv -s500G > /tmp/myimg