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
Summary: 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.
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
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".
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".
Cause
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.
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.
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.
Resolution
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.
Additional Information
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.
Affected Products
AvamarProducts
AvamarArticle Properties
Article Number: 000169212
Article Type: Solution
Last Modified: 03 Jun 2025
Version: 10
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.