Kopia dysku

Osobiście jestem zwolennikiem robienia rsync'iem kopi struktury FS zamiast całego bloku dysku/partycji, ponieważ:

- to się robi szybciej przy kolejnej iteracji bo tylko przenosza się różnice a nie całość

- w przypadku konieczności wykonania operacji odwrotnej (czyli odtworzenia na jakimś nowym dysku) gdy pendrive był jest większy niż pierwotne źródło trzeba pamiętać ile bloków miało pierwotne źródło by nie kopiować obszaru pendrive'a poza zakresem pierwotnego fsa. dd musi wtedy dostać zakres kopiowania.

Mam ogólnie relatywnie dużo softu, skomplikowanego, którego używam na codzień.

Jakiś czas temu robiłem backupy.

Teraz już mi się nie chce. Koszt postawienia systemu z backupu i zainstalowania wszystkich updateów jest na tyle duży, że najzwyczajniej postawienie nowego systemu + narzędzi zaczyna być kuszącą alternatywą.

Kwestia separacji narzędzi od danych. Narzędzia da się łatwo postawić na nowo a bywa, że daje to również jakieś plusy z okolicy porządku.

Innymi słowy: nie wiem co tam musisz odzyskiwac, ale dzisiaj instalcja windowsa to 10 minut, więc jedyny problem to narzędzia.

Oszczędzasz na kopiowaniu (zapisie), ale czytać i tak musisz wszystko, i to dwa razy, tzn. obie strony, więc to wcale nie taki oczywisty zysk.

Wystarczy na tym nośniku trzymać obraz FS-a, tj. plik wynikowy dd, a nie zapisywać nowy filesystem... To zresztą również bezpieczniejsze.

Tak czy inaczej: zarówno rsync, jak i kopiowanie obrazów to słabe podejścia, bo nie pozwalają cofnąć się w czasie poza ostatni zrzut. Ja od kilku już lat korzystam wylącznie z BORG-a. Bardzo przyjemny wynalazek.

Mateusz

To prawda, ze jak się naprawia i instaluje ponownie programy to można uporządkować (czyt. wyrzucić niepotrzebne rzeczy).

Ale niestety nie mam ostatnio czasu i nic nie wskazuje abym w najbliższej przyszłości miał aby się ponownie pałować z różnymi narzędziami.

Na przykład, mam stary kompilator do piców chodzący na wine, do którego w zawieruchach dziejowych pogubiłem klucze.

Kupiłem inny kompilator, ccs, ale on nie jest tak optymalny i nie mogę go używać do produkowanego wyrobu, gdy trzeba poprawkę/uzupełnienie/rozwinięcie jakieś zrobić; nie mieści się.

Tego typu sprawy.

No nic. Trzeba kupić dysk mechaniczny, ssd, pen i pokombinować.

Dziękuję za porady, mam nadzieję, że coś wyjdzie.

jp

Idealny powód aby odpalać go pod VirtualBoxem. Wiem, trochę za późno. Na przyszłosc mówię. Choć nie wykluczone, że nadal można go wydłubać jako obraz dysku i tak odpalać.

Trzeba było nie brać PICów, tak vendor-lockin a w zasadzie to tool-lockin :P

W dniu 11.10.2022 o 09:27, m4rkiz pisze:

Proponowałem podobnie ale z założeniem, że "nowy/używany" dysk będzie pracował obecnie po kopiowaniu a stary/sprawny odkładam na półkę, oczywiście najpierw sprawdził bym ten "nowy"...noale ja Widziarz jestem więc progsy mam pod Windę do sprawdzania :)

Osobiście użyłbym

Jakiś Kaczin nie zrozumiał tylko i się dopierdolił retorycznie. Pewnie ma tak w defaulcie i musi z tym żyć :]

W dniu 10.10.2022 o 22:53, Kaczin pisze:

Sryczne. Zwyczajnie nie zrozumiałeś, że z mojej strony to była sugestia, o czym napisałem w pierwszym zdaniu w pierwszej odpowiedzi na pytanie OPa.

...CBDU :)

Musisz odejść, jeszcze jest bezpiecznie... :]

Można też wyzerować najpierw wolne miejsce a potem dodatkowo taki obraz spakować, ale to pozbawia możliwości bezposredniego podmontowania.

No dd to nie, ale taki rsync? Mi tam robi kopie przyrostowe bez kasowania poprzednich.

Juz się parę razy przymierzałem, ale problem jest taki, ze musisz mieć tego borga wszędzie. A takie dd wszędzie już jest. Padnie mi system, wystaruje z jakiegoś live bez dostepu do Internetu ale czy tam będzie w podstawowej dystrybucji borg? Chyba nie będzie. No i będzie kłopot.

