Avamar v7 og nyere – Datasanering rapporterer "skipped-hashes" som ikke kan rengjøres på grunn av "Hash Referenced Bit Maps" når dataene er i bruk

摘要: I Avamar v7 og nyere kan loggen for datasanering rapportere flere "skipped-hashes" når de underliggende dataene er i bruk når vedlikeholdsaktiviteten kjøres.

本文适用于 本文不适用于 本文并非针对某种特定的产品。 本文并非包含所有产品版本。

症状

Funksjonen Hash Referenced Bit Maps er en funksjon som ble introdusert med Avamar v7.x-funksjonen, som gjør at sikkerhetskopiering kan forekomme under vedlikeholdsaktiviteten for datasanering (GC). 

Før denne funksjonen kunne ikke datainnsamlingen kjøre samtidig på grunn av muligheten for datakonflikter. 

Under fasen for datasanering opprettholder den nye funksjonen informasjon i minnet om data som legges til eller endres (et «kart over henviste hasher»). Datasanering kontrollerer denne informasjonen for å finne ut hvilke hashe (og dataene de refererer til) som ikke skal fjernes.  

Et krav til denne funksjonen er at disse "kartene" trenger minst 5 minutter med "stille" tid der ingen sikkerhetskopiering oppstår i den rekkefølgen de kan tilbakestilles. Når denne tilbakestillingen oppstår, kan data som ble låst i dem, skannes under den påfølgende innsamlingssyklusen for datasanering, så lenge de fortsetter å være uendret.

Denne stilletiden bør vurderes når du utformer den daglige Avamar-sikkerhetskopierings- og vedlikeholdsplanen. 
En manglende evne til å tilbakestille kartene kan hindre datasanering i å rydde opp i utløpte data.
Hvis hash-referansekartet ikke får mulighet til å tilbakestilles, behandles ikke data som er kvalifisert for fjerning av søppel, og kapasitetsbruken kan øke. Hvis kartet ikke kan tilbakestilles over en lengre periode, kan loggen for datasanering vise en økende mengde "skipped-hashes".

原因

Sikkerhetskopiering(er) utløp, men datasanering gjenopprettet ikke alle kvalifiserte data som var kvalifisert til å bli slettet fordi noen av dataene var i bruk på det tidspunktet.

Hvis du vil kontrollere dette, kjører du kommandoen nedenfor:
Kommandoen dumper vedlikeholdsloggen for datasanering i 7 dager og analyserer den slik at den vises.
  • Hvor mange hasher ble hoppet over,
  • Hvor mye data ble slettet
  • Hvor mange datasaneringspass fant sted
  • Hvor lenge datasanering kjørte for
dumpmaintlogs --types=gc --days=7 | grep passes | cut -d ' ' -f1,10,14,15,17

2014/02/11-11:03:23.01310 skipped-hashes="3118" megabytes-recovered="120" passes="10" elapsed-time="134"
2014/02/12-11:05:33.78790 skipped-hashes="4051" megabytes-recovered="88" passes="10" elapsed-time="264"
2014/02/12-16:18:16.79236 skipped-hashes="5098" megabytes-recovered="199" passes="16" elapsed-time="268"
2014/02/12-16:28:20.35698 skipped-hashes="5099" megabytes-recovered="0" passes="1" elapsed-time="97"
2014/02/12-17:14:22.88473 skipped-hashes="5452" megabytes-recovered="26" passes="20" elapsed-time="162"
2014/02/12-20:46:06.80518 skipped-hashes="6789" megabytes-recovered="83" passes="21" elapsed-time="184"
2014/02/12-21:09:30.70374 skipped-hashes="89139" megabytes-recovered="9432" passes="26" elapsed-time="536"
2014/02/12-23:30:13.07016 skipped-hashes="96510" megabytes-recovered="604" passes="21" elapsed-time="210"
2014/02/12-23:34:15.11324 skipped-hashes="96511" megabytes-recovered="1" passes="3" elapsed-time="99"
2014/02/13-13:41:02.20624 skipped-hashes="97301" megabytes-recovered="0" passes="1" elapsed-time="81"
2014/02/14-11:03:45.31704 skipped-hashes="98220" megabytes-recovered="131" passes="2" elapsed-time="157"
2014/02/14-16:49:14.94905 skipped-hashes="98220" megabytes-recovered="67" passes="2" elapsed-time="105"
2014/02/14-21:15:27.77268 skipped-hashes="98224" megabytes-recovered="0" passes="1" elapsed-time="106"
2014/02/14-21:25:51.71154 skipped-hashes="98224" megabytes-recovered="0" passes="1" elapsed-time="101"
2014/02/14-22:07:19.81136 skipped-hashes="98229" megabytes-recovered="0" passes="1" elapsed-time="125"
2014/02/14-22:15:21.50825 skipped-hashes="98275" megabytes-recovered="1" passes="5" elapsed-time="115"
2014/02/14-22:27:13.88500 skipped-hashes="98278" megabytes-recovered="0" passes="1" elapsed-time="98"
2014/02/14-23:58:47.70116 skipped-hashes="102294" megabytes-recovered="1" passes="4" elapsed-time="110"
2014/02/15-11:02:29.45054 skipped-hashes="102538" megabytes-recovered="0" passes="1" elapsed-time="82"
2014/02/16-00:56:27.25596 skipped-hashes="0" megabytes-recovered="900395" passes="59" elapsed-time="17417"
2014/02/17-11:32:42.66479 skipped-hashes="0" megabytes-recovered="57540" passes="28" elapsed-time="1890"

