Avamar: Linux VM yedeklemeleri, bir şablondan dağıtılmışsa LVM meta veri tutarsızlığına sahip olabilir

Geri yükleme sırasında aşağıdaki belirtiler görülür:

1. LVM sorunuyla birlikte FLR işlemi hatası:
   

   VEYA
   
   2 VM

2. Görüntü geri yüklenen işler Avamar UI'da başarılı, bir LVM sorunu nedeniyle Sanal Makinede (VM) önyükleme yapılıyor olabilir.

   Örnek önyükleme sorunu 1:
   Aşağıdaki Red Hat örneğinde, işletim sistemi bir acil durum dracut kabuğuna önyükleme yapar:
   

   (Bu örnekte) dracut kabuğundan aşağıdaki LVM komutu LVM durumunu onarır. Çıktı, sorunun lvm disklerinden birinin (sdb) LVM'den hatalı bir şekilde kaldırılmasından kaynaklandığını gösteriyor.

   dracut:/# lvm pvscan --config 'global{locking_type=1}'

   
   Artık kurtarılan sanal makine önyüklenebilir.

   Örnek önyükleme sorunu 2:
   Debian örneğinde, işletim sistemi bir acil durum meşgul kutusu kabuğuna önyükleme yapar:
   

   (Bu örnekte) busy box shell'den aşağıdakileri lvm Önceki yapılandırmadan LVM disk bölümü grubunun durumunu geri yükleme komutu:

   (initramfs)  lvm vgcfgrestore vm1-vg   --config 'global{locking_type=1}'

    

   Not: vm1-vg , bu örnekteki disk bölümü grubu adıdır

    

   
   Artık kurtarılan sanal makine önyüklenebilir.

Diğer belirtiler:

Üretim Sanal Makineleri (VM'ler) başarıyla yeniden başlatılabilir. Sorun yalnızca LVM kullanan ve aynı şablondan dağıtılan Linux VM'lerinin yedek kopyalarını etkiler.
LVM yapılandırmalarını kullanmayan Windows ve Linux sanal makinelerinde, yedek kopyalarında FLR veya önyükleme sorunları GÖSTERİLMEZ .

LVM Meta Veri Arka Planı:

1. LVM ile yapılandırılmış Linux VM'leri aynı şablondan klonlanır veya dağıtılır. Sonuçta ortaya çıkan yeni sanal makineler, aynı LVM Benzersiz Tanımlayıcılarına (UUID'ler) sahiptir.
2. LVM disklerinde yapılan herhangi bir değişiklik (örneğin, LVM'ye sanal disk eklemek), LVM meta veri bilgilerinin güncellenmesini zorunlu kılar. LVM, revizyon sıra numaraları (vg_seqno) adı verilen bir alan kullanarak bu güncellemeleri izler. Bu sayı, her değişiklik yapıldığında artırılır.

Çalışırken ekleme Yedekleme Sorunu:
Avamar yedeklemesi sırasında aşağıdaki koşullar karşılanırsa:

1. Hem kaynak hem de klonlanan VM'ler, hot add (varsayılan aktarım yöntemi) kullanılarak aynı anda yedeklenir.
2. Her iki VM de aynı Avamar proxy'si kullanılarak çalışırken eklenir.
3. LVM revizyonları, çalışırken eklenen VM'ler arasında farklılık gösterir.

Avamar proxy'sinin Linux çekirdeği, yanlış bir şekilde iki VM'nin disklerinin aynı LVM disk bölümü grubunda olduğunu varsayar ve LVM meta verilerini otomatik olarak güncelleştirir. Bu LVM güncellemesi gerçekleşirse LVM meta verileri yedek kopyada tutarsızdır.

Geri Yükleme Sorunu:
Çalışırken ekleme yedeklemesi sırasında güncellenen yanlış LVM meta verileri nedeniyle VM, Görüntü sırasında "Eksik LVM fiziksel kapsamları" veya "İşlem kimliği uyuşmazlıkları" görüntüleyebilir. Bu tutarsızlık, yukarıda belirtilen güncellemeden kaynaklanmaktadır.

Kurtarma LVM araçları, örneğin: vgcfgrestore, vgextend –restoremissingve vgchange -ay –activationmodepartial tam önyüklemeye izin vermek veya LVM durumunu düzeltmek üzere yedek kopyayı onarmak için gerekli olabilir.

Bu sorun Avamar proxy düzeltmelerinde çözülmüştür:
Avamar 19.4 333146.
Avamar 19.3 333148.
Avamar 19.2 333149.
Eski Avamar sürümü: Aşağıdaki notlara bakın.

Bu düzeltmeler, çalışırken ekleme işlemleri sırasında LVM meta veri güncellemelerini önlemek için Avamar proxy'sindeki LVM ayarını yeniden yapılandırır.

DÜZELTMEDEN ÖNCE

194proxy:~ # lvm config | grep filter
        filter="a/.*/"

DÜZELTMEDEN SONRA

194proxy:~ # lvm config | grep filter
        filter=["r|/dev/s.*|","r|/dev/disk.*|","a/.*/"]

Etkilenen istemcilerden herhangi biri için Değişiklik Bloğu İzleme (CBT) L0 yedeklemesini zorlamamız gerekir. Bu, yeni yedeklemelerde doğru LVM meta verilerinin yakalanmasını sağlar.

İstemci algılamaya yardımcı olmak için, Avamar mühendislik yeni bir komut dosyası geliştirdi. Bu komut dosyası, Linux yedeklemelerini LVM tutarsızlıklarına karşı tarar ve bulunursa bir sonraki iş için CBT'yi otomatik olarak sıfırlar.

vmlvmcheck.pl

1. Bu komut dosyası Avamar sunucusuna yüklenmelidir.
2. Komut dosyası kök kullanıcı olarak çalıştırılmalıdır.
3. Bu komut dosyası, tüm Linux Sanal makine istemcilerinin en son yedeğini tarar ve LVM tutarlılığını kontrol eder.
4. Bu komut dosyası birçok sanal makineyi tarıyorsa işlem uzun (birkaç saat) sürebilir. Varsayılan olarak, taranan sanal makine sayısı 50'yi aşarsa komut dosyası arka plan/geriplan modunda çalışır.

Komut Dosyası Mantığı:
Komut dosyası, .vmdk yedeklemelerindeki LVM mantıksal disk bölümlerini bulur ve aşağıdaki koşulları doğrular:

1. Tüm fiziksel birimlerin yedeklemede bulunmasını sağlar
2. Tüm fiziksel disk bölümlerinin bir LVM disk bölümü grubuyla ilişkili olduğunu doğrular.
3. Aynı disk bölümü grubuna ait tüm fiziksel disk bölümlerinin sıra numaraları aynıdır.

Yanlış pozitifler:

1. Keşfedilen bir disk bölümü grubu için bazı sanal diskler dahil EDILMEDİYSE bu araç bu aracı bayrakla yedekler. Temel neden, yukarıda açıklanan çalışırken ekleme sorunuyla ilgili değildir. Bu durumda Avamar'ın tüm sanal diskleri yedeklediğinden emin olun.
2. Sanal disklerden herhangi biri tam olarak başlatılmamış bir LVM bölümü içeriyorsa araç, yedeklemeyi bozuk olarak tanımlar. Ancak bu senaryoda, işletim sisteminde herhangi bir önyükleme sorunu OLMAZ.

İndirme talimatları:

1. central.dell.com web sitesinden vmlvmcheck.pl indirin. Central hakkında daha fazla bilgi için bkz . KB Avamar: Avamar komut dosyalarını ve araçlarını Dell Central Avamar sayfasından bulma ve indirme.
   

2. WinSCP gibi bir araç kullanarak vmlvmchck.pl Avamar sunucusundaki "/root" dizinine aktarın.

   Örnek 1 (salt okunur işlev) Tüm linux vm istemcilerinin en son yedeklemesini tarar.

   root@ave194:~/vmlvmcheck/#: perl vmlvmcheck.pl
   11:37:13 2021-10-06 : vmlvmcheck.pl version 19.04 @ave194
   11:37:14 14 VMs populated. Processing backups for these...
   <list of vms>  
   
   “===== 3 Vm(s) with potential LVM inconsistency  in backup ===
   vm1,vm2,vm3
   11:40:08 COMPLETED. Statistics on  ave194 (vmvlmcheck ver 19.04) ---  (after 2 minutes, 55 seconds)
           11      Activities examined
           11      Backups to DD
           30      Files Examined
           12.500  Run Sec per VM
           2.917   Run Time Minutes
           14      VMs Enabled
           14      VMs Total
           3       VMs With Inconsistent backups
           21.43 %         VMs With Inconsistent backups %
   
   

   VEYA Taranan toplam sanal makine sayısı 50'yi aştığında, komut dosyası bunun yerine arka planda otomatik olarak çalışır:

   root@ave194:/home/admin/#: perl vmlvmcheck.pl 
   10:55:34 2021-11-17 : vmlvmcheck.pl version 19.15 @ave194
   10:55:35 55 VMs populated. Processing backups for these...
   Output is now going to /usr/local/avamar/var/log/vmvlmcheck.log .
   PID# 3563 is now running vmlvmcheck as a background process.
   To terminate daemon process, enter:
        kill  3563
   Please run:  tail -f /usr/local/avamar/var/log/vmvlmcheck.log

   Örnek 2 (salt okunur işlev) kullanarak tek bir istemcinin en son yedeğini tarayın: --vm <vm name> bayrak

   root@ave194:/home/admin/#: perl vmlvmcheck.pl --vm cloud2116-clone1
   18:13:57 2021-10-05 : vmlvmcheck.pl version 19.04 @ave194
   18:13:57 1 VMs populated. Processing backups for these...
   INFO:============ cloud2116-clone1  /vc6-avamar.gslabs.lab.emc.com/ContainerClients: 1 Backups
   WARNING: pvs Did not see a LVM on /dev/loop1
   ERROR: Expected LVM member appears damaged:VMFiles/2/virtdisk-flat.vmdk.
   INFO: No partitions found in VMFiles/2/virtdisk-flat.vmdk.
   VM cskpcloud2116-clone1 has 1 LVMs inside 2 vmdks.
   ERROR: Bad backup: labelnum=2
   2 Snapshots to be deleted ...Option DELETE_SNAPSHOTS=0.
   18:14:09 COMPLETED. Statistics on  ave194 (vmvlmcheck ver 19.04) ---
           1       Activities examined
           1       Backups to DD
           2       Files Examined
           12.000  Run Sec per VM
           0.200   Run Time Minutes
           1       VMs Enabled
           1       VMs Total

   Örnek 3 (yazılabilir işlev) Örnek 1 ve 2 ile aynı, ancak bu sefer --DELETE_SNAPSHOTS seçeneği eklendi

   root@ave194:~/vmlvmcheck/#: perl vmlvmcheck.pl --vm cloud2116-clone1  --DELETE_SNAPSHOTS
   14:13:35 2021-10-06 : vmlvmcheck.pl version 19.04 @ave194
   14:13:36 1 VMs populated. Processing backups for these...
   INFO:============ cloud2116-clone1  /vc6-avamar.gslabs.lab.emc.com/ContainerClients: 1 Backups
   WARNING: pvs Did not see a LVM on /dev/loop1
   ERROR: Expected LVM member appears damaged:VMFiles/2/virtdisk-flat.vmdk.
   INFO: No partitions found in VMFiles/2/virtdisk-flat.vmdk.
   VM cskpcloud2116-clone1 has 1 LVMs inside 2 vmdks.
   ERROR: Bad backup: labelnum=2
   2 Snapshots to be deleted ...Option DELETE_SNAPSHOTS=1.
   14:13:49 COMPLETED. Statistics on  ave194 (vmvlmcheck ver 19.04) ---
           1       Activities examined
           1       Backups to DD
           2       Files Examined
           14.000  Run Sec per VM
           0.233   Run Time Minutes
           1       VMs Enabled
           1       VMs Total

Daha eski veya düzeltme eki uygulanmamış Avamar proxy'leri için manuel LVM ayarı

1. Proxy kök dizini olarak lvm.conf dosyasını yedekleyin

   194proxyga:~ # cp /etc/lvm/lvm.conf /etc/lvm/lvm.conf-`date +%s

2. /etc/lvm/lvm.conf dosyasını düzenleyin, mevcut "filtre" satırını arayın ve aşağıdakiyle değiştirin.

   ÖNCE

       filter = [ "a/.*/" ]

   SONRA

       filter = ["r|/dev/s.*|","r|/dev/disk.*|","a/.*/"]

3. Bu komutu çalıştırarak yeni filtre ayarının ayarlandığını doğrulayın

   194proxy:~ # lvm config | grep filter
           filter=["r|/dev/s.*|","r|/dev/disk.*|","a/.*/"]