Lvremove ile silinmiş mantıksal hacim nasıl kurtarılır


12

CentOS 5.5 kullanıyorum ve Xen kullanıyorum. Ben lvcreate kullanarak mantıksal birimler oluşturmak büyük bir birim grubu var. Bugün bir müşterinin hesabını iptal etmesini ve ardından bir saat sonra fikrini değiştirmesini istedim. Ne yazık ki Xen görüntüsünün bulunduğu LVM'yi zaten kaldırmıştım. (sadece standart bir kaldıraç kullanarak). O zamandan beri bu diskte başka bir LVM etkinliği olmamıştır (başka bir şey eklenmedi veya silinmedi). Bir lvremove "geri almak" veya mantıksal hacmi kurtarmak mümkün mü? Eğer öyleyse, nasıl başarabilirim?

Yanıtlar:


13

LVM, meta verilerini /etc/lvm/backupve dizinine yedekler /etc/lvm/archive. Her dosyanın üst kısmında, dosyanın oluşturulduğu zamanı / verileri size bildirir, böylece LV'yi silmeden önceki gibi eski meta verilerin bir kopyasına sahip olursunuz. Meta veriler değiştiğinde yedeklemenin otomatik olduğuna inanıyorum.

Aşağıdakiler tehlikeli ve yıkıcı olabilir, bu yüzden çok dikkatli olun ve mümkünse tam bir yedeğe sahip olun.

Bu birim grubu meta veri yedeklemelerini geri yükleme komutu vgcfgrestore. vgcfgbackup/ Etc / lvm / backup veya / etc dosyasındaki dosyaları değiştirmemek için, çıktı için farklı bir dosya belirtmek üzere -f işaretli komutu kullanarak mevcut çalışma yapılandırmasının geçerli bir kopyasını aldığınızdan emin olun. / lvm / arşiv klasörleri. Geçerli yapılandırmayı, uygulamak üzere olduğunuz değişikliklerin son zamanlarda silinen LV'yi yeniden oluşturmak olduğunu doğrulamak için geri yüklemek istediğiniz yapılandırmayla paylaştığınızdan emin olun. Verilerinizin tam bir yedeğine sahip olmak muhtemelen kötü bir fikir değildir. Ayrıca, daha önce kendim yapmak zorunda olmadığım için bir destek sözleşmesi yapıyorsanız, destek / rehberlik için Linux satıcınızla iletişime geçmeyi düşünebilirsiniz.

İyi şanslar.


1
Vgcfgrestore içine daha derin bir okuma, bu denemeden önce o kutudaki her VM kapatmanız veya tüm dizi bozulma riski gibi görünüyor. Talimatlarınızın işe yaradığı anlaşılıyor, bu yüzden cevabı kabul ediyorum, ancak veriler riske değmez. Teşekkürler
John P

@John P Evet VM'ler ve bunun gibi bir ortamda yapılması zor bir şey olduğunu düşündüm. Bu konuda bir almak sanırım gelecekte bir hesabı kaldırma prosedürü 30 günlük bir silme dönemi içermelidir.
3dinfluence

18

"Lütfen yedek dosyadan EFROM ve ETO bulma konusunda daha spesifik olabilir misiniz? Tüm lv yedek dosyam 0 bir" start_extend "var, bu yüzden biraz kayboldum :) Teşekkürler! - user186975 24 Ağu 13 at 17 : 06 "

Tamam, çok spesifik olacağım ... mantıklı bir birimi kurtarmanın en basit yolu.

Misal:

1 - Mantıksal sesimi kaldırdım!

$ sudo lvremove /dev/vg1/debian.root

2 - Yapılacak ilk şey, /etc/lvm/archive/vg1_(xxxxx).vg adresinde arşiv dosyasını aramaktır. Bunu yapabilirim, sadece mantıksal hacmi kaldırdığım tarihe bakarak!

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

3- buldum!

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

Lvremove yaptığım tarih !!! ... bir dakika önce ..

4 - Haydi dosyayı görelim!

$ 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 - Kurtarmadan önce bir test yapı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 - Tamam, şimdi (--test) olmadan komut satırını tekrarlayın

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

