Jak stworzyć pełen obraz dysku twardego Linux za pomocą polecenia dd?

Wed Oct 12, 2022 5:43 am   

Wed Oct 12, 2022 6:09 am   

On Tue, 11 Oct 2022 20:09:45 +0200, jacek pozniak
<jacek.pozniak@flowservice.pl> wrote:

Hehe, skąd ja to znam :)

--
Marek

Wed Oct 12, 2022 6:14 am   

On Tue, 11 Oct 2022 21:03:26 +0200, heby <heby@poczta.onet.pl> wrote:

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.

--
Marek

Wed Oct 12, 2022 6:21 am   

On Tue, 11 Oct 2022 13:09:29 +0200, heby <heby@poczta.onet.pl> wrote:

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.

--
Marek

Wed Oct 12, 2022 7:29 am   

2022-10-12 o 07:43 +0200, Marek napisał:

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

Wed Oct 12, 2022 7:33 am   

2022-10-12 o 07:43 +0200, Marek napisał:

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

Wed Oct 12, 2022 7:33 am   

On 12/10/2022 08:14, Marek wrote:

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.

Wed Oct 12, 2022 7:41 am   

On 12/10/2022 08:21, Marek wrote:

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.

Wed Oct 12, 2022 8:20 am   

On Wed, 12 Oct 2022 09:29:53 +0200, Mateusz Viste
<mateusz@xyz.invalid> wrote:

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ć.

--
Marek

Wed Oct 12, 2022 8:25 am   

2022-10-12 o 07:43 +0200, Marek napisał:

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

Wed Oct 12, 2022 8:27 am   

2022-10-12 o 07:43 +0200, Marek napisał:

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

Wed Oct 12, 2022 8:31 am   

2022-10-12 o 07:43 +0200, Marek napisał:

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

Wed Oct 12, 2022 8:50 am   

No, na pewno jakiegoś liveCD/USB użyję tak aby system przed wykonywaniem
kopi nie uruchomił się z mojego obecnego dysku.

jp

Wed Oct 12, 2022 9:00 am   

heby wrote:


niewygórowanych cenach; te które wykorzystuję. :-)

jp


--
jp

www.flowservice.pl
www.flowsystem.pl

Wed Oct 12, 2022 9:14 am   

2022-10-12 o 10:20 +0200, Marek napisał:

Serwer backupowy ma BORGa, i nic więcej nie potrzeba do wyciągnięcia
danego pliku z danego okresu. Ba, nie musisz nawet używać poleceń
BORGa, tylko skorzystać z podmontowanego backupu FUSE-em jeśli
koniecznie musisz widzieć pliki "normalnie".


Jeśli musisz ręcznie wyciągać pliki ze zdalnego backupu w okienku
*sekund*, to coś robisz bardzo źle. Ale tak czy inaczej niczego to nie
zmienia w perspektywie "BORG vs kopiowanie plików".


W opisywanym kontekście to raczej filesystemy się rozwijają. Na
serwerze backupowym musisz do tego mieć odpowiedni system plików,
wspierający CoW - typowo BTRFS, bo taki np. ext4 odpada.


Nie wykazujesz, tylko dogmatycznie i autorytatywnie stwierdzasz, że
rsync jest najlepszy, bo Ty go używasz. Jeśli Ci odpowiada to spoko,
niemniej jest to prymitywne narzędzie w porównaniu do alternatyw i
wymaga rzeźbienia, żeby uzyskać w przybliżeniu to, co faktyczne
rozwiązania backupowe proponują w standardzie.

Mateusz