记录一次系统恢复的经历

Posted 2023-05-22 jackiecui

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了记录一次系统恢复的经历相关的知识，希望对你有一定的参考价值。

开始

我的PC中装有两块NVME硬盘，其中nvme1n1用于测试性能,nvme0n1上安装有Linux/Archlinux

之前就想着，两个盘符这么相似，是不是可能会误操作，果然，今天就遇到了。

当时将nvme1n1的format格式调整为logical blocksize = 4k，所以我想验证下非4K对齐的写是不是会报错。于是：

dd if=/dev/zero of=/dev/nvme0n1 bs=4096 count=1 seek=512 oflag=direct,seek_bytes

果然把盘符写成/dev/nvme0n1了。本来这个应该还好，最多也就分区表坏了。结果这条命令成功了，我很诧异，所以想着是不是下层做了read-modify-write，所以这个差异会体现在带宽上，，所以我把count=1去掉了!!! 作大死

dd if=/dev/zero of=/dev/nvme0n1 bs=4096 seek=512 oflag=direct,seek_bytes

等我打开iostat看的时候，才发现写的是/dev/nvme0n1，于是赶紧Ctrl-C，但是dd告诉我已经写入了1.7GiB的数据了，，GG,，，，

So, what‘s next

我感觉lsblk看了下，发现了我当时的分区表如下：

nvme0n1     259:1    0 953.9G  0 disk
 ├─nvme0n1p1 259:2    0   500M  0 part /boot
 ├─nvme0n1p2 259:3    0   400G  0 part /
 ├─nvme0n1p3 259:4    0    16M  0 part
 ├─nvme0n1p4 259:5    0 552.7G  0 part
 └─nvme0n1p5 259:6    0   719M  0 part

所以分区表、boot分区、Root分区的开头1.2GiB全部挂了。

分区表还好说，通过查看内核分区表，还是可以恢复的

$ cd /dev/nvme0n1; ls -d nvme0n1p* | while read i; do echo start:$(cat $i/start) size:$(cat $i/size); done | column -t
start:2048        size:1024000
start:1026048     size:838860800
start:839886848   size:32768
start:839919616   size:1159014400
start:1998934016  size:1472512

boot分区也还好，linux kernel文件mkinitcpio -p就行，grub相关的grub-install/grub-mkconfig也还可以。不过由于boot分区也是我的EFI分区，所以windows的boot项也挂了，还得想办法修复。

但是，，Root分区也被写坏了，这就很麻烦了。好在目前系统似乎还能正常运行，我猜想由于开头的数据可能都是写入很早的数据，也就是都是系统文件，所以大部分应该在Pagecache中，所以系统还能跑。赶紧备份吧：

家目录还能读，还行整体备份到NAS
备份全部软件列表：
- pacman -Qqe > pkglist.txt
- pacman -Qtqe > pkglist.nodeps.txt
- pacman -Qtnqe > pkglist.nodeps.noaur.txt
打包Root分区
- 结果发现 ls / 已经报error了，但是 cd usr之类的还可以成功， 但是考虑到ls 失败，所以我放弃了备份root分区，后来证明，这是一个错误的决定
试图重装全部软件包，从而保证root分区上的数据被重新写一遍， 后来反思，这也是一个错误的决定，至少不应该在备份盘之前做
- pacman -S - < pkglist.txt 结果报了version不匹配之类的错误，于是：
- pacman -S -d - < pkglist.txt，然后成功
- 后来发现，这个操作对于fsck没有任何帮助，由于root inode以及其他一些inode的损坏，fsck完全无法重建整个目录树。反而，这个操作可能导致写入到原先有效的block中，从而导致有效数据被覆盖
备份整个分区
- dd if=/dev/nvme0n1p2 of=/mnt/nas/raw_disk bs=1024k
试图找资料，能否强制下刷全部page cache下盘，无论其是否dirty。结果没有发现，page cache似乎只提供了/proc/sys/vm/drop_caches功能，只能discard cache。
重新格式化boot分区，然后mkinitcpio -p, grub-install, grub-mkconfig，试图重建boot分区，但是grub-mkconfig报错，无法生成合法的grub.cfg文件

然后，，就无可奈何了，只能reboot，听天由命了。

趟坑

reboot之后，果然，只能进入到grub cmdline。我试图从grub cmdline中boot linux分区，结果linux root分区损坏无法启动，然后试图从grub cmdline中boot windows分区，结果也因为windows存放在EFI分区的bootmgr丢失，无法启动。

然后，我想从U盘启动，先恢复Windows，结果发现按<Del>/<F2>进入bios时，显示屏总是一片黑屏，完全无法操作。

我使用的主板是： rog-strix-b650e-e，之前进入BIOS都没有问题。

我怀疑了好几个地方：

BIOS对DP的支持不好 → 使用HDMI，无改变。仍旧黑屏
BIOS对AMD核显支持不好 → 从Nas上拆下GTX1060，连在PC以及显示器上。仍旧黑屏
查看BIOS QCode报错 → QCode显示A9，含义为正常进入Bios
主板灰尘太多 → 清灰。无效果

