Chociaż na początku proponowane „wyzwanie” może wydawać się trudne, niewykonalne lub naiwne, jak niektórzy komentowali, tak nie jest. Główną ideą przy użyciu dd do migracji z większego dysku na mniejszy jest całkowicie w porządku i ma korzyści z migracji danych. Oczywiście niezbędne jest posiadanie wystarczającej ilości wolnego miejsca, aby zajmowane dane mieściły się na dysku docelowym.
Chodzi o to, aby pomyśleć o utworzeniu każdej partycji z osobna, a nie całego dysku naraz, jak pierwotnie zaproponowano. Jeszcze więcej można osiągnąć: partycje, które zostaną obcięte, można również bezpiecznie migrować za pomocą narzędzi do zmiany rozmiaru systemu plików. Rzeczywiście, tego rodzaju migracja jest interesująca, aby zachować matadane systemu plików i rozszerzone atrybuty plików, których nie można łatwo skopiować za pomocą narzędzi takich jak cp, rsync, pax, ... które działają w warstwie systemu plików, a nie blokują warstwy urządzenia. Użycie dd eliminuje potrzebę ponownej instalacji systemu operacyjnego lub konieczności ponownego oznakowania FS, aby uniknąć problemów z SELinux.
Poniżej znajduje się to, co zwykle robię, aby wykonać podobne zadania:
1) Najpierw zmniejsz system (-y) plików w partycjach, których dotyczy problem, które zostałyby obcięte. W tym celu skorzystaj z narzędzia resize2fs (zakładając, że mówimy o ext2 / ext3 / ext4 fs - inne współczesne FS również mają narzędzia zmiany rozmiaru do tego samego celu). Zauważ, że chociaż - z oczywistych powodów - system plików nie może być większy niż partycja, na której się on znajduje, może być bezpiecznie mniejszy. Sztuczka bezpieczeństwa polega na zmniejszeniu „więcej niż to konieczne”. Na przykład: wyobraź sobie, że masz system plików o pojemności 1 TB, który chcesz przenieść na dysk 500 Gig. W takim przypadku sugeruję zmniejszenie fs, powiedzmy, do 450 Gig (musisz mieć wystarczająco dużo wolnego miejsca na to oczywiście, tj. Aktualnie zajęte miejsce w tym systemie plików nie może przekroczyć 450 Gig). Pozornie zmarnowane 50 gigabajtów miejsca zostanie naprawione po migracji danych.
2) Podziel dysk docelowy na odpowiednią geometrię, biorąc pod uwagę ograniczenia przestrzeni;
3) dd dane za pomocą urządzeń partycji, a nie urządzenia dyskowego (tj. Użyj dd if=/dev/sda# of=/dev/sdb#dla każdej partycji zamiast używać if=/dev/sda of=/dev/sdb). UWAGA: sda i sdb tutaj są tylko przykładami; WAŻNA UWAGA: Kiedy dd'ing z większego na mniejsze urządzenie partycjonujące, dd będzie narzekać na próbę zapisu postu na końcu urządzenia blokowego, to w porządku, ponieważ dane systemu plików zostałyby całkowicie skopiowane przed osiągnięciem tego punktu. Aby uniknąć takiego komunikatu o błędzie, możesz określić rozmiar kopii za pomocą bs=i count=parametry, aby dopasować rozmiar skurczonego systemu plików, ale będzie to wymagało pewnych (prostych) obliczeń, ale jeśli zostanie wykonane nieprawidłowo, możesz zaryzykować dane.
4) Po dodaniu danych ponownie zmień rozmiar odpowiedniego systemu plików w docelowej partycji za pomocą resize2fs. Tym razem nie określaj nowego rozmiaru systemu plików. Po uruchomieniu bez specyfikacji rozmiaru resize2fs powiększa system plików, dzięki czemu zajmuje maksymalny dozwolony rozmiar, więc w tym przypadku system plików 450 Gig ponownie wzrośnie, aby zająć całą partycję 500 Gig i nie zostanie zmarnowany żaden bajt. (Podejście „zmniejsz więcej niż potrzeba” pozwala uniknąć przypadkowego nieprawidłowego określenia rozmiarów i zaryzykowania danych. Pamiętaj, że jednostki GB vs GiB mogą być trudne).
Uwaga na bardziej złożone operacje: jeśli masz menedżera rozruchu, który zamierzasz skopiować, co jest bardzo prawdopodobne, możesz dodać pierwsze kilka KB dysku za pomocą urządzenia dyskowego zamiast urządzeń partycjonujących (takich jak dd if=/dev/sda of=/dev/sdb bs=4096 count=5), a następnie ponownie skonfiguruj geometrię w / dev / sdb (która będzie tymczasowo zawierać nieprawidłową geometrię dla nowego dysku, ale nienaruszony i prawidłowy menedżer rozruchu). Na koniec kontynuuj korzystanie z urządzeń partycjonujących, jak opisano powyżej, do tworzenia partycji na raz. Robiłem takie operacje wiele razy. Całkiem niedawno z powodzeniem przeprowadziłem złożoną migrację podczas aktualizacji z dysku twardego zawierającego mieszankę instalacji MacOSX i Linux na mniejszy SDD w moim MacMini6,2. W tym przypadku musiałem uruchomić Linuksa z dysku zewnętrznego, uruchomiłem bootmanagera, uruchomiłem gdisk, aby naprawić GPT na nowym dysku, i na końcu wykonałem każdą partycję zawierającą tylko zmniejszone pliki. (Należy pamiętać, że schemat partycji GPT przechowuje dwie kopie tabeli partycji, jedną na początku, a drugą na końcu dysku. gdisk bardzo narzeka, ponieważ nie może znaleźć drugiej kopii PT i ponieważ partycje przekraczają rozmiar dysku, ale poprawnie rozwiązuje problem kopiowania PT po ponownym zdefiniowaniu geometrii dysku). To był o wiele bardziej skomplikowany przypadek, ale warto o nim wspomnieć, ponieważ pokazuje, że ten rodzaj operacji jest również całkowicie wykonalny.
Powodzenia! ... a co najważniejsze pamiętaj, aby wykonać kopię zapasową wszystkich ważnych danych przed tego rodzaju operacją. Błąd i na pewno możesz nieodwracalnie uszkodzić swoje dane.
Na wszelki wypadek nie podkreśliłem wystarczająco: wykonaj kopię zapasową danych przed migracją! :)
ddobliczanie optymalnego rozmiaru bloku