Przywrócona baza danych synchronizacji może ponownie przesłać usunięte pliki, jeśli nie zawiera już zapisów usunięcia, które odróżniały celowe usunięcie od nowo wykrytych danych lokalnych.
Synchronizacja dwukierunkowa opiera się na czymś więcej niż tylko aktualnie widoczne pliki. Przechowuje indeks lub bazę danych wcześniejszych ścieżek, wersji, identyfikatorów urządzeń, znaczników usunięcia oraz stanu synchronizacji. Przywrócenie starszej bazy danych przy jednoczesnym pozostawieniu nowszych plików lokalnych lub stanu w chmurze powoduje rozbieżność w czasie: klient może przeskanować zachowaną kopię lokalną jako nową albo zinterpretować zdalne usunięcie jako konflikt. Wstrzymaj działanie wszystkich uczestników synchronizacji, zanim zdecydujesz, która oś czasu jest nadrzędna.
Potwierdź, która baza danych i które drzewo plików zostały przywrócone
Zapisz czas utworzenia kopii zapasowej bazy danych, czas drzewa plików lokalnych, stan chmury, konfigurację klienta, tożsamość urządzenia oraz moment pierwszego ponownego przesłania. Sprawdź, czy baza danych i pliki pochodzą z tego samego punktu odzyskiwania.
Procedura przywracania Nextcloud wymaga przywrócenia bazy danych i katalogu danych jako jednego spójnego systemu, ponieważ przywrócenie tylko jednej warstwy tworzy metadane, które nie odpowiadają już zapisanym plikom.
Jeśli baza danych pochodzi sprzed usunięcia, ale drzewo lokalne zawiera starszą zachowaną kopię, ponowne przesłanie jest przewidywalne. Zachowaj wszystkie trzy stany, zanim zezwolisz na kolejną automatyczną synchronizację.
Sprawdź, czy znaczniki usunięcia zostały wycofane
Ustal, czy przywrócony stan zawiera zdarzenie usunięcia, wersję pliku, identyfikator zdalnego elementu oraz urządzenie, które pierwotnie usunęło plik. Porównaj dzienniki bezpośrednio sprzed usunięcia i tuż po nim.
Syncthing przechowuje lokalną bazę indeksu i ostrzega, że zresetowanie bazy danych wymusza pełne ponowne skanowanie i ponowną synchronizację; jeśli starsze zamontowane drzewo plików pojawi się później, może dojść do niespójności wersji.
Usunięcie, które istniało tylko w nowszej bazie danych, nie będzie dostępne po wycofaniu. Podczas kolejnego skanowania zostanie wykryty pozostały plik, ale zabraknie historycznych informacji wskazujących, że powinien nadal być usunięty.
Sprawdź pliki listingu używane przez stanowe Bisync lub synchronizację dwukierunkową
W przypadku narzędzi takich jak Rclone Bisync znajdź oba wcześniejsze listingi, katalog roboczy, stan blokady oraz ostatnie pomyślne uruchomienie. Nie traktuj nowej ponownej synchronizacji jako równoważnej kontynuowaniu pracy na prawidłowym stanie.
Dokumentacja Rclone wyjaśnia, że Bisync zachowuje stan między kolejnymi uruchomieniami i przechowuje dane robocze oddzielnie od synchronizowanych folderów.
Przywrócenie lub usunięcie tych listingów może zatrzeć różnicę między „usunięto od ostatniego uruchomienia” a „istnieje tylko po tej stronie”. Użyj trybu próbnego i zapisz oba listingi przed odbudowaniem stanu.
Zaktualizuj odcisk serwera po przywróceniu bazy danych
Sprawdź, czy platforma serwera udostępnia znacznik odzyskiwania informujący klientów o przywróceniu bazy danych. Zastosuj go, zanim klienci ponownie się połączą.
OwnCloud zaleca administratorom uruchomienie polecenia maintenance:data-fingerprint po przywróceniu, aby klienci komputerowi i mobilni mogli rozpoznać odzyskany stan serwera.
Bez zmienionego odcisku odzyskiwania klienci mogą nadal korzystać z założeń utworzonych na podstawie późniejszej bazy danych. Może to powodować konflikty, ponowne przesyłanie lub próby usunięcia obiektów przywróconych na serwerze.
Zidentyfikuj lokalne kopie, które przetrwały usunięcie w chmurze
Przeszukaj każde synchronizowane urządzenie, folder offline, wykluczoną ścieżkę, kosz, katalog konfliktów oraz tymczasowy folder odzyskiwania w poszukiwaniu kopii usuniętego pliku.
Dropbox wyjaśnia, że usunięcie elementu może usunąć go na synchronizowanych urządzeniach, ale kopie należące do innych lokalizacji lub urządzeń, które nie uczestniczą już w tym samym stanie synchronizacji, mogą pozostać.
Zachowany plik lokalny staje się kandydatem do przesłania, gdy przywrócona baza danych nie rozpoznaje go już jako wcześniej usuniętego obiektu. Oblicz jego skrót i przenieś go do kwarantanny poza katalog główny synchronizacji przed uzgodnieniem stanu.
Wstrzymaj klientów przed resetowaniem lub odbudową stanu synchronizacji
Zatrzymaj serwerowe procesy synchronizacji i wstrzymaj każdego klienta synchronizacji na komputerze, urządzeniu mobilnym, w kontenerze oraz w zadaniach zaplanowanych. Najpierw ponownie połącz jeden nadrzędny punkt końcowy.
Procedura resetowania OneDrive firmy Microsoft stwierdza, że klient odbudowuje lokalny plik DAT, co pokazuje, dlaczego reset zmienia stan klienta, ale nie rozstrzyga, która historyczna wersja pliku powinna być nadrzędna.
Reset nie zastępuje wyboru właściwej osi czasu. Jeśli kilku klientów przeskanuje dane jednocześnie, jeden może przesłać starą kopię lokalną, podczas gdy inny rozpowszechni usunięcie.
Uzgodnij stan jednego folderu za pomocą uruchomienia próbnego i niezależnej kopii zapasowej
Wyeksportuj przywróconą bazę danych, skopiuj wszystkie lokalne pliki powodujące konflikty poza katalogi synchronizacji, wybierz stan nadrzędny i przetestuj jeden mały folder przed wznowieniem synchronizacji całej biblioteki.
Przewodnik ZimaSpace dotyczący kopii zapasowych 3-2-1 wyznacza powiązaną granicę: stan synchronizacji nie jest niezależną kopią odzyskiwania, jeśli może ponownie odtworzyć usunięcie lub przesłać nieaktualne dane.
Problem zostaje rozwiązany, gdy usunięte pliki pozostają usunięte, zamierzone zachowane pliki zostają przesłane tylko raz, konflikty są udokumentowane, a druga kontrolowana synchronizacja nie powoduje nieoczekiwanego odtworzenia plików.
Często zadawane pytania
Czy przywrócenie bazy danych przywraca również historię usunięć?
Tylko do momentu utworzenia kopii zapasowej bazy danych. Usunięcia zapisane później nie będą dostępne, chyba że zachowuje je inny dziennik lub punkt końcowy.
Czy podczas odzyskiwania wszystkie klienty synchronizacji powinny pozostać połączone?
Nie. Wstrzymaj je i najpierw ponownie połącz jeden nadrzędny punkt końcowy, aby starsze klienty nie mogły od razu ponownie wprowadzić nieaktualnych plików.
Czy pełne ponowne skanowanie bezpiecznie rozwiąże problem?
Ponowne skanowanie odbudowuje informacje o tym, co obecnie istnieje, ale nie może odtworzyć brakujących historycznych zamiarów. Może ponownie przesłać zachowane pliki, jeśli wcześniej nie zostanie wybrany stan nadrzędny.
Wsparcie i wskazówki
Więcej do przeczytania

Dlaczego przywracanie woluminu Dockera odtwarza zawartość plików, ale usuwa atrybuty rozszerzone?
Diagnoza przywracania woluminu obejmująca inwentaryzację atrybutów xattr, opcje tar i Rsync, przestrzenie nazw, obsługę miejsca docelowego, uprawnienia, etykiety, metadane aplikacji i testy.

Dlaczego uruchomiony kontener zachowuje stary limit pamięci po zmianie pliku Compose?
Diagnoza limitu pamięci obejmująca aktywne grupy cgroup, ponowne uruchamianie w porównaniu z odtwarzaniem, pola Compose, limity twarde i miękkie, zakresy nadrzędne, pamięć wymiany oraz...

Dlaczego ponowne uruchomienie odwrotnego proxy unieważnia każdą sesję w jednej samodzielnie hostowanej aplikacji?
Diagnoza utraty sesji obejmująca zakres restartu, własność plików cookie, rotację sekretów, sesje oparte na pamięci podręcznej, przekierowanie do serwera przyklejonego, bramy uwierzytelniania oraz przywracanie...

