Skip to main content
  • Place orders quickly and easily
  • View orders and track your shipping status
  • Create and access a list of your products

Avamar – Slik tolker du avtar-statuslinjer for sikkerhetskopieringslogg

Summary: Denne artikkelen beskriver hvordan du forstår og tolker avtar-loggstatuslinjene som genereres med jevne mellomrom under en sikkerhetskopieringsøkt. Dette er et nyttig verktøy, særlig når du undersøker problemer med klientytelse. ...

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.

Symptoms

Under en sikkerhetskopiering skriver avtarprosessen med jevne mellomrom statuslinjer til loggen som rapporterer statusen til, og fremdriften gjort av, avtar under sikkerhetskopieringen.

Eksempel:
2014-11-14 10:16:56 avtar Info <8688>: Status 2011-11-14 10:16:56, 328 filer, 16 mapper, 26,53 MB (328 filer, 15,35 MB, 57,86 % nye) 34 MB 1 % CPU C:\directory\Folder\file.doc

Slik isolerer du statusinformasjon
Bruk et redigeringsprogram som Notepad++ og søk etter linjer som inneholder «<8688>» eller «<5100>» i eldre klientversjoner.

Hyppighet for statuslogging
Som standard skrives informasjon om avtar-status hvert 15. minutt (900 s). Denne frekvensen kan endres ved å sende en verdi til avtar ved hjelp av flaggstatus=[sekunder]. Gjør dette enten ved hjelp av avtar.cmd-parameterfilen eller fra avamar-konfigurasjonsalternativene for brukergrensesnittet.

Det anbefales å beholde standardfrekvensen for å opprettholde logglesbarhet. Hvis en fil bruker mer enn 15 minutter på å sikkerhetskopiere, rapporterer den på flere statuslinjer. Hvis mer detaljerthet er nødvendig, reduserer du innstillingen etter behov. Hvis store logger genereres for langvarig sikkerhetskopiering, bør du vurdere å øke innstillingen for å rapportere hver time (3600 s).

Hva betyr de ulike delene av statuslinjen?
  • I tillegg til dato og klokkeslett forteller statusrapportene oss.
  • Hvor mange filer har blitt behandlet så langt.
  • Hvor mange av disse filene er endret.
  • Mengden data som skal sendes til Avamar-serveren
  • avtar-ressursmålinger
  • Detaljer om den siste filen som skal behandles.
Nedenfor bruker vi fargekoding for å identifisere disse målene.
2014-12-07 10:16:56 avtar Info <8688>: Status 2014-12-07 10:16:56, 20 788 307 filer, 343 633 kataloger, 327,9 GB (9 049 052 filer, 0 byte, 0,00 % nye) 1074 MB60 % CPU /data/types.dtc

Informasjon som oppgis av statuslinjen: -
  • Dato og klokkeslett (klientens tidssone)
  • Antall kildefiler og mapper som har blitt skannet så langt
  • Den samlede størrelsen på kildefiler som har blitt skannet så langt 

For avsnittet i braketter:-
(9 049 052 filer, 0 byte, 0,00 % nye)
  • Antall endrede filer som avtar fullstendig behandlet
  • Mengden data som legges til Avamar-serveren
  • Endringshastighet for denne sikkerhetskopieringen (så langt).

Den andre siden av logglinjen viser:-
1074 MB60 % CPU/base/data/types.dtc
  • Klientminnebruk av avtar-prosessen (i Megabyte)
  • Prosentandel av systemets CPU som forbrukes av avtar
  • Navnet på den siste filen ble sikkerhetskopiert da statusmeldingen ble generert.

