Jak przenieść dane kontenerów do puli SSD bez zmiany ścieżek montowania

Przenieś źródło danych po stronie hosta na dysk SSD, zachowując bez zmian każdą docelową ścieżkę po stronie kontenera.

Bezpieczna migracja traktuje bieżącą mapę montowań jako kontrakt interfejsu. Kontenery, bazy danych i aplikacje multimedialne oczekują ścieżek takich jak /config, /data lub /media, niezależnie od tego, który dysk je dostarcza. Procedura musi zatrzymać zapisy, przewidywalnie zamontować dysk SSD, skopiować właścicieli i metadane, zaktualizować wyłącznie źródło po stronie hosta, zweryfikować nowe montowanie przed uruchomieniem oraz zachować oryginalne dane do czasu pomyślnego przeprowadzenia pełnego testu przywracania.

Zainwentaryzuj każde bieżące źródło i docelową ścieżkę kontenera

Wyeksportuj plik Compose lub dane inspekcji kontenerów i wypisz każde montowanie bind, nazwany wolumen, montowanie tmpfs, katalog bazy danych, pamięć podręczną, ścieżkę transkodowania oraz lokalizację multimediów. Zapisz osobno źródło hosta i miejsce docelowe kontenera.

Praktyczny poradnik migracji wolumenu zaczyna się od zlokalizowania bieżących danych i zatrzymania kontenerów przed skopiowaniem ich do nowej lokalizacji na dysku. Taka inwentaryzacja zapobiega pozostawieniu danych konfiguracyjnych na dysku systemowym.

Oznacz ścieżki zawierające nadrzędny stan aplikacji, możliwą do odtworzenia pamięć podręczną oraz duże pliki multimedialne. Nie zakładaj, że folder o nazwie data zawiera cały trwały stan aplikacji.

Przewidywalnie zamontuj pulę SSD przed uruchomieniem Dockera

Utwórz system plików lub pulę SSD, zidentyfikuj ją za pomocą stabilnego identyfikatora UUID lub nazwy puli i zamontuj pod docelową ścieżką hosta. Po ponownym uruchomieniu sprawdź wolne miejsce, oczekiwane funkcje systemu plików oraz możliwość zapisu.

Przenoszenie danych Dockera do pamięci zewnętrznej może zakończyć się niepowodzeniem, gdy dysk jest niedostępny lub podczas uruchamiania zostanie zamontowany pod inną ścieżką. Niedawny przypadek dotyczący zewnętrznego dysku SSD pokazuje, jak relokacja pamięci Dockera zmienia zależność od docelowej ścieżki montowania.

Skonfiguruj kolejność uruchamiania usług lub automatyczne montowanie, aby Docker nigdy nie tworzył pustego katalogu zastępczego na dysku systemowym. Przerwij operację, jeśli dysk SSD nie jest zamontowany dokładnie pod oczekiwaną ścieżką.

Zatrzymaj procesy zapisujące i skopiuj dane z zachowaniem metadanych

Zatrzymaj aplikację oraz każdą zależność, która może zapisywać w jej danych, w tym bazy danych, indeksatory, programy pobierające i zadania działające w tle. W przypadku baz danych przed skopiowaniem surowych plików wykonaj zrzut spójny z aplikacją lub przeprowadź prawidłowe zamknięcie.

W dyskusji dotyczącej kontenerów Synology zaleca się przeniesienie wolumenu zarządzanego przez Dockera do montowania bind dopiero po zidentyfikowaniu danych wolumenu i zachowaniu ich zawartości w nowym źródle montowania bind.

Kopiuj rekursywnie, zachowując właścicieli, uprawnienia, znaczniki czasu, dowiązania, listy ACL i atrybuty rozszerzone, jeśli są obsługiwane. Po skopiowaniu, a przed zmianą pliku Compose, wykonaj porównanie testowe lub sprawdź próbkę sum kontrolnych.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Zmień wyłącznie ścieżkę źródłową hosta

Zachowaj identyczną ścieżkę docelową kontenera. Na przykład zmień /oldpool/app:/config na /ssdpool/app:/config, zamiast uczyć aplikację nowej ścieżki wewnętrznej.

Montowania bind udostępniają dokładną lokalizację hosta pod stabilną ścieżką wewnątrz kontenera. Przegląd pamięci masowej wyjaśnia, że takie bezpośrednie mapowanie jest przydatne, gdy administratorzy potrzebują kontroli nad ścieżką po stronie hosta.

Zachowanie ścieżki docelowej zapobiega uszkodzeniu baz danych aplikacji, odwołań do bibliotek, skryptów, uprawnień i wartości konfiguracji przechowujących ścieżkę po stronie kontenera.

Przywróć właścicieli, etykiety i spójność bazy danych

Porównaj numeryczne wartości UID i GID oczekiwane przez obraz z właścicielami na dysku SSD. Przywróć również listy ACL, etykiety SELinux, reguły AppArmor oraz opcje montowania wymagane do blokowania plików lub obsługi plików mapowanych w pamięci.

Poradnik migracji pamięci Dockera w systemie macOS zauważa, że relokacja danych Dockera wymaga skopiowania całego obrazu pamięci, a następnie potwierdzenia, że środowisko uruchomieniowe korzysta z nowej lokalizacji pamięci. W systemach NAS z Linuksem odpowiednikiem tej kontroli jest sprawdzenie, czy każde skonfigurowane źródło wskazuje zamontowany dysk SSD.

Uruchom samą bazę danych i przeanalizuj dzienniki odzyskiwania przed uruchomieniem aplikacji zależnych. Jeśli zgłosi uszkodzenie lub brak plików, zatrzymaj operację i wróć do oryginalnej kopii, zamiast pozwolić aplikacjom zainicjować pustą bazę danych.

Przełącz system z możliwością wycofania zmian i wykonaj pełny test działania

Uruchom stos w kolejności zależności i zweryfikuj konfigurację, rekordy bazy danych, uprawnienia, biblioteki multimediów, przesyłanie, pobieranie, aktualizacje oraz ponowne tworzenie kontenerów. Sprawdź, czy nowe zapisy trafiają na dysk SSD i czy zajętość dysku systemowego przestaje rosnąć.

Artykuł ZimaSpace dotyczący montowania bind Dockera, które nagle staje się tylko do odczytu, omawia kolejne kroki diagnostyczne, jeśli zmigrowana ścieżka jest zamontowana, ale odrzuca zapisy.

Trzymaj stare dane w trybie offline i bez zmian do czasu pomyślnego wykonania kopii zapasowych oraz ponownego utworzenia kontenera ze ścieżki SSD. Usuń stare źródło dopiero wtedy, gdy próba wycofania zmian potwierdzi możliwość odtworzenia pliku Compose, montowań, baz danych i stanu aplikacji.