Analyse:

Utdataene viser at antall hoppende hasher øker over tid til hash-referansekartet tilbakestilles 16. februar 2014.
Vi kan også se hvor mange data som er renset for "megabyte-gjenopprettet" hopping etter at hasher er frigjort, og datasanering kan behandle dem for utløpte data.

解决方案

Umiddelbar løsning

1. Kontroller at kartene kan tilbakestilles, og la datasanering kjøre på nytt.
2. Kontroller at det ikke er noen kjørende avtar-økter som legger til data i systemet (sikkerhetskopiering eller innkommende replikeringsdata). Bruk GUI-aktivitetsskjermen og se etter opphengte økter som bare vises med kommandoen «avmaint sessions --full» (Avmaint sessions --full).
3. Stopp alle sikkerhetskopieringer og innkommende replikeringsøkter.
4. Vent i minst fem minutter for å tillate at Hash Referenced Bit Maps er nok tid til å tilbakestille.  
5. Når GC kjører igjen, må du kontrollere GC-vedlikeholdsloggen for å bekrefte at skipped-hashes=0

Hvis hoppesede hashes ikke er tilbakestilt til null, må du samarbeide med kundestøtte for å dobbeltsjekke trinnene ovenfor. Hvis datasanering rapporterer MSG_ERR_TRYAGAINLATER, kan kundestøtte bekrefte om dette skyldes deling av indeksstriper. 
 

Langsiktig løsning

Designe tidsplanene for sikkerhetskopiering og vedlikehold, slik at det er vanlig "inaktiv" tilgjengelig for hash referenced bit-kartet som skal tilbakestilles.

Med andre ord skal ikke sikkerhetskopieringsplanene kjøres 24/7. Bygg en tidsplan som gir en kort tidsperiode når ingen sikkerhetskopiering eller innkommende replikeringsdata skrives til systemet. 


 

其他信息

Merknader: 
  • Den eneste gangen bittilordningene med hash-referanse sjekker om de kan tilbakestilles, er rett etter at en avtar-økt avsluttes. Når det ikke pågår noen avtar-økter, vil kartet bare tilbakestilles hvis:
    (a) Indeksstriper gjennomgår ikke deling
    (b) Hvis datasanering ikke kjører (kartet er låst» fra tilbakestilling under GC)
    (c) Hvis ingen andre avtar-økter (sikkerhetskopiering, gjenoppretting, replikering) kjører på Avamar-serveren. 
 
  • Én årsak til at antall haher som hoppes over, kan være midlertidig høy, skyldes indeksstripdeling. Dette skjer fordi hash-kodene som flyttes til det delte målet, er beskyttet. Indeksstripedeling skjer på systemer som fortsatt vokser eller blir fylt ut med data. 
  • Datasanering kan også mislykkes med MSG_ERR_TRYAGAINLATER når indeksstriper deles opp:  
  • MCS er kanskje ikke nødvendigvis klar over alle avtar-økter som oppstår på Avamar-serveren.

受影响的产品

Avamar

产品

Avamar
文章属性
文章编号: 000169212
文章类型: Solution
上次修改时间: 03 6月 2025
版本:  10
从其他戴尔用户那里查找问题的答案
支持服务
检查您的设备是否在支持服务涵盖的范围内。