Jak odzyskać wolumin logiczny usunięty za pomocą lvremove


12

Korzystam z CentOS 5.5 i korzystam z Xen. Mam dużą grupę woluminów, które tworzę logiczne woluminy przy użyciu lvcreate. Dzisiaj kazałem klientowi zlikwidować jej konto, a następnie zmienić zdanie około godziny później. Niestety już usunąłem LVM, na którym rezydował jej obraz Xen. (tylko używając standardowego lvremove). Od tego czasu na tym dysku nie było żadnych innych działań LVM (nic więcej nie dodano ani nie usunięto). Czy można „cofnąć” lvremove lub odzyskać wolumin logiczny? Jeśli tak, jak miałbym to zrobić?

Odpowiedzi:


13

LVM tworzy kopie zapasowe swoich metadanych do /etc/lvm/backupi /etc/lvm/archive. W górnej części każdego pliku powiesz czas / dane, kiedy plik został wygenerowany, więc są szanse, że będziesz mieć kopię starszych metadanych, tak jak było przed usunięciem LV. Uważam, że tworzenie kopii zapasowej odbywa się automatycznie przy każdej zmianie metadanych.

Poniższe mogą być niebezpieczne i destrukcyjne, dlatego należy zachować ostrożność i, jeśli to możliwe, mieć pełne kopie zapasowe.

Polecenie przywracania tych kopii zapasowych metadanych grupy woluminów to vgcfgrestore. Upewnij się, że wykonałeś bieżącą kopię istniejącej konfiguracji roboczej za pomocą vgcfgbackuppolecenia z flagą -f, aby określić inny plik wyjściowy, aby nie zmieniać żadnych plików znajdujących się w / etc / lvm / backup lub / etc / lvm / archive foldery. Upewnij się, że różnicujesz bieżącą konfigurację z konfiguracją, którą chcesz przywrócić, aby sprawdzić, czy jedyne zmiany, które zamierzasz zastosować, to odtworzenie ostatnio usuniętej LV. Posiadanie pełnej kopii zapasowej danych prawdopodobnie nie jest złym pomysłem. Możesz również rozważyć skontaktowanie się ze sprzedawcą systemu Linux w celu uzyskania wsparcia / wskazówek, jeśli masz umowę serwisową przed kontynuowaniem, ponieważ nigdy nie musiałem tego robić sam.

Powodzenia.


1
Wczytując się głębiej w vgcfgrestore, wygląda na to, że musiałbym zamknąć każdą maszynę wirtualną na tym polu przed próbą tego, albo ryzykować uszkodzenie całej tablicy. Wygląda na to, że twoje instrukcje działałyby, więc akceptuję odpowiedź, ale dane nie są warte ryzyka. Dzięki
John P

@John P Tak, zorientowałem się na temat maszyn wirtualnych i wszystko, co byłoby trudne do zrobienia w takim środowisku. Wydaje mi się, że można to odrzucić, ponieważ w przyszłości procedura usuwania konta powinna obejmować 30-dniowy okres bez usuwania.
3dinfluence 19.01.11

18

„Czy mógłbyś być bardziej konkretny, aby znaleźć EFROM i ETO z pliku kopii zapasowej? Wszystkie lv mają„ start_extend ”od 0 w moim pliku kopii zapasowej, więc jestem trochę zagubiony :) Dzięki! - użytkownik186975 : 06 "

Ok, będę bardzo konkretny ... z najprostszym sposobem na odzyskanie woluminu logicznego.

Przykład:

1 - Usunąłem mój wolumin logiczny!

$ sudo lvremove /dev/vg1/debian.root

2 - Pierwszą rzeczą do zrobienia jest poszukaj pliku archiwum na /etc/lvm/archive/vg1_(xxxxx).vg. Mogę to zrobić, szukając tylko daty usunięcia logicznego woluminu!

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

3- Znalazłem to!

-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**

Data, w której zrobiłem lvremove !!! ... to było kilka minut temu ..

4 - Zobaczmy plik!

$ 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 - Wykonaj test, zanim go odzyskasz!

$ 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, teraz powtórz wiersz poleceń, bez (--test)

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

