Ett Duplicati-meddelande som säger att en .dblock.zip.aes fil saknas låter som korruption i säkerhetskopian, men källtråden visar varför destruktiv reparation inte bör vara den första åtgärden. Säkerhetskopieringsmålet fanns på ZimaOS-värden och syntes via Samba, men Duplicatis container kunde faktiskt inte se hårddisken genom sina Docker-volymmappningar.
När användaren hade mappat den riktiga hårddisken på värden till containern och valt det nya målet på containersidan svarade hen att det verkade fungera. Källtråden slutade därför med en bekräftad lösning genom Docker-sökvägsmappning, inte med en bekräftad rensning av en trasig säkerhetskopia.
Det första felet såg ut som ett skadat Duplicati-repositorium
Duplicati rapporterade att Repair hade misslyckats eftersom en specifik krypterad säkerhetskopieringslagrings- dblock fil. Meddelandet föreslog två återställningsvägar: att återskapa saknade blockfiler från lokala källdata eller rensa säkerhetskopieringsposter som inte längre kunde återställas.
De alternativen är verkliga Duplicati-funktioner, men de är meningsfulla först efter att man har verifierat att säkerhetskopieringsmålet som granskas är rätt och komplett.
Användaren säkerhetskopierade en lokal disk till en annan
Den avsedda layouten var:
- källdata på en lokal SSD;
- säkerhetskopieringsmål på en separat hårddisk;
- Duplicati installerades från ZimaOS App Store och kördes därför i Docker.
Användaren valde sökvägar via appens mappväljare och antog att det innebar att containern kunde se samma lagring på värden.
En värdsökväg i ZimaOS och en containersökväg i Duplicati är inte samma sak
En Docker-app ser bara värdmappar som har monterats i containern. ZimaOS kan komma åt en disk via Filer eller Samba, medan Duplicati inte ser någonting om disken saknas i appens volymkonfiguration.
Därför kan ett anslutningstest vara missvisande: måltypen kan vara giltig, medan innehållet i den avsedda mappen faktiskt inte är synligt i containerns namnrymd.
Testet med en temporär fil avslöjade det verkliga problemet
Användaren skapade en temp.txt fil i målmappen. Den syntes via Samba men inte i Duplicatis filbläddrare. Det var ett starkt tecken på att Duplicati inte såg det faktiska innehållet på värdhårddisken.
Då ändrade communitymedlemmen uttryckligen inriktning och rådde användaren att inte köra rensning eller återskapning ännu.
Lösningen var att mappa hårddisken till containern
Den som svarade instruerade användaren att öppna appinställningarna i ZimaOS, lägga till hårddisken som en värdvolym och mappa den till en enkel containersökväg, till exempel /backup, starta om containern och välj sedan en målplats under den containersökvägen.
Den ursprungliga skribenten svarade: ”Det verkar fungera nu.”
Det bekräftade volymmappning som den praktiska lösningen.
Ytterligare källenheter behöver egna mappningar
Användaren frågade sedan om ett Duplicati-jobb kunde innehålla flera källmappar. Gemenskapens svar var ja, förutsatt att varje källsökväg också är synlig inuti containern.
Om en andra disk inte exponeras genom appens Docker-volymer visas den inte korrekt i Duplicati, oavsett hur giltig värdsökvägen är.
Använd aktuell volymmappning för ZimaOS-appar i stället för att gissa råsökvägar
Den aktuella versionen av ZimaOS visar värd- och containersökvägar i programinställningarna och dokumenterar hur beständig lagring mappas till Docker-appar.
Använd den aktuella Docker-sökvägsmodellen i ZimaOS när du lägger till säkerhetskopieringskällor eller -mål.
När Duplicati Repair är lämpligt
Duplicatis aktuella kommandoradsdokumentation säger att Repair kan återskapa den lokala databasen från fjärrlagringen eller försöka rekonstruera saknade fjärrdata när det nödvändiga lokala källinnehållet fortfarande finns tillgängligt.
Det avancerade --rebuild-missing-dblock-files alternativet försöker specifikt återskapa saknade blockfiler från lokala källdata, men Duplicati varnar för att data kan ha ändrats och att återställningen kan vara ofullständig eller långsam.
purge-broken-files är destruktivt för återställningshistoriken
Den aktuella Duplicati-dokumentationen säger purge-broken-files tar bort filer från säkerhetskopieringsversioner som inte längre kan återställas, så att säkerhetskopieringsuppsättningen kan fortsätta. Det bör endast användas när saknade fjärrdata inte kan återställas.
Innan du rensar, granska de aktuella Duplicati-kommandona för återställning och deras konsekvenser. En torrkörning eller en lista över skadade filer är säkrare än att radera säkerhetskopieringshistoriken på måfå.
Felmeddelandet var korrekt, men det underliggande målet var fel
Duplicati rapporterade korrekt att arkivvyn som programmet kunde se saknade förväntade filer. Det missvisande var antagandet att arkivvyn motsvarade den verkliga hårddisken. Docker-sökvägsmappningen hade pekat programmet mot en ofullständig eller annan filsystemsvy.
Vanliga frågor om Duplicati dblock
Visade det sig att källans säkerhetskopieringsarkiv var skadat?
Nej. Källproblemet löstes efter att Docker-volymmappningen korrigerades.
Bör purge-broken-files vara det första steget?
Nej. Kontrollera att rätt fullständiga mål är monterat och synligt innan någon destruktiv reparation utförs.
Kan ett Duplicati-jobb säkerhetskopiera flera ZimaOS-enheter?
Ja, men varje källenhet måste mappas in i Duplicati-containern.
