Avamar: Feilsøking ved treg ytelse ved sikkerhetskopiering

  
Typiske symptomer på treg sikkerhetskopieringsytelse:

• Sikkerhetskopieringen kan ikke fullføres i det planlagte tidsvinduet. Aktivitetsmonitoren rapporterer "Klientens tidsavbrudd - slutt"
• Sikkerhetskopiering får ikke mulighet til å starte før det planlagte vinduet slutter. Aktivitetsmonitoren rapporterer "Klienttidsavbrudd - start"
• Søppelinnsamling mislykkes regelmessig med MSG_ERR_BACKUPSINPROGRESS eller MSG_ERR_TRYAGAINLATER 

Samle informasjon:
Samle detaljert informasjon om problemet: 

• Informasjon som kreves av kundestøtte ved undersøkelse av ytelsesproblemer for Avamar-klientsikkerhetskopiering.

Finn ut hvilken del av reservekjeden som har den mest alvorlige flaskehalsen:
Følgende skjema viser hovedkomponentene i et backup-system.  


Flaskehalser eksisterer ALLTID, men vi bør jobbe for å forstå hvor de er.
Hvis vi kan gjøre dette, og redusere flaskehalsen, bør ytelsen forbedres. 
Når en flaskehals er redusert, kan en annen flaskehals bli tydelig. Vårt endelige mål er å nå en situasjon der backup varighet er akseptabelt. 


Avamar flaskehalser på serversiden:
Hvis ALL sikkerhetskopiering til en Avamar-server er treg, bør du vurdere muligheten for et problem på serversiden.  
Hvis ALL sikkerhetskopiering til en Avamar-server går tregt på visse tider av døgnet, bør du vurdere påstand på serversiden eller en nettverksflaskehals.
Hvis det er et ytelsesproblem med én eller noen få sikkerhetskopieringsklienter, fokuserer du på hver klient alene.


Servertilstand:
En sunn Avamar-server er neppe en flaskehals for sikkerhetskopiering. 

Kontroller tilstanden til sikkerhetskopiserveren.  

• Avamar: Slik kjører du proactive_check.pl-skriptet for helsesjekk på en Avamar-server
• Hvis sikkerhetskopier sendes til Data Domain, må du kontrollere DD Autosupport-informasjon eller engasjere Data Domain-støtte for å bekrefte at den er i orden

Avamar begrenser klienttilkoblinger for å bevare akseptable ytelsesnivåer.


Server Contention:

Hvis det er tider på dagen når sikkerhetskopieringsytelsen er dårlig, kan dette tyde på strid.

• Det sched.sh skriptet kan gi en visuell fremstilling av aktiviteter som kjørte parallelt med den langsomme sikkerhetskopieringen.
• Se Avamar: Bruke det sched.sh skriptet til å kontrollere historisk sikkerhetskopiering, replikering og vedlikeholdsaktivitet på en Avamar-server.
• Se etter pågående vedlikeholdsoppgaver ved å kjøre status.dpn
• Sjekk hvor mange klientøkter som er aktive

  • admin@utilitynode:~/>: avmaint session | grep path | wc -l

• Ordne tidsplaner for vedlikehold og sikkerhetskopiering slik at de ikke overlapper hverandre.
• Se gjennom utdataene fra status.dpn og de øverste kommandoene for å kontrollere belastningen på datanodene
• Kjør mapall 'iostat -x'på  datanodene. Sjekk %iowait og %idle og %util for å se om I/O-båndbredden til en disk er mettet.
• For å isolere ytelsen til en bestemt klient tester du sikkerhetskopieringen når Avamar-serveren ikke utfører vedlikeholdsoppgaver eller andre sikkerhetskopieringer eller replikeringer.

Ytelse for sikkerhetskopiering av datadomener:
Logg på Dell Support-portalen og gjennomgå:

• Data Domain: DDPCONNCHK Slik feilsøker du Data Domain DDBoost-tilkobling og -ytelse

