Rensa Sophos Firewall Secure Heartbeat-databasen vid supportfall

Detta förfarande är inte ett allmänt trimningstips för Sophos Firewall. Det beskriver ett snävt supportfall: Firewallen har för lite ledigt diskutrymme och Sophos Support har bekräftat att vissa tabeller kring Secure Heartbeat i databasen corporate har blivit ovanligt stora.

I detta fall kan ett riktat underhåll med VACUUM FULL återvinna diskutrymme. Eftersom det innebär direkt åtkomst till firewalls interna PostgreSQL-databas, bör förfarandet endast utföras efter aktuell bekräftelse från Sophos Support och med ett underhållsfönster.

När denna instruktion är relevant

Förfarandet är relevant när det börjar bli ont om diskutrymme på Sophos Firewall och det finns misstankar om att databastabeller kring Secure Heartbeat tar upp ovanligt mycket plats.

Typiska indikationer kan vara:

• Varningar om hög minnesanvändning
• Kraftigt belagda partitioner på firewallen
• Problem med rapporter, loggar eller tjänster på grund av begränsad disk-kapacitet
• En indikation från Sophos Support att Secure Heartbeat-databasen har blivit för stor

Om det är oklart varför disken blir full bör först den allmänna analysen från Kontrollera och hantera lagringsutrymme och rapporter på Sophos Firewall utföras. Detta databasunderhåll är endast meningsfullt när rapporter, loggar, mailkö, karantän, virtuell diskstorlek och andra uppenbara orsaker inte är den egentliga förklaringen eller om Sophos Support uttryckligen nämner databassökvägen.

Förutsättningar

För detta underhåll behöver man:

• Administrativ åtkomst till Sophos Firewall
• Åtkomst till Advanced Shell
• En konkret rekommendation eller bekräftelse från Sophos Support
• Ett underhållsfönster
• En aktuell konfigurationssäkerhetskopia av firewallen
• Säkrade loggar, om fallet senare behöver analyseras vidare
• Tillräckligt med ledigt diskutrymme för att databasunderhållet ska kunna slutföras

Om åtkomst till skalet ännu inte är upprättad, förklarar instruktionen Anslut till Sophos Firewall via SSH hur man upprättar en SSH-anslutning till firewallen. Om ett supportfall förbereds, hjälper även Säkra Sophos Firewall-loggar för extern analys och Öppna ett supportärende hos Sophos.

⚠️ Dessa kommandon ger direkt åtkomst till Sophos Firewalls interna PostgreSQL-databas. Utförandet bör endast ske riktat och efter aktuell bekräftelse från Sophos Support för det specifika supportfallet. VACUUM FULL kan låsa tabeller under körning och beroende på databasens storlek ta en viss tid.

När man inte bör köra kommandona

Kommandona bör inte köras om det bara finns en allmän minnesvarning och orsaken ännu inte har avgränsats. Ofta beror minnesproblem på rapporter, felsökningsloggar, supportfiler, mailskydd, karantän, för liten virtuell disk eller allmän loggförvaring.

Tydliga stopptecken är:

• Sophos Support har inte specifikt bekräftat de två tabellerna: Då skulle databasåtkomsten bara vara gissad och inte fallspecifikt godkänd.
• Ingen aktuell säkerhetskopia eller inget underhållsfönster: Vid ett fel saknas en säker återgång eller påverkan drabbar den löpande driften.
• SSH eller Advanced Shell är instabil: Ett avbrutet databas-kommando försvårar vidare analys.
• HA-roll, serienummer eller berörd nod är oklar: Kommandot kan vara verkningslöst på fel enhet eller förvränga diagnosen.
• Parallellt raderas rapporter, loggar eller supportarkiv: Därefter är det inte längre klart vilken åtgärd som frigjorde diskutrymme.
• Firewallen förlorar redan kritiska tjänster: Då bör det aktuella tillståndet först säkras och utvärderas med Sophos Support.

Förfarandet är också olämpligt som regelbundet underhåll, cronjobb eller förebyggande rensning. Om tabellerna växer snabbt igen efter kort tid är det ett symptom, inte ett normalt driftstillstånd. Då bör supportfallet fortsättas med aktuella loggar, disk-utskrifter och tidsförlopp.

Supportgodkännande och avbrottskriterier

Innan utförandet bör inte bara en säkerhetskopia finnas. Det bör också vara klart vem som har godkänt steget, vilket felbild som behandlas och när förfarandet ska avbrytas.

Meningsfulla minimikrav:

• Supportgodkännande: Ärendenummer, kontaktperson och konkret rekommendation.
• Berörd firewall: Serienummer, modell, firmwareversion, HA-roll.
• Felbild: Minnesvarning, berörd partition, berörda tjänster.
• Starttid: Tidpunkt före första kommandot.
• Före-värden: Utskrift av df -h, df -hkm och system diagnostics show disk.
• Avbrottskriterium: Felmeddelande, ovanligt lång körtid, instabil SSH-session eller nya systemfel.

Om SSH-anslutningen är instabil, firewallen redan förlorar kritiska tjänster eller Sophos Support inte har bekräftat tabellerna specifikt, bör man inte experimentera med databas-kommandon. I sådana fall är aktuella disk-utskrifter, loggar och ett rent supportfall mer värdefulla än ett halvfärdigt underhållsförsök.

Kontrollera diskutrymme före underhåll

Innan databasunderhållet bör man kontrollera hur mycket partitionerna är belagda:

df -h

För en mer detaljerad visning i megabyte kan följande kommando också användas:

df -hkm

