RTV forum PL | NewsGroups PL

Kopia dysku

NOWY TEMAT

elektroda NewsGroups Forum Index - Elektronika Polska - Kopia dysku

Goto page Previous  1, 2, 3, 4, 5  Next

Marek
Guest

Wed Oct 12, 2022 5:43 am   





Marek
Guest

Wed Oct 12, 2022 6:09 am   



On Tue, 11 Oct 2022 20:09:45 +0200, jacek pozniak
<jacek.pozniak@flowservice.pl> wrote:
Quote:
Na przykład, mam stary kompilator do piców chodzący na wine, do
którego w
zawieruchach dziejowych pogubiłem klucze.

Hehe, skąd ja to znam :)

--
Marek

Marek
Guest

Wed Oct 12, 2022 6:14 am   



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

Marek
Guest

Wed Oct 12, 2022 6:21 am   



On Tue, 11 Oct 2022 13:09:29 +0200, heby <heby@poczta.onet.pl> wrote:
Quote:
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?


Quote:
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

Mateusz Viste
Guest

Wed Oct 12, 2022 7:29 am   



2022-10-12 o 07:43 +0200, Marek napisał:
Quote:
On Tue, 11 Oct 2022 14:19:26 +0200, Mateusz Viste
mateusz@xyz.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.

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

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

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

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

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

Quote:
Ś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

Mateusz Viste
Guest

Wed Oct 12, 2022 7:33 am   



2022-10-12 o 07:43 +0200, Marek napisał:
Quote:
On Tue, 11 Oct 2022 14:19:26 +0200, Mateusz Viste
mateusz@xyz.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.

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

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

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

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

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

Quote:
Ś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

heby
Guest

Wed Oct 12, 2022 7:33 am   



On 12/10/2022 08:14, Marek wrote:
Quote:
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.

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

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

heby
Guest

Wed Oct 12, 2022 7:41 am   



On 12/10/2022 08:21, Marek wrote:
Quote:
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.

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

Marek
Guest

Wed Oct 12, 2022 8:20 am   



On Wed, 12 Oct 2022 09:29:53 +0200, Mateusz Viste
<mateusz@xyz.invalid> wrote:
Quote:
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.

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

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

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

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

--
Marek

Mateusz Viste
Guest

Wed Oct 12, 2022 8:25 am   



2022-10-12 o 07:43 +0200, Marek napisał:
Quote:
On Tue, 11 Oct 2022 14:19:26 +0200, Mateusz Viste
mateusz@xyz.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.

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

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

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

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

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

Quote:
Ś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

Mateusz Viste
Guest

Wed Oct 12, 2022 8:27 am   



2022-10-12 o 07:43 +0200, Marek napisał:
Quote:
On Tue, 11 Oct 2022 14:19:26 +0200, Mateusz Viste
mateusz@xyz.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.

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

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

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

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

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

Quote:
Ś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

Mateusz Viste
Guest

Wed Oct 12, 2022 8:31 am   



2022-10-12 o 07:43 +0200, Marek napisał:
Quote:
On Tue, 11 Oct 2022 14:19:26 +0200, Mateusz Viste
mateusz@xyz.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.

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

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

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

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

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

Quote:
Ś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

jacek pozniak
Guest

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

jacek pozniak
Guest

Wed Oct 12, 2022 9:00 am   



heby wrote:

Quote:

Trzeba było nie brać PICów, tak vendor-lockin a w zasadzie to tool-lockin
Razz
Zaszłości historyczne. Chociaż teraz sobie chwalę bo są w miarę dostępne, w

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

jp


--
jp

www.flowservice.pl
www.flowsystem.pl

Mateusz Viste
Guest

Wed Oct 12, 2022 9:14 am   



2022-10-12 o 10:20 +0200, Marek napisał:
Quote:
Dane w backupie maja być dostępne bez rękawiczek, bez narzędzi, tylko
natywnym cp,

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

Quote:
Mam tylko sekundy na
wyciągnięcie pliku z backupu bez rękawiczek.

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

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

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.

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

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

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

Goto page Previous  1, 2, 3, 4, 5  Next

elektroda NewsGroups Forum Index - Elektronika Polska - Kopia dysku

NOWY TEMAT

Regulamin - Zasady uzytkowania Polityka prywatnosci Kontakt RTV map News map