?? Ogromny zysk. Rsync po rsyncu na bieżąco fsa z 500tys plików przez Internet (nie lokalnie) trwa kilkadziesiąt sek. Robienie dumpa całości w moim przypadku to godziny. To, że czyta całość to zaleta, bo wtedy wcześniej wychodzą ewentulane problemy z dyskiem. Nie ma nic lepszego niż rsync, reszta to protezy.

Ale tworzenie obrazu to długa operacja, poza tym tworzenie obrazu dd jest bez sensu gdy fs jest np. w 1% zajęty lub ma pliki z dziurami. Dd tego nie zoptymalizuje.

Jak nie rsync pozwala? Opcja compare-dest, tworzy dumpy różnicowe. Mam możliwość odtworzenia wszystkich wersji zmian w plikach w dowolnym czasie. Świat się dzieli tylko na tych co używają rsync i tych, którzy będą go używać w przyszłości. Żadne inne protezy.

Hehe, skąd ja to znam :)

Ale po co tak kombinować jak można prościej i na natywnym FS? Opcja z vm IMHO jest opcją ostateczną, w której os hosta nie jest już w stanie uruchomić binariów.

Nie rozumiem. Backupy to nie tylko kopie plików "systemowych" dostępnych powszechnie ale też własne. Często nieporównywalnie większe od OSa. Nie backupujesz własnych tworów?

Kluczowy jest stan os'a obecny jaki się używa (z dodatkami, poprawkami itp) a nie waniliowy tuż po instalacji. Taki dla mnie jest nieużywalny, ergo koszt postawienia wszystkiego od nowa + dostosowanie jest zbyt kosztowny *dlatego* szybciej odtwarza się go z backupu.

Oczywiście, jeśli masz wąskie gardło między źródłem a celem, to podejście przyrostowe jest istotnie szybsze. Wcześniej nic nie pisałeś o backupach przez internet więc odniosłem się do sytuacji stricte lokalnej. Ale i tu BORG jest lepszy od rsync, bo dodatkowo deduplikuje i kompresuje.

Z tym nie będę polemizował, bo wkraczamy już w obszar religii.

Zależy od nośnika i stanu FSa. Przy magnetycznych talerzach, taki sekwencyjny dd potrafi być znacząco szybszy od kopiowania milionów porozrzucanych plików.

Ano, dlatego pisałem, że samo dd ogólnie słabe jest, jeśli o backupy chodzi. Można natomiast połączyć dd z BORGiem, wtedy wychodzi nam bardzo eleganckie rozwiązanie. Albo użyć BORGa bez dd, jeśli sama struktura FSa nas nie interesuje.

Niezupełnie. compare-dest kopiuje po prostu pliki, które uległy zmianie, kopiując je w całości, czyli mają plik gigabajtowy, w którym zmienił się tylko jeden bajt, w kopii przyrostowej rsync-a pojawi się cały gigabajt.

Przez parę lat używałem rsynca, ale świat idzie do przodu i obecnie istnieją dużo fajniejsze rozwiązania. Najpierw z rsynca przeskoczyłem na rdiff-backup, a później z rdiff-backup na BORG. Przy czym poniekąd masz rację, bo w obu tych rozwiązaniach rsync jest zaszyty.

Mateusz

Oczywiście, jeśli masz wąskie gardło między źródłem a celem, to podejście przyrostowe jest istotnie szybsze. Wcześniej nic nie pisałeś o backupach przez internet więc odniosłem się do sytuacji stricte lokalnej. Ale i tu BORG jest lepszy od rsync, bo dodatkowo deduplikuje i kompresuje.

Z tym nie będę polemizował, bo wkraczamy już w obszar religii.

Zależy od nośnika i stanu FSa. Przy magnetycznych talerzach, taki sekwencyjny dd potrafi być znacząco szybszy od kopiowania milionów porozrzucanych plików.

Ano, dlatego pisałem, że samo dd ogólnie słabe jest, jeśli o backupy chodzi. Można natomiast połączyć dd z BORGiem, wtedy wychodzi nam bardzo eleganckie rozwiązanie. Albo użyć BORGa bez dd, jeśli sama struktura FSa nas nie interesuje.

Niezupełnie. compare-dest kopiuje po prostu pliki, które uległy zmianie, kopiując je w całości, czyli mają plik gigabajtowy, w którym zmienił się tylko jeden bajt, w kopii przyrostowej rsync-a pojawi się cały gigabajt.