Den endelige og viktigste statuslinjen er sikkerhetskopisammendraget. Du finner den mot slutten av loggen ved å søke etter «Backup #».  
Etter dette har vi statistikklinjen for sikkerhetskopiering (søkbar med sikkerhetskopiert").

2015-11-18 00:34:32 avtar Info <5156>: Sikkerhetskopieringsnummer 75 ganger 2015-11-18 00:24:43, 4,007,032 filer, 1,974,043 mapper, 1,589 GB (2680 filer, 419,4 MB, 0,03 % ny) . 2015-11-18 00:34:32 avtar Info <6083>: Sikkerhetskopiert 1589 GB på 144,70 minutter: 659 GB/time (1 661 482 filer/time)

Åpne filer
For å sikkerhetskopiere en fil må avtar åpne den. Følgende melding viser at avtar har én fil som åpnes under sikkerhetskopieringen. Dette er atskilt fra alle andre applikasjoner som kanskje også fungerer på filen.

2016-08-22 21:30:04 avtar Info <8688>: Status 2016-08-22 21:30:04, 25, 921 filer, 3746 kataloger, 104,9 GB (1274 filer, 0 byte, 0,00 % nye) 1733 MB 46 % CPU (1 åpne filer) /opt/2016_hold.tar 

Cause

Ikke aktuelt

Resolution

Denne delen bør gjennomgås sammen med den generelle artikkelen om feilsøking av ytelsen til sikkerhetskopiering av klienter.
Se Avamar-klientens ytelse for sikkerhetskopiering. Slik identifiserer du flaskehalser (RESOLUTION PATH)


Gjennomgå klientlogger regelmessig for å forstå hva som er vanlig, slik at det kan identifiseres uvanlige mønstre.
" Outliers" kan indikere et potensielt problem som påvirker sikkerhetskopieringsytelsen og, eller Avamar-serverlagringskapasiteten!


Hver del av statusinformasjonen kan være nyttig. Her oppgir vi en rekke ting du bør ta hensyn til når du ser på hver statistikk.  
Ved å filtrere ut statuslinjene fra loggen og analysere figurene, kan vi forstå atferden.


Vurder følgende:

1) Antall kildefiler og mapper som er skannet så langt

, er det mange filer i sikkerhetskopien? Hver fil avtar må skanne, tar tid.  
Varigheten for sikkerhetskopiering av filsystemet er omtrent proporsjonal med antallet skannede filer.  


Etter hvert som sikkerhetskopieringen utvikler seg, bør antallet kildefiler og mapper som er skannet så langt, øke.
Hvis dette tallet slutter å øke, eller hvis hastigheten på filskanningen blir tregere, kontrollerer du filnavnene på slutten av statuslinjen. Du finner kanskje en stor, endret fil som behandles av avtar.
Vurder at avtar nå kan skanne filer i en annen partisjon eller et tregere (eller tyngre) lagringsundersystem.


Er antallet filer i sikkerhetskopien realistisk gitt ytelsen til filer/timer og det maksimale tilgjengelige vinduet for sikkerhetskopiering?

2) Forholdet mellom filer og mapper

Ser det ut til å være et uvanlig lite eller stort antall mapper i forhold til antall filer som er sikkerhetskopiert?  
Mange filer i én enkelt mappe (100 000 +) kan noen ganger føre til redusert ytelse, i tillegg til et lite fil-til-mappe-forhold.

3) Kombinert størrelse på kildefiler skannet så langt

Denne verdien vil til slutt gi den totale størrelsen på sikkerhetskopien.
Verdien er viktig for sikkerhetskopiering av databasetyper der avtar sannsynligvis vil behandle mange av filene i datasettet.
I slike situasjoner er ytelsen for sikkerhetskopiering proporsjonal med hvor raskt avtar kan behandle dataene (chunk, compress, hash).


Denne verdien er også viktig for ytelsen til sikkerhetskopiering av filsystemet. Sikkerhetskopieringer av større datasett kan tolerere mindre prosentvis endringshastighet.  

Merk: Når vi tar antallet filer som skannes og utsendes med størrelsen på kildefilene som skannes, lærer vi den gjennomsnittlige (gjennomsnittlige) filstørrelsen.
Hvis den gjennomsnittlige filstørrelsen er stor, oppretter selv et beskjedent antall endrede filer mye behandlingsarbeid for avtar.
Se ytelsesvurderinger når du bruker Avamar til å sikkerhetskopiere Outlook arkiv .pst files 




