我有一个备份驱动器/dev/sda1，但在做了简单的操作apt-get upgrade并重新启动我的服务器后，我无法再安装它。
挂载 /dev/sda1 /backups
mount: /backups: special device /dev/sda1 does not exist.
当我设置服务器时mkfs.ext4 /dev/sda1，驱动器一直工作良好好几个星期，直到我刚刚重新启动。
这是 lsblk 和 fsck 的输出：
LSBLK
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 3.7T 0 disk
nvme0n1 259:0 0 419.2G 0 disk
├─nvme0n1p1 259:1 0 511M 0 part /boot/efi
├─nvme0n1p2 259:2 0 511M 0 part
│ └─md2 9:2 0 511M 0 raid1 /boot
├─nvme0n1p3 259:3 0 417.7G 0 part
│ └─md3 9:3 0 417.7G 0 raid1 /
└─nvme0n1p4 259:4 0 511M 0 part [SWAP]
nvme1n1 259:5 0 419.2G 0 disk
├─nvme1n1p1 259:6 0 511M 0 part
├─nvme1n1p2 259:7 0 511M 0 part
│ └─md2 9:2 0 511M 0 raid1 /boot
├─nvme1n1p3 259:8 0 417.7G 0 part
│ └─md3 9:3 0 417.7G 0 raid1 /
└─nvme1n1p4 259:9 0 511M 0 part [SWAP]
fsck /dev/sda1
fsck from util-linux 2.31.1
e2fsck 1.44.1 (24-Mar-2018)
fsck.ext2: No such file or directory while trying to open /dev/sda1
Possibly non-existent device?
fsck /dev/sda
fsck from util-linux 2.31.1
e2fsck 1.44.1 (24-Mar-2018)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/sda
The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>
Found a PMBR partition table in /dev/sda
目前的内容/etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/md3 / ext4 errors=remount-ro 0 1
/dev/md2 /boot ext4 errors=remount-ro 0 1
/dev/nvme0n1p4 swap swap defaults 0 0
/dev/nvme1n1p4 swap swap defaults 0 0
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
UUID=4497-A8EC /boot/efi vfat defaults 0 0
我尝试添加
/dev/sda1 /backups ext4 errors=remount-ro 0 1
但这/etc/fstab只会导致服务器无法启动。
fdisk -l /dev/sda
Disk /dev/sda: 3.7 TiB, 4000787030016 bytes, 7814037168 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: 0x00000000
Device Boot Start End Sectors Size Id Type
/dev/sda1 1 4294967295 4294967295 2T ee GPT
猫/进程/分区
major minor #blocks name
259 0 439548984 nvme0n1
259 1 523264 nvme0n1p1
259 2 523264 nvme0n1p2
259 3 437971968 nvme0n1p3
259 4 523264 nvme0n1p4
9 2 523200 md2
9 3 437971904 md3
259 5 439548984 nvme1n1
259 6 523264 nvme1n1p1
259 7 523264 nvme1n1p2
259 8 437971968 nvme1n1p3
259 9 523264 nvme1n1p4
8 0 3907018584 sda
测试磁盘 /log /dev/sda https://pastebin.com/raw/mUHfDubj
有谁知道可能发生了什么以及如何修复驱动器？
答案1
您的fdisk输出表明磁盘在某个时刻曾经拥有 GPT 分区表。分区类型ee只是一个虚拟的东西，它告诉只理解MBR的操作系统“这里发生了一些你无法理解的事情，请不要碰”。对于支持 GPT 的操作系统，这意味着“GPT 分区表是真实的，请阅读它”。
GPT 分区表位于磁盘的开头，就在经典的 MBR 分区之后，并且应该在磁盘的最末尾有一个 GPT 分区表的备份副本。系统无法识别它这一事实表明两个副本可能都已损坏，或者您的内核由于某种原因无法识别正确的副本。
您可以使用testdisk（应该在 Ubuntu 中作为软件包提供）来扫描分区并希望恢复它们。如果需要，请安装它，然后运行：
sudo testdisk /log /dev/sda
选择分区表类型EFI GPT并开始快速搜索。对于 3.7 TiB 磁盘，即使是“快速”搜索也可能需要一段时间。如果文件系统仍然存在于磁盘上，该工具应该检测它，确定它的开始和结束位置，并为其重建有效的分区表条目。
如果不先显示其发现结果，该工具不会覆盖任何内容。然后它会给你一个机会看看结果是否有效，如果你确定它们有效，你可以选择将更正的分区表写入磁盘。但如果您不确定，该/log选项会告诉它创建一个日志文件，然后您可以将其发布到某处并将其链接添加到您的问题中以获取更多详细信息。
答案2
您可以检查一下/dev是否还有sda1条目。如果没有，您可以创建一个。
cd /dev
ls -l sda*
编辑：NVM，因为 mknod 没有解决为什么 /dev/sda1 不是由内核创建的更深层次问题。
我将保留这个答案，因为它与其他地方相关联。