7 - Sprawdź to!

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

8 - Jeśli logika nie była aktywna, zrób to!

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

To wszystko

Mam nadzieję, że pomoże to innym osobom szukającym tego rozwiązania!


5

Najłatwiejszą rzeczą do odzyskania z lvremove (zakładając, że nie pisałeś do zakresu, w którym LV przebywał) jest:

Wystarczy znaleźć kopię zapasową swoich metadanych w / etc / lvm / archive i dowiedzieć się

a) w jakim zakresie LV przebywał (EFROM, ETO)
b) w których PV mieszkał Twój LV i w jakim zakresie wykorzystuje PV (PFROM, PTO)

Po uzyskaniu tych informacji tworzysz nowy LV o dokładnie tym samym rozmiarze na dokładnie tym samym rozszerzeniu PV bez wymazywania pierwszych 8 kB LV:

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

1
Czy możesz bardziej precyzyjnie znaleźć EFROM i ETO z pliku kopii zapasowej? Wszystkie lv mają „start_extend” od 0 w moim pliku kopii zapasowej, więc jestem trochę zagubiony :) Dzięki!

3

(Jak wcześniej odpowiedział Thermoman) najłatwiejszym sposobem na odtworzenie usuniętego wolumenu LVM jest utworzenie go za pomocą lvcreate bez zerowania i upewnienie się, że będzie on w tej samej pozycji na dysku. (Polecenie z odpowiedzi termomana nie zadziałało).

Sprawdź rozmiar i położenie usuniętego woluminu logicznego, jakie były przed usunięciem, czytając pliki w / etc / lvm / archive. Wielkość ilości jest extent_countz segment1(lub suma segment*/extent_countwartości jakby miał kilka zakresów). Pozycja znajduje się w stripessekcji po fizycznym aliasie woluminu (np pv0.).

Na przykład sekcja głośności może wyglądać następująco:

    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
                            ]
                    }
            }
            ...
    }

Rozmiar tego examplewoluminu wynosił 1024 i znajdował się na / dev / somedisk, począwszy od zakresu 30720.

Oblicz ostatni zakres jako początek + rozmiar -1 = 30720 + 1024 - 1 = 31743. Aby odtworzyć ten problem z woluminem, wykonaj następujące czynności:

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

Ta odpowiedź właśnie uratowała moją noc wczoraj! Miałem uszkodzony XenServer, który
kasował

2

Miałem podobną sytuację. Miałem wszystkie PV zawierające pożądane LV, ale moje VG pokazało brakujące PV i 0 LV. Odzyskałem, wykonując następujące czynności:

  1. Zostań rootem
  2. Uruchom, pvsaby zebrać UUID dla wszystkich dysków.
  3. Przejrzyj pliki w / etc / lvm / archive, aż znalazłem taki, który zawiera wszystkie te same UUID.
  4. Utwórz kopię roboczą zarchiwizowanego pliku konfiguracyjnego i rozpocznij edycję.
  5. W physical_volumessekcji ustaw device =wiersze, aby pasowały do ​​bieżących urządzeń / identyfikatorów UUID zgłoszonych przez pvs, wyczyść wszystkie "MISSING"flagi i usuń wszystkie pvNbrakujące sekcje.
  6. W logical_volumessekcji usuń wszystkie wykazy, które miały paski w pvNsekcjach, które już nie istniały.
  7. To było to, potem pobiegłem

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

  8. Gdy to zadziałało, uruchomiłem ponownie bez --testopcji.

Osiągnąłem swoją szczególną sytuację, rozszerzając VG o PV sdg i sdh. Następnie utworzyłem nowy LV, określając /dev/sdg /dev/sdhw wierszu polecenia, aby wiedzieć, że nowy LV znajduje się na tych dyskach. Następnie przeniosłem te dyski na nową maszynę. Stara maszyna była bardzo zaniepokojona brakującymi dyskami, a kiedy wymusiłem ich usunięcie, usunąłem WSZYSTKIE LV. Porażka.

Następnym razem oczywiście utworzę nową VG, aby uniknąć tego problemu.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.