これは私の自宅のファイル保存設定でした。 RAID設定は冗長性を目的としているため、バックアップはありません。私は何が起こったのか説明せず、代金を払っています。セットアップ：
- Ubuntu 16.04
- mdadm（4 x 2 TB）を使用した4ディスクRAID 5アレイ：/ dev / md0
- アレイ上では、LVMによって管理されるPVとLV。
- vg0という名前の論理ボリューム上のXFSファイルシステム。
/ etcと/ bootを含むLinuxホストは別のディスクにインストールされており、完全にアクセス可能です（したがって/ etc / lvm / archiveにアクセスできます）。 RAIDアレイは純粋にファイルストレージです。ブートプロセスは/ etc / fstabのエントリ以外には依存しません。
どういうわけか私が理解するのに苦労していたFreeDOSインストーラから起動しました。覚えているわけではありませんが、このボリュームを再分割するように言ったのかもしれません。いずれにせよ、私がLinux（Ubuntu 16.04）を再起動したとき、私はrootユーザーとしてリカバリモードのプロンプトに落ちました。 / etc / fstabに定義されているボリュームグループのUUIDをマウントできませんでした。
このRAIDアレイを最初にセットアップしてから、LVMの機能を完全に忘れたか、ボリュームの作成にLVMを使用したことさえあるので、十分な長さがあります。 （10 - 12年、その間に時々ハードディスクを交換し、アレイのサイズを変更することもありました。）それで、最初にtestdiskを使おうとしました。 1 ]をクリックしてパーティション情報を見つけて復元します。これは決してうまくいきませんでした、パーティションは常に不正確なサイズ（4.5TBの代わりに524Gb）であり、そして決して「物理的セクター境界」上にありませんでした。パーティションを完全に復元するための魔法の組み合わせがあると考えて、さまざまなジオメトリを試しました。これはfdiskに従ったディスクの現在のステータスです：
$ sudo fdisk -l /dev/md0
GPT PMBR size mismatch (1098853631 != 200894463) will be corrected by w(rite).
Disk /dev/md0: 4.1 TiB, 4500904476672 bytes, 8790829056 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 1048576 bytes / 3145728 bytes
Disklabel type: dos
Disk identifier: 0x00000000
Device Boot Start End Sectors Size Id Type
/dev/md0p1 1 1098853631 1098853631 524G ee GPT
Partition 1 does not start on physical sector boundary.
そして別れ：
(parted) print list
Error: /dev/md0: unrecognised disk label
Model: Linux Software RAID Array (md)
Disk /dev/md0: 4501GB
Sector size (logical/physical): 512B/4096B
Partition Table: unknown
Disk Flags:
testdiskフォーラムに質問を投稿する際には 2 ]、私はRAIDアレイを管理するためにLVMを使っていたこと、そしてこれらが伝統的なパーティショニングツールをまったく使わないことが可能であることに気付きました。 「lvm物理ボリュームの回復」の研究開発 http://blog.adamsbros.org/2009/05/30/recover-lvm-volume-groups-and-logical-volumes-without-backups/ 。 pvckは私に次のように伝えます：
$ sudo pvck /dev/md0
Incorrect metadata area header checksum on /dev/md0 at offset 4096
Found label on /dev/md0, sector 1, type=LVM2 001
Found text metadata area: offset=4096, size=192512
Incorrect metadata area header checksum on /dev/md0 at offset 4096
/ etc / lvm / archivesにLVMボリュームのバックアップもいくつかあります。最新のものは次のとおりです。
crw@bilby:~$ sudo cat /etc/lvm/archive/vg0_00002-935168089.vg
# Generated by LVM2 version 2.02.98(2) (2012-10-15): Sun Jul 19 12:00:04 2015
contents = "Text Format Volume Group"
version = 1
description = "Created *before* executing 'lvextend /dev/vg0/lv0 /dev/md0'"
creation_host = "bilby" # Linux bilby 3.16.0-43-generic #58~14.04.1-Ubuntu SMP Mon Jun 22 10:21:20 UTC 2015 x86_64
creation_time = 1437332404 # Sun Jul 19 12:00:04 2015
vg0 {
id = "Q4ZRRc-1l0h-FEgu-jrxA-EfW1-tAis-vv0jyL"
seqno = 5
format = "lvm2" # informational
status = ["RESIZEABLE", "READ", "WRITE"]
flags = []
extent_size = 262144 # 128 Megabytes
max_lv = 0
max_pv = 0
metadata_copies = 0
physical_volumes {
pv0 {
id = "bKQs0l-zNhs-X4vw-NDfz-IMFs-cJxs-y0k6yG"
device = "/dev/md0" # Hint only
status = ["ALLOCATABLE"]
flags = []
dev_size = 8790828672 # 4.09355 Terabytes
pe_start = 384
pe_count = 33534 # 4.09351 Terabytes
}
}
logical_volumes {
lv0 {
id = "pqInOe-ZLpV-t9oK-GQE1-AoIt-mB3M-4ImaV1"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
segment_count = 1
segment1 {
start_extent = 0
extent_count = 22356 # 2.729 Terabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 0
]
}
}
}
}
それが役に立つならば、以下はRAIDアレイの詳細です：
$ sudo mdadm --detail /dev/md0
/dev/md0:
Version : 0.90
Creation Time : Sun Oct 11 13:34:16 2009
Raid Level : raid5
Array Size : 4395414528 (4191.79 GiB 4500.90 GB)
Used Dev Size : 1465138176 (1397.26 GiB 1500.30 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Mon Oct 3 13:12:51 2016
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 1024K
UUID : 9be3b2f7:102e373a:822b5a8f:216da2f7 (local to host bilby)
Events : 0.103373
Number Major Minor RaidDevice State
0 8 64 0 active sync /dev/sde
1 8 48 1 active sync /dev/sdd
2 8 16 2 active sync /dev/sdb
3 8 32 3 active sync /dev/sdc
最後に、これが私が取り残したtestdisk.logの悲しい証です。 https://dl.dropboxusercontent.com/u/2776730/testdisk.log
編集：lsblkの出力：
crw@bilby:~$ sudo lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 59.6G 0 disk
├─sda1 8:1 0 243M 0 part /boot
├─sda2 8:2 0 1K 0 part
└─sda5 8:5 0 59.4G 0 part
├─bilby--vg-root 252:0 0 43.4G 0 lvm /
└─bilby--vg-swap_1 252:1 0 16G 0 lvm [SWAP]
sdb 8:16 0 1.8T 0 disk
└─md0 9:0 0 4.1T 0 raid5
sdc 8:32 0 1.8T 0 disk
└─md0 9:0 0 4.1T 0 raid5
sdd 8:48 0 1.8T 0 disk
└─md0 9:0 0 4.1T 0 raid5
sde 8:64 0 1.8T 0 disk
└─md0 9:0 0 4.1T 0 raid5
私は完全に道に迷っています、そして私は物事を悪化させたと思います。私の質問は：
LVMの問題に対処する前にパーティション情報を「修正」する必要がありますか？ 私は "pvcreate --uuid xxx --restorefile yyy"を試みるべきですか？それからディスクを拡張して、xfsに相当するfsckのようなものを実行する必要がありますか？それとも、この時点で私のデータは失われていますか？ ： '（
この問題のデバッグを容易にするために追加できるものがあるかどうかをお知らせください。ありがとうございます。