2022-10-12 o 13:38 +0200, Marek napisał:
> On Wed, 12 Oct 2022 10:25:15 +0200, Mateusz Viste
> <m...@x...invalid> wrote:
> > Oczywiście, jeśli masz wąskie gardło między ź
>
> 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?

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

do góry

2022-10-12 o 13:36 +0200, Marek napisał:
> On Wed, 12 Oct 2022 11:14:51 +0200, Mateusz Viste
> <m...@x...invalid> wrote:
> > Nie wykazujesz, tylko dogmatycznie i autorytatywnie stwierdzasz, że
> > rsync jest najlepszy, bo Ty go używasz. Jeśli Ci odpowiada to spo
> > ko,
> > niemniej jest to prymitywne narzędzie w porównaniu do alternatyw i
>
> Lol alternatyw, które i tak używają rsynca... Co za lame..

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 góry

On Wed, 12 Oct 2022 14:07:11 +0200, Adam <a...@p...onet.pl> wrote:
> Po co te złośliwości?

Do rozgrzania atmosfery :).

--
Marek

do góry

On Wed, 12 Oct 2022 14:26:09 +0200, jacek pozniak
<j...@f...pl> wrote:
> Ale niedawno kolega mnie pytał o 18f25k22-i/so i "moja" Chinka
> podała mi
> cenę 4,62USD.

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

--
Marek

do góry

2022-10-12 o 00:24 GMT, Marcin Debowski napisał:
> 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.

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

do góry

On 2022-10-12, Mateusz Viste <m...@x...invalid> wrote:
> 2022-10-12 o 00:24 GMT, Marcin Debowski napisał:
>> 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.
>
> 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ą.

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?

--
Marcin

do góry

2022-10-15 o 00:31 GMT, Marcin Debowski napisał:
> > 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ą.
>
> 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
90%, to BORG potrafi to wykryć i zapisuje 90% ich zawartości tylko raz.

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

do góry

On 2022-10-15, Mateusz Viste <m...@x...invalid> wrote:
> 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.

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.

--
Marcin

do góry

Dnia Wed, 12 Oct 2022 14:17:54 +0200, heby napisał(a):

> On 12/10/2022 14:01, Adam wrote:
>> Podniesienie jednym ruchem wersji kompilacji Win10 z nawet kilkuletniej do
>> aktualnej, to w zasadzie minuty, nie godziny.
>
> 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.

Ty praktykowałeś (tak można zrozumieć Twój wpis) jeden raz, miesiąc temu.
A ja to robię u klientów co jakiś czas. W zasadzie od Windows 98, bo Win NT
3.5 oraz 4.0, Win 98 oraz Windows for Workgroups 3.11 nie wymagały
aktualizacji, poza sporadycznymi SP.

Jeśli nie umiesz inaczej, spróbuj chociażby podnosić wersję za pomocą WSUS
Offline.

>
>> 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.
>
> 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).
>
>> Miewałem klientów, którzy na jednym stanowisku mieli blisko 50 różnych
>> liencji komercyjnych.
>
> 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.

Jakoś nie zauważyłem, aby ktoś pisał o archiwizacji bądź backupie
(odróżniasz?) w aspekcie tylko jednego zainstalowanego w systemie programu.
Ale nie czytałem dokładnie, może przeoczyłem.


--
Pozdrawiam.

Adam

do góry

On 20/10/2022 09:28, Adam wrote:
>> 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.
> Ty praktykowałeś (tak można zrozumieć Twój wpis) jeden raz, miesiąc temu.

Jeden przykład obala twierdzenie, że to bezproblemowe i trwa minuty.

Nie jeden raz. Ale jeden raz miesiąc temu miałem problem z Win10, który
ponoć miał trwać "minuty".

> A ja to robię u klientów co jakiś czas. W zasadzie od Windows 98, bo Win NT
> 3.5 oraz 4.0, Win 98 oraz Windows for Workgroups 3.11 nie wymagały
> aktualizacji, poza sporadycznymi SP.

Sprawdź wiec czy da się podnieść WindowsXP z pierwszej wersji do SP3 za
pomocą update i bez ingerencji, skoro powołujesz się na wykopaliska.

To samo zrób z Vistą, tam jeszcze wiecej przygód, wliczajac w to
samodestrukcję update przez update do update. Wymaga wklepania kilku
komend w konsolę, jak u byle pryszczatych linuksiarzy aby w ogóle
przywrócić tą funkcję.

Podziel się doświadczeniami.

Podpowiem: mi na kilkadziesiąt prób, nigdy się nie udało bez problemu
podnieśc systemu na taką odległość jak ~rok. Dotyczyło to czystych
systemów i różnych hardware. MS nie ma technologii pozwalajacej na
głeboki update. Maja tylko w miarę działajace "codzienne". Zwyczajowo to
drobne duperele, które nie rozwalaja pracy, ale generują interesujace
efekty specjalne. Jak mój ulubiony bootloop z XP, albo crash na
instalacji pierwszego XP po otwarciu przeglądarki (crashuje strona
domowa MS).

Update z Microsoftu to najgorsze guano jakie widziałem w świecie OSów.
Działa dobrze tylko, jesli jest non-stop online.

Dev od update z XP przyznał sie kiedyś na forum, że "sorry, ale przez
przypadek wyszła nam złożonośc kwadratowa" czy coś w ten deseń, ale
równie zabawne. Nie naprawili w XP. W Viście chyba też nie. W 7 i 10
przypudrowali.

> Jeśli nie umiesz inaczej, spróbuj chociażby podnosić wersję za pomocą WSUS
> Offline.

Robię to właśnie *DLATEGO*, że update MS jest taki gówniany. I robi się
tym bardziej gówniany im więcej zbiera sie updates do instalacji.

WSUS Offline niestety nie zawsze działa. Działa jednak lepiej niż
wypociny MS.

Przyznaje: w Win7 troszeczkę to poprawili, w windows 10 troche wiecej.
Zaryzykuję, że głównie z powodu ograniczenia ilości restartów, gdzie
najczęsciej dochodziło do katastrof.

Ale to nadal ten sam, poputy update. Kończy się kernelowaniem kompili
jeśli odpowiedniu długo pozwolisz mu nie robić się samemu.

> Jakoś nie zauważyłem, aby ktoś pisał o archiwizacji bądź backupie

Trzeba uważniej czytać pierwszego posta:

"[...] zabezpieczyć na wypadek awarii, tak aby
mieć możliwość szybkiego przywrócenia funkcjonalności, bez potrzeby
instalacji wszystkiego od początku."

> (odróżniasz?)

Archiwizacja i backup nie mają wyraźnej granicy, jeśli pracujesz na VM.

To że miesiac temu miałem złe doświadczenie z Win10, nie oznacza, że to
było jedyne doświadczenie. Mam je na tyle często i od tak dawna, że
instalacja OSa na czysto stała się równorzędnym rozwiązaniem nad męki z
gównianym update MS. Zaczynajac od Millenium, co zostanie traumą do
końca żywota mego.

do góry