Dlaczego pliki o nazwach różniących się tylko wielkością liter kolidują podczas przywracania NAS na różnych platformach?

Konflikty nazw plików różniących się tylko wielkością liter pojawiają się podczas przywracania NAS międzyplatformowego, gdy kopia zapasowa zawiera dwie ścieżki, które cel przywracania uznaje za równoważne. Domowy serwer Linux może zachować Photo.jpg oraz photo.jpg jako oddzielne pliki, podczas gdy wolumen Windows, domyślny wolumen macOS lub klient SMB mogą traktować te nazwy jako jeden cel. Narzędzie do przywracania musi wtedy nadpisać, zmienić nazwę, pominąć, scalić lub zatrzymać operację.

Nie kontynuuj pełnego przywracania, dopóki nie dowiesz się, które ścieżki się zderzyły i jak narzędzie sobie z tym poradziło. Przywróć dotknięte drzewo do izolowanej lokalizacji tymczasowej, zachowaj oba obiekty źródłowe pod deterministycznymi tymczasowymi nazwami i utwórz rekord mapowania ścieżek przed przeniesieniem danych do aktywnego udziału NAS.

Dlaczego kopia zapasowa może przechowywać dwie nazwy, które cel przywracania odrzuca?

Repozytorium kopii zapasowej może zapisywać ścieżki jako nieprzejrzyste nazwy bez wymuszania reguł porównywania systemu plików docelowego. Systemy plików Linux zwykle rozróżniają wielkość liter, podczas gdy systemy Windows i domyślne systemy macOS zwykle zachowują wpisaną wielkość liter, ale porównują nazwy bez rozróżniania wielkości liter. Dyskusja o przywracaniu międzyplatformowym pokazuje, że ścieżki źródłowe mogą być ważne w kopii zapasowej, ale nieprzedstawialne na systemie przywracania.

W przypadku domowego NAS często zdarza się to po przywróceniu wolumenu kontenera Linux, katalogu dewelopera, drzewa importu zdjęć lub biblioteki multimediów na udział, do którego będzie dostęp z Windows lub macOS. Kopia zapasowa nie musi być uszkodzona; przestrzeń nazw docelowa ma mniejszy zestaw unikalnych nazw.

SMB zachowujący wielkość liter nie jest tym samym co pamięć wrażliwa na wielkość liter

Udział SMB może wyświetlać oryginalną wielkość liter, a jednocześnie wykonywać wyszukiwanie bez rozróżniania wielkości liter. Przykład z społeczności TrueNAS opisuje różne zasady dotyczące wielkości liter na warstwach zbioru danych i dostępu SMB. Serwer może więc lokalnie przechowywać nazwy z mieszanymi literami, podczas gdy klient SMB Windows lub macOS nie może traktować ich jako oddzielnych obiektów.

Testuj faktyczną ścieżkę przywracania, nie tylko ustawienie systemu plików NAS. Utwórz dwa nieszkodliwe pliki, których nazwy różnią się tylko wielkością liter, za pomocą tego samego klienta, protokołu, punktu montowania i katalogu docelowego, które zostaną użyte w zadaniu przywracania. Jeśli utworzenie drugiego pliku się nie powiedzie lub zostanie przypisane do pierwszego pliku, ta ścieżka nie może bezpiecznie przyjąć oryginalnej struktury bez zmian.

Kolizja Nazwy Folderu Może Scalić Całe Poddrzewo

Konflikt może wystąpić w dowolnym komponencie katalogu, nie tylko w końcowej nazwie pliku. Jeśli kopia zapasowa zawiera Photos/2025/A.jpg i photos/2025/B.jpg, docelowy system ignorujący wielkość liter może scalić obie gałęzie w jeden katalog lub odrzucić drugą gałąź. Konto transferu mieszającego Linux i Windows pokazuje, jak kolizje w komponentach katalogów mogą błędnie kierować lub usuwać pliki.

Porównuj pełne ścieżki względne po zastosowaniu reguł ignorowania wielkości liter docelowego systemu. Raport sprawdzający tylko duplikaty nazw bazowych może pominąć kolizje powstałe w katalogach nadrzędnych.

Narzędzia do Przywracania Nie Obsługują Bezpiecznie Każdej Kolizji

Aplikacja do przywracania może zatrzymać się z błędem „już istnieje”, dodać sufiks, zachować pierwszy plik, zachować ostatni plik lub scalić drzewa katalogów. Niektóre zadania kończą się sukcesem lub ostrzeżeniem, mimo że jeden z plików w parze kolizji został pominięty. Badania nad niekonsekwentną obsługą kolizji spowodowanych rozróżnianiem wielkości liter pokazują, dlaczego zachowanie narzędzia należy obserwować, a nie zakładać.

Przed dużym przywracaniem utwórz małą testową kopię zapasową zawierającą pary plików i katalogów różniące się tylko wielkością liter. Zapisz, czy narzędzie zawiodło, zmieniło nazwę, nadpisało, czy scaliło pliki, i zweryfikuj sumy kontrolne zawartości po operacji.

Normalizacja Unicode Może Powodować Podobne Kolizje

