Varför kan en integritetskontroll av ett arkiv godkännas trots att en fil fortfarande inte kan återställas?
En arkivkontroll kan godkännas trots att en fil inte kan återställas, om kontrollen validerar metadata eller ett urval av data i stället för just den återställningsvägen.
Säkerhetskopieringsverifiering är inte en enda universell åtgärd. Vissa kontroller bekräftar arkivstruktur, index, manifest och refererade chunkar utan att läsa varje lagrad byte. Andra samplar data, hoppar över filer som aldrig fångades upp eller säger inget om målfilsystemets namn, behörigheter, ACL:er, etiketter, ledigt utrymme och programlås. Betrakta den misslyckade filen som en väg från val av ögonblicksbild via lagrade objekt till skapandet på målet.
Identifiera exakt vad den godkända kontrollen verifierade
Spara kontrollkommandot, alternativen, säkerhetskopieringsverktygets version, arkivets backend, ögonblicksbildens ID och den slutliga loggen. Fastställ om kontrollen granskade arkivstruktur, arkivmetadata, refererade chunkar, lagrade data eller en faktisk extrahering.
Borg anger att dess vanliga arkivkontroll läser metadata men inte fildata som standard, om inte dataverifiering uttryckligen begärs.
Ett grönt resultat kan därför bevisa att referenserna är internt konsekventa, samtidigt som vissa nyttolastchunkar förblir olästa. Kalla inte arkivet fullt återställningsbart förrän representativa filer har extraherats.
Fastställ om filens lagrade data faktiskt lästes
Leta upp filen i den avsedda ögonblicksbilden och identifiera de packfiler, chunkar eller objekt som krävs för att återskapa den. Jämför den misslyckade återställningen med arkivkontrollens dataläsningsomfattning.
Restic dokumenterar kontrollerna read-data och read-data-subset, vilket visar att en rutinmässig strukturkontroll och en fullständig läsning av nyttolasten är olika verifieringsnivåer.
Om bara en delmängd lästes kan den misslyckade filen vara beroende av en okontrollerad packfil. Kör en riktad eller fullständig datakontroll som stöds innan du försöker reparera.
Bekräfta att filen ingick i den ögonblicksbilden
Lista den exakta relativa sökvägen i den valda ögonblicksbilden. Kontrollera filter, undantag, varningar om oläsbara källor, regler för symboliska länkar, monteringsgränser och om återställningsgränssnittet valde en annan version.
Kopia varnar för att ignoreringsprinciper utelämnar matchande sökvägar, så arkivets konsekvens kan godkännas även när den önskade filen aldrig fångades upp.
En platshållarsökväg eller en post för den överordnade mappen bevisar inte att filens nyttolast finns. Jämför ögonblicksbildens innehållsförteckning, storlek, hash och tidsstämpel med den förväntade källposten.
Kontrollera begränsningar för filnamn och sökvägar på målet
Återställ samma fil till en kort, tom lokal sökväg med ett enkelt namn. Jämför ogiltiga tecken, reserverade namn, krockar mellan versaler och gemener, avslutande blanksteg, sökvägslängd och Unicode-normalisering.
Microsofts vägledning för filnamn dokumenterar begränsningar för Windows-filnamn och sökvägar som kan avvisa en enskild återställd sökväg medan själva arkivet fortfarande är felfritt.
Om filen återställs till en tillfällig, kort sökväg är det lagrade innehållet tillgängligt. Korrigera målets struktur eller namnöversättning i stället för att reparera arkivet.
Verifiera återställning av ACL:er, utökade attribut och ägarskap
Upprepa återställningen med metadata-bevarande inaktiverat, men endast på ett temporärt mål, och jämför den med en vanlig metadata-medveten återställning. Dokumentera det första attributet som misslyckas.
GNU tar dokumenterar separat återställning av ACL:er och utökade attribut, vilket visar varför fildata kan vara läsbar samtidigt som tillämpningen av metadata misslyckas.
Acceptera inte en återställning utan metadata som produktionslösning när program är beroende av ACL:er, ägarskap, glesa områden eller xattr. Använd den endast för att identifiera det felande lagret.
Kontrollera säkerhetsetiketter och policy på målet
Inspektera SELinux-etiketter, antivirus eller slutpunktsskydd, skydd mot utpressningstrojaner, oföränderliga flaggor, delningsbehörigheter och programlås på återställningsmålet.
Red Hat dokumenterar återställning av standardiserade säkerhetskontexter när filer anländer med saknade eller olämpliga etiketter.
En fil som extraheras men inte kan öppnas kan bero på en policy på målet snarare än på ett fel i arkivet. Testa med samma användare och det program som behöver den återställda filen.
Gör en isolerad återställning innan du reparerar något
Återställ den misslyckade filen, dess metadata för den överordnade mappen och flera närliggande filer till en tom datamängd eller tillfällig katalog. Spara hashvärden, loggar och arkivets tillstånd innan du kör reparationskommandon.
ZimaSpaces guide om verifiering av kontrollsummor och metadata beskriver den närliggande skillnaden mellan integriteten hos lagrat innehåll och användbar återställning i program.
Problemet är löst när den valda filen återställs från den avsedda ögonblicksbilden, överensstämmer med det förväntade innehållet, får nödvändiga metadata och kan öppnas via produktionsprogrammets väg.
Vanliga frågor
Bevisar en godkänd arkivkontroll att alla filer kan återställas?
Nej. Det beror på om kontrollen läste alla lagrade data och om målet kan återskapa varje sökväg och dess metadata.
Bör jag köra en reparation direkt efter ett enda återställningsfel?
Nej. Testa först ett annat mål, bekräfta att filen finns i ögonblicksbilden och kör en datakontroll som stöds. En reparation kan ta bort skadade metadata eller objekt.
Är en lyckad teståterställning starkare än en verifieringsrapport?
Ja, för den testade återställningsvägen. Den bevisar val, dekryptering, läsning av nyttolasten, skapande på målet och hantering av metadata för just det provet.
Rekommenderade produkter
Support och tips
Mer att läsa
Varför återskapar en återställning av en Docker-volym filinnehållet men tar bort utökade attribut?
En felsökning av volymåterställning som omfattar inventering av xattr, alternativ för tar och Rsync, namnrymder, stöd för måldestinationen, behörigheter, etiketter, appmetadata och tester.
Varför behåller en körande container sin gamla minnesgräns efter att Compose-filen har ändrats?
En minnesgränsdiagnos som omfattar aktiva cgroups, omstart kontra återskapande, Compose-fält, hårda och mjuka gränser, överordnade scope, växlingsutrymme och körningsheapar.
Varför ogiltigförklarar en omstart av en omvänd proxy varje session för en självhostad app?
En sessionsförlustdiagnos som omfattar omstartens omfattning, cookie-ägarskap, rotation av hemligheter, cachebaserade sessioner, sticky routing, autentiseringsgatewayer och återställning.
