Avamar v7 och senare – Skräpinsamling rapporterar "skipped-hashes" som inte kan rensas på grund av "Hash Referenced Bit Maps" när data används

Funktionen Hash Referenced Bit Maps är en funktion som introducerades med funktionen Avamar v7.x, vilket gör det möjligt att utföra säkerhetskopieringar under skräpinsamlingsunderhållsaktiviteten. 

Innan den här funktionen kunde skräpinsamling inte köras samtidigt på grund av risken för datakonflikter. 

Under skräpinsamlingen behåller den nya funktionen information i minnet om data som läggs till eller ändras (en "karta över refererade hashuppsättningar"). Skräpinsamling kontrollerar den här informationen för att ta reda på vilka hashfunktioner (och de data som de refererar till) inte ska tas bort.  

Ett krav för den här funktionen är att dessa "kartor" behöver minst 5 minuter av "tyst" tid när det inte finns några säkerhetskopior för att kunna återställas. När återställningen sker kan de data som låsts in skannas under den efterföljande skräpinsamlingscykeln så länge de fortsätter att vara oförändrade.

Du bör fundera på den här tysta tiden när du utformar det dagliga schemat för Säkerhetskopiering och underhåll av Avamar. 
En oförmåga för kartorna att återställa kan förhindra skräpinsamling från att rensa upp förfallna data.
Om den hashreferenserade kartan inte får möjlighet att återställa bearbetas inte data som motsvarar berättigande till borttagning av skräp och kapacitetsanvändningen kan öka. Om kartan inte kan återställas under en längre tidsperiod kan skräpinsamlingsloggen visa allt fler överhoppade hashuppsättningar.

Säkerhetskopior upphörde att gälla, men skräpinsamling återställde inte alla data som kunde tas bort eftersom en del av data användes vid den tidpunkten.

Kontrollera detta genom att köra kommandot nedan:
Kommandot dumpar underhållsloggen för skräpinsamling i sju dagar och tolkar den så att den visas.

• Hur många hash-kommandon som hoppas över
• Hur mycket data som har tagits bort
• Hur många skräpsamlingspass har tagits
• Hur länge har skräpsamling körts för

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"

Analys:

Utdata visar att antalet överhoppade hash-hash-fel ökar med tiden tills hashreferensen för kartan återställs den 16 februari 2014.
Vi kan också se hur mycket data som rensas i hopparningen "megabytes-recovered" efter att hasharna har frigjorts och skräpinsamling kan bearbeta dem för förfallna data.

Omedelbar lösning

1. Kontrollera att kartorna kan återställas och göra det möjligt att köra om skräpinsamlingen.
2. Se till att det inte finns några avtar-sessioner som lägger till data i systemet (säkerhetskopiering eller inkommande replikeringsdata). Använd aktivitetsövervakaren för det grafiska användargränssnittet och kontrollera om sessioner har hängt sig och endast visas med kommandot "avmaint sessions --full".
3. Stoppa alla säkerhetskopierings- och inkommande replikeringssessioner.
4. Vänta minst fem minuter så att Hash Referenced Bit Maps kan återställas tillräckligt med tid.  
5. När GC körs igen kontrollerar du GC-underhållsloggen för att bekräfta att skipped-hashes=0

Om skipped-hashes inte har återställts till noll, arbeta med supporten för att dubbelkontrollera stegen ovan. Om skräpinsamling rapporterar MSG_ERR_TRYAGAINLATER kan supporten kontrollera om det beror på indexstrimlans delningsaktivitet. 
 

Långsiktig lösning

Utforma säkerhetskopierings- och underhållsschemana så att det finns regelbundna "idle" tillgängliga för den hash-refererade bitkartan som ska återställas.

Med andra ord bör säkerhetskopieringsschemana inte köras dygnet runt. Skapa ett schema som ger kort tid när inga säkerhetskopior eller inkommande replikeringsdata skrivs till systemet. 

Kommentarer: 

• Den enda gången som hash-refererade bitkartor kontrollerar om de kan återställas är direkt efter att en avtar-session avslutas. När inga avtar-sessioner pågår återställs kartan endast om:

• En anledning till att det överhoppade hashvärdet kan vara tillfälligt högt beror på att indexstrimlan delas. Det beror på att hasharna som flyttas till det delade målet är skyddade. Indexstrimlor uppstår på system som fortfarande växer eller fylls med data. 
• Skräpinsamling kan också misslyckas med MSG_ERR_TRYAGAINLATER när indexstrimlor delas:  
• MCS kanske inte nödvändigtvis är medvetna om alla avtar-sessioner som inträffar på Avamar-servern.