Kontrollera Sophos Firewall SSD-hälsa med SMART

Ett SMART-värde kan vara användbart vid hårdvarudiagnostik. På fysiska XGS Appliances där den interna SSD-enheten är monterad som /dev/sda ger en läsande smartctl-fråga posten för endurance. För SFOS 22.0 dokumenterar Sophos dock inget allmänt administratörskommando, ingen fast enhetssökväg och inget modellövergripande gränsvärde för slitage. Kontrollera därför först appliance, nod och enhetssökväg och behandla värdet som en diagnostisk indikation, inte som enda underlag för beslut om byte.

Den säkra vägen börjar i WebAdmin: kontrollera beläggning och systembeteende, skapa en Consolidated troubleshooting report (CTR) och involvera Sophos Support vid misstänkt hårdvarufel. Frågan som dokumenteras nedan läser befintliga SMART-data och startar inget självtest. Andra enhetssökvägar, SMART-tester eller reparationskommandon hör endast hemma i ett konkret supportärende.

⚠️ Viktigt: Advanced Shell ger direkt åtkomst till systemet. Prova inte olika enhetssökvägar, starta inte SMART-självtester, ändra inte partitioner, radera inte filer manuellt och byt inte SSD på egen hand. Även system fsck-on-nextboot i Device Console får bara användas på rekommendation av Sophos Support: kommandot hjälper vid monteringsfel för /sig, /conf eller /var, tvingar fram en filsystemskontroll av alla partitioner vid nästa omstart och kan skada filsystemet om hårdvaran eller SSD-enheten inte är frisk. on, off och show aktiverar, inaktiverar respektive visar statusen; standardvärdet är off. I Failsafe Mode kan SFOS aktivera kontrollen automatiskt, till exempel om konfigurations-, rapport- eller signaturdatabasen inte startar, om en migrering inte kan tillämpas eller om distributionsläget saknas. Den säkra proceduren finns i Diagnostisera Sophos Firewall Failsafe Mode.

Säker diagnostik

1. Gå i WebAdmin till Diagnostics > System graphs, välj Disk usage som graf och välj en period som omfattar när störningen började.
2. Kontrollera om rapporter, loggar, karantän, WebAdmin eller tjänster samtidigt uppvisar problem. Disk usage visar upptaget lagringsutrymme, inte SSD-slitage eller SMART-hälsa.
3. Kontrollera dessutom brandväggens meddelanden och aviseringar före en firmwareuppgradering. SFOS 22.0 kan för vissa XGS Appliance-modeller meddela att en SSD-firmwareuppdatering krävs; i HA kontrolleras varje nod separat mot uppgraderingskraven.
4. Under Diagnostics > Tools vid Consolidated troubleshooting report väljer du System snapshot och All log files, anger orsaken till diagnostiken och väljer Generate och därefter Download. Debug-läge behövs inte för System Snapshot.
5. Vid I/O-fel, filsystemsfel, startfel eller återkommande databasfel öppnar du ett Sophos Support-ärende och bifogar CTR, tidpunkt, symtom och enhetsdata. Support avgör om ytterligare Shell-/SMART-diagnostik och en eventuell RMA behövs.

Vid ett rent lagringskapacitetsproblem hjälper Kontrollera lagringsutrymme och hantera rapporter på Sophos Firewall. Central Firewall Reporting kan minska beroendet av lokala rapportdata. En Sophos Firewall Health Check bedömer däremot konfigurationsrisker och ersätter inte hårdvarudiagnostik.

Vad de synliga signalerna betyder

Disk usage visar kapacitet, inte slitage

Under Diagnostics > System graphs > Disk usage visar X-axeln minuter, timmar, dagar eller månader beroende på vald period, medan Y-axeln visar beläggningen i procent. Förklaringen skiljer mellan signaturer (orange), konfigurationsfiler (lila), rapporter (grönt) och tillfälligt lagringsutrymme (blått). Ett högt värde kan påverka rapporter och tjänster men bevisar inte att SSD-enheten är defekt. Omvänt säger ledigt utrymme inget om hårdvarufel eller återstående skrivlivslängd. Grafen innehåller varken SMART-attribut eller slitagegränser.

Ett meddelande om SSD-firmware är inget SMART-resultat

För vissa XGS Appliance-modeller kan en SSD-firmwareuppdatering som förbättrar tillförlitligheten vara obligatorisk före SFOS 22.0 eller senare. Om en åtgärd krävs visas en avisering. Det är ett modellrelaterat uppgraderingskrav, inte ett uppmätt endurance-värde eller automatiskt ett fel.

Kontrollera därför aktuell backup, tillgängligt lagringsutrymme, stödd uppgraderingsväg, Release Notes och ett underhållsfönster före uppgraderingen. I HA måste båda noderna vara nåbara, friska, synkroniserade och var för sig uppfylla uppgraderingskraven; om en av dem inte gör det kan uppgraderingen blockeras. Starta uppgraderingen endast från Primary Device.

SMART-utdata är modellberoende diagnostikdata

SMART-attribut, enhetsnamn och deras innebörd kan skilja sig mellan SSD, styrenhet, appliance och firmware.

Läsa endurance på en XGS Appliance med /dev/sda

Logga in på brandväggen via SSH, öppna Advanced Shell och bekräfta att du arbetar på rätt appliance eller rätt HA-nod. Avanet har kört frågan på en XGS 3100 med SFOS 21.5.1 MR-1 Build 261. Om den interna SSD-enheten där är monterad som /dev/sda läser följande kommando fullständiga SMART-data och visar endast rader som innehåller Endurance:

smartctl -x /dev/sda | grep Endurance

I Avanets exempel rapporterar SSD-enheten råvärdet 1 för Percentage Used Endurance Indicator. På den här enheten innebär ett lågt värde att en liten del av skrivlivslängden har förbrukats. Överför dock inte skalan till andra SSD-enheter utan kontroll: attributnamn, normalisering och råvärde kan vara definierade på andra sätt beroende på tillverkare och modell. Ett värde på 80 är därför inget universellt Sophos-gränsvärde för RMA. Dokumentera utvecklingen över tid och ta med symtom, I/O-fel och den modellspecifika bedömningen.

Kommandot och den modellberoende tolkningen har redan diskuterats offentligt i praktiken eftersom de inte dokumenteras i hjälpen för Sophos Firewall: Kontrollera livslängden på en Sophos XGS SSD på Administrator.de. Inlägget rekommenderar ett snabbt byte vid ett värde över 80; Avanet väljer uttryckligen att inte använda detta community-värde som ett universellt Sophos-gränsvärde för RMA. Skärmbilden ovan kommer från en Avanet-appliance och inte från inlägget.

Ett SSD-fel kan inträffa utan föregående varning från SFOS. HA skyddar trafiken men inte automatiskt alla lokalt lagrade data: loggar, Mail Queue och karantän kan påverkas på den felande noden; Mail Queue och karantän synkroniseras inte mellan HA-noderna. Centrala rapporter, aktuella backuper och en dokumenterad återstartsprocedur minskar risken men ersätter inte övervakning av SSD-enheten.

Om ingen rad visas saknas antingen ett passande Endurance-attribut, så är den bekräftade enhetssökvägen fel för denna appliance eller så kan smartctl inte läsa SSD-enheten på motsvarande sätt via den aktuella styrenheten. Tom utdata bevisar varken att enheten är frisk eller defekt. Prova inte andra enhetsnamn eller ett SMART-självtest på eget initiativ.

Följande gäller för den fortsatta bedömningen:

• Använd bara /dev/sda om sökvägen har bekräftats för den aktuella appliance-modellen; gissa inte NVMe- eller RAID-sökvägar.
• Härled inget allmänt gränsvärde från attributnamn som Endurance, Percentage Used eller Wear.
• Tolka inte ett enskilt värde eller skillnaden mellan två HA-noder som ett beslut om byte.
• Bedöm inte utebliven SMART-utdata som vare sig frisk eller defekt enhet.

I HA körs det bekräftade kommandot separat på båda noderna eftersom varje nod har en egen SSD-enhet. Spara utdata, datum, tidszon, SFOS-version och nodroll tillsammans. Om det finns symtom, höga eller snabbt stigande värden eller oklara attribut ska även ärendenummer och Sophos Supports bedömning dokumenteras.

Dokumentera och validera resultatet

En kort och konsekvent historik är mer användbar än ett enskilt värde:

• Datum och tid med tidszon: exempelvis 2026-09-05 10:30 CEST
• Appliance och plats: exempelvis XGS 2100 – HQ
• Serienummer och, i HA, rollen: Primary eller Auxiliary
• SFOS-version och build
• Symtom: lagringsvarning, I/O-fel, startfel, rapport- eller databasproblem
• Period för Disk usage och anmärkningsvärd förändring
• CTR-fil och supportärendets nummer
• Praktisk SMART-fråga: bekräftad enhetssökväg, exakt kommando och oförändrad utdata

Diagnosen är inte slutförd enbart för att grafen ser normal ut eller för att ett enskilt SMART-värde har lästs. Validera att lagringsbeläggningen och berörda funktioner förblir stabila efter den säkra åtgärden och om felen återkommer under den överenskomna observationsperioden. För virtuella brandväggar bör enhetsstatus, datastore, I/O-latens och fel i första hand övervakas i hypervisorn och lagringsplattformen.

Vid misstanke om temperatur- eller fläktproblem passar Kontrollera temperatur och fläkt via SSH; status och historik för sensorer som stöds kan kompletteras med SNMP Hardware Monitoring. Ingen av dessa kontroller ersätter SSD-diagnostik från Sophos.

Om appliance-enheten är instabil eller inte kan nås

Kör inga omstarts-, filsystems- eller reparationskommandon på måfå. Dokumentera den senaste tidpunkten då systemet fungerade, ändringar före störningen, LED-status och åtkomst via HTTPS, SSH och seriekonsol. Vid ett fullständigt strömavbrott testar du först ett annat eluttag och en annan strömkabel; på appliances med dubbla nätaggregat kontrollerar du den andra ingången och, på modeller som är avsedda för det, ett annat hot-swap-nätaggregat. Ett foto eller en video av LED- och startbeteendet påskyndar RMA-bedömningen.

För en appliance som inte startar kontrollerar du HTTPS och SSH via LAN och WAN samt seriekonsolen direkt via DB-9, en Serial-to-USB-adapter eller Micro-USB-konsolporten på nyare XGS Appliance-modeller. Kontrollera i Device Manager på administratörens dator om det finns drivrutins- eller anslutningsfel. Ställ in 38400 baud, kontrollera statusen med flera tidsintervall och dokumentera synliga fel med skärmbilder. Om konsolen förblir tyst gör du en motkontroll med en annan kabel eller dator. Sophos avgör först efter egen kontroll om en enhet ska klassas som DOA. Den fullständiga interna proceduren finns i Sophos hårdvarufel: förbered RMA och utbyte.

Om appliance-enheten fortfarande kan nås reproducerar du felet omedelbart före datainsamlingen och noterar den exakta tidpunkten med tidszon. Under Diagnostics > Tools > Consolidated troubleshooting report väljer du System snapshot och All log files, anger orsaken och klickar på Generate och därefter Download. Ladda upp den krypterade rapporten i supportärendet. Vissa CTR-loggar innehåller endast det antal rader som konfigurerats via CLI; vid en äldre händelse bör därför berörda Troubleshooting logs också sparas separat. Debug-läget är avstängt som standard och behövs inte för System Snapshot; debug-loggar ökar lagringsbehovet och ska stängas av igen efter en riktad inspelning. I HA synkroniseras inte loggar och rapporter; de samlas in per nod och märks tydligt. Den fullständiga proceduren finns i Spara Sophos Firewall-loggar för support och analys.

Om Sophos begär fjärråtkomst för diagnostiken kan du skapa ett tidsbegränsat Access ID under Diagnostics > Support access. Brandväggen upprättar då en säker utgående styranslutning via TCP 22 till *.apu.sophos.com; en router framför brandväggen måste tillåta detta. Aktivera Support access, bekräfta med OK, välj tidsperiod, klicka på Apply och sedan på OK igen och kopiera det unika ID:t under Access status. Dela Access ID endast i supportärendet. Sophos får med detta åtkomst till WebAdmin och Shell utan administratörslösenord; inaktiva sessioner avslutas efter 15 minuter. Åtkomsten kan stängas av när som helst och inaktiveras efter ärendet. Den interna detaljproceduren finns i Ge Avanet Support Access till Sophos Firewall.

