Dlaczego przywracanie woluminu Dockera odtwarza zawartość plików, ale usuwa atrybuty rozszerzone?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Why Does a Docker Volume Restore Recreate File Contents but Drop Extended Attributes? - Zima Store Online

Przywracanie woluminu Dockera może odtworzyć każdy bajt pliku, a mimo to pominąć atrybuty rozszerzone, jeśli format kopii zapasowej, opcje, uprawnienia lub miejsce docelowe nie umożliwiają ich zachowania.

Atrybuty rozszerzone to pary nazwa–wartość metadanych przechowywane poza zwykłą zawartością plików, informacjami o właścicielu, bitami uprawnień i znacznikami czasu. Mogą zawierać dane ACL, etykiety SELinux, możliwości systemu Linux, znaczniki aplikacji lub metadane Samby. Prosta kopia zapasowa woluminu oparta na tarze może odtworzyć katalog, który wygląda na kompletny, podczas gdy aplikacje zachowują się inaczej, ponieważ archiwum nie zapisało atrybutów rozszerzonych lub proces przywracania nie mógł zapisać w chronionej przestrzeni nazw.

Przed ponownym przywracaniem zinwentaryzuj atrybuty źródłowe

Wybierz reprezentatywne pliki i zapisz ich sumy kontrolne, właściciela, uprawnienia, listę ACL oraz każdą nazwę i wartość atrybutu rozszerzonego. Uwzględnij pliki, które po przywróceniu nie działają poprawnie w aplikacji.

Model atrybutów rozszerzonych systemu Linux rozdziela przestrzenie nazw user, system, security i trusted, z których każda ma inne wymagania dotyczące dostępu i uprawnień.

Jeśli źródło nie ma atrybutów rozszerzonych, przywracanie ich nie utraciło. Jeśli znika tylko jedna przestrzeń nazw, skup się na uprawnieniach, zasadach bezpieczeństwa lub obsłudze miejsca docelowego, a nie na warstwie zawartości plików w archiwum.

Sprawdź, co faktycznie zarchiwizowało polecenie kopii zapasowej Dockera

Zapisz dokładny obraz, polecenie, katalog roboczy, format archiwum, użytkownika, zamontowane źródło oraz zamontowane miejsce docelowe kopii zapasowej użyte przez kontener wykonujący kopię.

Przykład kopii zapasowej woluminu Dockera używa tar wewnątrz pomocniczego kontenera, ale zachowanie metadanych nadal zależy od implementacji tar oraz wybranych opcji.

Poprawne utworzenie pliku archiwum potwierdza, że odczytano wpisy katalogów i zawartość, ale nie oznacza, że uwzględniono każdą przestrzeń nazw atrybutów rozszerzonych. Sprawdź archiwum za pomocą tego samego narzędzia, którego użyto do jego utworzenia.

Włącz atrybuty rozszerzone podczas tworzenia i rozpakowywania archiwum

Porównaj opcje tar użyte podczas tworzenia kopii zapasowej i przywracania. Potwierdź, że atrybuty rozszerzone były włączone w obu kierunkach oraz że wzorce uwzględniania lub wykluczania nie usunęły wymaganych przestrzeni nazw.

GNU tar podaje, że --xattrs zapisuje i przywraca atrybuty rozszerzone.

Dodanie tej opcji wyłącznie podczas rozpakowywania nie odzyska atrybutów, które nigdy nie zostały zapisane. Utwórz nowe małe archiwum na podstawie pliku źródłowego ze znanym testowym atrybutem rozszerzonym i sprawdź je przed zmianą kopii produkcyjnych.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Użyj właściwych opcji Rsync dotyczących metadanych w kopiach opartych na plikach

Jeśli kopia zapasowa woluminu korzysta z Rsync, sprawdź po obu stronach opcje archiwizacji, ACL, atrybutów rozszerzonych, numerycznych identyfikatorów, fake-super i uprawnień.

Oficjalna instrukcja Rsync opisuje opcję -X służącą do zachowywania atrybutów rozszerzonych oraz przechowywanie danych fake-super, gdy uprzywilejowanych metadanych nie można zastosować bezpośrednio.

Typowa opcja archiwizacji -a nie obejmuje automatycznie wszystkich wymagań dotyczących ACL i atrybutów rozszerzonych. Przetestuj dokładne polecenie na rzeczywistych systemach plików źródłowym i docelowym.

