Làm cách nào để khôi phục khối lượng logic đã bị xóa bằng lvremove


12

Tôi đang dùng CentOS 5.5 và đang chạy Xen. Tôi có một nhóm khối lượng lớn mà tôi tạo ra các khối hợp lý khi sử dụng lvcreate. Hôm nay tôi có một khách hàng hủy tài khoản của cô ấy, sau đó đổi ý sau khoảng một giờ. Thật không may, tôi đã xóa LVM hình ảnh Xen của cô ấy. (chỉ sử dụng một lvremove tiêu chuẩn). Không có hoạt động LVM nào khác trên đĩa này kể từ đó (không có gì khác được thêm hoặc xóa). Có thể "hoàn tác" một lvremove hoặc khôi phục âm lượng hợp lý không? Nếu vậy, làm thế nào tôi sẽ đi về nó?

Câu trả lời:


13

LVM sao lưu siêu dữ liệu của nó /etc/lvm/backup/etc/lvm/archive. Ở đầu mỗi tệp, nó sẽ cho bạn biết thời gian / dữ liệu khi tệp được tạo nên rất có thể bạn sẽ có một bản sao của siêu dữ liệu cũ như trước khi bạn xóa LV. Tôi tin rằng sao lưu là tự động bất cứ khi nào siêu dữ liệu thay đổi.

Những điều sau đây có thể nguy hiểmphá hoại vì vậy hãy thật cẩn thận và nếu có thể hãy có một bản sao lưu đầy đủ.

Lệnh để khôi phục các bản sao lưu siêu dữ liệu volumegroup này là vgcfgrestore. Đảm bảo rằng bạn tạo một bản sao hiện tại của cấu hình làm việc hiện tại bằng cách sử dụng vgcfgbackuplệnh với cờ -f để chỉ định một tệp khác cho đầu ra để bạn không thay đổi bất kỳ tệp nào trong / etc / lvm / backup hoặc / etc / lvm / thư mục lưu trữ. Đảm bảo bạn khác cấu hình hiện tại với cấu hình bạn muốn khôi phục để xác minh rằng những thay đổi duy nhất bạn sắp áp dụng là để tạo lại LV đã bị xóa gần đây. Có một bản sao lưu đầy đủ dữ liệu của bạn có lẽ cũng không phải là một ý tưởng tồi. Bạn cũng có thể muốn xem xét liên hệ với nhà cung cấp Linux của mình để được hỗ trợ / hướng dẫn nếu bạn thuộc hợp đồng hỗ trợ trước khi tiếp tục vì tôi chưa bao giờ phải tự làm việc này.

Chúc may mắn.


1
Đọc sâu hơn vào vgcfgrestore, có vẻ như tôi sẽ cần phải tắt mọi VM trên hộp đó trước khi thử điều này hoặc có nguy cơ làm hỏng toàn bộ mảng. Có vẻ như hướng dẫn của bạn sẽ hoạt động nên tôi chấp nhận câu trả lời, nhưng dữ liệu không đáng để mạo hiểm. Cảm ơn
John P

@ John P Vâng, tôi đã hình dung với VM và tất cả điều này sẽ là một điều khó thực hiện trong một môi trường như thế. Tôi đoán người ta sẽ bỏ qua điều này là trong tương lai có lẽ thủ tục xóa tài khoản sẽ kéo dài 30 ngày không xóa.
3dinfluence

18

"Bạn có thể vui lòng cụ thể hơn nữa khi tìm thấy EFROM và ETO từ tệp sao lưu không? Tất cả các lv đều có" start_extend "từ 0 trong tệp sao lưu của tôi nên tôi hơi bị mất :) Cảm ơn! : 06 "

Ok, tôi sẽ rất cụ thể ... với cách đơn giản nhất để phục hồi âm lượng hợp lý.

Thí dụ:

1 - Tôi đã loại bỏ khối lượng logic của tôi!

$ sudo lvremove /dev/vg1/debian.root

2 - Điều đầu tiên cần làm là, tìm tệp lưu trữ tại /etc/lvm/archive/vg1_(xxxxx).vg. Tôi có thể làm điều đó, chỉ cần nhìn vào ngày mà tôi đã loại bỏ khối lượng hợp lý!

$ sudo ls -l /etc/lvm/archive |more

3- Tôi đã tìm thấy nó!

-rw------- 1 root root 16255 Mar 20 14:29 vg1_00223-235991429.vg
-rw------- 1 root root 16665 Mar 20 16:49 vg1_00224-748876387.vg
-rw------- 1 root root 17074 Mar 20 16:49 vg1_00225-931666169.vg
-rw------- 1 root root 17482 Mar 20 16:50 vg1_00226-1238302012.vg
-rw------- 1 root root 18081 **Mar 20 21:57 vg1_00227-2048533959.vg**

Ngày mà tôi đã làm lvemove !!! ... đó là một phút trước ..

4 - Hãy xem tập tin!

$ sudo head /etc/lvm/archive/vg1_00227-2048533959.vg
*# Generated by LVM2 version 2.02.95(2) (2012-03-06): Thu Mar 20 21:57:58 2014
contents = "Text Format Volume Group"
version = 1
description = **"Created *before* executing 'lvremove /dev/vg1/debian.root'"**
creation_host = "server"    # Linux server 3.8.0-35-generic #50-Ubuntu SMP Tue Dec 3 01:24:59 UTC 2013 x86_64
creation_time = 1395363478  # Thu Mar 20 21:57:58 2014*

5 - Làm một bài kiểm tra trước khi phục hồi nó!

