web-dev-qa-db-ja.com

わずかに損傷したSSDを新しいSSDに適切に複製する方法

そのため、最近、古いSSD（システムの/ root +/homeパーティションを含む）が壊れて（詳細 この質問で ）、新しいSSDを入手しました。今、私はそれを複製したかったのですが、次の問題に遭遇しました：

$ pv /dev/sdd > /dev/sda
4.24GiB 0:00:18 [ 234MiB/s] [==>                          ]  7% ETA 0:03:55
pv: /dev/sdd: read failed: Input/output error

$ dd if=/dev/sdd of=/dev/sda bs=1M status=progress
dd: error reading '/dev/sdd': Input/output error
4397+1 records in
4397+1 records out
4611493888 bytes (4.6 GB, 4.3 GiB) copied, 22.0249 s, 209 MB/s

古いSSDはまだちょっと動作します。破損しているためにシステムがフリーズすることがたくさんありますが、ロックを解除してマウントし、それでも問題なく使用できます。すべてのデータ（AFAIK）にアクセスでき、tarを使用した完全バックアップもうまく機能しました。

ファイルごと（またはtar）のコピーよりも直接クローンを好む理由は次のとおりです。

  1. 利便性
  2. 速度
  3. ディスクの暗号化がかなり複雑なので、再度セットアップしたくない

このウェブサイトconv=noerrorをddと一緒に使用することをお勧めしますが、これが安全かどうかはわかりません。 dd_rescueとclonezillaの-rescueについても同じ懸念があります。

質問：古いSSDを新しいSSDに安全に複製するにはどうすればよいですか？後でクローンが作成されたことを確認するのに十分なmd5sumチェックです。 100％成功しましたか？

上でリンクしたWebサイトでは、gpartedを使用してクローンが成功したかどうかを確認することを提案していますが、AFAIKgpartedはLUKS暗号化パーティションでは機能しません。 （さらに複雑にするために：LUKSヘッダーは切り離されています。）

ボーナス質問：ドライブの復号化は起動時にgrubとパーティションのID（UUIDではない）を使用して行われます。 crypttabとgrubの設定でIDを更新するだけで十分ですか、それとももっと行う必要がありますか？

編集：md5sumもドライブの読み取りに失敗する可能性が高いことに気づきました。クローンが成功したかどうかを安全に判断する他の方法はありますか？

UPDATE：そこで、-rescueオプションを指定してclonezillaを試しました。 動作しているようで、LUKSコンテナのロックを解除してLVMを表示できますが、ルートパーティションをマウントしようとすると次のようになります。

$ Sudo mount /dev/mapper/vvg-root /mnt/sda
mount: wrong fs type, bad option, bad superblock on /dev/mapper/vvg-root,
       missing codepage or helper program, or other error

dmesgからの関連データ：

[ 4686.401702] JBD2: no valid journal superblock found
[ 4686.401707] EXT4-fs (dm-3): error loading journal

だから、それは計画通りに機能しなかったと思います。誰かもっと良いアイデアがありますか？

UPDATE2：新しいドライブのパーティションでfsck.ext4 -yvを実行しました。私はエラーで溢れていました。数百万で。これでマウントできましたが、ほとんどすべてのファイルが欠落しています。/homeディレクトリは、とりわけ、完全になくなっています。その上に約30〜35GBのデータがあるはずです。今では53MBです。

私の唯一のオプションは、私が持っているtarバックアップを本当にロールバックすることですか？特定のファイルが破損している/読み取れない場合に報告されるので、1対1のrsyncコピーの方が良いと思いますよね？ tarアーカイブを作成したときに--verifyを使用しましたが、エラーは報告されませんでした。

linuxhard-drivessdcloneluks
5
confetti

私の質問で述べたことをした後、私は次のことをすることになりました：
1）CloneZillaのコピーが失敗した後、新しいSSDのLVMを削除します。
2）うまく機能したので、外側のdm-cryptはそのままにしました。
3）新しいLVMを再作成し、新しい（より大きな）SSDに合うようにすべてのサイズを変更しました。
（これは私の場合にのみ関連するため、フォントが小さくなります。質問の更新を参照してください）

今クローンのために：

1）両方のSSDのルートパーティションを、ロックを解除した後、通常はライブシステムにマウントしました。

# unlock the LUKS containers with cryptsetup first
mount /dev/mapper/ovvg-root /mnt/oldssd
mount /dev/mapper/vvg-root /mnt/newssd

2）rsyncを使用してファイルのクローンを作成しました：

rsync -ahv --progress /mnt/oldssd /mnt/newssd

3）すべてのフォルダのサイズが一致することを確認しました。

du -cs /mnt/oldsdd/* && echo " " && du -cs /mnt/newssd/*

4）すべてのファイルがそこにあることを確認し、再確認します。

find /mnt/oldssd | cut -d "/" - f 4- | sort > oldssd.txt
find /mnt/newssd | cut -d "/" - f 4- | sort > newssd.txt
diff oldssd.txt newssd.txt

newssd.txtに8つのファイルが存在しなかったので、それらに読み取りエラーがあったと思います。バックアップがあるので、これらのファイルをそのままにしておくことになりました。後で手動でコピーします。

5）チェックサムをチェックして、私の妄想をさらに満足させました。

cd /mnt/oldssd && find . -type f -exec md5sum {} \; | sort > /root/oldssd_md5.txt
cd /mnt/newssd && find . -type f -exec md5sum {} \; | sort > /root/newssd_md5.txt
cd /root && diff oldssd_md5.txt newssd_md5.txt

出力がまったくない-すべてのファイルが同じであることを意味します！

おまけの質問は：

1）/etc/fstabのデバイスパスを（UUIDを使用して）変更します
2）by-idのデバイスパスを（/etc/default/grubを使用して）変更します
3）現在、システムにchrootできないため、ディスクのgrub.cfgの変更を反映するように、by-idを直接変更しました。ただし、これを行わず、代わりに、ルートシステムにchrootして、GRUBブートローダーを再構成します。新しいSSDからシステムに起動した後、すぐにこれを行いました。

思っていたよりも複雑でしたが、少なくとも安全に機能しました。

0
confetti

まず、SSDを使用したり、SSDでテストを実行したりしないことをお勧めします。これは、ドライブの障害が続く可能性があるためです。修理中のドライブがあり、整合性チェックを実行した後、それ自体が失敗する可能性があります。まったく読まれる。それでも別のシステムから表示できる場合は、保存できるはずですが、使用するとチップの読み取りが停止する可能性があるため、他の作業を行う前に完全なクローンを試してみます。クローン作成中にSSDを不要な読み取り/書き込みから遠ざけるために、USBからClonezillaを使用することをお勧めします。クローンを作成したら、md5sumがすべてを確認するための最良の方法ですが、失敗した場合は信頼できない可能性があります。クローンOSまたはハードウェアクローンを使用することの利点は、すべてのデータがセクターごとにコピーされることです。

0
Willyuiop