Przez parę lat używałem rsynca, ale świat idzie do przodu i obecnie istnieją dużo fajniejsze rozwiązania. Najpierw z rsynca przeskoczyłem na rdiff-backup, a później z rdiff-backup na BORG. Przy czym poniekąd masz rację, bo w obu tych rozwiązaniach rsync jest zaszyty.

Mateusz

Kombinujesz trochę aby potem nie kombinować wielokrotnie i dużo.

Zysk jest w tym jak łatwo potem backupować taki vm.

Kwestia wyobraźni: czy zrobienie raz vm jest droższe niż robienie kilka razy (nie wiadomo ile) kopiowania backupu licząc się z tym, że i tak zrobisz kiedyś vm bo hardware zdechnie.

Relatywnie dużo firm wrzuca stwoje stare systemy budowania do vm tylko dlatego, że to ułatwia im zycie na nastepne 30 lat.

Domyślnie: OSa.

Dane, jak wspomniałem, są separowane od systemu. A do "backupowania" codziennego danych używam systemu kontroli wersji, zaś do sporadycznego, backupu offline w innej lokalizacji.

Nie zakładaj, że backup OSa to backup prywatych danych przy okazji. Jeśli trzymasz higienę, to dwie rózne rzeczy, rozwiązywane na różne sposoby.

Mam odwrotne doświadczenia. Koszt zaktualizowania Win10 ze starego backupu to 2 doby mielenia dyskiem przez ten gówniany update z MS, kilka restartów, kopania w dupę update żeby to przyśpieszyć i na końcu jakiś wesoły konflikt wymagający kernelowania kompili i gmerania w szabie o nazwie internet na forach, gdzie radzą restartować i sprawdzać czy wtyczka włożona do gniazdka. Przerabiałem to dostatecznie często i stwierdziłem, że koszty są wyższe niż stawianie od zera.

Instalacja z nośnika wygenerowanego przed chwilą na innej maszynie nie robi takich problemów.

Dodatkwoo mogę pracować w trakcie setupu innych tooli. Można częściowo uznać, że instalacja mniej ważnych tooli robi się w tle.

I to ogromna wada. Parafrazując Theodore Levitt'a "ludize nje chcą kupować ćwierć calowego wiertła tylko chca mieć ćwierć calową dziurę" ja nie potrzebuje backuou (tym bardziej zamkniętego w jakimś formacie) tylko kopii pliku, do którego muszę mieć jak najszybszy dostęp. W sytuacji krytycznej gdy dostęp do danych musi być w sekundach, ręcznie pliku nie wyciągnę bez tego borga. Dane w backupie maja być dostępne bez rękawiczek, bez narzędzi, tylko natywnym cp, Jacek już Ci to wcześniej słusznie wykazał. Jawnie kopia FS jest najszybszym źródłem dostępu do poszczególnego pliku.

Jak najbardziej właśnie mnie interesuje. Mam tylko sekundy na wyciągnięcie pliku z backupu bez rękawiczek.

Nie, rync wspiera takie sytuacje (inplace /sparse) kopiujac tylko zmienione bloki lub jeśli plik ma dziury (np. obrazy vm) również dziury nie przenosi. Wbrew tego co zasugerowałeś rsync również się rozwija.

Cały czas próbuje Ci to wykazać.

Oczywiście, jeśli masz wąskie gardło między źródłem a celem, to podejście przyrostowe jest istotnie szybsze. Wcześniej nic nie pisałeś o backupach przez internet więc odniosłem się do sytuacji stricte lokalnej. Ale i tu BORG jest lepszy od rsync, bo dodatkowo deduplikuje i kompresuje.

Z tym nie będę polemizował, bo wkraczamy już w obszar religii.

Zależy od nośnika i stanu FSa. Przy magnetycznych talerzach, taki sekwencyjny dd potrafi być znacząco szybszy od kopiowania milionów porozrzucanych plików.

Ano, dlatego pisałem, że samo dd ogólnie słabe jest, jeśli o backupy chodzi. Można natomiast połączyć dd z BORGiem, wtedy wychodzi nam bardzo eleganckie rozwiązanie. Albo użyć BORGa bez dd, jeśli sama struktura FSa nas nie interesuje.

Niezupełnie. compare-dest kopiuje po prostu pliki, które uległy zmianie, kopiując je w całości, czyli mają plik gigabajtowy, w którym zmienił się tylko jeden bajt, w kopii przyrostowej rsync-a pojawi się cały gigabajt.

Przez parę lat używałem rsynca, ale świat idzie do przodu i obecnie istnieją dużo fajniejsze rozwiązania. Najpierw z rsynca przeskoczyłem na rdiff-backup, a później z rdiff-backup na BORG. Przy czym poniekąd masz rację, bo w obu tych rozwiązaniach rsync jest zaszyty.

Mateusz