Komunikat Duplicati informujący, że brakuje pliku .dblock.zip.aes Brak pliku .dblock brzmi jak uszkodzenie kopii zapasowej, ale wątek źródłowy pokazuje, dlaczego destrukcyjna naprawa nie powinna być pierwszą reakcją. Miejsce docelowe kopii zapasowej istniało na hoście ZimaOS i było widoczne przez Sambę, jednak kontener Duplicati nie mógł faktycznie zobaczyć tego dysku HDD za pośrednictwem mapowań woluminów Dockera.
Gdy użytkownik zmapował rzeczywisty dysk HDD hosta w kontenerze i wybrał nowe miejsce docelowe po stronie kontenera, odpowiedział, że wygląda na to, iż wszystko działa. Źródłem problemu okazała się zatem konfiguracja mapowania ścieżki Dockera, a nie potwierdzone usunięcie uszkodzonej kopii zapasowej.
Początkowy błąd wyglądał jak uszkodzone repozytorium Duplicati
Duplicati poinformował, że naprawa nie powiodła się, ponieważ w miejscu przechowywania kopii zapasowej brakowało określonego zaszyfrowanego pliku dblock plik. Komunikat oferował dwa sposoby odzyskania danych: odbudowanie brakujących plików bloków z lokalnych danych źródłowych lub usunięcie wpisów kopii zapasowej, których nie można już było przywrócić.
Te opcje są rzeczywistymi funkcjami Duplicati, ale mają sens dopiero po zweryfikowaniu, że sprawdzane miejsce docelowe kopii zapasowej jest właściwe i kompletne.
Użytkownik tworzył kopię zapasową jednego lokalnego dysku na drugim
Zamierzony układ był następujący:
- dane źródłowe na lokalnym dysku SSD;
- miejsce docelowe kopii zapasowej na osobnym dysku HDD;
- Duplicati zainstalowano ze sklepu aplikacji ZimaOS, więc działał w Dockerze.
Użytkownik wybierał ścieżki za pomocą selektora folderów aplikacji i zakładał, że kontener będzie widział tę samą pamięć hosta.
Ścieżka hosta w ZimaOS i ścieżka kontenera w Duplicati to nie to samo
Aplikacja Docker widzi tylko te foldery hosta, które zostały zamontowane w kontenerze. ZimaOS może uzyskiwać dostęp do dysku przez Pliki lub Sambę, podczas gdy Duplicati nic nie widzi, jeśli tego dysku brakuje w konfiguracji woluminów aplikacji.
Dlatego sam test połączenia może wprowadzać w błąd: typ miejsca docelowego może być prawidłowy, podczas gdy zawartość zamierzonego folderu nie jest faktycznie widoczna w przestrzeni nazw kontenera.
Test z plikiem tymczasowym ujawnił prawdziwy problem
Użytkownik utworzył temp.txt plik w folderze docelowym. Był widoczny przez Sambę, ale nie w przeglądarce plików Duplicati. Był to mocny dowód na to, że Duplicati nie widział rzeczywistej zawartości dysku HDD hosta.
W tym momencie osoba odpowiadająca ze społeczności wyraźnie zmieniła podejście i zaleciła, aby na razie nie uruchamiać czyszczenia ani odbudowy.
Działające rozwiązanie polegało na zmapowaniu dysku HDD do kontenera
Osoba odpowiadająca zaleciła użytkownikowi otwarcie ustawień aplikacji ZimaOS, dodanie dysku HDD jako woluminu hosta i zmapowanie go do prostej ścieżki kontenera, takiej jak /backup, uruchom ponownie kontener, a następnie wybierz miejsce docelowe w tej ścieżce kontenera.
Autor pierwotnego wpisu odpowiedział: „Wygląda na to, że teraz działa.”
To potwierdziło, że mapowanie woluminu było praktycznym rozwiązaniem.
Dodatkowe dyski źródłowe wymagają własnych mapowań
Użytkownik zapytał następnie, czy jedno zadanie Duplicati może zawierać wiele folderów źródłowych. Odpowiedź społeczności brzmiała: tak, pod warunkiem że każda ścieżka źródłowa jest również widoczna wewnątrz kontenera.
Jeśli drugi dysk nie jest udostępniony za pośrednictwem woluminów Docker aplikacji, nie pojawi się prawidłowo w Duplicati, niezależnie od tego, jak poprawna jest ścieżka hosta.
Korzystaj z bieżącego mapowania woluminów aplikacji ZimaOS zamiast zgadywać surowe ścieżki
Bieżący ZimaOS udostępnia ścieżki hosta i kontenera w ustawieniach aplikacji oraz opisuje sposób mapowania pamięci trwałej do aplikacji Docker.
Podczas dodawania źródeł lub miejsc docelowych kopii zapasowych używaj aktualnego modelu ścieżek Docker w ZimaOS.
Kiedy naprawa Duplicati jest właściwym rozwiązaniem
Aktualna dokumentacja wiersza poleceń Duplicati mówi, że naprawa może odbudować lokalną bazę danych z pamięci zdalnej lub spróbować odtworzyć brakujące dane zdalne, jeśli wymagane lokalne dane źródłowe są nadal dostępne.
Zaawansowana opcja --rebuild-missing-dblock-files Ta opcja próbuje odtworzyć brakujące pliki bloków na podstawie lokalnych danych źródłowych, ale Duplicati ostrzega, że dane mogły ulec zmianie, a odzyskiwanie może być niepełne lub powolne.
purge-broken-files niszczy historię przywracania
Aktualna dokumentacja Duplicati mówi, że purge-broken-files usuwa z wersji kopii zapasowych pliki, których nie można już przywrócić, aby zestaw kopii zapasowych mógł działać dalej. Należy go używać tylko wtedy, gdy brakujących danych zdalnych nie można odzyskać.
Przed usunięciem danych sprawdź bieżące polecenia odzyskiwania Duplicati i ich konsekwencje. Próba bez wykonywania zmian lub wyświetlenie listy uszkodzonych plików jest bezpieczniejsze niż bezmyślne usuwanie historii kopii zapasowych.
Komunikat o błędzie był prawdziwy, ale wskazywał niewłaściwą lokalizację docelową
Duplicati prawidłowo zgłaszał, że widok repozytorium, do którego miał dostęp, nie zawierał oczekiwanych plików. Wprowadzające w błąd było założenie, że ten widok repozytorium przedstawiał rzeczywisty dysk HDD. Mapowanie ścieżek Docker kierowało aplikację do niekompletnego lub innego widoku systemu plików.
Najczęściej zadawane pytania dotyczące dblock w Duplicati
Czy potwierdzono, że repozytorium kopii zapasowej źródła było uszkodzone?
Nie. Problem ze źródłem rozwiązano po naprawieniu mapowania woluminu Docker.
Czy purge-broken-files powinno być pierwszym krokiem?
Nie. Przed wykonaniem jakiejkolwiek destrukcyjnej naprawy sprawdź, czy zamontowano i udostępniono prawidłową, kompletną lokalizację docelową.
Czy jedno zadanie Duplicati może tworzyć kopie zapasowe wielu dysków ZimaOS?
Tak, ale każdy dysk źródłowy musi być zamapowany w kontenerze Duplicati.
