Avamar: Come aggiornare il riferimento ai metadati di backup che è stato richiamato manualmente da Data Domain Cloud Tier
Summary: Avamar mantiene e utilizza i metadati di backup per eseguire il ripristino cloud-tier in base alle esigenze per una griglia Avamar integrata con un Data Domain. Questo articolo spiega come risincronizzare i backup richiamati manualmente da DD e aggiornare i metadati Avamar. ...
Symptoms
La procedura di richiamo corretta per un backup da Data Domain (DD) Cloud Tier al tier attivo utilizza Avamar "avtier", come documentato in Avamar: Come richiamare i backup migrati a Data Domain Cloud Tier.
Questo articolo illustra gli scenari in cui non è stata utilizzata la procedura corretta e il richiamo è stato eseguito manualmente su DD senza modifiche ad Avamar.
Dopo il richiamo DD manuale, il backup si trova nel tier attivo DD, ma i metadati Avamar per il backup lo mostrano sul cloud tier.
Ad esempio:
avmgr getb --path=/clients/ClientName --format=xml --incpartials | grep -i 1D359BBB62CE6BA
backuplistrec flags="24117249" labelnum="592" label="***_Exchange_Full-1510201386783#0" created="1510274087" roothash="fff989cfe0fe0654abc5453466fcbe7b12879207"
totalbytes="3537383718912.00" ispresentbytes="0.00" pidnum="3018" percentnew="0" expires="0" created_prectime="0x1d359bbb62ce6ba" partial="0" retentiontype=
"daily,weekly,monthly" backuptype="Full" ddrindex="1" locked="0" direct_restore="1" tier="2" appconsistent="not_available" sealstate="COMPLETE"/>
(Output sottoposto a wrapping per garantire la leggibilità)
Da questo output, tier="2" indica che Avamar riconosce ancora il backup come archiviato nel Cloud Tier.
I tentativi di ripristinare questo backup da Avamar causano un nuovo spostamento di dati (non necessario) su DD tra il tier attivo e il Cloud Tier quando viene richiamato il richiamo.
Cause
Se un backup richiamato da Data Domain Cloud Tier al tier attivo non è stato eseguito da Avamar, i metadati per tale backup su Avamar non sono sincronizzati con la posizione dei dati su Data Domain.
Resolution
Esistono due soluzioni alternative per risolvere questo problema:
Metodo 1. Sincronizzare i metadati di backup tra GSAN e Data Domain eseguendo la Garbage Collection (GC) con "checkalltierduringgc" abilitato:
1. Arrestare l'utilità di pianificazione della manutenzione:
dpnctl stop maint
2. Abilitare l'opzione changealltiering parametro:
avmaint --ava config checkalltierduringgc=true
3. Avviare la garbage collection:
avmaint --ava garbagecollect
4. Monitorare la griglia fino al completamento del GC utilizzando uno dei comandi riportati di seguito:
avmaint gcstatus -- or -- status.dpn
5. Al termine del processo GC, disabilitare changealltiering parametro:
avmaint --ava config checkalltierduringgc=false
6. Riavviare l'utilità di pianificazione della manutenzione:
dpnctl start maint
Metodo 2. Aggiornare manualmente i metadati di backup utilizzando "avmgr chgt":
1. Creare un checkpoint Avamar in caso di problemi.
2. Eseguire una query sullo stato del backup da richiamare da Data Domain Cloud Tier utilizzando il comando riportato di seguito. Registrare il parametro "created_prectime" valore.
avmgr getb --path=/clients/ClientName --format=xml --incpartials |grep 'labelnum="<labelnum>"'
Ad esempio:
avmgr getb --path=/clients/ClientName --format=xml --incpartials |grep 'labelnum="592"'
backuplistrec flags="24117249" labelnum="592" label="***_Exchange_Full-1510201386783#0" created="1510274087" roothash="fff989cfe0fe0654abc5453466fcbe7b12879207" totalbytes="3537383718912.00" ispresentbytes="0.00" pidnum="3018" percentnew="0" expires="0" created_prectime="0x1d359bbb62ce6ba" partial="0" retentiontype="daily,weekly,monthly" backuptype="Full" ddrindex="1" locked="0" direct_restore="1" tier="3" ...
3. L'utilizzo del comando "created_prectime" dall'alto, eseguire il seguente comando:
avmgr chgt --path=/clients/clientName --date="<created_prectime>" --tiering=0 --ava
Ad esempio:
avmgr chgt --path=/clients/clientName --date="0x1d359bbb62ce6ba" --tiering=0 --ava
"--tiering=0" modifica la posizione dei metadati di backup dal Cloud Tier al tier attivo.
4. Eseguire nuovamente il comando del passaggio 2 per verificare che il backup presenti il tier corretto:
avmgr getb --path=/clients/ClientName --format=xml --incpartials |grep 'labelnum="<labelnum>"'
Ad esempio:
avmgr getb --path=/clients/ClientName --format=xml --incpartials |grep 'labelnum="592"'
avmgr getb --path=/clients/ClientName --format=xml --incpartials labelnum=592
<backuplistrec flags="24117249" labelnum="592" label="***_Exchange_Full-1510201386783#0" created="1510274087" roothash="fff989cfe0fe0654abc5453466fcbe7b12879207" totalbytes="3537383718912.00" ispresentbytes="0.00" pidnum="3018" percentnew="0" expires="0" created_prectime="0x1d359bbb62ce6ba" partial="0" retentiontype="daily,weekly,monthly" backuptype="Full" ddrindex="1" locked="0" direct_restore="1" tier="0" ...
Additional Information
| Nome tier | Numero | Note |
| Attivo | 0 |
Il backup viene archiviato nel tier attivo di Data Domain e non nel cloud. |
| Marcato | 1 |
Il backup è contrassegnato per il tiering nel cloud. |
| Cloud | 2 |
Il backup è stato sottoposto a tiering nel cloud. |
| Indeterminato | 3 |
Quando l'Avamar Server contrassegna i backup per il tiering o richiama i backup dal cloud, il backup presenta lo stato Indeterminate. |