Kopia dysku

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

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

jp

Zaszłości historyczne. Chociaż teraz sobie chwalę bo są w miarę dostępne, w niewygórowanych cenach; te które wykorzystuję. :-)

jp

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

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

Lol alternatyw, które i tak używają rsynca... Co za lame..

I tak ile razy będziesz tego posta wysyłał? Zakładam, że również czytnik jaki używasz równie nowoczesny jak ten borg?

O jakich mowa? Pilnie szukam 18f26k22 ostatecznie 18f26k20. Próbowałem kilka razy na aliex ale po kliknięciu odpisują sorry, nie ma.

Dnia Wed, 12 Oct 2022 09:41:48 +0200, heby napisał(a):

Podniesienie jednym ruchem wersji kompilacji Win10 z nawet kilkuletniej do aktualnej, to w zasadzie minuty, nie godziny.

Natomiast (z własnego doświadczenia) - instalacja programów, szukanie kluczy, w niektórych przypadkach wyrejestrowanie aktywnych licencji, aby je można było na nowo "przykleić", to droga przez mękę. Czasami proces awykonalny, bo np. nie wiadomo na kogo i jak były instalowane choćby głupie Office. A jak masz jedną licencję na pięć stanowisk, zamiast VLM, to już dupa blada. A to tylko początek problemów. Bo są jeszcze Adobe, bo są inne programy graficzne, muzyczne czy jakieć CAD-y. Chyba tylko programy do obsługi firm idą z marszu - np. Comarch Optima, CDN-XL, Enova. Aczkolwiek i tak przykładowo Symfonia wymaga ręcznego zrzucenia klucza u producenta. Podobne kołomyje są np. z AutoStacją - systemem do sprzedaży i serwisów samochodów.

Miewałem klientów, którzy na jednym stanowisku mieli blisko 50 różnych liencji komercyjnych. Teraz już raczej takich nie miewam, jest po kilka czy góra kilkanaście licencji.

Odtworzenie systemy z backupu to w zasadzie minuty, natomiast stawianie od nowa to godziny lub dłużej.

Lepiej jest w większych firmach czy szkołach, gdzie wszystko siedzi na Active Directory - wtedy kładzie się surowy Windows, a cała konfiguracja to wpisanie danych do logowania. Kilka minut roborty.

Dnia Wed, 12 Oct 2022 13:38:11 +0200, Marek napisał(a):

Po co te złośliwości?

Nie zgadzam się. Podniesienie z 1 wersji Win10 do aktualnej praktykowałem miesiąc temu. Kosztowało mnie to półtora dnia bezustannego mielenia update i na koniec zakończyło się błedem z wesołymi cyferkami o których google nie słyszało.

Masz inne potrzeby i inny zestaw programów. Ja piszę o mojej subiektywnej sytuacji, gdzie instalacja narzędzi robina jest inkrementalnie, w miarę potrzeby. U mnie to narzędzia głównie programistyczne. Ostatnio to ćwiczyłem kilka miesiący temu i narzędzia były gotowe w mniej niż 15 minut (kompilator, vcs, IDE).

Więc trudno mówić tu o sytuacji z tego wątku, gdzie kluczowy jest jeden kompilator do PICa i tyle. Wielu programistów będzie miało niewiele więcej potrzeb. A co bardziej zorientowani zauważą, że wiele programów przychodzi w wersji portable. A jeszcze bardziej dociekliwi zauważą, że wiele programów można zrobić portable.

Ja to głównie 16f1936 i 16lf1937.

Ale niedawno kolega mnie pytał o 18f25k22-i/so i "moja" Chinka podała mi cenę 4,62USD.

jp

Nie nie, tu zawiodło białko, czyli ja. Serwer Aioe miał rano jakąś czkawkę i twierdził, że nie udało mu się przyjąć mojego posta. I faktycznie - post się nie wyświetlał. A ja, zamiast przezornie sprawdzić na innym serwerze po prostu nalegałem i klikałem co jakiś czas do skutku... aż się spostrzegłem, że nagle mój post pojawił się kilka razy.

Czytelników grupy przepraszam za to drobne zamieszanie.

Mateusz

Używają rsynca (a śliślej - librsync) do tego, w czym jest dobry, czyli do zgrabnego wykrywania zmian w plikach.