Flaskehalser på nettverkssiden:
Nettverket kan være en flaskehals hvis en klient sikkerhetskopieres over et WAN.

Ventetid på nettverk:
Dette påvirker hastigheten klientene kan sjekke om det finnes hash på Avamar-serveren.  

• Kjør ping fra klienten til Avamar-serveren, og kontroller pakketap og ventetid på nettverket

2014-11-20 04:45:30 avtar Info <5156>: Backup #1180 timestamp 2014-11-20 04:45:28, 23 files, 5 folders, 291.7 GB (23 files, 4.316 GB, 1.48% new) 

Hvis klient og server er atskilt av et WAN, kan koblingen overføre de nødvendige dataene i sikkerhetskopivinduet?
I dette tilfellet er dataene som må overføres4.316 GB. 

Disse verdiene henger alle sammen:

• Mengde nye sikkerhetskopierte data
• Tid til rådighet for sikkerhetskopiering
• Effektiv nettverksbåndbredde

Større mengder nye data krever mer nettverksbåndbredde eller lengre tid på sikkerhetskopiering.
Disse faktorene har praktiske grenser, men kan til en viss grad kontrolleres av brukeren.
Vurder om noen av dem kan manipuleres for å imøtekomme en rettidig sikkerhetskopiering.


Hvis det er mistanke om nettverksflaskehals eller serverkommunikasjonsproblem:
Bekreft nettverksgjennomstrømningen mellom klienten og sikkerhetskopieringsenheten. 

• Avamar – Slik kjører du iperf mellom to Avamar-systemer for å teste ytelsen til nettverksgjennomstrømningen

Aktiver avtar comstats-logging for å forenkle feilsøking.

• Avamar: Slik aktiverer og tolker du avtar COMSTATS-logging for å diagnostisere kommunikasjonsproblemer

Flaskehalser på klientsiden:

• Avamar Backup mislyktes med "Time Out - End" fordi den fortsatt utfører en første sikkerhetskopiering

Kontroller at sikkerhetskopieringen ikke ble avbrutt for tidlig:
Søk etter «kansellert» i sikkerhetskopiloggen. Nedenfor er et eksempel der en utålmodig bruker avbrøt en L1-sikkerhetskopi.
 

2013-11-05 12:15:29 avtar Info <5157>: PARTIAL Backup #14 timestamp 2011-11-05 12:13:36, 2,030 files, 562 folders, 397.3 MB (691 files, 17.44 MB, 4.39% new)
2013-11-05 12:15:29 avtar Info <7539>: Label "MOD-xxxxxxxxxx", scheduled to expire 11/12/11, none backup
2013-11-05 12:15:29 avtar Info <6083>: Backed-up 397.3 MB in 1.36 minutes: 17 GB/hour (89,593 files/hour)
2013-11-05 12:15:29 avtar Info <7883>: Finished at 2011-11-05 12:15:29 GMT Standard Time, Elapsed time: 0000h:01m:21s
2013-11-05 12:15:29 avtar Info <8468>: Sending wrapup message to parent
2013-11-05 12:15:29 avtar Info <5314>: Command failed (exit code 10013: Externally canceled)

I tilfeller som dette, hvor en sikkerhetskopi avsluttes på en elegant måte, beholdes dataene som en "DELVIS" sikkerhetskopi.

• Avamar: Funksjonalitet for delvis sikkerhetskopiering og anbefalte fremgangsmåter for første sikkerhetskopiering

Selv om delvise sikkerhetskopilogger indikerer ytelse for sikkerhetskopiering, krever riktig analyse loggen fra en fullført sikkerhetskopi.


Se loggen for problemer med størrelsen på filhurtigbufferen eller hash-hurtigbufferen:

• Se Avamar – Slik kontrollerer du Avamar-klientloggen for problemer med filhurtigbuffer eller hash-bufferskalering