4) Antall endrede filer behandlet av avtar

Dette hjelper oss med å forstå hvor mye arbeid sikkerhetskopien må gjøre.

For sikkerhetskopiering av databaser er dette tallet relativt høyt i forhold til antall filer i datasettet.  
Det kan også være tilfelle at alle filene i datasettet er endret.  


For sikkerhetskopiering av filsystem bør du notere dette nummeret nøye. Under første sikkerhetskopiering er tallet alltid høyt.  
For sikkerhetskopiering på nivå 1 (sikkerhetskopier som tas etter den første sikkerhetskopieringen), vil tallet vanligvis være under 3 % av det totale antallet filer som er skannet.  
Hvis andelen er >5 % kan det føre til en dramatisk effekt på varigheten av sikkerhetskopieringen, særlig hvis det er en stor mengde data i datasettet, eller hvis den gjennomsnittlige filstørrelsen er stor.


Finn ut hvilke filer som endrer seg, og vurder hvorfor de endrer seg. Se;

5) Mengden data som legges til Avamar-serveren

Dette er mengden data som må sendes over ledningen til Avamar-serveren. Det påvirker kapasitetsbruken på Avamar-serveren eller Data Domain.  
For klienter atskilt fra serveren over en WAN, eller der replikering vurderes for en klient, bør denne verdien være liten nok til å overføre klientens data i vinduet for sikkerhetskopiering gitt den tilgjengelige nettverksbåndbredden.


Det er mulig å identifisere klienter som har lagt mest mulig data til et Avamar-system ved hjelp av capacity.sh skriptet (se nedenfor).)


6) Endringshastigheten for denne sikkerhetskopien (så langt)

Denne verdien er etmontering av data som er lagt til Avamar-serveren delt på den kombinerte størrelsen på kildefiler som er skannet så langt.
En endringshastighet på over 3 % anses som høy.
7) Gjeldende minnebruk av avtarprosessen (i Megabyte)

Minnebruk avhenger av ulike faktorer, inkludert;
  • Avamar-versjon
  • Klientoperativsystem
  • Datasettegenskaper
  • Type filhurtigbuffer som brukes.  
Vurder andelen av klientens RAM som brukes av avtar, og om dette forbruket kan påvirke klientens klientprosesser.
Når Avtar sikkerhetskopierer store kataloger, bruker den mer minne når den prøver å skanne og sortere dataene.
Økt minneforbruk kan også forekomme hvis du bruker visse avtar tuningparametere (for eksempel maxopendirs-flagget).



8) Prosentandelen av systemets CPU som forbrukes av avtar

A middels til middels høy verdi er ønskelig, siden det betyr at avtar mates data raskt nok til å holde CPU-en opptatt.
Hvis CPU-bruken er lav (<10 eller <20 %), kan det skyldes treg, travel eller svært oppsagt lagring eller muligens en treg nettverkstilkobling.


Vurder om Avtar konkurrerer med andre prosesser som kjører på maskinen. Ideelt sett bør sikkerhetskopier planlegges i perioder med lavere aktivitet på klienten.


9) Navnet på den siste filen ble sikkerhetskopiert da statusmeldingen ble generert:

Vurder hva slags data som sikkerhetskopieres ved å kontrollere filnavn, katalogstruktur eller filtyper.
Bruker avtar lang tid på å behandle bestemte filer eller kataloger? 
Reduseres hastigheten på filskanning under en bestemt katalogbane eller mens du arbeider gjennom filer i en bestemt partisjon?

Additional Information

Eksempel på logging: –

