バックアップドライブがありますが、/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パーティションテーブルがありました。パーティションタイプは、eeMBRだけが理解しているオペレーティングシステムに「理解できないことが発生しました。触れないでください」と伝える仮想のものです。 GPTをサポートするオペレーティングシステムの場合、これは「GPTパーティションテーブルが本当であるため、お読みください」を意味します。
GPTパーティションテーブルはディスクの先頭、クラシックMBRパーティションの直後にあり、ディスクの最後にGPTパーティションテーブルのバックアップコピーが必要です。システムがそれを認識しないという事実は、両方のコピーが破損しているか、カーネルが何らかの理由で正しいコピーを認識しないことを意味します。
testdisk（Ubuntuでパッケージとして利用可能である必要があります）を使用してパーティションをスキャンして回復できます。必要に応じてインストールしてから、以下を実行してください。
sudo testdisk /log /dev/sda
パーティションテーブルの種類を選択EFI GPTしてクイック検索を開始します。 3.7TiBディスクを使用すると、「高速」検索にも時間がかかることがあります。ファイルシステムがディスクにまだ存在する場合、ツールはそれを検出し、開始位置と終了位置を決定し、その有効なパーティションテーブルエントリを再設定する必要があります。
このツールは最初に結果を表示せずに何も扱いません。その後、結果が有効であることを確認する機会が提供され、結果が有効であると確信している場合は、変更されたパーティションテーブルをディスクに書き込むことを選択できます。ただし、不明な場合は、この/logオプションを使用してログファイルを生成するように求められます。ログファイルをどこかに投稿し、質問へのリンクを追加して詳細を確認できます。