Làm thế nào tôi có thể tái hòa nhập một pv bị mất và tìm thấy vào một LVM vg?

Gần đây tôi đã mất một RAID là một ổ đĩa vật lý của một trong các nhóm âm lượng LVM linux của tôi. Tôi đã kết thúc việc làm vgreduce --removemissingvà bắt tay vào công việc khôi phục dữ liệu.

Chà, hôm nay tôi thấy rằng RAID (nó đang bị ẩn, đừng hỏi).

# pvdisplay -m /dev/md2
  WARNING: Volume group mg20 is not consistent
  "/dev/md2" is a new physical volume of "499.87 GiB"
  --- NEW Physical volume ---
  PV Name               /dev/md2
  VG Name               
  PV Size               499.87 GiB
  Allocatable           NO
  PE Size               0   
  Total PE              0
  Free PE               0
  Allocated PE          0
  PV UUID               SUXIe9-B4xG-Qlbz-5cSd-f1dh-cRQh-vOF4qz

mg20không nhất quán vì PV bị mất và tìm thấy /dev/md2có thể chứa các bản sao của danh mục khối lượng logic cũ có đề cập đến hệ thống tệp sống /dev/md2.

Làm thế nào để tái hòa nhập /dev/md2vào mg20và duy trì hệ thống tập tin mà sống trên đó? (và tự cứu mình khỏi những rắc rối khi khôi phục nội dung của nó) Một yếu tố đơn giản hóa là /dev/md2chỉ chứa một LV và LV hoàn toàn được chứa trong đó /dev/md2.

— Bob đột biến
nguồn

Tôi tìm thấy một số thông tin hữu ích tại redhat.com/archives/linux-lvm/2007-November/msg00040.html redhat.com/archives/linux-lvm/2007-November/msg00039.html xoay quanh bộ lọc trong lvm.conf, nhưng không thể khai thác nó một cách chính xác, vì PV dường như đã bị loại bỏ khối lượng logic của nó, có lẽ vì các bộ lọc của tôi không đủ hạn chế ("a | / dev / md2 |" khớp / dev / md20). Có thể là nếu tôi cẩn thận hơn, tôi có thể tránh được sự ô nhiễm chéo của siêu dữ liệu VG mới đối với PV bị mất và tìm thấy.

— Mutant Bob

Tôi đã tìm ra một cách để phục hồi cuộc đột kích. Các hệ thống LVM hiện đại tạo ra các bản sao lưu cấu hình VG khá thường xuyên. Bạn có thể thấy một danh sách các bản sao lưu của bạn và các lệnh đã kích hoạt chúng bằng cách sử dụng vgcfgrestore --list. Tôi đã chọn cái trước đó khi tôi làm vgreduce --removemissingvà tìm thấy các bit có liên quan bên trong nó:

pv8 {
        id = "SUXIe9-B4xG-Qlbz-5cSd-f1dh-cRQh-vOF4qz"
        device = "unknown device"       # Hint only

        status = ["ALLOCATABLE"]
        flags = ["MISSING"]
        dev_size = 1048312832   # 499.875 Gigabytes
        pe_start = 2048
        pe_count = 127967       # 499.871 Gigabytes
}

và

homes18 {
        id = "d7yt43-PMTv-XnsH-qAff-3d5A-ilB6-eQB0Jy"
        status = ["READ", "WRITE", "VISIBLE"]
        flags = []
        segment_count = 1

        segment1 {
                start_extent = 0
                extent_count = 89600    # 350 Gigabytes

                type = "striped"
                stripe_count = 1        # linear

                stripes = [
                        "pv8", 0
                ]
        }
}

Vì vậy, tôi đã tạo một bản sao của tập tin đó và xóa "MISSING"khỏi flags =. Tôi cũng đặt device = "/dev/md2", mặc dù điều đó có lẽ không cần thiết. Tôi đã thực hiện một vgcfgrestore -f /etc/lvm/archive/mg20_synthetic-2015.vg mg20và bây giờ mg20 / homes18 của tôi đã trở lại và vượt qua một fsck.

Thành thật mà nói, tôi không thực sự hài lòng với điều này như một câu trả lời. Đó là một chút quá mức cần thiết để khôi phục cấu hình ENTIRE.

Tôi nghĩ rằng một câu trả lời thực sự có thể liên quan lvcreate -Z n, nhưng tôi quá lười biếng để thực hiện các thí nghiệm cần thiết để xác minh điều này.

— Bob đột biến
nguồn