$ sudo vgcfgrestore vg1 --test -f /etc/lvm/archive/vg1_00227-2048533959.vg
Test mode: Metadata will NOT be updated and volumes will not be
(de)activated.   **Restored volume group vg1**

6 - Ok, bây giờ lặp lại dòng lệnh, không có (--test)

$ sudo vgcfgrestore vg1 -f /etc/lvm/archive/vg1_00227-2048533959.vg
**Restored volume group vg1**

7 - Kiểm tra xem!

$ sudo lvscan |grep debian
ACTIVE            '/dev/vg1/debian.root' [7,81 GiB] inherit

8 - Nếu logic không hoạt động, hãy làm điều đó!

$ sudo lvchange -a y /dev/vg1/debian.root 

Đó là tất cả

Tôi hy vọng điều này có thể giúp những người khác đang tìm kiếm giải pháp này!


5

Cách dễ nhất để khôi phục từ lvremove (giả sử bạn không viết thư cho các khu vực mà LV đang cư trú) là:

Chỉ cần tìm bản sao lưu siêu dữ liệu của bạn trong / etc / lvm / archive và tìm ra

a) mở rộng LV đang cư trú trong (EFROM, ETO)
b) mà PV của bạn đang cư trú và mở rộng trên PV mà nó đang sử dụng (PFROM, PTO)

Sau khi bạn có thông tin này, bạn tạo một LV mới có cùng kích thước trên cùng một PV chính xác mà không xóa 8kB đầu tiên của LV:

lvcreate --extents EFROM-ETO --zero n --name customer007 YOUR-VG-NAME /dev/yourpv:PFROM-PTO

1
Bạn có thể vui lòng cụ thể hơn nữa khi tìm thấy EFROM và ETO từ tệp sao lưu không? Tất cả các lv đều có "start_extend" từ 0 trong tệp sao lưu của tôi nên tôi hơi bị mất :) Cảm ơn!

3

(Như đã được trả lời bởi thermoman trước đó) cách dễ dàng để tạo lại âm lượng LVM đã xóa là bằng cách tạo nó với lvcreate mà không zeroing và đảm bảo rằng nó sẽ ở cùng một vị trí trên đĩa. (Lệnh từ câu trả lời của thermoman không hoạt động.)

Kiểm tra kích thước và vị trí của khối lượng logic đã bị xóa như trước khi xóa bằng cách đọc các tệp trong / etc / lvm / archive. Kích thước của khối lượng là trong extent_countnhững segment1(hoặc tổng của segment*/extent_countcác giá trị nếu nó có nhiều mức độ). Vị trí nằm trong stripesphần sau bí danh âm lượng vật lý (ví dụ:pv0 ).

Ví dụ: phần âm lượng có thể trông như thế này:

    physical_volumes {
            pv0 {
                    device = "/dev/somedisk" # Hint only
                    ...
            }
    }

    logical_volumes {
            ...
            example {
                    ...
                    segment_count = 1

                    segment1 {
                            start_extent = 0
                            extent_count = 1024     # 4 Gigabytes

                            type = "striped"
                            stripe_count = 1        # linear

                            stripes = [
                                    "pv0", 30720
                            ]
                    }
            }
            ...
    }

Kích thước của tập này examplelà 1024 và nó nằm ở / dev / somedisk bắt đầu từ phạm vi 30720.

Tính toán mức độ cuối cùng khi bắt đầu + kích thước -1 = 30720 + 1024 - 1 = 31743. Để tạo lại vấn đề âm lượng đó như sau:

lvcreate --extents 1024 --zero n --name example vgname /dev/somedisk:30720-31743

Câu trả lời này vừa cứu đêm hôm qua của tôi! Tôi đã bị hỏng XenServer đang xóa nhầm LV do lỗi API ...: o
Elektordi

2

Tôi đã ở trong hoàn cảnh tương tự. Tôi đã có tất cả các PV chứa LV ​​mong muốn, nhưng VG của tôi cho thấy các PV bị thiếu và 0 LV. Tôi đã phục hồi bằng cách làm như sau:

  1. Trở thành root
  2. Chạy pvsđể thu thập UUID cho tất cả các ổ đĩa.
  3. Xem lại các tệp trong / etc / lvm / archive cho đến khi tôi tìm thấy một tệp liệt kê tất cả các UUID giống nhau.
  4. Tạo một bản sao làm việc của tệp cấu hình lưu trữ và bắt đầu chỉnh sửa.
  5. Trong physical_volumesphần, đặt các device =dòng khớp với thiết bị / UUID hiện tại được báo cáo bởi pvs, xóa mọi "MISSING"cờ và xóa bất kỳ pvNphần nào thực sự bị thiếu.
  6. Trong logical_volumesphần, xóa mọi danh sách có sọc trên các pvNphần không còn tồn tại.
  7. Thế là xong, rồi tôi chạy.

    vgcfgrestore --test vg -f /root/dangerously_edited.vg

  8. Khi nó hoạt động, tôi chạy lại mà không có --testtùy chọn.

Tôi đã đạt được tình huống cụ thể của mình bằng cách mở rộng VG với PV sdg và sdh. Sau đó, tôi đã tạo một LV mới, chỉ định /dev/sdg /dev/sdhtrên dòng lệnh để tôi biết LV mới có trên các ổ đĩa đó. Sau đó, tôi chuyển những ổ đĩa đó sang một máy mới. Máy cũ rất khó chịu về các ổ đĩa bị mất và khi tôi buộc loại bỏ chúng, nó cũng loại bỏ TẤT CẢ các LV. Bummer.

Lần tới, tất nhiên, tôi sẽ tạo một VG mới để tránh vấn đề này.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.