![移动到 ssd:全新安装;或者旧 hdd 的“dd”是否“足够好”?](https://linux22.com/image/980324/%E7%A7%BB%E5%8A%A8%E5%88%B0%20ssd%EF%BC%9A%E5%85%A8%E6%96%B0%E5%AE%89%E8%A3%85%EF%BC%9B%E6%88%96%E8%80%85%E6%97%A7%20hdd%20%E7%9A%84%E2%80%9Cdd%E2%80%9D%E6%98%AF%E5%90%A6%E2%80%9C%E8%B6%B3%E5%A4%9F%E5%A5%BD%E2%80%9D%EF%BC%9F.png)
我们慷慨的管理层考虑提供 SSD 来替换笔记本电脑中的 HDD。
有人告诉我,SSD 的大小与 HDD 相同;所以我现在想知道:我是否应该简单地使用“dd”来复制我现有的 xubuntu 14.04 安装(然后,再进行列出的调整)对于该相关问题)?
或者,在该 SSD 上进行“全新”的 xubuntu 安装是否存在重大的“技术”优势?
换句话说:进行这样的“完整二进制”复制是否会对 SSD 性能、缓存等产生负面影响?
编辑 2:我当前的安装是使用“默认” ubuntu 安装程序创建的;这意味着它使用 LUKS 和 LVM。提供一些低级信息:
sudo pvs
PV VG Fmt Attr PSize PFree
/dev/mapper/sda5_crypt xubuntu-vg lvm2 a-- 465,52g 44,00m
sudo lvs
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
root xubuntu-vg -wi-ao--- 449,83g
swap_1 xubuntu-vg -wi-ao--- 15,64g
命令fdisk -lu
Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00079ee9
Device Boot Start End Blocks Id System
/dev/sda1 * 2048 499711 248832 83 Linux
/dev/sda2 501758 976771071 488134657 5 Extended
Partition 2 does not start on physical sector boundary.
/dev/sda5 501760 976771071 488134656 83 Linux
Disk /dev/mapper/sda5_crypt: 499.8 GB, 499847790592 bytes
255 heads, 63 sectors/track, 60769 cylinders, total 976265216 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000
Disk /dev/mapper/sda5_crypt doesn't contain a valid partition table
Disk /dev/mapper/xubuntu--vg-root: 483.0 GB, 483003465728 bytes
255 heads, 63 sectors/track, 58721 cylinders, total 943366144 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000
Disk /dev/mapper/xubuntu--vg-root doesn't contain a valid partition table
Disk /dev/mapper/xubuntu--vg-swap_1: 16.8 GB, 16793993216 bytes
255 heads, 63 sectors/track, 2041 cylinders, total 32800768 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000
Disk /dev/mapper/xubuntu--vg-swap_1 doesn't contain a valid partition table
猫/etc/fstab
...
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/xubuntu--vg-root / ext4 errors=remount-ro 0 1
# /boot was on /dev/sda1 during installation
UUID=b58b2697-1bf2-4ad3-80bd-4dee61e63fe4 /boot ext2 defaults 0 2
/dev/mapper/xubuntu--vg-swap_1 none swap sw 0 0
答案1
如果两个驱动器具有相同的大小,则将源驱动器克隆到目标驱动器dd
将具有与目标磁盘的完整写入完全相同的影响。
甚至在开始考虑这是否是一个问题之前,如果您需要旧驱动器上已有的所有内容并且它“足够满”,那么就不应该再有疑问了:这dd
将为您节省大量时间,而不会比全新安装对目标驱动器造成更大的磨损。
话虽如此,目标磁盘的完整写入已完成一次是不是意义重大。甚至连第二个和第三个都意义不大。
商用MLC
SSD 可以承受 2000-3000 次完整写入。更不用说SLC
SSD 了。
真正重要的是随着时间的推移您将如何使用新驱动器。如果 SSD 需要经历大量的编程/擦除循环(例如创建/删除/创建文件),其使用寿命将大幅缩短。
所以总而言之,我会盲目地寻找dd
解决方案,并关注如何通过随着时间的推移巧妙地使用它来不缩短它的寿命。
答案2
使用 LVM 工具移动所有数据是大有裨益的。以下是有关如何操作的简短信息:
获取 SSD 磁盘的 USB 连接器并将其连接到已连接 SSD 的笔记本电脑
按照与当前磁盘相同的方式重新分区你的设备(实际上如何分区并不重要,但新的 LUSK 分区应该与当前的 LUKS 分区相同或更大)
将您的启动文件夹分区复制到新的 SSD 分区。如果您的 SSD 被检测为 /dev/sdb,您可以按照以下步骤操作:
sudo mkfs.ext2 /dev/sdb1
sudo mount /dev/sdb1 /mnt
sudo rsync -a /boot/* /mnt/
sudo umount /mnt
在 /dev/sdb2(新 SSD 磁盘的第二个分区)上设置 crypt 分区,并将其附加到当前 VG(LVM 卷组)
sudo cryptsetup -y luksFormat /dev/sdb2
sudo cryptsetup luksOpen /dev/sdb2 crypt_ssd
sudo vgextend xubuntu-vg /dev/mapper/crypt_ssd
将物理数据从当前物理分区移动到新的 SSD 物理分区(确保时间足够长,确保 USB 连接到 SSD 稳定,不会发生任何中断)
sudo pvmove /dev/mapper/sda5_crypt
它会自动将所有数据移动到您的免费 SSD 加密物理分区。
由于所有移动都将在线进行,因此您应该检查启动分区的新 UUID
sudo blkid
找到 /dev/sdb1(您的新启动分区)并相应地编辑 /etc/fstab /boot UUID 条目(是的,所有文件都已在新 SSD 磁盘上,下次您只能使用此磁盘进行启动)
从卷组中删除旧磁盘
sudo vgreduce xubuntu-vg /dev/mapper/sda5_crypt
祈祷并重启(我做了大约十次这样的动作,但没有使用 LUKS,因为我看到你应该在启动时输入密码来打开你的设备
如果您对 LUKS 或 LVM 一无所知,请不要这样做,这只是建议,请随时询问更多信息或咨询您的工程师。我不希望您丢失任何数据。我建议这样做,因为dd
对于 500G 设备来说确实不太好。那里有几乎相同的问题如何将加密的 LVM 安装迁移到新磁盘但是他们创建了新的 LVM VG 并使用 rsync 复制数据(pvmove
使用块而不是文件移动数据 - 换句话说,pvmove 确实更快,并且不会破坏任何权限、位等)。我认为需要对 /etc/crypttab 进行一些编辑,但相信不需要这样做。请在移动之前备份所有必要的数据并获取 live-cd 或 usb。
编辑:
顺便说一句,回答你的主要问题,我可以说大约两年前有一个错误,使用 pvmove 在 SSD 上撕毁数据关联。如果您没有遇到任何问题,并且您不介意进行全新安装,那么这实际上也是一种保护您免受任何灾难的方法。