最近我的旧 SSD(包含系统的 /root + /home 分区)坏了(详细信息在这个问题中),然后我去买了一个新的。现在我想克隆它,但遇到了以下问题:
$ 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 还可以用。由于损坏,系统经常死机,但我仍然可以解锁、安装和使用它。我可以访问所有数据(据我所知),使用完整备份tar
也很好用。
我更喜欢直接克隆而不是逐个文件(或tar
)复制的原因是:
- 方便
- 速度
- 磁盘上的加密相当复杂,我不想再次重新设置
本网站建议conv=noerror
与 一起使用dd
,但我不确定这是否安全。我对dd_rescue
和 clonezilla 的也有同样的担忧-rescue
。
问题:如何安全地将旧 SSD 克隆到新 SSD 上,md5sum
事后检查是否足以确保克隆 100% 成功?
我上面链接的网站建议使用 gparted 检查克隆是否成功,但据我所知,gparted 不适用于 LUKS 加密分区。(事情变得更加复杂:LUKS 标头已分离。)
附加问题:我的驱动器解密是在启动时完成的,使用 grub 和分区的 ID(不是 UUID)。我只需更新 crypttab 和 grub 配置中的 ID 就足够了吗,还是我需要做更多?
编辑:我刚刚意识到这md5sum
很可能也会无法读取驱动器。还有其他方法可以安全地判断克隆是否成功吗?
更新:所以我尝试了 clonezilla 的选项-rescue
。它似乎工作并且我可以解锁 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
所以我猜这并没有按计划进行。有人有更好的主意吗?
更新2:我在新驱动器的分区上运行了fsck.ext4 -yv
。错误太多了。有数百万个。现在我可以挂载它了,但几乎所有文件都丢失了。/home 目录和许多其他目录完全消失了。上面应该有大约 30-35GB 的数据。现在只有 53MB。
我唯一的选择真的是回滚tar
我拥有的备份吗?我在想也许一对一的 rsync 复制更好,因为这样可以报告特定文件是否损坏/无法读取,对吗?我--verify
在创建tar
存档时使用了它,它没有报告任何错误。
答案1
按照我在问题中所述操作后,我最终做了以下操作:
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
所以我猜想这些文件存在读取错误。我最终保留了这些文件,因为我有备份,稍后我会手动复制它们。
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) 更改设备路径(使用 UUID)/etc/fstab
2) 更改设备路径(使用by-id
)/etc/default/grub
3) 由于我现在无法 chroot 到我的系统中,因此我grub.cfg
直接修改了以反映磁盘的更改by-id
- 但是更好的做法是不这样做,而是 chroot 到根系统并重新配置 GRUB 引导加载程序。我从新的 SSD 启动到系统后立即执行了此操作。
它比我所希望的要复杂得多,但至少它安全地运行了。
答案2
首先,我建议不要使用 SSD 或在其上运行测试,因为这可能会导致驱动器继续出现故障,我曾经修理过一个驱动器,在对其进行一些完整性检查后,它根本不允许自己被读取。如果您仍然能够从单独的系统看到它,那么它应该仍然可以保存,尽管使用可能会导致芯片停止读取,所以我会在做任何其他事情之前尝试完整克隆。我建议从 USB 使用 Clonezilla,以便在克隆期间避免对 SSD 进行不必要的读取/写入。当您克隆它时,md5sum 是确认所有内容都存在的最佳方法,尽管如果它出现故障,它可能不可靠。使用克隆操作系统或硬件克隆器的好处是所有数据都是逐扇区复制的。