Utskriften bör dokumenteras före underhållet så att man senare kan jämföra om diskutrymme har frigjorts. Dessutom är Sophos-specifik diskstatus från Device Console användbar:

system diagnostics show disk

Vid HA-kluster bör båda noderna kontrolleras separat. Lokala databaser, loggar och ledigt utrymme kan skilja sig mellan Primary och Auxiliary.

Innan underhållet bör det också vara klart om andra orsaker samtidigt tar upp utrymme. Detta inkluderar gamla supportarkiv, stora rapportdatabaser, mailkö, karantän, felsökningsloggar eller manuellt lagrade filer. Om dessa punkter inte har kontrollerats är Secure Heartbeat-databasen bara en gissning.

Utföra databasunderhåll

Följande kommandon körs i Advanced Shell. Under körningen bör SSH-sessionen förbli stabil. Firewallen bör inte startas om medan ett kommando körs.

Först rensas tabellen tbleacappcache:

psql -U pgroot -d corporate -c "VACUUM FULL tbleacappcache"

Därefter rensas tabellen tblappstoeps:

psql -U pgroot -d corporate -c "VACUUM FULL tblappstoeps"

Kommandona rapporterar vanligtvis VACUUM efter framgångsrik körning. Om ett kommando ger ett felmeddelande eller hänger ovanligt länge bör man inte fortsätta med fler experimentella databas-kommandon. I detta fall är utskrift, tidpunkt och aktuell diskstatus relevanta för Sophos Support.

Under körningen bör ingen annan person parallellt rensa diskutrymme, rapporter eller databaser. Annars är det senare inte klart vilken åtgärd som hade vilken effekt. För produktiva firewalls är en kort ändringspost med starttid, kommando och resultat meningsfull.

Kontrollera diskutrymme efter underhåll

Efter att kommandona har slutförts bör diskutrymmet kontrolleras igen:

df -h

Om Secure Heartbeat-databasen verkligen var orsaken bör beläggningen av den berörda partitionen minska. Hur stor effekten blir beror på hur stora tabellerna var tidigare och hur mycket data PostgreSQL kunde frigöra.

Efter underhållet bör man dessutom kontrollera:

• Visar system diagnostics show disk återigen rimliga värden?
• Är Log Viewer, rapporter och berörda tjänster återigen användbara?
• Finns det nya fel i de relevanta tjänsterna och loggarna?
• Växer minnesanvändningen återigen kraftigt inom de närmaste timmarna eller dagarna?
• Är de utförda stegen dokumenterade i ärendet eller ändringen?

För efterkontrollen räcker inte alltid en enda framgångsrik df -h-jämförelse. Om partitionen bara avlastas kort och sedan snabbt fylls igen är underhållet inte en avslutning utan en diagnosindikation. Då bör tidsförloppet med färska disk-utskrifter, loggperiod och berörda tjänster återföras till Sophos Support.

Viktiga anmärkningar

• Detta underhåll åtgärdar inte automatiskt orsaken till varför tabellerna har vuxit.
• Om diskutrymmet sedan snabbt ökar igen bör ett Sophos-supportärende öppnas.
• VACUUM FULL är mer intensivt än ett vanligt VACUUM eftersom tabeller skrivs om.
• Kommandona bör inte användas som regelbunden cronjobb eller rutin utan diagnos.
• För produktiva firewalls rekommenderas ett underhållsfönster eftersom vissa funktioner kan reagera fördröjt under databasunderhållet.
• Vid HA-kluster måste det vara klart på vilken nod underhållet behövs.
• Innan ytterligare databas-kommandon bör Sophos Support återigen involveras.

Vanliga fel

Utföra kommandon utan diagnos

En full partition betyder inte automatiskt att Secure Heartbeat är orsaken. Innan databas-kommandon bör disk-utskrifter, loggar och uppenbara minnesförbrukare kontrolleras.

Inte planera in ett underhållsfönster

VACUUM FULL kan beroende på tabellstorlek ta tid och låsa tabeller. På produktiva firewalls bör steget inte köras vid sidan av under en kritisk driftfas.

Inte fortsätta observera efter rensning

Om diskutrymmet bara frigörs kort och sedan återigen växer kraftigt är orsaken inte åtgärdad. Då behövs ytterligare analys med Sophos Support.

Förväxla HA-nod

I HA-miljöer kan den lokala minnessituationen per nod vara olika. Därför bör det före varje kommando vara klart om man arbetar på Primary eller Auxiliary och vilket serienummer som är berört. Ett kommando på fel nod kan vara verkningslöst och försvåra senare analys i onödan.

Fallbedömning

I det specifika supportfallet var orsaken en för stor Secure Heartbeat-databas. De två nämnda VACUUM FULL-kommandona används för att specifikt rensa de berörda tabellerna och frigöra onödigt diskutrymme. Men man bör inte dra slutsatsen att detta är ett allmänt databasunderhåll för Sophos Firewall.

Artikeln behandlar endast detta snäva diskutrymmesfall. Om Security Heartbeat inte fungerar, endpoints inte rapporterar Heartbeat-status, Central-synkronisering misslyckas eller firewall-regler med Heartbeat-villkor inte fungerar som förväntat, är det en annan felbild. Då är Sophos Central-anslutning, endpoint-status, firewall-regel, Log Viewer och relevanta serviceloggar viktigare än ett direkt databas-ingrepp.

För allmänna minnesproblem är den första ingången den systematiska kontrollen av diskutrymme, loggar, rapporter och supportdata. För drift kring Sophos Central passar dessutom Anslut Sophos Firewall med Sophos Central, för loggfiler Sophos Firewall Troubleshooting: Tjänster och loggar.

FAQ