Sjekk om strupeflagg sendes til avtar:
Avtar CPU eller nettverksbegrensning reduserer sikkerhetskopieringsytelsen betraktelig. 
See Avamar : Slik struper du en Avamar-klients forbruk av systemressurser (CPU, nettverk, I/O og minne).

Dette kan oppdages i sikkerhetskopiloggen.

2013-09-06 14:22:13 avtar Info <6557>: Network bandwidth throttling is enabled, limiting to approx. 0.512 Mbps (62.50 KB/sec)
2013-09-06 14:22:13 avtar Info <6558>: CPU throttling is enabled, limiting CPU usage to approx. 70%

Finnes det en Avamar-klient-CPU eller en flaskehals for minne?
En Avamar-sikkerhetskopiering kjører like raskt som maskinvaren tillater, og konkurrerer med andre tjenester om ressurser. Vær oppmerksom på kundens "dagjobb" og når den er opptatt. 

Overvåk klienten ved hjelp av Oppgavebehandling eller Process Explorer (på Windows) eller "topp" -kommandoen (UNIX eller Linux). Disse kan avsløre if CPU-metning oppstår under sikkerhetskopieringen. 

Dell har et internt "LogAnalyzer"-verktøy som kartlegger ressursforbruk og ytelse over tid. Samarbeid med kundestøtte for å bruke dette.

Hurtigbufferfiler lastes inn i minnet under sikkerhetskopieringen. Kontroller klientens minnebruk for å se etter sidefeil eller ledetråder om at klienten mangler RAM.

Dette er et mindre problem der Avamar v7.x-klienter til Data Domain bruker hurtigbufferen for sideveksling (f_cache2.dat).
Personsøkingsbufferen reduserer minnefotavtrykket på en klient sammenlignet med den tradisjonelle "monolittiske" avtar-cachen.


Se etter en I/O-flaskehals på klientsiden:
Etter størrelsen på klientbufferen er lagringssystemet som er vert for sikkerhetskopidataene og mater dem til avtar, den neste faktoren som bestemmer sikkerhetskopiytelsen.


Sørg for at mållagringen er i orden:
Kontroller at det ikke er noen problemer med mållagringsenheten som hindrer optimal ytelse. 
 

Forsikre deg om at tredjepartsprogramvare ikke konkurrerer med avtar om I/O:
Konkurrerer noen av applikasjonene på klienten med Avamar-klienten om lagrings-I/O?
Antivirusprogramvare, skanning i sanntid eller ved tilgang har en drastisk innvirkning på ytelsen til Avamar-klienten.  

• Sikkerhetskopieringsytelsen til en Avamar-klient blir svært påvirket av antivirusprogramvare som skanner filer i sanntid

• Bruke volumparallellitet til å forbedre ytelsen til Avamar-sikkerhetskopiering

Kontroller at klienten ikke sikkerhetskopierer data ved hjelp av CIFS eller NFS:
Sikkerhetskopiering av CIFS- eller NFS-data støttes bare via en NDMP-akselerator. 

• Avamar og støtte for CIFS (SMB) OG NFS-tilordnede delte nettverksressurser. 

Kontroller om lagringskomprimering eller -kryptering er i bruk:
Ytelsen for sikkerhetskopiering kan være lavere enn forventet hvis måldataene ligger på mållagring der data komprimeres eller krypteres på filsystemnivå.  


Analysere flaskehalser i Windows-klientressurser med Perfmon:
Følgende artikkel bidrar til å opprette ytelsesgrafer for å forstå om klienten venter på en bestemt ressurs på et bestemt tidspunkt. Vurder å bruke med grafer produsert av LogAnalyzer-verktøyet.

• Avamar - Bruke Microsoft Windows perfmon til ytelsesovervåking av Avamar-klienter 

Sikkerhetskopiering av Outlook-arkiv .pst-filer
En sikkerhetskopi med mange eller store PST-filer kan fungere tregt. 

• Ytelseshensyn ved bruk av Avamar til å sikkerhetskopiere PST-filer i Outlook-arkivet

