Een Duplicati-melding dat een .dblock.zip.aes bestand ontbreekt klinkt als beschadiging van de back-up, maar de oorspronkelijke thread laat zien waarom destructief herstel niet de eerste reactie zou moeten zijn. De back-upbestemming bestond op de ZimaOS-host en was zichtbaar via Samba, maar de Duplicati-container kon die HDD via de Docker-volumetoewijzingen niet daadwerkelijk zien.
Nadat de gebruiker de daadwerkelijke HDD op de host in de container had gekoppeld en de nieuwe bestemming aan de containerzijde had geselecteerd, antwoordde de gebruiker dat het erop leek te werken. De bron eindigde dus met een bevestigde oplossing voor Docker-padtoewijzing, niet met een bevestigde oplossing waarbij een defecte back-up werd verwijderd.
De eerste fout leek op een beschadigde Duplicati-repository
Duplicati meldde dat Repair was mislukt omdat in de opslagbestemming van de back-up een specifiek versleuteld dblock bestand. Het bericht bood twee herstelrichtingen: ontbrekende blokbestanden opnieuw opbouwen vanuit lokale brongegevens of back-upitems verwijderen die niet langer konden worden hersteld.
Deze opties zijn echte functies van Duplicati, maar ze zijn pas zinvol nadat is gecontroleerd of de bekeken back-upbestemming de juiste en volledige bestemming is.
De gebruiker maakte een back-up van de ene lokale schijf naar de andere
De beoogde indeling was:
- brongegevens op een lokale SSD;
- back-upbestemming op een afzonderlijke HDD;
- Duplicati was geïnstalleerd vanuit de ZimaOS App Store en draaide daarom in Docker.
De gebruiker selecteerde paden via de mappen kiezer van de applicatie en nam aan dat de container dezelfde opslag op de host kon zien.
Een ZimaOS-hostpad en een Duplicati-containerpad zijn niet hetzelfde
Een Docker-app ziet alleen hostmappen die in de container zijn gekoppeld. ZimaOS kan een schijf via Bestanden of Samba benaderen, terwijl Duplicati niets ziet als die schijf ontbreekt in de volum configuratie van de app.
Daarom kan alleen een verbindingstest misleidend zijn: het bestemmingstype kan geldig zijn, terwijl de inhoud van de beoogde map niet daadwerkelijk zichtbaar is binnen de containernamespace.
De test met het tijdelijke bestand bracht het echte probleem aan het licht
De gebruiker maakte een temp.txt bestand in de bestemmingsmap. Het was zichtbaar via Samba, maar niet in de bestandsbrowser van Duplicati. Dat was sterke aanwijzing dat Duplicati de daadwerkelijke inhoud van de HDD op de host niet zag.
Op dat moment wijzigde de beantwoorder expliciet van koers en adviseerde hij om purge of rebuild nog niet uit te voeren.
De werkende oplossing was om de HDD in de container te koppelen
De beantwoorder instrueerde de gebruiker om de app-instellingen van ZimaOS te openen, de HDD als hostvolume toe te voegen en deze toe te wijzen aan een eenvoudig containerpad zoals /backup, start de container opnieuw op en kies vervolgens een bestemming onder dat containerpad.
De oorspronkelijke poster antwoordde: “Het lijkt nu te werken.”
Dat bevestigde dat het toewijzen van de volumes de praktische oplossing was.
Extra bronschijven hebben hun eigen koppelingen nodig.
De gebruiker vroeg vervolgens of één Duplicati-taak meerdere bronmappen kon bevatten. Het antwoord uit de community was ja, op voorwaarde dat elk bronpad ook binnen de container zichtbaar is.
Als een tweede schijf niet via de Docker-volumes van de app beschikbaar wordt gesteld, verschijnt deze niet correct in Duplicati, hoe geldig het hostpad ook is.
Gebruik de huidige volumekoppeling van ZimaOS-apps in plaats van te gokken met onbewerkte paden
De huidige versie van ZimaOS toont host- en containerpaden in de applicatie-instellingen en documenteert hoe permanente opslag aan Docker-apps wordt gekoppeld.
Gebruik het huidige ZimaOS-model voor Docker-paden bij het toevoegen van back-upbronnen of -bestemmingen.
Wanneer Duplicati Repair geschikt is
In de huidige opdrachtregeldocumentatie van Duplicati staat dat Repair de lokale database kan reconstrueren vanuit externe opslag, of kan proberen ontbrekende externe gegevens opnieuw samen te stellen wanneer de vereiste lokale broninhoud nog beschikbaar is.
De geavanceerde --rebuild-missing-dblock-files de optie probeert specifiek ontbrekende blokbestanden opnieuw te maken op basis van lokale brongegevens, maar Duplicati waarschuwt dat de gegevens mogelijk zijn gewijzigd en dat herstel onvolledig of traag kan zijn.
purge-broken-files is destructief voor de herstelgeschiedenis
De huidige Duplicati-documentatie vermeldt purge-broken-files verwijdert bestanden uit back-upversies die niet langer kunnen worden hersteld, zodat de back-upset kan doorgaan. Gebruik dit alleen wanneer ontbrekende externe gegevens niet kunnen worden hersteld.
Raadpleeg vóór het opschonen de actuele Duplicati-herstelopdrachten en de gevolgen ervan. Een proefrun of een lijst met beschadigde bestanden is veiliger dan blindelings back-upgeschiedenis verwijderen.
De foutmelding was echt, maar de onderliggende bestemming was verkeerd
Duplicati meldde correct dat de repositoryweergave waartoe het toegang had, de verwachte bestanden niet bevatte. Het misleidende deel was de aanname dat die repositoryweergave de echte harde schijf vertegenwoordigde. De Docker-padkoppeling had de toepassing naar een onvolledige of andere bestandssysteemweergave geleid.
Duplicati dblock-FAQ
Was bewezen dat de bronback-uprepository beschadigd was?
Nee. Het probleem met de bron werd opgelost nadat de Docker-volumekoppeling was hersteld.
Moet purge-broken-files de eerste stap zijn?
Nee. Controleer vóór een destructieve reparatie of de juiste volledige bestemming is gekoppeld en zichtbaar is.
Kan één Duplicati-taak een back-up maken van meerdere ZimaOS-schijven?
Ja, maar elke bronschijf moet in de Duplicati-container worden gekoppeld.