Zweryfikuj obsługę systemu plików i montowania w miejscu docelowym

Utwórz tymczasowy plik bezpośrednio na przywróconym woluminie i spróbuj ustawić, wyświetlić oraz usunąć jeden atrybut rozszerzony użytkownika. Powtórz test za pośrednictwem hosta i kontenera wykonującego kopię zapasową.

Użyj narzędzia do wyświetlania atrybutów zarówno na hoście, jak i w kontenerze przywracania, aby niezależnie od archiwum potwierdzić, czy miejsce docelowe akceptuje i zwraca atrybuty rozszerzone.

Jeśli bezpośrednie utworzenie atrybutu rozszerzonego kończy się niepowodzeniem, sprawdź typ systemu plików, opcje montowania, protokół sieciowy, sterownik woluminu oraz obsługę po stronie urządzenia pamięci masowej. Żadna opcja archiwizacji nie przywróci metadanych, których miejsce docelowe nie potrafi reprezentować.

Sprawdź uprawnienia do przestrzeni nazw security i trusted

Zapisz użytkownika kontenera przywracającego dane, jego możliwości, przestrzeń nazw użytkownika, tryb rootless, zasady SELinux oraz informację, czy ścieżka woluminu jest montowana z hosta jako bind mount.

Red Hat dokumentuje, że etykiety SELinux mogą wymagać przywrócenia zgodnie z zasadami po skopiowaniu lub ponownym utworzeniu plików.

Nie przyznawaj kontenerowi kopii zapasowej na stałe szerokich uprawnień do hosta. Użyj kontrolowanego środowiska przywracania albo najpierw przywróć zwykłe dane, a następnie ponownie zastosuj etykiety zarządzane przez zasady za pomocą obsługiwanych narzędzi.

Rozdziel ACL, możliwości i atrybuty rozszerzone specyficzne dla aplikacji

Porównuj osobno wpisy POSIX ACL, możliwości plików systemu Linux, etykiety SELinux, atrybuty rozszerzone użytkownika oraz metadane Samby lub macOS. Każdy z tych elementów może nie działać z innego powodu.

Moduł Samba xattr_tdb może przechowywać atrybuty rozszerzone osobno względem bazowego systemu plików.

Archiwum woluminu na poziomie plików może więc zachować widoczne drzewo plików, ale nie osobną bazę metadanych Samby. Uwzględnij każdy zależny magazyn metadanych lub odbuduj go za pomocą procedury obsługiwanej przez aplikację.

Przywróć jeden plik testowy i zweryfikuj działanie aplikacji

Utwórz znany plik źródłowy z sumą kontrolną zawartości, listą ACL, atrybutem rozszerzonym użytkownika oraz wymaganymi metadanymi aplikacji. Utwórz jego kopię zapasową i przywróć go do tymczasowego woluminu.

Artykuł ZimaSpace dotyczący zmian uprawnień i metadanych podczas korzystania z NAS omawia szersze zachowanie podczas migracji; ten artykuł skupia się na tworzeniu kopii zapasowej i przywracaniu woluminu Dockera.

Problem jest rozwiązany, gdy po drugim kontrolowanym utworzeniu kopii zapasowej i przywróceniu zgadzają się sumy kontrolne zawartości, wymagane nazwy i wartości atrybutów rozszerzonych, listy ACL, etykiety bezpieczeństwa oraz działanie aplikacji.

Często zadawane pytania

Czy atrybuty rozszerzone są tym samym co ACL?

Nie. Na niektórych systemach plików listy ACL mogą być implementowane za pomocą systemowych atrybutów rozszerzonych, ale atrybuty rozszerzone przechowują również etykiety bezpieczeństwa, możliwości, metadane użytkownika i wartości specyficzne dla aplikacji.

Czy tar domyślnie zachowuje atrybuty rozszerzone?

Nie zakładaj, że tak. GNU tar udostępnia jawne opcje dotyczące atrybutów rozszerzonych, a archiwum musi zapisać atrybuty podczas tworzenia, zanim rozpakowywanie będzie mogło je przywrócić.

Czy przywracanie może utracić atrybuty rozszerzone nawet po uruchomieniu jako root?

Tak. Archiwum może ich nie zawierać, miejsce docelowe może ich nie obsługiwać, zasady bezpieczeństwa mogą je odrzucać lub metadane mogą znajdować się w osobnej bazie danych aplikacji.