Avamar: Trage back-upprestaties oplossen

  
Typische symptomen van trage back-upprestaties:

• De back-up kan niet worden voltooid binnen het geplande venster. De activiteitenmonitor meldt "Time-out client - einde"
• De back-up kan niet worden gestart voordat het geplande venster is afgelopen. De activiteitenmonitor meldt "Client time out - start"
• Afvalinzameling mislukt regelmatig met MSG_ERR_BACKUPSINPROGRESS of MSG_ERR_TRYAGAINLATER 

Verzamel informatie:
Verzamel gedetailleerde informatie over het probleem: 

• Informatie die Support nodig heeft bij het onderzoeken van prestatieproblemen met back-ups van Avamar-clients.

Bepaal welk deel van de back-upketen het grootste knelpunt heeft:
Het volgende schema geeft de belangrijkste onderdelen van een back-upsysteem weer.  


Knelpunten bestaan ALTIJD, maar we moeten proberen te begrijpen waar ze zijn.
Als we dit kunnen doen en het knelpunt kunnen beperken, zouden de prestaties moeten verbeteren. 
Zodra een knelpunt is gemitigeerd, kan een ander knelpunt aan het licht komen. Ons einddoel is om een situatie te bereiken waarin de duur van de back-up acceptabel is. 


Knelpunten aan de serverzijde van Avamar:
Als ALLE back-ups naar een Avamar-server traag zijn, overweeg dan de mogelijkheid van een probleem aan de serverzijde.  
Als ALLE back-ups naar een Avamar server op bepaalde tijden traag zijn, moet u rekening houden met een conflict aan de serverzijde of een knelpunt in het netwerk.
Als er een prestatieprobleem is met een of enkele back-upclients, richt u dan op elke client afzonderlijk.


Serverstatus:
Een gezonde Avamar-server is waarschijnlijk geen knelpunt voor back-ups. 

Controleer de status van de back-upserver.  

• Avamar: Het healthcheckscript proactive_check.pl uitvoeren op een Avamar server
• Als back-ups naar Data Domain worden verzonden, controleert u de DD Autosupport-informatie of schakelt u Data Domain-support in om te controleren of alles in orde is

Avamar beperkt clientverbindingen om acceptabele prestatieniveaus te behouden.


Serverconflict:

Als er momenten van de dag zijn waarop de back-upprestaties slecht zijn, kan dit duiden op een conflict.

• Het sched.sh script kan een visuele weergave geven van activiteiten die parallel aan de trage back-up werden uitgevoerd.
• Zie Avamar: Het sched.sh script gebruiken om historische back-up-, replicatie- en onderhoudsactiviteiten op een Avamar Server te controleren.
• Controleer op lopende onderhoudstaken door status.dpn uit te voeren
• Controleer hoeveel clientsessies er actief zijn

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

• Organiseer onderhouds- en back-upschema's zodat ze elkaar niet overlappen.
• Bekijk de uitvoer van de status.dpn en de belangrijkste opdrachten om de belasting van de dataknooppunten te controleren
• Voer mapall 'iostat -x'  uit op de dataknooppunten. Controleer %iowait en %idle en %util om te zien of de I/O-bandbreedte van een schijf verzadigd is.
• Als u de prestaties van een bepaalde client wilt isoleren, test u de back-up wanneer de Avamar-server geen onderhoudstaken of andere back-ups of replicatie uitvoert.

Opnameprestaties voor Data Domain back-up:
Meld u aan bij de Dell Support portal en raadpleeg:

• Data Domain: DDPCONNCHK Problemen met Data Domain DDBoost-connectiviteit en -prestaties oplossen

Knelpunten aan de netwerkzijde:
Het netwerk kan een knelpunt vormen als er een back-up van een client wordt gemaakt via een WAN.

Netwerklatentie:
Dit is van invloed op de snelheid waarmee clients kunnen controleren of hashes aanwezig zijn op de Avamar-server.  

• Voer ping uit van de client naar de Avamar-server en controleer het pakketverlies en de latentie van het netwerk

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) 

Als client en server gescheiden zijn door een WAN, kan de koppeling dan de benodigde data verzenden binnen het back-upvenster?
In dit geval zijn de gegevens die moeten worden verzonden4.316 GB. 

Deze waarden zijn allemaal met elkaar verbonden:

• Hoeveelheid nieuwe back-updata
• Beschikbare tijd voor back-up
• Effectieve netwerkbandbreedte

Voor grotere hoeveelheden nieuwe data is meer netwerkbandbreedte of een langere back-uptijd nodig.
Deze factoren hebben praktische beperkingen, maar kunnen tot op zekere hoogte door de gebruiker worden gecontroleerd.
Overweeg of een van hen kan worden gemanipuleerd om een tijdige back-up mogelijk te maken.


Als een knelpunt in het netwerk of een probleem met de servercommunicatie wordt vermoed:
Bevestig de netwerkdoorvoer tussen de client en het back-upapparaat. 

• Avamar - iperf uitvoeren tussen twee Avamar-systemen om de netwerkdoorvoerprestaties te testen

Schakel avtar comstats-logging in om probleemoplossing te vergemakkelijken.

• Avamar: Avtar COMSTATS-logging inschakelen en interpreteren om communicatieproblemen te diagnosticeren

Knelpunten aan de clientzijde:

• Avamar back-up mislukt met "Time Out - End" omdat er nog steeds een initiële back-up wordt uitgevoerd

Controleer of de back-up niet voortijdig is geannuleerd:
Zoek in het back-uplogboek naar 'geannuleerd'. Hieronder ziet u een voorbeeld waarbij een ongeduldige gebruiker een L1-back-up heeft geannuleerd.
 

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)

In dergelijke gevallen, waarin een back-up op correcte wijze wordt beëindigd, worden de data bewaard als een 'GEDEELTELIJKE' back-up.

• Avamar: Gedeeltelijke back-upfunctionaliteit en best practices voor initiële back-ups

Hoewel gedeeltelijke back-uplogboeken back-upprestaties aangeven, vereist een goede analyse het logboek van een voltooide back-up.


Controleer het logboek op problemen met de grootte van de bestandscache of hashcache:

• Zie Avamar - Het Avamar clientlogboek controleren op problemen met de bestandscache of de grootte van de hashcache

Controleren of beperkingsvlaggen worden doorgegeven aan avtar:
Avtar CPU of netwerkbeperking vermindert de back-upprestaties aanzienlijk. 
Zie Avamar : Het verbruik van systeembronnen (CPU, netwerk, I/O en geheugen) van een Avamar client beperken.

Dit kan worden gedetecteerd in het back-uplogboek.

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%

Is er een knelpunt in de CPU of het geheugen van de Avamar client?
Een Avamar back-up wordt zo snel uitgevoerd als de hardware toelaat en concurreert met andere services om bronnen. Houd rekening met de "dagtaak" van de klant en wanneer het druk is. 

Bewaak de client met behulp van Taakbeheer of Procesverkenner (op Windows) of het 'top'-commando (UNIX of Linux). Deze kunnen aantonenof er tijdens de back-up een CPU-verzadiging is opgetreden. 

Dell heeft een interne "LogAnalyzer"-tool die het resourceverbruik en de prestaties in de loop van de tijd in kaart brengt. Werk samen met Support om dit te gebruiken.

Cachebestanden worden tijdens de back-up in het geheugen geladen. Controleer het geheugengebruik van de client om te letten op paginafouten of aanwijzingen dat de client onvoldoende RAM heeft.

Dit is minder een probleem wanneer Avamar v7.x-clients naar Data Domain gebruikmaken van de wisselcache (f_cache2.dat).
De paging-cache vermindert de geheugenvoetafdruk op een client in vergelijking met de traditionele 'monolithische' avtar-cache.


Controleer op een I/O-knelpunt aan clientzijde:
Na de grootte van de clientcache is de volgende factor die de back-upprestaties bepaalt het storagesysteem dat de back-updata host en deze naar avtar stuurt.


Zorg ervoor dat de doelstorage in orde is:
Zorg ervoor dat er geen problemen zijn met het doelopslagapparaat waardoor optimale prestaties in de weg staan. 
 

Zorg ervoor dat software van derden niet concurreert met avtar voor I/O:
Zijn er applicaties op de client die met de Avamar Client concurreren voor storage-I/O?
Antivirussoftware, realtime of scannen bij toegang hebben een drastische invloed op de prestaties van de Avamar-client.  