Benchmarking av lagringsytelse
Kontroller ytelsen til lagringsenheten der måldataene er lagret.

• Testing av diskytelse for Avamar Linux-klienter 

Dårlig ytelse for sikkerhetskopiering på grunn av sikkerhetskopiering av data:
Den vanligste årsaken til trege sikkerhetskopieringer skyldes egenskapene til dataene som sikkerhetskopieres.


Sjekk om det er mange nye eller endrede data:

• Avamar - En sikkerhetskopiering er treg eller mislykkes med "Time out - end" på grunn av mange nye eller endrede data  

Noen få store, nye eller endrede filer kan føre til at en ellers rask sikkerhetskopiering overskrider sikkerhetskopieringsvinduet. Hvis du vil identifisere disse filene, kan du se:

• Avamar: Slik bruker du klientloggene til å identifisere hvilke filer som er nye eller endret siden forrige sikkerhetskopiering   
• Slik identifiserer du hvilke filer som tok lang tid å behandle under en Avamar-sikkerhetskopiering 

Windows-klienter

• Avamar-sikkerhetskopiering av datasett som inneholder mange symbolske koblinger, kjører svært sakte  
• Avamar-klientytelse og Windows NTFS-komprimering 

Linux- og UNIX-klienter – Kontroller om klientens datasett inneholder store, sparsomme filer. 

• Avamar og sparsomme filer 
• Størrelsen på sikkerhetskopien til en Avamar Linux-klient kan være villedende på grunn av «/var/log/lastlog» og Avamars sparsomme filhåndteringsatferd 

Kontroller sammendragslinjene for sikkerhetskopien for å forstå sikkerhetskopieringsomfanget og identifisere utliggerverdier:
Søk etter strengene "Backup #" eller "Backed-up" i sikkerhetskopiloggen.

2017-06-07 20:21:38 avtar Info <5156>: Backup #441 timestamp 2017-06-07 20:21:38, 2,653,523 files, 255,181 folders, 1,566 GB (10,777 files, 668.4 MB, 0.04% new)
2017-06-07 20:21:38 avtar Info <6083>: Backed-up 1,566 GB in 1281.60 minutes: 73 GB/hour (124,228 files/hour)

Disse kan spare deg for mye tid når du undersøker sikkerhetskopieringsytelsen.
For utdataene ovenfor bør du vurdere:

1. Enten dette er en første eller nivå 1 sikkerhetskopi. (Usannsynlig, siden sikkerhetskopien etiketten er # 441)
2. Om antall filer i sikkerhetskopien er rimelig. (2,6 millioner filer er rimelige)
3. Forholdet mellom fil og mappe? (Det er 10:1, dette er typisk)
4. Den totale mengden data i datasettet. (~1,5 TB)
5. Antall filer som skal behandles og andelen av det totale antallet filer. (~ 11 K ut av 2.5M filer er rimelig)
6. Den totale størrelsen på alle filer som skal behandles. (dette kan bare være et estimat)
7. Mengden endrede data som skal sendes til Avamar-serveren. (668 MB)
8. Om endringsfrekvensen er rimelig. Høyere endringsrater kan tolereres for mindre datasett (0,04% er rimelig)
9. Hvorvidt ytelsen per time, gitt den totale størrelsen og omfanget av sikkerhetskopien, er rimelig. (124 K filer / time vil bli ansett som treg ytelse gitt de andre tallene)

Ofte gir disse detaljene oss nok data til å forstå årsaken til dårlig sikkerhetskopieringsytelse.
Se om nødvendig gjennom statuslinjemeldingene som genereres mens sikkerhetskopien kjører.

Fastslå om noen av verdiene i disse to logglinjene er avvik. Med andre ord, er de større eller mindre enn det som er vanlig?
Hvis du er kjent med sikkerhetskopieringsatferden, er det lettere å oppdage avvik.


Forholdet
mellom fil og mappeDe fleste kundedatasett har en fil til mappe på omtrent 10:1, og avtar er innstilt for å gjenspeile dette.
Hvis et datasett har et lavt fil-til-mappe-forhold som i eksemplet nedenfor, kan det hende at sikkerhetskopieringen ikke kjører like effektivt uten mindre justering.  

2015-11-18 00:34:32 avtar Info <5156>: Backup #75 timestamp 2015-11-18 00:24:43, 4,007,032 files, 1,974,043 folders, 1,589 GB (2,680 files, 419.4 MB, 0.03% new)

Se Avamar-klient om ytelsesjustering for sikkerhetskopiering for datasett med lavt forhold mellom filer og mapper.

Ytelsesanalyse ved hjelp av avtar-logg Statusinformasjonsmeldinger:
Bruk Notepad++ eller lignende, filtrer loggen for avtar Info-linjer som inneholder statusmeldinger . Disse kan filtreres ved hjelp av kodeoppføringer som inneholder <5100> eller <8688> , avhengig av Avamar-klientversjonen. Disse linjene er periodiske statusmeldinger rapportert av avtar.

• Avamar - Tolke statuslinjer for avtar sikkerhetskopilogg.  

• Avamar-sikkerhetskopieringen går tregt på grunn av at tredjepartsprogramvaren endrer metadata for filer som ellers ikke er endret 

Se gjennom bruken av inkludere og ekskludere flagg. Unngå «inkluder»-utsagn:
Veiledningen for anbefalte fremgangsmåter for drift tar for seg lister over inkludere og ekskludere. 

Avamar må sammenligne hver fil i det sikkerhetskopierte datasettet med begge listene for å avgjøre om filen skal sikkerhetskopieres. Denne sammenligningsprosessen legger til overhead, og kan øke sikkerhetskopieringstiden.

Sjekk klientens avsar-katalog for tilstedeværelse av en avtar.cmd-fil .
Kontroller om filen inneholder aktive - -exclusion - eller --exclude-from-file-setninger .
Hvis en katalog eller et filsystem er ekskludert, men inkluderer flagg brukes, skanner avtar det for elementer som det har blitt fortalt å "inkludere".

Sjekk om datasettet inneholder reanalyseringspunkter eller stubbfiler:
Vær forsiktig hvis et datasett inneholder stubbfiler eller pekere til data som er lagret på en annen enhet.
Sikkerhetskopieringsytelsen lider hvis avtar må vente på at den eksterne filen skal hentes tilbake.
Eksempler på slik programvare er: Enterprise Vault Archiver, Moonwalk og DiskXtender.

• Avamar-sikkerhetskopieringsytelsen til winclusterfs-plugin-sikkerhetskopiering er dårlig etter oppgradering fra 7.0 til 7.2.

Sikkerhetskopiering av virtuelle klienter med en Avamar-gjesteinstallasjon

• Avamar-gjestesikkerhetskopiering av Virtual Machine kjører langsomt og blir tidsavbrutt på grunn av en flaskehals for maskinvareressurs  
• Avamar VM-klientens gjestebackup opplever treg ytelse på grunn av VMware vShield Endpoint Trend Micro Deep Security  

• Avamar: Dårlig sikkerhetskopieringsytelse i winclusterfs plugin-sikkerhetskopiering etter oppgradering til 7.2 fra 7.0 

Andre notater

• Sørge for at klienter for virtuelle maskiner ikke er ressursbegrensede eller overholder strenge maskinvarebegrensninger som påvirker Avamar-sikkerhetskopieringens evne til å fullføre det raskt.  På travle maskiner kan operativsystemet være overbelastet eller sjonglere for mange tråder, noe som resulterer i alvorlig kontekstbytte.
• Bruk av veiledningen med anbefalte fremgangsmåter for Avamar for å optimalisere Avamar-systemet, planlegge sikkerhetskopier og justere klientbuffere.

Andre referanser

• Avamar-klientytelse og Windows NTFS-komprimering