Status 2011-11-14 10:19:26, 413 files, 36 folders, 43.84 MB (413 files, 24.54 MB, 55.99% new) 33MB   2% CPU  E:\\store\Small-file.txt
Status 2011-11-14 10:19:41, 418 files, 39 folders, 46.24 MB (418 files, 26.14 MB, 56.53% new) 33MB   2% CPU  E:\\store\Large.ppt
Status 2011-11-14 10:19:56, 420 files, 39 folders, 47.79 MB (420 files, 27.49 MB, 57.52% new) 33MB   2% CPU  E:\\store\Large.ppt
Status 2011-11-14 10:20:11, 420 files, 39 folders, 49.25 MB (420 files, 28.87 MB, 58.63% new) 33MB   1% CPU  E:\\store\Large.ppt
Status 2011-11-14 10:20:26, 420 files, 39 folders, 52.68 MB (420 files, 32.30 MB, 61.32% new) 33MB   2% CPU  E:\\store\Large.ppt
Status 2011-11-14 10:20:41, 420 files, 39 folders, 54.80 MB (420 files, 34.33 MB, 62.65% new) 33MB   2% CPU  E:\\store\Large.ppt
Status 2011-11-14 10:20:56, 420 files, 39 folders, 58.48 MB (420 files, 38.01 MB, 64.99% new) 33MB   2% CPU  E:\\store\Large.ppt
Status 2011-11-14 10:21:11, 420 files, 39 folders, 59.87 MB (420 files, 39.39 MB, 65.80% new) 33MB   1% CPU  E:\\store\Large.ppt
Status 2011-11-14 10:21:26, 420 files, 39 folders, 62.40 MB (420 files, 41.92 MB, 67.19% new) 33MB   2% CPU  E:\\store\Large.ppt
Status 2011-11-14 10:21:41, 420 files, 39 folders, 64.59 MB (420 files, 44.12 MB, 68.31% new) 33MB   2% CPU  E:\\store\Large.ppt
Status 2011-11-14 10:21:56, 420 files, 39 folders, 67.04 MB (420 files, 46.57 MB, 69.46% new) 33MB   2% CPU  E:\\store\Large.ppt
Status 2011-11-14 10:22:11, 420 files, 39 folders, 69.13 MB (420 files, 48.66 MB, 70.39% new) 33MB   1% CPU  E:\\store\Large.ppt
Status 2011-11-14 10:22:26, 421 files, 39 folders, 71.99 MB (421 files, 51.25 MB, 71.20% new) 33MB   2% CPU  E:\\store\Smalller.pptx
Status 2011-11-14 10:22:41, 421 files, 39 folders, 74.80 MB (421 files, 54.06 MB, 72.27% new) 33MB   2% CPU  E:\\store\Small.xls
Status 2011-11-14 10:22:56, 424 files, 39 folders, 77.23 MB (424 files, 56.24 MB, 72.83% new) 33MB   2% CPU  E:\\store\Small.txt
Status 2011-11-14 10:23:11, 425 files, 39 folders, 79.33 MB (425 files, 57.62 MB, 72.63% new) 33MB   1% CPU  E:\\store\Small.pdf

What we learn from this logging example:
  • Statusrapporter er angitt med 15 intervaller (standard er = 900 s. Forfatteren vil anbefale innstillinger på 300, 600 eller 900).
  • Sikkerhetskopieringen gjør treg, men jevn fremgang.
  • Ytelsen til filen per time er lav (sikkerhetskopieringen fortsetter gjennom 12 filer på fire minutter).
  • Dataene som sikkerhetskopieres, tilordnes fra en delt lagringsenhet.
  • Hvis prosentandelen av "nye" data er uvanlig høy, kan dette være en førstegangs sikkerhetskopiering, eller sikkerhetskopieringen inneholder mange nye data.
  • LargePresentation.ppt brukte flere minutter på å sikkerhetskopieres.
  • CPU-bruken er lav. noe som innebærer at avtar blir levert data fra mållagringsenheten med en lav hastighet. De innkommende dataene er ikke tilstrekkelige til å holde CPU-en opptatt.

Affected Products

Avamar
Article Properties
Article Number: 000062852
Article Type: Solution
Last Modified: 18 Oct 2024
Version:  6
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.