DD imagem menor que a unidade copiada

Question

Eu fiz um backup do disco do sistema operacional do meu servidor por meio de um USB ativo. Usando o comando:

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

O comando foi concluído sem erros e a imagem foi criada. O img.gz é de 16 GB

(o sistema operacional do servidor ocupa ~ 15gb de armazenamento), mas quando eu abro o arquivo .gz no winrar, ele me diz que o conteúdo é de apenas 2,21 GB e o arquivo tem 16 GB.

Isso significa que houve um erro no processo de backup ou é normal que o arquivo seja maior do que a imagem dentro dele?

Obrigado

    

Answer 1

Backups

Em primeiro lugar, alguns conselhos sobre backups em geral: você não pode confiar em um backup até ter testado e verificado se o processo de restauração funciona. Existem alguns métodos para testar backups:

• Uma restauração completa para hardware físico, se você tiver o hardware à mão e for um backup crítico.
• Uma restauração completa para uma máquina virtual, se você não tiver hardware sobressalente.
• Como extrair dados e verificar a correção e a integridade, se você não se importar em restaurar um sistema operacional inicializável.

Eu geralmente não consideraria a verificação do tamanho descompactado com o WinZip como algo particularmente útil. No entanto, os resultados obtidos poderiam indicar que você forneceu um count incorreto, o que nos leva a ...

Problemas com o comando dd

count=(30 gb worth of sectors)

Meu primeiro pensamento ao ver isso é que você nunca deve especificar um count ao fazer o backup de uma unidade. Se você quiser fazer o backup de uma partição específica, use um dispositivo de bloco de partição ( /dev/sdXN , em que N é um número). Caso contrário, você deve apenas deixar dd tomar a unidade inteira; especificando um count você arrisca (na verdade, quase garante) que você estará descartando dados e possivelmente corrompendo o sistema de arquivos.

Em um comentário, você forneceu o raciocínio:

The drive is 500gb and I gave my last spare HDD to a friend so I didn't have anywhere to dump the file that could accommodate a 500gb image. Since the os is only ~15 gb of space, I specified a count that would equal 30gb of sectors just to be safe

Infelizmente, não é assim que os sistemas de arquivos funcionam. A maioria dos sistemas de arquivos não garante que todos os dados sejam armazenados no início da unidade.

Alternativas

Existem algumas outras maneiras de fazer o que você quer.

Arquivando apenas arquivos / dados

Se você quiser apenas um backup de dados e não se importar muito com a possibilidade de restaurar um sistema operacional inicializável, só poderá fazer o backup de arquivos com o comando tar . Isso significa que você ainda terá seus dados, mas terá que reinstalar um sistema operacional a partir do zero e recuperar manualmente os dados (e quaisquer aplicativos instalados).

1. Copie arquivos para um arquivo com tar canalizado para gzip .

Backups compactados com espaço livre zerado

Isso é mais ou menos o que você já tentou. Você tem a idéia certa com gzip : esperamos que ele comprima qualquer espaço não utilizado ( muito compressível) para nada. Você só precisa soltar o count do seu comando.

Infelizmente, isso não funcionará necessariamente porque arquivos excluídos ainda podem existir no disco e não aparecerão como vazios em gzip . Portanto, você deve limpar o espaço não utilizado primeiro. Seu processo de backup se torna:

1. Limpar espaço não utilizado com zerofree ou similar
2. Copie a unidade para uma imagem compactada com dd (sem count !) canalizada por gzip

Use uma ferramenta que faça backup apenas de blocos usados, por exemplo, %código%

Existem algumas ferramentas, como partclone , que são inteligentes o suficiente para reconhecer e fazer backup somente de blocos usados. O Wiki do Arch tem alguns exemplos sobre uso com partclone , e o manual tem alguns exemplos abaixo. Isso substitui efetivamente gzip no seu pipeline.

Você precisará usar a mesma ferramenta novamente ao restaurar os dados.