Oprogramowanie > Narzędzia administracyjne
Kopia i odtwarzanie z kopii dysku
mikajlo:
Cześć,
próbuję wykonać poprawną kopię całego mojego dysku (wraz z systemem operacyjnym) i coś mi to nie wychodzi, ponieważ po odzyskaniu kopii system nie uruchamia się ..
Próbowałem w sumie już dwóch narzędzi:
1. dd tool
Wykonałem kopię całego dysku przy użyciu następującego polecenia:
--- Kod: ---
dd if=/dev/sda conv=sync,noerror bs=64K | gzip -c > /mnt/fs/sda.img.gz
--- Koniec kodu ---
Następnie próbuję odzyskać przygotowaną kopię:
--- Kod: ---
gunzip -c /mnt/fs/sda.img.gz | dd of=/dev/sdc conv=sync,noerror bs=64K
--- Koniec kodu ---
i jest lipa..
W celu uzupełnienia informacji dodam, że kopię wykonywałem z poziomu działającego systemu operacyjnego, gdzie dysk był zamontowany pod ścieżką /dev/sda. Natomiast przy odzyskiwaniu kopii wykorzystałem liveCD i tam dysk był zamontowany pod ścieżką /dev/sdc. Czy to może być problemem? A może błędne polecenia programu dd stosuję..
2. clonezilla
Próbowałem wykonać pełną kopię dysku również przy użyciu clonezilla. Efekt końcowy jest podobny jak do w/w. Co ciekawe, kiedyś z powodzeniem używałem clonezilli do utworzenia kopi, jednak wtedy był to laptop a teraz jest to maszyna serwerowa.
EDIT: 2016-04-22 14:13
Z clonezilla ostatecznie udało się odzyskać wykonaną kopię, jednakże pytanie odnośnie dd i innych metod wykonywania kopii jest nadal aktualne.
Podsumowując - proszę o wskazówki odnośnie tematu. Być może istnieją również inne dedykowane narzędzia do wykonywania backaupu całego dysku, które lepiej by się tutaj sprawdziły..
Pozdrawiam,
Michał
Paweł Kraszewski:
Na czym konkretnie polega lipa z dd? To jest normalna procedura (+/- backup robi się też z LiveCD a nie z poziomu systemu archiwizowanego, ba na działającym systemie jego partycje mogą być niespójne)
Ja robię zrzutki tak:
1) sfdiskiem zrzut tablicy partycji
2) dd zrzut od mbr do początku pierwszej partycji (czyli na ogół 2048 sektorów)
3a) blkid zrzut UUIDów partycji, każdą partycję osobno montuję i jadę TARem
albo
3b) bez montowania jadę partimage'm
Odtworzenie to
1) Odzysk struktury z sfdiska
2) Odzysk bootmanagera ze zrzutu 2048sektorów (nadpisuje sfdiskowy, ale nie zawiera partycji rozszerzonych)
3a) Pozakładanie partycji we właściwych typach, z oryginalnymi UUID i etykietami i rozpakowanie tam TARów
albo
3b) Rozpakowanie obrazóœ partimage'a
mikajlo:
@{Paweł Kraszewski} - dzięki za zainteresowanie.
'Lipa' z dd wyglądała tak, że po wykonaniu metod podanych powyżej system operacyjny po prostu się nie ładował (wyświetlany jest migający w nieskończoność underscore).
Po część wpływ na taki stan rzeczy pewnie miało to, że wykonywałem tę kopię danych z poziomu działającego systemu. Tylko, że jak nawet w przypadku dd należy wyłączyć serwer, aby wykonać 'pełen' backup, to równie dobrze mogę użyć clonezilli.
Z drugiej strony rozpisana bez Ciebie metoda ma być może swoje zalety, których nie jestem wstanie dostrzec, ponieważ wykonywanie tego typu backupu jest dla mnie nowością.. Muszę poszukać w sieci więcej informacji na ten temat.. (jakbyś czasami dysponował jakimś tutorialem/whatever to proszę o podrzucenie .)
btw. Z tego co zauważyłem to clonezilla po części pewnie korzystać 'pod spodem' z podobnych poleceń, które Ty przytoczyłeś.. na pewno widziałem, że używał partimage.
Paweł Kraszewski:
--- Cytuj ---ma być może swoje zalety, których nie jestem wstanie dostrzec
--- Koniec cytatu ---
"Czyste" DD kopiuje też obszary nie należące już do żadnych plików (a, że tam często nie ma "zer" tylko oryginalna "kaszka", taki obraz słabo się kompresuje). Rozwiązanie z partimage/tar robi obraz tylko części dysku rzeczywiście zawierającej bieżące dane. Dzięki temu backup może być dużo mniejszy. (warning - nie dotyczy SSD z poprawnie zaimplementowanym trimem i systemem plików obsługującym trim, np EXT4. Wtedy usunięcie pliku logicznie wipuje też odpowiedni obszar nośnika)
Par example:
1. Weź pendrive tak z 2G i zwipuj go do czysta (bcwipem, dd if=/dev/zero of=/dev/sdPEN albo czymś podobnie skutecznym).
2. Nagraj tam plik tekstowy mający 1kB i plik z danymi pseudolosowymi (może też być JPG, MPG, MP3) mający 1GB
3. Skasuj plik 1GB zostawiając plik 1kB
I teraz tak:
1/ Dane pliku 1GB dalej są na nośniku, tylko oznaczone jako nieużywane.
2/ Jak zrobisz DD tego pendrive'a, to obraz będzie miał 2G. Ale kompresja nie wyciśnie więcej niż 1G, bo ten pseudolosowy śmietnik po pliku 1G się nie kompresuje.
3/ Jak zrobisz backup tar/dar/partimage, to będzie on miał 1kB+trochę metadanych, bo nie będzie zrzucany obszar po pliku 1G (jako nieistotny).
OT:
Jak archiwizacja/przywrócenie dd nie zadziałały, to znaczy że coś źle zrobiłeś. To, że zrobiłeś backup "żywego" systemu sprawi tylko/aż tyle, że po przywróceniu musisz zrobić chkdisk/fsck, żeby przywrócić spójność systemu plików. No i potencjalnie odbudowę indeksów bazy danych, jeżeli backup obejmował jakiegoś mysqla/postgresa czy cóś.
Jeżeli często robisz backupy "żywych" systemów - to do tego powstały specjalne systemy plików i rozwiązania techniczne. Btrfs, XFS i ZFS umożliwiają zrobienie "migawki" systemu plików w dowolnym momencie i zrobienie backupu z tej migawki tar-em/dar-em. LVM2 umożliwia zrobienie migawki całego urządzenia blokowego i zrobienie spójnego backupu dd/partimagem.
mikajlo:
@{Paweł Kraszewski} - Dzięki za wypowiedź i przykład funkcjonowania narzędzia dd. (szkoda, że nie można tutaj przyznawać punków albo coś w tym rodzaju, bo na pewno bym Ci je przyznał .)
Odnosząc się jednak do Twojego OT - u siebie w firmie będę miał opieką dwa serwery (Centos6), dla których muszę wprowadzić jakąś formę backupu (bo aktualnie tego brakuje..). W takim przypadku najrozsądniejszym rozwiązaniem wydaje się być zastosowanie odpowiedniego systemu plików, np. Btrfs lub ZFS i wykonywaniu snapshotów. Wtedy np. gdy system 'padnie' po aktualizacji systemu lub po czymś innym, będę mógł szybko przywrócić system do poprzedniego snapshota.
Nawigacja
[#] Następna strona
Idź do wersji pełnej