Avamar-Data Domain: Hög DD-användning på mål: Analys och bästa praxis

Måldatadomänen har högre användning än källdatadomänen.

Ur Avamar-perspektiv:

Ångring
I händelse av en återställning på källData Domain kan måldatadomänen lagra extra dagar med data beroende på återställningstiden. Den här avvikelsen finns tills de extra säkerhetskopiorna på målet upphör att gälla.

Exempel: DD1 replikeras till DD2. Eftersom återställningen är 2 dagar tillbaka ser vi att det finns 3 säkerhetskopior på källan, men fem säkerhetskopior replikeras till målet.

Partiella replikeringar
Om en replikering inte slutförs som den ska lagras de data som redan har replikerats i minst sju dagar och rensas genom Data Domain-rensning.  Partiella replikeringar innehåller data och fingeravtryck som gör att efterföljande försök att replikera data kan köras snabbare.
Kostnaderna för partiell replikering kan vara lika höga som mängden replikerade data om replikeringsfel precis innan de slutförs.

Skillnad i kvarhållning
I Avamar-serverkonfigurationen är det möjligt att ange att replikerna ska behållas på målservern längre än en källa. Detta orsakar skillnader i kapacitetsanvändning.

Skillnader
i Avamar-konfigurationEn säkerhetskopia av en kontrollpunkt på Avamar-servern kan vara mycket stor. Om den endast är konfigurerad på målet Avamar ökar användningen av Data Domain på destinationen.

Ur Data Domain-perspektiv:

Fingeravtryck.

När data skickas till Data Domain under replikeringen tas de bort dubbletter. Ett fingeravtryck av data skickas först till måldomänen för att kontrollera om målet har data.

• Om Data Domain returnerar att fingeravtrycket finns där behöver data inte skickas på nytt

• Om Data Domain inte returnerar att fingeravtrycket inte hittas innebär det att antingen:

  • Fingeravtrycket finns inte där

  • Destination Data Domain har fingeravtryck men vill att data ska skickas ändå för att förbättra den speciella lokaliteten på Data Domain.

  • Data Domain är upptagen och vill inte slutföra hela sökningen.

Om duplicerade data skickas till Data Domain dedupliceras dessa data under rensningen genom att extra kopior av dessa data tas bort.
Destination Data Domain kommer att ha högre användning, men variationen bör inte vara stor.

Omkostnader för metadata.
Varje säkerhetskopierad fil levereras med dess filinformationsmetadata och den innehåller även fingeravtryck för var och en.

Exempel: För en fil på 1 TB är användningskostnaden 0,3 % av filstorleken.

För en genomsnittlig databit på 8 kB finns det 82 B metadata.  Det är cirka 0,01 % omkostnader för kapacitet efter kompilering.
Dessa omkostnader ökar dessutom med Avamar-integrering eftersom Avamar kombinerar säkerhetskopiorna för att få en syntetisk fullständig säkerhetskopiering från inkrementell varje gång säkerhetskopieringen slutförs.
Vi ser också att metadatakostnaderna ökar när det hoppas över säkerhetskopieringar, eller om data replikeras i fel ordning.
De enda säkerhetskopior som inte skapar den här kostnaden är säkerhetskopieringar av virtuella datorer. Kostnaden för metadata minimeras.

Exempel: När säkerhetskopian replikeras i fel ordning skapas L0-säkerhetskopiering på målet, som har mycket större metadatakostnader än Inc.  Anta att vi har 5 dagars säkerhetskopieringar.

Replikering Äldst till nyaste:

Första replikeringen kommer att vara L0, sedan kommer alla efterföljande att vara Inc.
1 × L0 + 4 × Inc

Replikering från nyaste till äldsta:

Replikeringen hoppar över en säkerhetskopiering:

Filspårning
Data Domain måste veta hur varje fil ska byggas från de deduplicerade blocken. Om Data Domain inte har denna information måste den återskapas och fingeravtryckskedjan återskapas. Detta kan orsaka en betydande ökning av kapaciteten.
Det finns två scenarier som kan orsaka en betydande ökning av kapaciteten på mål-Data Domain:

Exempel: Om mål-Data Domain har angetts i DNS med flera IP-adresser och IP-adresserna distribueras i round robin, kommer käll-Data Domain att ansluta till olika IP-adresser varje gång. Kopian av data som skickades igår känns inte igen och mer data skickas, vilket också ökar metadatakostnaden.

Det här problemet kan uppstå när SFS_BFT_ENABLED lämnas som falskt efter att Avamar-serveråterställningen har slutförts.

Detta kan resultera i en mycket stor avvikelse.  Utrymmet frigörs när säkerhetskopiorna upphör att gälla.

Inbyggd deduplicering
Data Domain kommer att be om dubbletter av data upp till 6 % av en logisk storlek på data för att optimera sin inbyggda deduplicering.

Skillnad i deduplicering och komprimering.
Data Domains utför sin egen deduplicering och komprimering av data på den lokala lagringen oberoende av varandra, och beroende på hur måldata lagras är detta inte lika och orsakar skillnader i användning.

Rensning av
Data DomainOm käll- och målData Domains kör rensning på olika dagar, eller om någon av Data Domains kör den oftare eller längre, kommer det att finnas skillnader i kapacitetsanvändning.

Bästa praxis:

Eftersom det kommer att finnas skillnader i användningen mellan de två Data Domain-systemen, källa och mål, finns det bästa praxis som kan hjälpa till att minimera skillnaden:

1. Minimera risken för återställning genom att ta hand om hfscheck-fel och maskinvarufel så snart de inträffar.

2. Se till att replikeringen slutförs. Om det finns ett pågående problem med att replikeringen är klar kan du kontakta Dell Technologies support för att granska konfigurationen.

3. Om du behöver behålla de två datadomänerna vid liknande användning ska du behålla samma kvarhållning av käll- och målkopior av säkerhetskopiorna och se till att säkerhetskopian av kontrollpunkter är inställd på samma sätt på båda Avamar-servrarna.

4. Se till att replikeringarna alltid är äldst till nyaste och att inga säkerhetskopieringar hoppas över.

5. Om Data Domain har konfigurerats med flera IP-adresser kontrollerar du att IP-adresserna inte distribueras med resursallokering.

6.  Låt båda Data Domain-systemen, källa och mål, köra rensning på samma dag och tid.

7. Ha SFS_BFT_ENABLED inställt på true.  Detta måste aktiveras av teknisk support (skapa en tjänstebegäran och referera till denna KB# – 182755)