On Tue, 11 Oct 2022 21:03:26 +0200, heby <h...@p...onet.pl> wrote:
> 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ć.

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

do góry

On Tue, 11 Oct 2022 13:09:29 +0200, heby <h...@p...onet.pl> wrote:
> Jakiś czas temu robiłem backupy.

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?


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

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

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

do góry

2022-10-12 o 07:43 +0200, Marek napisał:
> On Tue, 11 Oct 2022 14:19:26 +0200, Mateusz Viste
> <m...@x...invalid> wrote:
> > Oszczędzasz na kopiowaniu (zapisie), ale czytać i tak musisz wszy
> > stko,
> > i to dwa razy, tzn. obie strony, więc to wcale nie taki oczywisty
> > zysk.
>
> ?? Ogromny zysk. Rsync po rsyncu na bieżąco fsa z 500tys plików przez
> Internet (nie lokalnie)

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.

> Nie ma nic lepszego niż rsync, reszta to protezy.

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

> Ale tworzenie obrazu to długa operacja

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.

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

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.

> Jak nie rsync pozwala? Opcja compare-dest, tworzy dumpy różnicowe.

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.

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

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

do góry

2022-10-12 o 07:43 +0200, Marek napisał:
> On Tue, 11 Oct 2022 14:19:26 +0200, Mateusz Viste
> <m...@x...invalid> wrote:
> > Oszczędzasz na kopiowaniu (zapisie), ale czytać i tak musisz wszy
> > stko,
> > i to dwa razy, tzn. obie strony, więc to wcale nie taki oczywisty
> > zysk.
>
> ?? Ogromny zysk. Rsync po rsyncu na bieżąco fsa z 500tys plików przez
> Internet (nie lokalnie)

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.

> Nie ma nic lepszego niż rsync, reszta to protezy.

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

> Ale tworzenie obrazu to długa operacja

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.

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

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.

> Jak nie rsync pozwala? Opcja compare-dest, tworzy dumpy różnicowe.

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.

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

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

do góry

On 12/10/2022 08:14, Marek wrote:
>> 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ć.
> Ale po co tak kombinować

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

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

> jak można prościej i na natywnym FS?

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.

> Opcja z vm
> IMHO jest opcją ostateczną, w której os hosta nie jest już w stanie
> uruchomić binariów.

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

do góry

On 12/10/2022 08:21, Marek wrote:
>> Jakiś czas temu robiłem backupy.
> 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?

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.

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

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.

do góry

On Wed, 12 Oct 2022 09:29:53 +0200, Mateusz Viste
<m...@x...invalid> wrote:
> lokalnej. Ale i tu BORG jest lepszy od rsync, bo dodatkowo
> deduplikuje
> i kompresuje.

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.

> ssama struktura
> FSa nas nie interesuje.

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

> 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 rs
> ync-a
> pojawi się cały gigabajt.

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.

> masz rację, bo w obu tych rozwiązaniach rsync jest zaszyty.

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

--
Marek

do góry

2022-10-12 o 07:43 +0200, Marek napisał:
> On Tue, 11 Oct 2022 14:19:26 +0200, Mateusz Viste
> <m...@x...invalid> wrote:
> > Oszczędzasz na kopiowaniu (zapisie), ale czytać i tak musisz wszy
> > stko,
> > i to dwa razy, tzn. obie strony, więc to wcale nie taki oczywisty
> > zysk.
>
> ?? Ogromny zysk. Rsync po rsyncu na bieżąco fsa z 500tys plików przez
> Internet (nie lokalnie)

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.

> Nie ma nic lepszego niż rsync, reszta to protezy.

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

> Ale tworzenie obrazu to długa operacja

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.

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

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.

> Jak nie rsync pozwala? Opcja compare-dest, tworzy dumpy różnicowe.

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.

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

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

do góry

2022-10-12 o 07:43 +0200, Marek napisał:
> On Tue, 11 Oct 2022 14:19:26 +0200, Mateusz Viste
> <m...@x...invalid> wrote:
> > Oszczędzasz na kopiowaniu (zapisie), ale czytać i tak musisz wszy
> > stko,
> > i to dwa razy, tzn. obie strony, więc to wcale nie taki oczywisty
> > zysk.
>
> ?? Ogromny zysk. Rsync po rsyncu na bieżąco fsa z 500tys plików przez
> Internet (nie lokalnie)

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.

> Nie ma nic lepszego niż rsync, reszta to protezy.

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

> Ale tworzenie obrazu to długa operacja

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.

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

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.

> Jak nie rsync pozwala? Opcja compare-dest, tworzy dumpy różnicowe.

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.

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

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

do góry

2022-10-12 o 07:43 +0200, Marek napisał:
> On Tue, 11 Oct 2022 14:19:26 +0200, Mateusz Viste
> <m...@x...invalid> wrote:
> > Oszczędzasz na kopiowaniu (zapisie), ale czytać i tak musisz wszy
> > stko,
> > i to dwa razy, tzn. obie strony, więc to wcale nie taki oczywisty
> > zysk.
>
> ?? Ogromny zysk. Rsync po rsyncu na bieżąco fsa z 500tys plików przez
> Internet (nie lokalnie)

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.

> Nie ma nic lepszego niż rsync, reszta to protezy.

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

> Ale tworzenie obrazu to długa operacja

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.

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

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.

> Jak nie rsync pozwala? Opcja compare-dest, tworzy dumpy różnicowe.

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.

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

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

do góry