由于无法进入Bios，所以每次开机之后都只能进入grub cmdline，我抱着死马当作活马医的想法，进入到linux 的emergency mode之后，直接fsck.ext4 /dev/nvme0n1p2，直接显示root inode都不是个directory，然后还有好多其他的报错。最后没办法，硬着头皮上不断yes。最后fsck跑完之后，整个分区直接空了，全部文件都到了lost+found目录中，然后全是一堆inode编号的目录，大约有几百个。这下Linux分区算是挂到底了。

最后，我突然想到，既然每次都从内置nvme0n1启动的话，我直接把这块盘拆了看看可不可以从USB启动。结果神奇的事情发现了，，可以进BIOS了。

恢复Windows

能进BIOS就好做多了，先恢复windows。

按照这篇教程： https://woshub.com/how-to-repair-deleted-efi-partition-in-windows-7/ 走了一遍:

启动进入到windows 安装盘
在第一个界面，按Shift+F10得到一个cmd
进入到diskpart命令，list disk选中nvme0n1，list partition选中新创建的boot分区（nvme0n1p1)，然后format quick fs=fat32 label="System"格式化，然后list vol选中boot分区，assign letter=G挂载到一个盘符。
然而我发现我的windows分区nvme0n1p4没有挂载到一个盘符，从而无法下一步。然后diskpart也无法将nvme0n1p4识别为一个ntfs分区。我进入到usb-live archlinux中发现ntfs其实可以挂载这个分区，所以感觉非常奇怪。我搜索资料之后，并没有什么发现，但是突然我注意到fdisk中的分区类型，nvme0n1p4仍旧标记的是Linux filesystem，我尝试把它改成Microsoft basic data之后，再次进入到windows 安装盘后，diskpart就可以成功识别了，然后将nvme0n1p4挂载到C:
bcdboot c:\\windows /s G: /f UEFI
bcdedit可以发现显示了一个Windows Boot Manager条目，device显示partition=G：因此创建成功
wpeutil reboot重启电脑

重启之后，系统成功进入Windows,查看了一遍，一切正常。

恢复Linux

在我的fsck之后，我就意识到Linux分区彻底挂了。所以重装吧。

按着usb-live archlinux的安装步骤，又来了一遍，然后安装包的时候，使用之前备份的package list: pacman -S - < pkglist.txt

然后从Nas中恢复home分区的内容，在enable一些service：

systemctl enable lightdm
systemctl start NetworkManager && systemctl enable NetworkManager

然后yay安装aur的包，目前看上去终于一切正常了。

可惜了一个美好的周末了。

# diskgenius 记录一次 RAID1 硬盘盒数据恢复的经历

摘要

本篇文章记录了一次由于数据库被盗而引起的恢复硬盘数据的经历。我的体会：(1) 在服务器上设置数据库时切记谨慎！密码强度要足够，SSH连接切记要建立好，公开域名时，注意是否有其他不必要的文件暴露在公网下。(2) 用移动硬盘保存数据并不可靠，需要使用RAID、或者多重备份的方法保存数据。

起因

事情的起因是一个小型数据库被黑客入侵。
这个小型数据库主要是给我写的微信小程序使用的。主要保存中文和英文词语的翻译。

前几天学校反映我的小程序不能用了，让我去排除一下问题。然后，我登录了微信后台，看到了这样的错误：

看起来像是在查询字典时，后台读不到数据库了。于是登录数据库一看，结果发现，整个数据库被人篡改了！

黑客修改了数据库的密码，还留下了一封勒索信，威胁索要0.1比特币，否则就公开数据：

得了，先别追究这个数据库公不公开的事情了，赶紧恢复数据要紧。

数据恢复

当初开发这个小程序时，所有内容做了存档，存到了两年前一个RAID硬盘里，已经放在柜子里积灰很久了。就是这货：

这个硬盘阵列盒支持两块硬盘，可以组RAID1或者RAID0硬盘阵列。我当初在使用时，放了两块1T硬盘组了RAID1阵列，用来存储代码、文档信息。以前大学四年上课的内容、项目、论文、还有一些游戏存档都放在了里面。

插上线通电，系统无法识别任何信息，无法读取硬盘内容。硬盘正常转动，硬盘盒风扇不转。主控制器灯不亮，猜测是硬盘主控制器故障。

于是去沃尔玛店里又买了一块单硬盘盒。因为两块硬盘采用了RAID1搭建，所有文件在两块硬盘中都有备份。缺少的就是硬盘分区引导了。我取下了其中一块硬盘，将新硬盘盒插入计算机，检测到新硬件，但是磁盘分区显示如下：

磁盘1就是没有引导的磁盘。因为没有引导，所以windows无法识别。但是里面的文件是肯定在的，只能用软件搜寻并重建分区表，把文件找回来。