1

Я сделал резервную копию OS диска моего сервера через живой USB. Используя команду:

dd if=/dev/sda bs=512 count=(30 gb worth of sectors) conv=noerror,sync status=progress | gzip -c > /path/to/removable/media

Команда выполнена без ошибок, и изображение было создано. Размер файла img.gz составляет 16 ГБ.

(Операционная система сервера занимает ~ 15 ГБ памяти), но когда я открываю .gz в winrar, он сообщает, что его содержимое составляет всего 2,21 ГБ, а архив - 16 ГБ.

Означает ли это, что в процессе резервного копирования произошла ошибка или архив обычно больше, чем образ в нем?

Спасибо

1 ответ1

3

Резервные копии

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

  • Полное восстановление физического оборудования, если у вас есть удобное оборудование и оно является критически важным резервным копированием.
  • Полное восстановление виртуальной машины, если вам не хватает запасного оборудования.
  • Извлечение данных и проверка правильности и полноты, если вам не нужно восстанавливать загрузочную ОС.

Как правило, я не считаю проверку несжатого размера WinZip особенно полезной. Однако полученные вами результаты могут указывать на то, что вы указали неверный count , что приводит нас к ...


Проблемы с вашей командой dd

count=(30 gb worth of sectors)

Моя первая мысль, увидев это, заключается в том, что вы никогда не должны указывать count при резервном копировании диска. Если вы хотите создать резервную копию определенного раздела, вам следует использовать блочное устройство раздела (/dev/sdXN где N - число). В противном случае вы просто должны позволить dd взять весь диск; указав count вы рискуете (фактически, почти гарантируете), что вы отбросите данные и, возможно, повредите файловую систему.

В комментарии вы предоставили обоснование:

Накопитель емкостью 500 ГБ, и я передал свой последний запасной жесткий диск другу, поэтому у меня не было места, куда можно записать файл, который может вместить изображение размером 500 ГБ. Поскольку ОС занимает всего ~ 15 ГБ пространства, я указал количество, которое будет равно 30 ГБ секторов, чтобы быть в безопасности.

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


альтернативы

Есть несколько других способов сделать то, что вы хотите.

Архивирование только файлов / данных

Если вам нужна только резервная копия данных, и вам не нужно слишком много возможности восстанавливать загрузочную ОС, вы можете создавать резервные копии файлов только с помощью команды tar . Это означает, что у вас все еще будут ваши данные, но вам придется переустанавливать ОС с нуля и восстанавливать данные вручную (и любые установленные приложения).

  1. Скопируйте файлы в архив с помощью tar архива в gzip .

Сжатые резервные копии с нулевым свободным пространством

Это более или менее то, что вы уже пытались. У вас есть правильная идея с gzip: надеюсь, он сожмет любое неиспользуемое пространство (очень сжимаемое) до нуля. Вам просто нужно сбросить count из вашей команды.

К сожалению, это не обязательно сработает, потому что удаленные файлы могут все еще существовать на диске и не будут выглядеть пустыми для gzip . Поэтому сначала вы должны очистить неиспользуемое пространство . Ваш процесс резервного копирования становится:

  1. Очистить неиспользуемое пространство с zerofree или аналогичным
  2. Скопируйте диск в сжатый образ с помощью dd (без count !) пропустил через gzip

Используйте инструмент для резервного копирования только используемых блоков, например, partclone

Существуют некоторые инструменты, такие как partclone , которые достаточно умны, чтобы распознавать и создавать резервные копии только используемых блоков. В вики Arch есть несколько примеров использования с gzip , а в руководстве есть несколько примеров внизу. Это эффективно заменяет dd в вашем конвейере.

Вам нужно будет использовать тот же инструмент снова при восстановлении данных.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .