Varför beter sig ett deduplicerat säkerhetskopieringsarkiv som skrivskyddat efter en avbruten rensning?
Ett arkiv kan fungera skrivskyddat efter en avbruten rensning när ett exklusivt lås, lagringsfel, ett oföränderligt backend-system eller ett ofullständigt underhållstillstånd blockerar ändringar.
”Skrivskyddat” kan vara backupklientens säkerhetsåtgärd snarare än filsystemets faktiska monteringsläge. En avbruten rensning kan lämna kvar ett exklusivt lås, ofullständigt pack- eller indexarbete, otillräckligt arbetsutrymme för rensning eller backend-åtgärder som tillåter läsning men avvisar borttagningar. Separat kan operativsystemet montera om arkivets filsystem som skrivskyddat efter I/O- eller konsistensfel. Identifiera vilket lager som avvisar den första skrivningen innan du tar bort lås eller kör rensningen igen.
Fånga den första åtgärden som rapporterar skrivskydd
Kör ett kommando för att lista arkivet, därefter en icke-destruktiv kontroll, och spara det första felet från klienten, backend-systemet och operativsystemets loggar.
Restic-dokumentationen förklarar att prune skriver om arkivdata och behöver exklusiv åtkomst eftersom den tar bort innehåll som inte längre refereras och kan packa om delvis använda filer.
Om listning fungerar men alla åtgärder som skapar ett lås eller skriver metadata misslyckas, skiljer du mellan ett kvarlämnat lås, skrivbehörighet i backend-systemet och objektlagring.
Kontrollera om en exklusiv låsning lämnades kvar av den avbrutna rensningen
Lista arkivets lås via backupverktyget och identifiera värd, process, skapandetid och kommandot som äger varje lås.
Borg dokumenterar att kommandon som ändrar arkivet använder arkivlås för att förhindra samtidiga skrivningar och varnar för att ett aktivt lås kan skada arkivets tillstånd om det bryts.
Ta endast bort ett kvarlämnat lås med det kommandot som stöds, och först efter att du har bevisat att ägaren inte längre körs.
Fastställ om filsystemet monterades om som skrivskyddat
Kontrollera monteringstabellen, kärnloggen, filsystemets hälsa, lagringspoolens tillstånd och nya USB-, SATA-, nätverks- eller styrenhetsfel.
Linux-dokumentationen för ext4 listar errors=remount-ro som en säkerhetspolicy, vilket visar hur ett lagringsfel kan göra arkivet genuint skrivskyddat.
Framtvinga inte en ommontering med skrivåtkomst medan maskinvaru- eller filsystemfel kvarstår. Bevara loggarna och reparera lagringen först.
Granska tillståndet efter en delvis genomförd prune, compact eller indexering
Fastställ vilken fas som avbröts: val av utgångna ögonblicksbilder, borttagning av referenser, ompackning av data, återskapande av ett index eller verkställande av metadata.
Borgs referens för prune noterar att prune och compact är separata steg, så arkiv kan fortfarande vara giltiga även om utrymmesåtervinningen inte är slutförd.
Använd arkivets kontrollkommando innan du kör en ny destruktiv åtgärd. Ta aldrig bort packfiler, index eller segment manuellt.
Kontrollera objektlåsning, oföränderlighet och autentiseringsuppgifter för backend-systemet
För molnarkiv kontrollerar du objektkvarhållning, juridisk spärr, bucket-policy, versionshantering, behörighet att ta bort och rotation av autentiseringsuppgifter.
AWS anger att S3 Object Lock förhindrar borttagning eller överskrivning under en skyddad kvarhållningsperiod, vilket tillåter läsning medan prune misslyckas.
Försvaga inte den oföränderliga kvarhållningen bara för att få prune att lyckas. Använd en arkitektur som stöds av backupverktyget.
Verifiera ledigt utrymme, inoder och arbetsutrymme för prune
Kontrollera filsystemets byte, inoder, kvoter, reserver för ögonblicksbilder, tillfälliga kataloger, objektlagringsgränser och utrymme i den lokala cachen.
GNU Coreutils förklarar att df kan rapportera block och inode-användning, vilket skiljer ett fullt filsystem från ett lås eller behörighetsfel på arkivnivå.
Om filsystemet är fullt lägger du till tillfällig kapacitet eller tar bort verifierade, orelaterade data i stället för att ta bort arkivobjekt.
Återställ med kontroll, upplåsning och en kontrollerad underhållskörning
Skydda de senaste återställningspunkterna som är kända för att fungera, stoppa schemalagda jobb, kör en kontroll som stöds, rensa endast ett bekräftat kvarlämnat lås och genomför en enda loggad underhållskörning.
ZimaSpaces guide om återställning av ett fullt backupmål ger samma grundregel: behandla ett arkiv som en hanterad struktur, inte som fristående filer.
Problemet är löst när listning, kontroll, backup, kvarhållning och en teståterställning fungerar utan tvingad upplåsning eller manuella borttagningar.
Vanliga frågor
Kan jag ta bort låsfilen manuellt?
Inte som första åtgärd. Bekräfta att ingen process äger den och använd backupverktygets upplåsningsåtgärd som stöds.
Bör jag köra prune igen direkt efter en krasch?
Nej. Verifiera arkivets, indexets, filsystemets och backend-systemets hälsa innan du genomför ytterligare en destruktiv underhållskörning.
Betyder skrivskyddat beteende att backupdata är säker?
Inte nödvändigtvis. Saknade packfiler, lagringsfel, oföränderliga objekt eller ofullständiga index kan fortfarande förhindra återställningar.
Rekommenderade produkter
Support och tips
Mer att läsa
Kan Plex dela ett GPU-kort med en annan Docker-container?
Plex och en annan container kan ofta använda samma GPU, men du måste testa drivrutinsstöd, enhetsmappning, belastningen på videoenheten, minne och återställningsbeteende.
Så avgör du om ett Plex-fel kommer från klienten eller servern
Återskapa samma objekt på en annan klient, jämför sessionsvägen och samla sedan in serverbevis först efter att scope har visat var felet faktiskt finns.
Så konfigurerar du Plex-cache och tillfällig lagring för omkodning
Skydda beständigt Plex-tillstånd genom att placera temporära transkodningsfiler på lämplig lokal lagring och verifiera rensning, ledigt utrymme samt omstartsfunktionssätt.