Dwie nazwy plików mogą wyglądać identycznie, używając różnych sekwencji punktów kodowych Unicode, takich jak znak akcentowany złożony i znak bazowy z następującym po nim znakiem łączącym. Obsługa nazw w APFS zachowuje formy, jednocześnie stosując znormalizowane porównania w niektórych trybach, a rozróżnianie wielkości liter i normalizacja Unicode współdziałają przy wyszukiwaniu nazw plików.

Nie zakładaj, że każdy pozorny konflikt tylko z powodu wielkości liter jest spowodowany wyłącznie wielkimi i małymi literami. Eksportuj nazwy w formacie ucieczkowym lub świadomym punktów kodowych, gdy zaangażowane są nazwy z akcentami, języków azjatyckich lub wizualnie identyczne.

Zamroź przywracanie i najpierw zachowaj oba obiekty

Gdy pojawi się kolizja, zatrzymaj przywracanie do docelowego miejsca na żywo. Nie uruchamiaj wielokrotnie tego samego zadania z włączonym nadpisywaniem, ponieważ zwycięzca może się zmieniać w zależności od kolejności przeglądania. Utwórz system plików stagingowy rozróżniający wielkość liter lub przywróć przez środowisko Linux, które może reprezentować obie nazwy. Artykuł dotyczący wiersza poleceń Windows wyjaśnia, że katalogi rozróżniające wielkość liter mogą zachować nazwy, których zwykłe aplikacje Windows nie potrafią rozróżnić, co ilustruje, dlaczego staging musi używać przestrzeni nazw, która może reprezentować oba obiekty.

Przywróć każdy kolidujący obiekt do unikalnej tymczasowej nazwy, takiej jak Photo.jpg.__case1 oraz photo.jpg.__case2. Zachowaj oryginalną ścieżkę, wersję kopii zapasowej, rozmiar, sumę kontrolną i wybraną tymczasową nazwę w pliku mapowania CSV lub JSON.

Deterministycznie zmień nazwy kolidujących plików przed przeniesieniem ich do udostępniania na żywo

Wybierz regułę, która nigdy nie zależy od tego, który plik zostanie napotkany jako pierwszy. Dodaj etykietę platformy źródłowej, stabilny fragment hasha lub wyraźną sekwencję, zachowując rozszerzenie. Na przykład zachowaj Photo__linux_A1B2.jpg oraz photo__linux_C3D4.jpg zamiast akceptować automatyczne sufiksy „copy”, których znaczenie jest niejasne.

Przejrzyj mapowanie przed zmianą nazw w repozytorium kopii zapasowej lub oryginalnym źródle. Przewodnik ZimaSpace dotyczący wykrywania kolizji nazw plików rozróżniających wielkość liter przed kopiowaniem między platformami może być użyty do skanowania odtworzonego drzewa stagingowego i potwierdzenia, że nie pozostała żadna nierozwiązana para.

Napraw odwołania aplikacji po zmianie nazw plików

Plik multimedialny po zmianie nazwy może zniknąć z bazy danych biblioteki, konfiguracja kontenera może wskazywać na starą ścieżkę, a aplikacja do zdjęć może traktować zmieniony obiekt jako nowy zasób. Najpierw przywróć dane, a następnie zaktualizuj listy odtwarzania, linki sidecar, skrypty, rekordy bazy danych, montowania wiązań i indeksy aplikacji zależne od dokładnej pisowni.

Dla aplikacji samodzielnie hostowanych zachowaj bazę danych i konfigurację opisującą oryginalne ścieżki. Przywracanie tylko systemu plików może zachować każdy bajt, ale pozostawić aplikację niekompletną, gdy odwołania do ścieżek nie pasują.

Użyj raportu kolizji, aby zdecydować o działaniu naprawczym

Najczęściej zadawane pytania

Czy udział SMB może zachować oba File.txt oraz file.txt?

Tylko wtedy, gdy podstawowy zestaw danych, konfiguracja serwera SMB, klient i aplikacja używają zgodnych semantyk rozróżniających wielkość liter. Sam zestaw danych NAS rozróżniający wielkość liter nie gwarantuje, że każdy klient SMB może utworzyć i adresować obie nazwy.

Czy przywrócenie na wolumin APFS rozróżniający wielkość liter rozwiązuje każdy konflikt?

Nie. Może zachować pary różniące się tylko wielkością liter, ale późniejszy cel SMB, klient Windows, aplikacja, format archiwum lub zasady porównywania Unicode mogą nadal łączyć lub odrzucać te nazwy.

Dlaczego dwie wizualnie identyczne nazwy plików mogą nadal powodować konflikt?

Mogą używać różnych sekwencji Unicode, które docelowe środowisko normalizuje do tej samej formy porównawczej. Sprawdź punkty kodowe zamiast polegać wyłącznie na tym, jak Finder lub Explorer wyświetla nazwę.

Ostateczne wnioski

Kolizje nazw plików różniących się tylko wielkością liter występują, ponieważ kopia zapasowa może zachować więcej unikalnych ścieżek niż może reprezentować docelowe środowisko przywracania międzyplatformowego. Zatrzymaj się przy pierwszej kolizji, przywróć do zgodnego obszaru tymczasowego, zachowaj każdy obiekt pod deterministycznymi tymczasowymi nazwami, zapisz mapowanie i zweryfikuj liczbę oraz sumy kontrolne przed importem danych do aktywnego udziału NAS w domu.