Obracany dysk USB do tworzenia kopii zapasowych może otrzymać przyrostek w ścieżce montowania, gdy preferowany katalog oparty na etykiecie jest już zajęty, zduplikowany lub przypisany przez inny automatyczny mechanizm montowania.
Rotacja kopii zapasowych często wykorzystuje kilka podobnych dysków, a administratorzy mogą klonować systemy plików lub ponownie używać tej samej etykiety woluminu dla wygody. Po ponownym uruchomieniu kolejność wykrywania, automatyczne montowanie przez środowisko graficzne, nieaktualne katalogi montowania, zduplikowane etykiety lub konkurencyjny wpis w fstab mogą sprawić, że jeden z dysków pojawi się pod ścieżką taką jak BACKUP_1 zamiast BACKUP. Dysk może działać prawidłowo, podczas gdy zadanie tworzenia kopii zapasowej zacznie korzystać z niewłaściwego katalogu. Przed przenoszeniem plików lub edycją ścieżek zweryfikuj tożsamość dysku.
Zidentyfikuj system plików znajdujący się za nieoczekiwaną ścieżką
Zapisz rzeczywiste urządzenie, identyfikator UUID systemu plików, etykietę, numer seryjny lub ścieżkę by-id, źródło montowania, punkt docelowy, typ systemu plików oraz opcje dla każdego podłączonego dysku używanego w rotacji.
Linuksowe polecenie findmnt mapuje punkt docelowy na jego aktywne źródło, dzięki czemu myląca nazwa folderu nie zostanie uznana za nazwę właściwego dysku kopii zapasowej.
Jeśli katalog z przyrostkiem należy do właściwego UUID, problem dotyczy przypisania ścieżki. Jeśli należy do innego dysku, zatrzymaj tworzenie kopii zapasowej, zanim dane zostaną zapisane w niewłaściwym zestawie rotacyjnym.
Sprawdź zduplikowane etykiety lub identyfikatory UUID systemów plików
Porównaj UUID, etykietę, PARTUUID, numer seryjny oraz nazwy by-id wszystkich dysków używanych w rotacji, w tym dysków obecnie odłączonych, jeśli masz dostęp do odpowiedniej dokumentacji.
ArchWiki wyjaśnia, że etykiety łatwiej zduplikować niż UUID, dlatego automatyczne montowanie wyłącznie na podstawie etykiety jest ryzykowne, gdy kilka dysków kopii zapasowych celowo ma tę samą przyjazną nazwę.
Klonowanie systemu plików może również sklonować jego UUID. Nadaj każdemu systemowi plików unikalną tożsamość, zanim zaczniesz polegać na bezobsługowej rotacji, i udokumentuj, który fizyczny dysk odpowiada danemu identyfikatorowi.
Dowiedz się, dlaczego automatyczne mechanizmy montowania dodają przyrostek
Sprawdź, czy sesja środowiska graficznego, usługa NAS, pomocniczy moduł UDisks lub menedżer nośników wymiennych zamontował dysk przed wykonaniem wpisu fstab albo uruchomieniem usługi tworzenia kopii zapasowych.
Filesystem Hierarchy Standard dopuszcza dodawanie cyfr do katalogów montowania nośników wymiennych, gdy więcej niż jedno urządzenie potrzebuje podobnej lokalizacji montowania.
Dokładna zasada dodawania przyrostków zależy od automatycznego mechanizmu montowania, ale zasada diagnostyczna pozostaje taka sama: preferowana ścieżka była niedostępna lub niejednoznaczna w chwili podłączenia urządzenia.
Sprawdź, czy preferowany katalog montowania był już zajęty
Sprawdź oczekiwany katalog przed podłączeniem dysku. Ustal, czy znajduje się w nim inny punkt montowania, przypadkowe pliki zapisane podczas nieobecności dysku, montowanie bind lub nieaktualny katalog roboczy procesu.
Wskazówki Oracle dotyczące nośników wymiennych informują, że etykiety nośników służą do nazywania ścieżek montowania, co powoduje kolizję, gdy wiele nośników przedstawia tę samą nazwę ścieżki utworzoną na podstawie etykiety.
Nie usuwaj zajętego katalogu bez sprawdzenia, czy nie zawiera kopii zapasowych omyłkowo zapisanych w głównym systemie plików. Zweryfikowane przypadkowe dane przenieś w kontrolowanym procesie odzyskiwania.
Zdefiniuj jeden stały punkt montowania w fstab dla każdego dysku rotacyjnego
Wybierz stabilną zasadę: albo każdy fizyczny dysk otrzymuje własny stały katalog, albo skrypt rotacji montuje aktualnie wybrany UUID w jednym kontrolowanym punkcie kopii zapasowej po zweryfikowaniu tożsamości dysku.
Red Hat opisuje trwałe montowanie za pomocą fstab z użyciem UUID i stałego punktu montowania, eliminując zautomatyzowanej ścieżki zależność od kolejności wykrywania oraz kolizji przyjaznych etykiet.
Nie twórz kilku aktywnych wpisów fstab konkurujących o ten sam katalog docelowy. Proces rotacji powinien potwierdzić odmontowanie poprzedniego dysku przed podłączeniem następnego.
Uzależnij uruchomienie kopii zapasowej od zweryfikowanego montowania
Sprawdź, czy harmonogram uruchamia się przed zakończeniem wykrywania i montowania urządzenia USB. Dodaj kontrolę wstępną sprawdzającą UUID, punkt montowania, możliwość zapisu oraz oczekiwany plik znacznikowy.
Dokumentacja montowania systemd w Debianie wyjaśnia, że wpisy fstab stają się zależnościami montowania systemd, dzięki czemu usługi tworzenia kopii zapasowych mogą oczekiwać na określony punkt montowania zamiast na przypadkowy katalog.
Samo sprawdzenie istnienia katalogu jest niewystarczające, ponieważ pusty katalog istnieje również wtedy, gdy dysku nie ma. Zweryfikuj tożsamość zamontowanego systemu plików.
Przetestuj całą rotację po ponownym uruchomieniu i wymianie dysków
Dla każdego dysku wykonaj prawidłowe odmontowanie, odłączenie, ponowne uruchomienie, ponowne podłączenie, walidację tożsamości, testowy zapis, próbne uruchomienie kopii zapasowej oraz weryfikację odczytu. Zapisz oczekiwaną ścieżkę i UUID.
Artykuł ZimaSpace dotyczący montowania za pomocą UUID i stabilnych ścieżek aplikacji omawia szersze zagadnienie projektowania stałych ścieżek; ten artykuł koncentruje się na kolizjach powodowanych przez rotowanie kilku wymiennych dysków do tworzenia kopii zapasowych.
Problem można uznać za rozwiązany, gdy każdy dysk rotacyjny po wielokrotnych testach ponownego uruchamiania i wymiany jest mapowany na udokumentowaną ścieżkę, a tworzenie kopii zapasowej odmawia uruchomienia, gdy oczekiwany UUID jest nieobecny lub zamontowany w innym miejscu.
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...