Förbered support och RMA

Ha följande redo före eskaleringen:

• exakt felbeskrivning, starttid, frekvens och påverkan;
• modell, revision, serienummer, SFOS-version och build;
• HA-status och berörd nod;
• historik för Disk usage, relevanta felmeddelanden och CTR;
• aktuell nedladdad konfigurationsbackup;
• håll lösenordet för backupkryptering och tillhörande Secure Storage Master Key säkert tillgängliga, men dela dem endast via den säkra metod som Sophos anvisar;
• licens- och supportstatus.

Ett SMART-värde utlöser inte automatiskt en RMA. Enligt Sophos omfattar RMA-processen först felidentifiering och enhetsdata och därefter supportärende och validering; Sophos kan begära ytterligare diagnostik. Modell, revision, firmwareversion, serienummer och HA-tillhörighet ska anges i RMA-formuläret.

I HA måste det dessutom fastställas vilken nod som ska ersättas. Återställningsproceduren som beskrivs här gäller endast Active-Passive, inte Active-Active, och medför driftavbrott. Dokumentera i förväg modell, revision, ursprunglig Primary samt firmwareversion och build för båda enheterna med system diagnostics show version-info.

• Förbered ersättningsenheten: Om samma firmware-build inte är tillgänglig begär du den från Sophos Support. Anslut en DHCP-klient till Port 1 och öppna https://172.16.16.16:4444. Konfigurera Port 2 via Setup Assistant endast för WAN och internetåtkomst; skapa inga ytterligare gränssnitt till att börja med. Efter reimage eller uppdatering verifierar du åter build-numret med system diagnostics show version-info.
• Ersätta Auxiliary: Den friska Primary-enheten körs tillfälligt ensam. Uppgradera ersättningsenheten till samma firmwareversion och build, gör claim i Central och överför licensen från den defekta Auxiliary-enheten. Inaktivera HA på den friska Primary-enheten, kontrollera med service -S | grep msync att statusen är UNTOUCHED eller STOPPED, koppla om kablarna och bygg upp Active-Passive HA igen med den friska enheten som Primary.
• Ersätta Primary: Avregistrera den friska Auxiliary-enheten från Central och bekräfta under My Products > Firewall Management > Firewalls att den inte längre visas. Spara en aktuell backup från den. Uppgradera ersättningsenheten till samma firmwareversion och build, gör claim, överför licensen, återställ backupen och låt den efter kabelbytet ta över trafiken som standalone. Återställ därefter den tidigare Auxiliary-enheten till fabriksinställningarna, gör claim igen och konfigurera om Active-Passive HA med ersättningsenheten som Primary.

Utbytet tillhandahåller hårdvara men garanterar inte att systemet är driftklart. Dokumentera licensöverföring, backupkompatibilitet, Central-tilldelning, kabeldragning och funktionstest före underhållsfönstret. Grunderna för rollerna finns i Sophos Firewall HA-kluster: Active-Passive, Active-Active och Auxiliary Appliance.

Garanti- och supportgrunderna sammanfattas i Hur länge får jag garanti på Sophos-hårdvara?. Om Sophos kräver en reimage följer du den separata proceduren Installera om Sophos Firewall OS: reimage med USB-minne.

Slutkontroll

• Disk usage och period kontrollerade utan att kapacitet tolkades som SSD-hälsa.
• Symtom, tidsförlopp, modell, serienummer, SFOS-version och HA-nod dokumenterade.
• Aktuell backup sparad utanför appliance-enheten och återställningshemligheter tillgängliga.
• CTR med System snapshot och All log files skapad och säkert sparad.
• Inga gissade enhetssökvägar och inga SMART-självtester, fsck-, raderings- eller reparationskommandon körda utan godkännande.
• Supportärende öppnat vid misstänkt hårdvarufel; ytterligare diagnostik endast enligt konkret supportinstruktion.
• RMA eller hårdvarubyte planerat först efter validering av Sophos.

FAQ