Quando você dd
- dispositivo de origem / sistema de arquivos não deve ser alterado / montado / gravado em
- não use
convcomnoerroresync, corrompe dados - adicione
bs=1M(oubs=64K) para motivos de desempenho
Além disso, se você espera que ocorram erros de leitura (portanto sync , noerror e outras opções conv ), é muito mais confiável usar ddrescue . Ele lida com erros de leitura corretamente e até mesmo tem a capacidade de repetir e retomar.
Ao todo, as cópias em nível de bloco tendem a não ser confiáveis porque é fácil cometer erros. A única razão pela qual eles são feitos é que é o único método para produzir uma cópia com consistência perfeita (somente se for feito corretamente).
Todas as outras abordagens são meramente boas o suficiente na prática, nunca perfeitas. Não há como fazer uma cópia perfeita com processos em execução que mantêm metade dos dados na memória e a outra metade no disco. Você tem que desligá-lo para obter a imagem completa. (Ou virtualize tudo e congele-o.)
Existem alternativas:
- backups baseados em arquivos usando programas de backup dedicados, como cp, rsync, ou borg
- ferramentas específicas do sistema de arquivos (xfsdump, btrfs send / snapshot, ...)
- LVM instantâneos (mas não com btrfs )
- Bancos de dados precisam de tratamento especial e fornecem suas próprias ferramentas de backup
Se deve ser uma cópia em nível de bloco, você também pode abusar do sistema mdadm para colocar uma camada RAID 1 na unidade de origem e usá-la para produzir uma cópia consistente de um sistema em execução adicionando uma unidade de destino. O RAID mantém ambos os lados em perfeita sincronia, evitando assim, principalmente, o problema de inconsistência (desde que você permita que a sincronização termine antes de remover a unidade de destino).
# RAID creation (before installing Linux)
mdadm --create /dev/md0 --level=1 --raid-devices=1 --force /dev/source
# /proc/mdstat
md0 : active raid1 sda2[3]
134306472 blocks super 1.2 [1/1] [U]
# Add the target drive.
mdadm --grow /dev/md0 --raid-devices=2 --force
mdadm --manage /dev/md0 --add --write-mostly /dev/target
# Wait for RAID resilvering.
mdadm --wait /dev/md0
sync
# Remove the target drive.
mdadm /dev/md0 --fail /dev/target
mdadm /dev/md0 --remove /dev/target
mdadm --grow /dev/md0 --raid-devices=1 --force
Mas isso é um hack e a cópia ainda aparecerá como um sistema de arquivos que não foi montado corretamente. Isso é um pouco menos pior do que uma perda de energia, já que você não consegue fazer um sync quando perde energia inesperadamente. Mas ordens de magnitude melhor do que dd , onde o estado da primeira metade da imagem é de horas após a última metade.
Eu uso esse método para espelhar minha unidade SSD única no HDD toda semana, sem impedir que o HDD fique em standby. Caso o SSD falhe, o HDD pode ser inicializado diretamente com pouco esforço.
É claro que o mesmo pode ser alcançado com uma cópia baseada em arquivo.
Já que você menciona UUIDs, clonar unidades em um nível de bloco irá clonar UUIDs, o que pode ser a causa do desaster. (No caso do hack RAID acima, eles estão convenientemente escondidos atrás da camada RAID).
A cópia baseada em arquivo para um novo sistema de arquivos terá novos UUIDs, mas é razoavelmente fácil de resolver:
-
chroot, edite/etc/fstab, atualize initramfs, reinstale o gerenciador de inicialização (você encontra o método chroot basicamente em todos os linux wiki) - Caso contrário, restaure antigos UUIDs alterando-os com
tune2fs -U <UUID>, existem ferramentas semelhantes para outros sistemas de arquivos (requer documentação, caso contrário, você não saberá quais UUIDs você precisa). Novamente, cuidado para não duplicá-los, faça isso apenas se o dispositivo antigo desaparecer completamente.