
Gostaria de saber qual seria a melhor maneira de prosseguir com a clonagem do meu disco rígido a ponto de poder simplesmente inserir a unidade clonada no meu PC e inicializá-la perfeitamente, como faço atualmente com a unidade existente.
Eu tenho um disco rígido rodando o Debian que parece estar falhando de acordo com os dados SMART. Eu tenho backups e também posso reinstalar o sistema operacional em uma nova unidade; entretanto, minha primeira preferência no momento seria clonar a unidade, e atualmente não tenho outra opção a não ser usar o System Rescue CD 5.0.3 a partir de um CD inicializável.
A unidade não tem muito espaço - provavelmente menos de 10 GB de espaço usado, com muito poucos dados, então não estou muito preocupado com o tempo porque não espero que isso leve muito tempo.
Se bem me lembro, passei pelas opções ao instalar o Debian para configurá-lo como uma unidade criptografada, então acredito que /dev/sda aparece como uma partição de inicialização não criptografada e o resto é criptografado, e então nesse "descanso", eu tem uma pequena partição raiz de 10 GB dentro da área criptografada e o restante não é usado atualmente.
Também estou lidando com unidades PATA mais antigas - sem unidades SATA disponíveis - e o computador tem um conector PATA na placa-mãe, no qual um cabo de fita PATA é conectado à unidade de CD-ROM para inicialização e quase falha no disco rígido. unidade, portanto não há espaço para conectar qualquer segunda unidade PATA para uma transferência local.
Para contornar isso, tenho um segundo computador com o mesmo conector PATA único na placa-mãe, no qual anexei outra unidade de CD-ROM para inicialização e o disco rígido de destino.
Inicializei os dois computadores por meio da unidade de CD-ROM para abrir o System Rescue CD 5.0.3 e estou considerando minhas opções para clonar a unidade com falha da melhor maneira possível.
Os computadores estão disponíveis pela LAN e estou me conectando a ambos remotamente por SSH por meio de um terminal sem interface gráfica.
Não tenho muita certeza sobre os tamanhos da unidade de origem e da unidade de destino. É possível que a unidade de origem tenha uma capacidade maior que a unidade de destino, então, idealmente, eu gostaria de transferir apenas o espaço usado, em vez de percorrer toda a unidade vazia.
Eu estava pensando em usar o ddrescue conforme descritoaqui; no entanto, descreve apenas a transferência de dados localmente.
ATUALIZAR:Estou vendo como o instalador do Debian configurou a unidade de origem. Parece que tenho três partições e apenas a última está criptografada:
src # fdisk -l /dev/sda
Disk /dev/sda: 37.3 GiB, 40027029504 bytes, 78177792 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x332e4146
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 247807 245760 120M 83 Linux
/dev/sda2 247808 8060927 7813120 3.7G 82 Linux swap / Solaris
/dev/sda3 8060928 78176255 70115328 33.4G 83 Linux
src# cryptsetup --verbose isLuks /dev/sda1
Device /dev/sda1 is not a valid LUKS device.
Command failed with code 22: Invalid argument
src# cryptsetup --verbose isLuks /dev/sda2
Device /dev/sda2 is not a valid LUKS device.
Command failed with code 22: Invalid argument
src# cryptsetup --verbose isLuks /dev/sda3
Command successful.
Acredito que também estou tentando transferir entre unidades de capacidade semelhante: uma unidade PATA de 40 GB para outra unidade PATA de 40 GB.
Aqui está o destino:
dest# fdisk -l /dev/sda
Disk /dev/sda: 37.3 GiB, 40027029504 bytes, 78177792 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
ATUALIZAR:Estou pensando em usar o NBD para expor as partições da unidade de origem na LAN para usar o ddrescue do destino.
Aqui está o que tentei até agora para expor a unidade de origem ...
src# nbd-server -d 8000 /dev/sda
...e monte localmente no computador de destino:
dest# nbd-client src 8000 /mnt/nbd-sda
Infelizmente, estou recebendo um erro ao tentar fazer isso; Não consigo nem montar o dispositivo remoto:
Warning: the oldstyle protocol is no longer supported.
This method now uses the newstyle protocol with a default export
Error: Cannot open NBD: No such file or directory
Please ensure the 'nbd' module is loaded.
Exiting.
ATUALIZAR:A próxima coisa que estou tentando é simplesmente recriar manualmente as partições na unidade de destino.
Comecei copiando o MBR:
src# dd if=/dev/sda of=/tmp/sda-mbr.dat bs=512 count=1
dest# scp root@src:/tmp/sda-mbr.dat /tmp
dest# dd if=/tmp/sda-mbr.dat of=/dev/sda
dest# sync
Antes de prosseguir, pensei que ajudaria pelo menos criar uma partição de recuperação desta vez.
dest# fdisk /dev/sda
Estou excluindo a última partição e me reservando cerca de 15 GB de espaço para uma partição final.
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x332e4146
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 247807 245760 120M 83 Linux
/dev/sda2 247808 8060927 7813120 3.7G 82 Linux swap / Solaris
/dev/sda3 8060928 45809663 37748736 18G 83 Linux
/dev/sda4 45809664 78177791 32368128 15.4G 83 Linux
Preciso criar a mesma partição criptografada no destino que /dev/sda3 na origem; Eu também poderia fazer o mesmo para esta partição de recuperação:
dest# cryptsetup luksFormat /dev/sda3 --verify-passphrase
dest# cryptsetup luksFormat /dev/sda4 --verify-passphrase
Em seguida, abra a partição de recuperação criptografada:
dest# cryptsetup open /dev/sda4 sda4-opened
dest# mkdir /mnt/sda4-open
dest# mke2fs -j /dev/mapper/sda4-opened
dest# mount /dev/mapper/sda4-opened /mnt/sda4-open
Pelo menos agora posso montar esta partição de recuperação remotamente e transferir os dados para uma unidade melhor.
Primeiro, abri a partição criptografada na unidade de origem:
src# cryptsetup open /dev/sda3 sda3-opened
src# mkdir /mnt/sda3-open
src# mount /dev/mapper/sda3-opened /mnt/sda3-open
Agora, com o df, vejo que estou usando apenas 12 GB de espaço em disco aqui.
Vamos desmontar, mas manter o mapeamento:
src# umount /mnt/sda3-open
src# rmdir /mnt/sda3-open
Agora eu queria montar a partição de recuperação na unidade de origem:
src# mkdir /mnt/dest-sda4
src# sshfs root@dest:/mnt/sda4-open /mnt/dest-sda4
Com isso montado, agora eu poderia executar o ddrescue:
src# ddrescue -f -n /dev/sda1 /mnt/dest-sda4/sda1.ddrescue.img /mnt/dest-sda4/sda1.ddrescue.log
Isso produziu uma imagem do mesmo tamanho da partição original, então parece que isso não exclui o espaço não utilizado.
Estou tentandoarquivofsarchiverem vez disso agora:
src# fsarchiver savefs /mnt/dest-sda4/sda1.fsarchiver.img.fsa /dev/sda1
Statistics for filesystem 0
* files successfully processed:....regfiles=314, directories=6, symlinks=0, hardlinks=0, specials=0
* files with errors:...............regfiles=0, directories=0, symlinks=0, hardlinks=0, specials=0
Montar /dev/sda1 e executar df mostra que ele está usando apenas 33 MB e o arquivo .fsa tem apenas 24 MB, então talvez esteja compactado. É melhor que os 120 MB originais.
Agora vamos tentar com a partição raiz sda3 para ver como funciona:
src# fsarchiver savefs /mnt/dest-sda4/sda3.fsarchiver.img.fsa /dev/mapper/sda3-opened
Provavelmente vai demorar um pouco, então estou salvando esta atualização por enquanto.
ATUALIZAR:Isso foi mais rápido do que eu esperava. Aqui está o que acabei recebendo:
dest# ls -lh
total 7.7G
drwx------ 2 root root 16K Apr 8 01:49 lost+found
-rw-r--r-- 1 root root 24M Apr 8 02:04 sda1.fsarchiver.img.fsa
-rw-r--r-- 1 root root 7.7G Apr 8 02:43 sda3.fsarchiver.img.fsa
Aqui está a parte ainda mais interessante da saída do comando acima:
src# fsarchiver savefs /mnt/dest-sda4/sda3.fsarchiver.img.fsa /dev/mapper/sda3-opened
Statistics for filesystem 0
* files successfully processed:....regfiles=149025, directories=84796, symlinks=20559, hardlinks=127551, specials=1269
* files with errors:...............regfiles=0, directories=0, symlinks=0, hardlinks=0, specials=0
Se estou lendo corretamente, isso é encorajador porque não tive nenhuma dificuldade em ler os dados da unidade de origem.
Vamos limpar alguns:
src# umount /mnt/dest-sda4
src# rmdir /mnt/dest-sda4
Em seguida, estou restaurando os arquivos arquivados de volta em /dev/sda1 e /dev/sda3 do destino, mas primeiro vamos dar uma olhada e ver o que temos na unidade de destino porque esqueci onde parei de configurá-lo.
Primeiro, existe algum sistema de arquivos em/dev/sda1?
dest# mkdir /mnt/sda1
dest# mount /dev/sda1 /mnt/sda1
NTFS signature is missing.
Failed to mount '/dev/sda1': Invalid argument
The device '/dev/sda1' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?
OK. Eu não esperava nenhum sistema de arquivos, mas não esperava uma mensagem NTFS. Então não há nada lá.
Vamos restaurar a primeira imagem da partição:
dest# fsarchiver restfs /mnt/sda4-open/sda1.fsarchiver.img.fsa id=0,dest=/dev/sda1
Statistics for filesystem 0
* files successfully processed:....regfiles=314, directories=6, symlinks=0, hardlinks=0, specials=0
* files with errors:...............regfiles=0, directories=0, symlinks=0, hardlinks=0, specials=0
Vamos montar agora:
dest# mount /dev/sda1 /mnt/sda1
dest# ls -l /mnt/sda1
...
dest$ df -h | grep sda1
...
As coisas parecem boas até agora.
Vamos fazer a partição root agora.
dest# cryptsetup open /dev/sda3 sda3-opened
dest# mkdir /mnt/sda3-open
dest# mount /dev/mapper/sda3-opened /mnt/sda3-open
NTFS signature is missing.
Failed to mount '/dev/mapper/sda3-opened': Invalid argument
The device '/dev/mapper/sda3-opened' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?
O mesmo que antes - não há nada lá.
Vamos restaurar a imagem da partição:
dest# fsarchiver restfs /mnt/sda4-open/sda3.fsarchiver.img.fsa id=0,dest=/dev/mapper/sda3-opened
Statistics for filesystem 0
* files successfully processed:....regfiles=149025, directories=84796, symlinks=20559, hardlinks=127551, specials=1269
* files with errors:...............regfiles=0, directories=0, symlinks=0, hardlinks=0, specials=0
Vamos montar agora:
dest# mount /dev/mapper/sda3-opened /mnt/sda3-open
dest# ls -l /mnt/sda3
...
dest$ df -h | grep sda3
...
As coisas parecem boas até agora.
Eu executei o seguinte também em ambos:
# fsarchiver probe simple
As coisas parecem como esperado.
Uma coisa que acredito que ainda sinto falta é que acho que isso vai bagunçar o Grub. Parece que me lembro de algo sobre a inicialização correta do Estágio 1 a partir do MBR, mas não foi possível encontrar o Estágio 2 na partição /boot quando tentei fazer algo assim da última vez.
Esta páginalevou aesse, que descreve como reparar o Grub:
dest# mount -o bind /proc /mnt/sda3-open/proc
dest# mount -o bind /dev /mnt/sda3-open/dev
dest# mount -o bind /sys /mnt/sda3-open/sys
dest# chroot /mnt/sda3-open /bin/bash
(dest) chroot# mount /dev/sda1 /boot/
(dest) chroot# grub-install /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.
(dest) chroot# umount /boot
(dest) chroot# exit
dest# umount /mnt/sda3-open/{sys,dev,proc}
Quando eu reinicio, isso deve funcionar e a unidade deve inicializar corretamente; no entanto, agora é tarde e não quero entrar nisso ainda.
Além disso, ainda não estou convencido de que isso terá um final feliz. O comando grub-install acima afirmou que está sendo instalado para i386, mas acredito que quero 64 bits.
Talvez eu precise refazer esta parte reiniciando o System Rescue CD via salvamento64. Não tenho certeza se a inicialização padrão trouxe 32 bits.
Mais uma vez, vou cuidar do resto amanhã.
ATUALIZAR:Portanto, a boa notícia é que a inicialização padrão do System Rescue CD era o Rescue64, então isso não teria sido nenhum problema.
Acontece que esqueci completamente do LVM e os UUIDs da unidade obviamente não correspondem.
...
cryptsetup: lvm is not available
cryptsetup: lvm is not available
cryptsetup: lvm is not available
cryptsetup: lvm is not available
ALERT! /dev/disk/by-uuid/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx does not exist.
Check cryptopts=source= bootarg: cat /proc/cmdline
or missing modules, devices: cat /proc/modules; ls /dev
-r Dropping to a shell. Will skip /dev/disk/by-uuid/xxxxxxxx-xxxx-xxxx-xxxx-xxxx
xxxxxxxx if you can't fix.
modprobe: module ehci-orion not found in modules.dep
BusyBox vx.xx.x (Debian x:x.xx.x-x+xxxxxx) built-in shell (ash)
Enter 'help for a list of built-in commands.
/bin/sh: can't access tty: job control turned off
(initramfs)
Suponho que poderia lutar contra isso, mas não vou me preocupar. Em vez disso, vou tentar o que o dirkt sugeriu e clonar o /dev/sda completo - UUIDs e tudo mais - já que 40 GB são apenas quatro vezes 10 GB, que transferi ontem à noite e não demorei muito. LAN.
Não pude fazer isso ontem à noite porque não consegui fazer o NBD funcionar, então recorri a salvar em arquivos de imagem. Não posso fazer isso se estiver fazendo um clone completo do disco, então vamos ver se os pipes ou pipes nomeados funcionam melhor.
Então, de volta ao início, ambos os computadores foram inicializados a partir do CD inicializável do System Rescue CD, ambos estão disponíveis na rede por meio de seus respectivos endereços IP atribuídos por DHCP e ambos tiveram sua senha root definida por meio do passwd
comando.
Antes de fazer isso com os drives reais, quero praticar com um pequeno e falso, então vou começar configurando-o.
src# dd if=/dev/zero of=/root/tempsrc.dat bs=1M count=128
...
src# fdisk -l /root/tempsrc.dat
Disk /root/tempsrc.dat: 128 MiB, 134217728 bytes, 262144 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x8b8647e7
Device Boot Start End Sectors Size Id Type
/root/tempsrc.dat1 * 2048 34815 32768 16M 83 Linux
/root/tempsrc.dat2 34816 100351 65536 32M 82 Linux swap / Solaris
/root/tempsrc.dat3 100352 262143 161792 79M 83 Linux
src# mkdir /mnt/tempsrc
src# mkdir /mnt/tempsrc-mounted
src# losetup /dev/loop1 /root/tempsrc.dat -o $(expr 2048 \* 512)
src# mke2fs /dev/loop1
src# mount /dev/loop1 /mnt/tempsrc-mounted
src# echo 'This is partition 1' > /mnt/tempsrc-mounted/note1.txt
src# umount /mnt/tempsrc-mounted
src# losetup -d /dev/loop1
src# losetup /dev/loop1 /root/tempsrc.dat -o $(expr 100352 \* 512)
src# cryptsetup luksFormat /dev/loop1 --verify-passphrase
src# cryptsetup open /dev/loop1 loop1-opened
src# mke2fs -j /dev/mapper/loop1-opened
src# mount /dev/mapper/loop1-opened /mnt/tempsrc-mounted
src# echo 'This is partition 3' > /mnt/tempsrc-mounted/note3.txt
src# umount /mnt/tempsrc-mounted
src# cryptsetup close loop1-opened
src# losetup -d /dev/loop1
src# rmdir /mnt/tempsrc-mounted
src# rmdir /mnt/tempsrc
Eu sei. Não lidei com o LVM novamente. Ah bem.
Agora tenho um /root/tempsrc.dat que contém uma imagem de um disco como uma imagem de cartão SD que desejo transferir para o destino remoto. Na primeira partição há um arquivo chamado note1.txt
, e a terceira partição é criptografada e possui um note3.txt
conteúdo diferente. Gostaria de ter certeza de que conseguirei fazer tudo isso depois de executá-lo fsarchiver
e transferi-lo.
Vamos preparar algo no destino:
dest# dd if=/dev/zero of=/root/tempdest.dat bs=1M count=128
dest# fdisk -l /root/tempdest.dat
Disk /root/tempdest.dat: 128 MiB, 134217728 bytes, 262144 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Vamos também criar dispositivos de loopback para estes:
src# losetup /dev/loop1 /root/tempsrc.dat
dest# losetup /dev/loop2 /root/tempdest.dat
Agora, enquanto eu estava me preparando para realizar a transferência, descobri que o fsarchiver não consegue lidar com isso conforme indicadoaquieaqui.
Eu esperava fazer algo como o seguinte:
src# fsarchiver savefs /tmp/fifo1 /dev/loop1
dest# fsarchiver restfs /tmp/fifo2 id=0,dest=/dev/loop2
ATUALIZAR:Substituí minha unidade de destino de 40 GB por uma terceira unidade temporária e liguei o PC de destino.
Vamos começar configurando esta nova unidade:
dest# mkdir /mnt/sda-open
dest# mount /dev/sda1 /mnt/sda-open
Tentando transferir novamente, só que desta vez operando em /dev/sda inteiro de uma só vez:
src# mkdir /mnt/dest-sda
src# sshfs root@dest:/mnt/sda-open /mnt/dest-sda
src# fsarchiver savefs /mnt/dest-sda/src-sda.fsarchiver.img.fsa /dev/sda
filesys.c#317,generic_mount(): partition [/dev/sda] cannot be mounted on [/tmp/fsa/20180408-222928-xxxxxxxx-00] as [vfat] with options []
oper_save.c#1032,filesystem_mount_partition(): cannot mount partition [/dev/sda]: filesystem may not be supported by either fsarchiver or the kernel.
removed /mnt/dest-sda/src-sda.fsarchiver.img.fsa
Bem, chega dessa ideia. Acho que eles o chamam de arquivador "FS" por um motivo. Vamos tentar partimage.
src# partimage --compress=1 save /dev/sda /mnt/dest-sda/src-sda.partimg.bz2
Isso também não funcionou; aparentemente, isso lida com sistemas de arquivos e não com discos como um todo.
Como estamos operando no disco como um todo, vamos ver se o ddrescue funcionaria agora.
src# ddrescue --no-scrape /dev/sda /mnt/dest-sda/src-sda.ddrescue.img /mnt/dest-sda/src-sda.ddrescue.img.log
GNU ddrescue 1.21
Press Ctrl-C to interrupt
ipos: 785580 kB, non-trimmed: 0 B, current rate: 12320 kB/s
opos: 785580 kB, non-scraped: 0 B, average rate: 10615 kB/s
non-tried: 39241 MB, errsize: 0 B, run time: 1m 14s
rescued: 785580 kB, errors: 0, remaining time: 1h
percent rescued: 1.96% time since last successful read: 0s
Copying non-tried blocks... Pass 1 (forwards)
Comecei às 17h41 para uma unidade de 40 GB, acho que uma LAN de 100 Mbps. No momento, a saída afirma que isso será feito em cerca de uma hora.
Responder1
Bem, parece que eu estava no caminho certo com a unidade intermediária. Não era isso que eu pretendia fazer originalmente, mas me ajudou a superar meu problema.
A nova unidade agora é um clone da unidade original e está funcionando perfeitamente.
Para clonar minha unidade original com as limitações apresentadas - em particular, exigindo passar pela LAN com um CD de resgate do sistema sem Clonezilla - consegui resolver isso da seguinte maneira.
Primeiro, conectei o disco rígido temporário de 160 GB a um PC sobressalente, conforme descrito acima, e inicializei os dois computadores com meu CD inicializável do System Rescue.
No meu src
PC, montei o disco rígido de 160 GB no dest
PC localmente usando sshfs
e executei ddrescue
conforme descrito acima para criar a imagem do disco rígido com falha no disco rígido de 160 GB como um arquivo de imagem. Esta unidade de 40 GB foi transformada em um arquivo de imagem de 40 GB e levou cerca de uma hora para ser concluída em minha LAN de 100 Mbps.
Vou manter esta imagem por perto para não ter que fazer isso de novo; deste ponto em diante, os backups incrementais dos dados deverão ser suficientes para restaurar após a captura desta imagem inicial.
Depois que essa fase foi concluída, substituí a unidade de 40 GB com falha pela unidade substituta que tem a mesma capacidade de 40 GB no src
host, sem tocar ou mesmo desligar dest
.
Então, liguei src
novamente com o CD do System Rescue inicializado, montei o dest
diretório sshfs
novamente e desta vez restaurei a partir da minha imagem com:
dest# ddrescue --force --no-scrape /mnt/dest-sda/src-sda.ddrescue.img /dev/sda /mnt/dest-sda/src-restore-sda.ddresue.img_2018-04-08.log
Isso levou cerca de mais uma hora para ser concluído.
Como esta era uma imagem de uma unidade completa - não de partições - consegui simplesmente ejetar o CD e reiniciar src
, e tudo ficou como estava.