Muszę tu jednocześnie wprowadzić drobną poprawkę do mojej wcześniejszej wypowiedzi: otóż z librsync korzystają rdiff-backup i BURP, ale BORG nie. Ten ostatni najwyraźniej ogarnął temat samodzielnie.

Mateusz

Do rozgrzania atmosfery :).

Daj jakiś kontakt do niej, to ktoś z AliExpress? Pewne źródło? Czy to te ruskie podrabiane pice?

BORGa masz na serwerze backupowym, i to wystarczy. Możesz traktować BORGa w kategorii "sprytnego storage", dzięki czemu Twoje dumpy z dd będą zabierały znacząco mniej miejsca na serwerze.

A kiedy będziesz potrzebował któregoś z tych obrazów dd, to albo wyciągasz go BORGiem na serwerze (a dalej tradycyjnie, na dyskietce czy co tam używasz), albo montujesz BORGa FUSE-em i eksportujesz zasób NFSem lub inną Sambą.

Mateusz

A ta kompresja to jest na poziomie bloków jakiegoś wewnętrznego systemu plików, skoro, jak napisałeś gdzieindziej, zmiana w dużym pliku nie oznacza jego nowej, pełnej kopii?

Nie tyle w wewnętrznym "systemie plików", co w sposobie, w jaki BORG trzyma dane (tj. formacie swojej bazy danych). Przy czym sama kompresja tak naprawdę niewiele daje. Dużo bardziej interesująca jest deduplikacja. Kiedy masz dwa pliki, których zawartość pokrywa się np. w

Masz natomiast rację w tym, że jest to podejście blokowe, poniekąd podobne zresztą do tego, które znamy z torrentów. Deduplikacja działa tak, że BORG każdy plik dzieli na bloki. Dla każdego bloku oblicza hash i taką parę HASH=BLOK sobie zapisuje w swojej bazie. Jeśli widzi, że hash o takiej wartości już wcześniej wystąpił, to nie zapisuje go kolejny raz, tylko trzyma odnośnik do niego. Co istotne: nieważne, czy blok pochodzi z tego samego pliku, czy z dwóch różnych, czy nawet z różnych źródeł lub różnych okresów backupu: BORG trzyma go tylko raz.

Czyli jeśli mam gigabajtowy plik wideo, który sobie skopiuję na dysk pod inną nazwą, potem wyślę na laptop żony, i dodatkowo zapiszę na domowym NASie, to po backupach tych trzech komputerów w bazie BORGa plik nadal będzie zapisany tylko raz, a nie 4x jak to miałoby miejsce przy konwencjonalnym podejściu.

Do tego deduplikacja zachodzi już na kliencie, czyli zamiast wysyłać całość danych do serwera backupowego, klient BORGa wysyła mu listę znalezionych plików, i dla każdego pliku listę bloków (hashy), z których się składa. Serwer wówczas pyta tylko o te bloki, których jeszcze nie zna, dzięki czemu wysyłamy relatywnie mało danych (dużo mniej, niż wysłałby rsync).

BORG daje też fajny podgląd na to, jak skuteczny jest każdy z etapów. Tutaj przykład obecnego stanu mojego repo:

------------------------------------------------------------------ Original size Compressed size Deduplicated size All archives: 2.32 TB 1.87 TB 110.30 GB

Unique chunks Total chunks Chunk index: 575'596 12'846'752

------------------------------------------------------------------

Takie repo można zamontować (read-only) borgfs-em, wówczas użytkownik widzi normalną strukturę katalogów, a borgfs zajmuje się w tle odpowiednim mapowaniem danych.

Mateusz

Dzięki za objaśnienia. Chyba się faktycznie skuszę, bo w końcu to może funkcjonować równolegle do innych rodzajów archiwizacji, a ja mam to de facto już w tej chwili zorganizowane jako struktura na serwerze typu klient-serwer.

A sam pomysł kompresji ciekawy. Tak mi się trochę kojarzy z kompresją międzyramkową wideo, gdzie kolejne bloki pierwotnego (oryginalnego) pliku, przy jego kolejnych kopiach, byłyby porównywane i kompresowane na zasadzie I-frame i P-frames.