• De back-upprestaties van de Avamar client worden aanzienlijk beïnvloed door het real-time scannen van bestanden door antivirussoftware

• Volumeparallellisme gebruiken om de Avamar back-upprestaties te verbeteren

Ervoor zorgen dat de client geen back-up van data maakt met CIFS of NFS:
Back-up van CIFS- of NFS-data wordt alleen ondersteund via een NDMP-accelerator. 

• Avamar en ondersteuning voor in kaart gebrachte CIFS (SMB) en NFS netwerkshares. 

Controleer of er storagecompressie of versleuteling wordt gebruikt:
Back-upprestaties kunnen lager zijn dan verwacht als de doeldata zich bevinden op doelstorage waar data zijn gecomprimeerd of versleuteld op bestandssysteemniveau.  


Knelpunten in Windows-clientbronnen analyseren met Perfmon:
Het volgende artikel helpt bij het maken van prestatiegrafieken om te begrijpen of de client op een bepaald moment op een bepaalde resource wacht. Overweeg om grafieken te gebruiken die zijn geproduceerd door de LogAnalyzer tool.

• Avamar - Microsoft Windows-prestaties gebruiken voor prestatiebewaking van Avamar-clients 

Een back-up maken van PST-bestanden
uit Outlook-archievenEen back-up met veel of grote .pst-bestanden kan traag werken. 

• Prestatieoverwegingen bij het gebruik van Avamar om een back-up te maken van PST-bestanden uit Outlook-archieven

Storageprestaties
benchmarkenControleer de prestaties van het storageapparaat waarop de doeldata worden gehost.

• Schijfprestatietests voor Avamar Linux-clients 

Slechte back-upprestaties omdat er een back-up wordt gemaakt van de data:
De meest voorkomende oorzaak van trage back-ups is te wijten aan de kenmerken van de data waarvan een back-up wordt gemaakt.


Controleer of er veel nieuwe of gewijzigde gegevens zijn:

• Avamar - Een back-up is traag of mislukt met "Time-out - end" vanwege veel nieuwe of gewijzigde data  

Een paar grote nieuwe of gewijzigde bestanden kunnen ervoor zorgen dat een anders snelle back-up het back-upvenster overschrijdt. Om deze bestanden te identificeren, raadpleegt u:

• Avamar: Aan de hand van de clientlogboeken bepalen welke bestanden nieuw zijn of gewijzigd sinds de vorige back-up   
• Identificeren welke bestanden er lang over deden om te worden verwerkt tijdens een Avamar-back-up 

Windows-clients

• Avamar-back-up van een dataset met veel symbolische koppelingen werkt erg langzaam  
• Avamar-clientprestaties en Windows NTFS-compressie 

Linux- en UNIX-clients - Controleer of de dataset van de client grote, schaarse bestanden bevat. 

• Avamar en schaarse bestanden 
• De back-upgrootte van een Avamar Linux-client kan misleidend zijn vanwege het gedrag van de schaarse bestandsverwerking van /var/log/lastlog en Avamar 

Controleer de back-upoverzichtsregels voor meer inzicht in het back-upbereik en om uitschieterwaarden te identificeren:
Zoek in het back-uplogboek naar de tekenreeksen "Backup #" of "Backed-up".

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)

Deze kunnen u veel tijd besparen bij het onderzoeken van back-upprestaties.
Voor de bovenstaande uitvoer moet u rekening houden met:

1. Of dit nu een initiële back-up of een back-up van niveau 1 is. (Onwaarschijnlijk, aangezien het back-uplabel #441 is)
2. Of het aantal bestanden in de back-up redelijk is. (2,6 miljoen bestanden zijn redelijk)
3. De verhouding tussen bestand en map? (Het is 10:1, dit is typisch)
4. De totale hoeveelheid data in de dataset. (~1,5 TB)
5. Het aantal te verwerken dossiers en het aandeel in het totaal aantal dossiers. (~11 K van de 2,5 miljoen bestanden is redelijk)
6. De totale grootte van alle te verwerken bestanden. (dit kan slechts een schatting zijn)
7. De hoeveelheid gewijzigde data die naar de Avamar-server moet worden verzonden. (668 MB)
8. Of het veranderingspercentage redelijk is. Hogere wijzigingspercentages kunnen worden getolereerd voor kleinere datasets (0,04% is redelijk)
9. Of de prestaties per uur, gezien de totale omvang en reikwijdte van de back-up, redelijk zijn. (124 K bestanden/uur zou gezien de andere cijfers als trage prestaties worden beschouwd)

Vaak bieden deze gegevens ons voldoende data om de oorzaak van slechte back-upprestaties te begrijpen.
Controleer indien nodig de statusregelberichten die worden gegenereerd terwijl de back-up wordt uitgevoerd.

Bepaal of een van de waarden in deze twee logboekregels uitschieters zijn. Met andere woorden, zijn ze groter of kleiner dan typisch is?
Als u bekend bent met het back-upgedrag, is het gemakkelijker om afwijkingen te detecteren.


Verhouding
tussen bestand en mapDe meeste datasets van klanten hebben een bestand naar map van ongeveer 10:1, en avtar is hierop afgestemd.
Als een dataset een lage verhouding tussen bestand en map heeft, zoals in het onderstaande voorbeeld, wordt de back-up mogelijk niet zo efficiënt uitgevoerd zonder kleine afstemming.  

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)

Zie Afstellen van de prestaties van Avamar-clientback-ups voor datasets met een lage verhouding tussen bestanden en mappen.

Prestatieanalyse met behulp van avtar-logboek Statusinformatieberichten:
Gebruik Kladblok++ of iets dergelijks om het logboek te filteren op avtar Info-regels die statusberichten bevatten. Deze kunnen worden gefilterd met behulp van de codevermeldingen met <5100> of <8688> , afhankelijk van de versie van de Avamar-client. Deze regels zijn periodieke statusmeldingen die door avtar worden gerapporteerd.

• Avamar - De statusregels van het avtar-back-uplogboek interpreteren.  

• Avamar-back-up werkt traag omdat software van derden metadata wijzigt voor bestanden die verder ongewijzigd zijn gebleven 

Bekijk het gebruik van include- en exclusievlaggen. Vermijd 'include'-verklaringen:
De gids met operationele best practices bespreekt lijsten opnemen en uitsluiten. 

Avamar moet elk bestand in de back-updataset vergelijken met beide lijsten om te bepalen of er een back-up van het bestand moet worden gemaakt. Dit vergelijkingsproces voegt overhead toe en kan de runtime voor back-ups verhogen.

Controleer de avsar-directory van de client op de aanwezigheid van een avtar.cmd-bestand .
Controleer of dat bestand actieve --exclude of --exclude-from-file instructies bevat.
Als een directory of bestandssysteem is uitgesloten, maar include-vlaggen worden gebruikt, scant avtar het op items waarvan het is opgedragen om ze op te nemen.

Controleer of de dataset reparsepunten of stubbestanden bevat:
Wees op uw hoede als een dataset stubbestanden of verwijzingen bevat naar data die op een ander apparaat zijn opgeslagen.
De back-upprestaties lijden eronder als avtar moet wachten tot het externe bestand wordt opgehaald.
Voorbeelden van dergelijke software zijn: Enterprise Vault Archiver, Moonwalk en DiskXtender.

• Avamar back-upprestaties van winclusterfs plug-in back-up zijn slecht na een upgrade van 7.0 naar 7.2.

Back-ups van virtuele clients met een Avamar-gastinstallatie

• Avamar gastback-up van virtuele machine werkt traag en er treedt een time-out op als gevolg van een knelpunt in de hardwarebron  
• Back-up van gastgasten van Avamar VM-client ondervindt trage prestaties als gevolg van VMware vShield Endpoint Trend Micro Diepe beveiliging  

• Avamar: Slechte back-upprestaties in WinclusterFS plug-up na een upgrade naar 7.2 van 7.0 

Overige opmerkingen

• Zorg ervoor dat clients voor virtuele machines geen resources hebben of zich houden aan strikte hardwarebeperkingen die van invloed zijn op het vermogen van de Avamar-back-up om snel te worden voltooid.  Op drukke machines kan het besturingssysteem overbelast raken of te veel threads jongleren, wat resulteert in ernstige contextwisselingen.
• Gebruik van de handleiding met operationele best practices voor Avamar om het Avamar-systeem te optimaliseren, back-ups te plannen en clientcaches af te stemmen.

Andere referentiematerialen

• Avamar-clientprestaties en Windows NTFS-compressie