7 - Kontrol et!

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

8 - Mantıksal etkin değilse, yapın!

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

Hepsi

Umarım bu, bu çözümü arayan diğer insanlara yardımcı olabilir!


5

LVremove'tan kurtarmanın en kolay yolu (LV'un bulunduğu uzantılara yazmadığınız varsayılarak):

Meta verilerinizin yedeğini / etc / lvm / archive içinde bulun ve anlayın

a) hangi LV'nin oturduğunu uzatan (EFROM, ETO)
b) LV'nizin hangi PV'lerin üzerinde bulunduğu ve hangi PV'yi kullandığı (PFROM, PTO)

Bu bilgiye sahip olduktan sonra, aynı PV'de tam olarak aynı boyutta yeni bir LV yaratırsınız , LV'nin ilk 8kB'sini silmeden uzanır :

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

1
Lütfen yedek dosyadan EFROM ve ETO'yu bulmak konusunda daha spesifik olabilir misiniz? Tüm lv yedek dosyam 0 bir "start_extend" var, bu yüzden biraz kayboldum :) Teşekkürler!

3

(Daha önce termoman tarafından yanıtlandığı gibi) silinmiş bir LVM birimini yeniden oluşturmanın kolay yolu, sıfırlamadan lvcreate ile oluşturmak ve diskte aynı konumda olmasını sağlamaktır. (Termomanın cevabındaki komut işe yaramadı.)

/ Etc / lvm / archive içindeki dosyaları okuyarak silinen mantıksal birimin silinmeden önceki boyutlarını ve konumlarını kontrol edin. Hacminin büyüklüğü olan extent_countbir segment1(ya da Özetle segment*/extent_countbirkaç kapsamlarını olsaydı değerleri). Konum, stripesfiziksel hacim takma adından sonraki bölümdedir (örn. pv0).

Örneğin, birim bölümü şöyle görünebilir:

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

Bu examplebirimin boyutu 1024'tür ve 30720'den başlayarak / dev / somedisk üzerinde bulunuyordu.

Son boyutu başlangıç ​​+ boyut -1 = 30720 + 1024 - 1 = 31743 olarak hesaplayın. Aşağıdaki cilt sorununu yeniden oluşturmak için:

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

Bu cevap dün gecemi kurtardı! Bir API hatası nedeniyle yanlış LV silme kırık bir XenServer vardı ...: o
Elektordi

2

Benzer bir durum yaşadım. İstenen LV'leri içeren tüm PV'lere sahiptim, ancak VG'm eksik PV'ler ve 0 LV'ler gösterdi. Aşağıdakileri yaparak iyileştim:

  1. Kök ol
  2. pvsTüm sürücüler için UUID'leri toplamak üzere çalıştırın .
  3. Aynı UUID'lerin tümünü listeleyene kadar / etc / lvm / archive içindeki dosyaları inceleyin.
  4. Arşivlenmiş yapılandırma dosyasının çalışan bir kopyasını oluşturun ve düzenlemeye başlayın.
  5. Bölümde, satırları rapor edilen geçerli aygıt / UUID'lerle eşleşecek şekilde physical_volumesayarlayın, tüm bayrakları temizleyin ve eksik olan bölümleri kaldırın .device =pvs"MISSING"pvN
  6. Bölümde, artık var olmayan bölümlerde logical_volumesşeritleri olan listeleri kaldırın pvN.
  7. Öyleydi, sonra koştum

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

  8. Bu işe yaradığında, --testseçenek olmadan tekrar koştum .

Özel durumumu VG'yi sdg ve sdh ile genişleterek başardım. Sonra /dev/sdg /dev/sdhkomut satırını belirterek yeni LV oluşturdum, böylece yeni LV'nin bu sürücülerde olduğunu biliyordum. Sonra sadece bu sürücüleri yeni bir makineye taşıdım. Eski makine eksik sürücüler hakkında çok üzgündü ve onları zorla kaldırdığımda TÜM LV'leri de çıkardı. Aylak.

Bir dahaki sefere, elbette, bu sorunu önlemek için yeni bir VG oluşturacağım.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.