私の問題の主な部分は、以前ここで議論されました... ... しかし、これまで答えられていない特別な質問が 2 つあります。
状況: ハードウェアをアップグレードし、新しいディスクを 2 つインストールして、設定を変更しました。
これは新しい設定
PROMPT> blkid
/dev/nvme0n1p3: UUID="29cd2fd5-2cd5-455c-9ac0-7cb278e46ee3" TYPE="swap" PARTUUID="dc3d569d-363f-4f68-87ac-56e1bdb4f29d"
/dev/nvme0n1p1: UUID="D2F8-117C" TYPE="vfat" PARTUUID="cdc50870-bddc-47bf-9835-369694713e41"
/dev/nvme0n1p2: UUID="e36edd7b-d3fd-45f4-87a8-f828238aab08" TYPE="ext4" PARTUUID="25d98b84-55a1-4dd8-81c1-f2cfece5c802"
/dev/sda: UUID="2d9225e8-edc1-01fc-7d54-45fcbdcc8020" UUID_SUB="fec59176-0f3a-74d4-1947-32b508978749" LABEL="fangorn:0" TYPE="linux_raid_member"
/dev/sde: UUID="2d9225e8-edc1-01fc-7d54-45fcbdcc8020" UUID_SUB="efce71d0-3080-eecb-ce2f-8a166b2e4441" LABEL="fangorn:0" TYPE="linux_raid_member"
/dev/sdf: UUID="dddf84e3-2ec3-4156-8d18-5f1dce7be002" UUID_SUB="be5e9e9f-d627-2968-837c-9f656d2f62ba" LABEL="fangorn:1" TYPE="linux_raid_member"
/dev/sdg: UUID="dddf84e3-2ec3-4156-8d18-5f1dce7be002" UUID_SUB="1e73b358-a0c8-1c2d-34bd-8663e7906e6f" LABEL="fangorn:1" TYPE="linux_raid_member"
/dev/sdh1: UUID="6588304d-6098-4f80-836e-0e4832e2de8f" TYPE="ext4" PARTUUID="000533fc-01"
/dev/md0: UUID="7Nyd6C-oG50-b3jJ-aGkL-feIE-pAFc-5uM7vy" TYPE="LVM2_member"
/dev/md1: UUID="MtJAdS-Jdbn-2MR7-6evR-XCvL-wEm5-PUkg8p" TYPE="LVM2_member"
/dev/mapper/fg00-Data: LABEL="data" UUID="a26b7a38-d24f-4d28-ab8d-89233db95be6" TYPE="ext4"
PROMPT> mdadm -Es
ARRAY /dev/md/1 metadata=1.2 UUID=dddf84e3:2ec34156:8d185f1d:ce7be002 name=fangorn:1
ARRAY /dev/md/0 metadata=1.2 UUID=2d9225e8:edc101fc:7d5445fc:bdcc8020 name=fangorn:0
奇妙な:/dev/md/0
および/dev/md/1
ファイルはなく、およびのみ/dev/md0
である/dev/md1
PROMPT> mdadm --detail /dev/md[01]
/dev/md0:
Version : 1.2
Creation Time : Wed Oct 16 16:51:48 2019
Raid Level : raid1
Array Size : 3906886464 (3725.90 GiB 4000.65 GB)
Used Dev Size : 3906886464 (3725.90 GiB 4000.65 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Wed Oct 16 16:57:03 2019
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Consistency Policy : bitmap
Name : fangorn:0 (local to host fangorn)
UUID : 2d9225e8:edc101fc:7d5445fc:bdcc8020
Events : 2
Number Major Minor RaidDevice State
0 8 0 0 active sync /dev/sda
1 8 64 1 active sync /dev/sde
/dev/md1:
Version : 1.2
Creation Time : Wed Oct 16 16:51:56 2019
Raid Level : raid1
Array Size : 1953382464 (1862.89 GiB 2000.26 GB)
Used Dev Size : 1953382464 (1862.89 GiB 2000.26 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Wed Oct 16 16:51:56 2019
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Consistency Policy : bitmap
Name : fangorn:1 (local to host fangorn)
UUID : dddf84e3:2ec34156:8d185f1d:ce7be002
Events : 1
Number Major Minor RaidDevice State
0 8 80 0 active sync /dev/sdf
1 8 96 1 active sync /dev/sdg
これら2つのRAID1アレイの上にボリュームグループを構築し、それらを1つのパーティションにまとめ、/data
マウントとして使用します。
問題
再起動するたびに RAID が失われます。アレイの痕跡はひとつも残っていません。
はい、編集しました/etc/mdadm/mdadm.conf
PROMPT> cat /etc/mdadm/mdadm.conf
# mdadm.conf
#
# !NB! Run update-initramfs -u after updating this file.
# !NB! This will ensure that initramfs has an uptodate copy.
#
# Please refer to mdadm.conf(5) for information about this file.
#
# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
#DEVICE partitions containers
DEVICE /dev/sda /dev/sde /dev/sdf /dev/sdg
# automatically tag new arrays as belonging to the local system
HOMEHOST <system>
# instruct the monitoring daemon where to send mail alerts
MAILADDR m++++@++++++.++
# definitions of existing MD arrays
#ARRAY /dev/md1 metadata=1.2 name=fangorn:1 UUID=7068062b:a1a9265e:a7b5dc00:586d9f1b
#ARRAY /dev/md0 metadata=1.2 name=fangorn:0 UUID=9ab9aecd:cdfd3fe8:04587007:892edf3e
ARRAY /dev/md0 level=raid1 num-devices=2 metadata=1.2 name=fangorn:0 UUID=7368baaf:9b08df19:d9362975:bf70eb1f devices=/dev/sda,/dev/sde
ARRAY /dev/md1 level=raid1 num-devices=2 metadata=1.2 name=fangorn:1 UUID=dc218d09:18f63682:78b5ab94:6aa53459 devices=/dev/sdf,/dev/sdg
はい、発行しましたupdate-initramfs -u
データを復元する唯一の方法は、再起動のたびにアレイを再作成することです。
mdadm --create /dev/md0 --assume-clean --level=raid1 --verbose --raid-devices=2 /dev/sda /dev/sde
mdadm --create /dev/md1 --assume-clean --level=raid1 --verbose --raid-devices=2 /dev/sdf /dev/sdg
--assume-clean
スイッチに注意してください- LVM はすぐに再作成され、マウントできるようになります。
- データは失われません。
しかし、再起動時にシステムがアレイを再構成するようにするにはどうすればよいでしょうか?
ディスクにはすでにかなりのデータが存在するため、データを失うことなく再パーティション化できる方法がない限り、基盤となるハードウェアを再パーティション化することは望ましくありません。
アレイと LVM が稼働していなくてもデータにアクセスできますか?
追加情報
- 2019-10-22 追加
再起動直後、つまり再構築が失敗してシングルユーザー モードになっているときに、mdadm から次の出力が表示されます (mdadm.conf
その間に削除して、役立つかどうかを確認しましたが、役に立ちませんでした)。
PROMPT> mdadm --assemble --scan -v
mdadm: looking for devices for further assembly
mdadm: cannot open device /dev/sr0: No medium found
mdadm: no recogniseable superblock on /dev/sdh1
mdadm: Cannot assemble mbr metadata on /dev/sdh
mdadm: Cannot assemble mbr metadata on /dev/sdg
mdadm: Cannot assemble mbr metadata on /dev/sdf
mdadm: Cannot assemble mbr metadata on /dev/sde
mdadm: Cannot assemble mbr metadata on /dev/sda
mdadm: no recogniseable superblock on /dev/nvme0n1p3
mdadm: no recogniseable superblock on /dev/nvme0n1p2
mdadm: Cannot assemble mbr metadata on /dev/nvme0n1p1
mdadm: Cannot assemble mbr metadata on /dev/nvme0n1
mdadm: No arrays found in config file or automatically
その後、上記のように配列を再作成し、次の出力を得ました。
PROMPT> mdadm --create /dev/md0 --assume-clean --level=raid1 --verbose --raid-devices=2 /dev/sda /dev/sde
mdadm: partition table exists on /dev/sda
mdadm: partition table exists on /dev/sda but will be lost or
meaningless after creating array
mdadm: Note: this array has metadata at the start and
may not be suitable as a boot device. If you plan to
store '/boot' on this device please ensure that
your boot-loader understands md/v1.x metadata, or use
--metadata=0.90
mdadm: partition table exists on /dev/sde
mdadm: partition table exists on /dev/sde but will be lost or
meaningless after creating array
mdadm: size set to 3906886464K
mdadm: automatically enabling write-intent bitmap on large array
Continue creating array?
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
PROMPT> mdadm --create /dev/md1 --assume-clean --level=raid1 --verbose --raid-devices=2 /dev/sdf /dev/sdg
mdadm: partition table exists on /dev/sdf
mdadm: partition table exists on /dev/sdf but will be lost or
meaningless after creating array
mdadm: Note: this array has metadata at the start and
may not be suitable as a boot device. If you plan to
store '/boot' on this device please ensure that
your boot-loader understands md/v1.x metadata, or use
--metadata=0.90
mdadm: partition table exists on /dev/sdg
mdadm: partition table exists on /dev/sdg but will be lost or
meaningless after creating array
mdadm: size set to 1953382464K
mdadm: automatically enabling write-intent bitmap on large array
Continue creating array?
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
その後、もう一つやりましたlsblk
:
PROMPT> lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT
NAME SIZE FSTYPE TYPE MOUNTPOINT
sda 3,7T linux_raid_member disk
└─md0 3,7T LVM2_member raid1
└─fg00-Data 5,5T ext4 lvm /data
sde 3,7T linux_raid_member disk
└─md0 3,7T LVM2_member raid1
└─fg00-Data 5,5T ext4 lvm /data
sdf 1,8T linux_raid_member disk
└─md1 1,8T LVM2_member raid1
└─fg00-Data 5,5T ext4 lvm /data
sdg 1,8T linux_raid_member disk
└─md1 1,8T LVM2_member raid1
└─fg00-Data 5,5T ext4 lvm /data
sdh 119,2G disk
└─sdh1 119,2G ext4 part /home
sr0 1024M rom
nvme0n1 477G disk
├─nvme0n1p1 300M vfat part /boot/efi
├─nvme0n1p2 442,1G ext4 part /
└─nvme0n1p3 34,6G swap part [SWAP]
これは誰かが理解できるヒントでしょうか?
PROMPT> fdisk -l
The primary GPT table is corrupt, but the backup appears OK, so that will be used.
Disk /dev/sda: 3,65 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: ST4000DM004-2CV1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 513C284A-5CC0-4888-8AD0-83C4291B3D78
The primary GPT table is corrupt, but the backup appears OK, so that will be used.
Disk /dev/sde: 3,65 TiB, 4000787030016 bytes, 7814037168 sectors
Disk model: ST4000DM004-2CV1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 437D10E3-E679-4062-9321-E8EE1A1AA2F5
The primary GPT table is corrupt, but the backup appears OK, so that will be used.
Disk /dev/sdf: 1,84 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: ST2000DL003-9VT1
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: gpt
Disk identifier: E07D5DB8-7253-45DE-92C1-255B7F3E56C8
The primary GPT table is corrupt, but the backup appears OK, so that will be used.
Disk /dev/sdg: 1,84 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: Hitachi HDS5C302
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: E07D5DB8-7253-45DE-92C1-255B7F3E56C8
Disk /dev/md0: 3,65 TiB, 4000651739136 bytes, 7813772928 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 /dev/md1: 1,84 TiB, 2000263643136 bytes, 3906764928 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 /dev/mapper/fg00-Data: 5,47 TiB, 6000908173312 bytes, 11720523776 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
もう一つの情報
PROMPT> gdisk /dev/sda
GPT fdisk (gdisk) version 1.0.4
Caution! After loading partitions, the CRC doesn't check out!
Warning! Main partition table CRC mismatch! Loaded backup partition table
instead of main partition table!
Warning! One or more CRCs don't match. You should repair the disk!
Main header: OK
Backup header: OK
Main partition table: ERROR
Backup partition table: OK
Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: damaged
****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************
答え1
Martin L. ソリューションの別のバリエーションを紹介したいと思います。このソリューションは、システムが動作している間に新しいアレイへのデータ移行を透過的に実行できるため、ダウンタイムが大幅に短縮されるという点で異なります。移行中はディスク パフォーマンスが低下するだけです。
提案通りにしてください彼の答えの中で新しいVGを作成することを提案するところまで。
新しい VG を作成しないでください。新しく作成したアレイに新しい PV を作成し、これらの PV を使用して既存の VG を拡張しますvgextend fg00 /dev/md-NEW
。
次に、 を使用して、論理ボリュームを古い pv から新しい pv に移動しますpvmove /dev/md-OLD
。これは、ファイル システムがマウントされ、アクセスされている間でも実行できます。これには長い時間がかかりますが、最終的には終了します。私はこれを 内で実行し、 をscreen
冗長的に実行します。SSHscreen pvmove -vi5 /dev/md-OLD
セッションが閉じられて 5 秒ごとに進行状況が表示されても中断されないようにします。
新しい PV にこれを行うのに十分な PE がない場合があります。これは、ドライブ全体ではなくパーティションを使用するため、使用可能なスペースとアレイ サイズがわずかに小さくなるためです。その場合は、LV を 1 つ減らす必要があります。たとえば、FS をアンマウントし、 を ( を使用resize2fs
) して LV サイズを減らします。これには時間がかかりますが、ビジーなファイル システムをファイルごとにコピーするよりは高速です。
古い PV が空になったら (pvmove が完了)、それらを VG から削除し、PV ラベルを削除して、古いアレイを削除します。現在使用されていないドライブを消去し、パーティション分割して、実行中のアレイに追加します。アレイの再同期もバックグラウンドで実行され、完了するまでディスク パフォーマンスが低下するだけです。
mdadam --examine --scan >> /etc/mdadm/mdadm.conf
ここで、ブート、つまり、update-initramfs
などの修正を忘れないでください。
答え2
@nh2は簡単な答えだが危険かもしれない彼の答えの解決策パーティションを使用してmdadmアレイを作成する場合とディスク全体を直接使用する場合の違いは何ですか
ちなみに、このような事態が起こっても、データは失われません。おそらく
sgdisk --zap
デバイスだけを削除して、たとえばmdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdc /dev/sdd
(mdadm は過去のデータをすでに検出したことを通知し、そのデータを引き続き再利用するかどうかを尋ねます) を使用して RAID を再作成できます。私はこれを複数回試しましたが、うまくいきましたが、実行する前にバックアップを取ることをお勧めします。
長い調査の末、なんとか解決策を見つけることができました。
私がやったことはこれです
まずステータス情報
PROMPT> df -h
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
/dev/mapper/fg00-Data 5,4T 1,5T 3,8T 28% /data
次にパーティションをアンマウントします
PROMPT> umount /data
PROMPT> cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid1 sdg[1] sdf[0]
1953382464 blocks super 1.2 [2/2] [UU]
bitmap: 0/15 pages [0KB], 65536KB chunk
md0 : active raid1 sde[1] sda[0]
3906886464 blocks super 1.2 [2/2] [UU]
bitmap: 0/30 pages [0KB], 65536KB chunk
unused devices: <none>
2つのアレイを分解します
PROMPT > mdadm --manage /dev/md0 --fail /dev/sde
mdadm: set /dev/sde faulty in /dev/md0
PROMPT > mdadm --manage /dev/md1 --fail /dev/sdg
mdadm: set /dev/sdg faulty in /dev/md1
PROMPT > cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid1 sdg[1](F) sdf[0]
1953382464 blocks super 1.2 [2/1] [U_]
bitmap: 0/15 pages [0KB], 65536KB chunk
md0 : active raid1 sde[1](F) sda[0]
3906886464 blocks super 1.2 [2/1] [U_]
bitmap: 0/30 pages [0KB], 65536KB chunk
unused devices: <none>
アレイからディスクを取り外す
PROMPT > mdadm --manage /dev/md0 --remove /dev/sde
mdadm: hot removed /dev/sde from /dev/md0
PROMPT > mdadm --manage /dev/md1 --remove /dev/sdg
mdadm: hot removed /dev/sdg from /dev/md1
PROMPT > cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid1 sdf[0]
1953382464 blocks super 1.2 [2/1] [U_]
bitmap: 0/15 pages [0KB], 65536KB chunk
md0 : active raid1 sda[0]
3906886464 blocks super 1.2 [2/1] [U_]
bitmap: 0/30 pages [0KB], 65536KB chunk
unused devices: <none>
現在/dev/sde
、 と は/dev/sdg
自由に (再) パーティション化できます。
/dev/sde
そこで、/dev/sdg
提案されたとおり、使用可能なスペースよりも数 MB 小さい新しいパーティションを作成しました。- 1 つのアクティブ ディスクと 1 つの「欠落」ディスクを持つ新しい 2 ディスク RAID1 アレイを作成しました。
- 新しいアレイを物理ボリュームとして新しいLVMボリュームグループを構築しました
- その上に論理ボリュームを作成しました(パーティション作成時に失われた数MBを除いた、古いものと同じサイズ)
- 古いLVから新しいLVにすべてのデータをコピーしました
- 古いRAIDを破壊し、
ディスクのパーティションを新しいものに追加しました
これが新しい状況です
PROMPT > lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT
NAME SIZE FSTYPE TYPE MOUNTPOINT
sda 3,7T disk
└─sda1 3,7T linux_raid_member part
└─md2 3,7T LVM2_member raid1
└─fg01-Data 5,5T ext4 lvm /data
sde 3,7T disk
└─sde1 3,7T linux_raid_member part
└─md2 3,7T LVM2_member raid1
└─fg01-Data 5,5T ext4 lvm /data
sdf 1,8T disk
└─sdf1 1,8T linux_raid_member part
└─md3 1,8T LVM2_member raid1
└─fg01-Data 5,5T ext4 lvm /data
sdg 1,8T disk
└─sdg1 1,8T linux_raid_member part
└─md3 1,8T LVM2_member raid1
└─fg01-Data 5,5T ext4 lvm /data
sdh 119,2G disk
└─sdh1 119,2G ext4 part /home
sr0 1024M rom
nvme0n1 477G disk
├─nvme0n1p1 300M vfat part /boot/efi
├─nvme0n1p2 442,1G ext4 part /
└─nvme0n1p3 34,6G swap part [SWAP]
PROMPT > cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md3 : active raid1 sdf1[1] sdg1[0]
1953381376 blocks super 1.2 [2/1] [U_]
[==>..................] recovery = 10.0% (196493504/1953381376) finish=224.9min speed=130146K/sec
bitmap: 0/15 pages [0KB], 65536KB chunk
md2 : active raid1 sda1[1] sde1[0]
3906884608 blocks super 1.2 [2/1] [U_]
[=>...................] recovery = 6.7% (263818176/3906884608) finish=429.0min speed=141512K/sec
bitmap: 2/30 pages [8KB], 65536KB chunk
unused devices: <none>