Re: Backup za free poprzez LAN

Michal Kawecki schrieb:
> Użytkownik "Tomasz Chmielewski" <tch@nospam.unc.edu> napisał w
> wiadomości news:d8jaut$gem$1@newsreader3.netcologne.de...
>
>>Michal Kawecki schrieb:
>>
>>>Bo tamte programy działają na zupełnie innej zasadzie. Tutaj
>>>odcinana jest całkowicie możliwość wprowadzania zmian w obszarze
>>>rejestrującym modyfikacje położenia i atrybutów plików do
>>>momentu zakończenia backupu. To jest prawdziwy *snapshot*, a nie
>>>jego namiastka jaką robią programy do backupu, niechby i
>>>profesjonalne...
>>
>>no to niewatpliwie ciekawe rozwiazanie w takim razie.
>
>
> Jest to na pewno forma backupu danych wbrew temu co twierdził ktoś w
> tej dyskusji (Konrad?), i to pod wieloma względami lepsza forma niż
> wiele profesjonalnych programów backupujących dane. Programik ten ma
> wbudowaną bardzo szybką i prostą w obsłudze przeglądarkę obrazów,
> zintegrowaną z powłoką systemu, w związku z czym można spokojnie
> powiedzieć że operuje on na plikach - bo są one dla usera w prosty
> sposób osiągalne. Jedyną jego wadą jest konieczność backupu całej
> partycji a nie tylko wybranych katalogów z danymi, co niestety wiąże
> się z wielkością utworzonych obrazów. Sam proces tworzenia backupu

to "dosyc" istotna wada dla wiekszosci rozwiazac :)

> jest bardzo szybki - w granicach kilku minut dla partycji o wielkości
> 10 GB wypełnionej w 80 % danymi.
>
> P.S. Żałuję niestety że pod Linuksa nie ma takich narzędzi i muszę
> niestety co jakiś czas swój serwerek na czas backupu danych wyłączać.

a nie wystarczy uzyc narzedzi do backupu twojej bazy?
skoro juz wylaczasz serwer, to rownie dobrze mozesz wylaczyc sama baze
danych.

> Ale co się dziwić, skoro zamiast zająć się rozwojem rozwiązań
> przeznaczonych dla profesjonalistów skupiono się na aspiracjach w
> kierunku desktopu dla pospólstwa... BP, MSPANC ;-).

no, nie zgodze sie, bys troche posiedzial, pomyslal, i bys cos
wyprodukowal do backupu w postaci 10 linijkowego skryptu.

1) Linuksa mozesz odtworzyc z samych plikow - po prostu kopiujesz je na
nowy dysk, instalujesz bootloader, i system dziala

- na razie dwie linijki

2) te pliki, ktorych nie mozna zarchiwizowac "w locie", naleza zazwyczaj
do jakiejs bazy danych - takie maja specjalne narzedzia do tego

- trzecia linijka skryptu

3) po co ci obraz 30 GB czegos, co ma baze danych 8 MB (dajmy na to, 100
MB - dane, ktore zmieniaja sie naprawde)? jest to nawyk ludzi
uzywajacych "Ghosta / super / bakapa" pod Windowsami, i przenoszacymi te
nawyki pod Linuksa.

naprawde podchodzisz do tego "nie z glowa".

u nas w firmie zajmujemy sie wlasnie podobnym tematem. klientami sa
firmy majace oddzialy (20 i wiecej) w calym kraju, ktore nie chca
zatrudniac informatyka (20 * minimum 2000 euro (w Niemczech) za
informatyka na pol etatu, troche wychodzi oszczednosci miesiecznie).

nie ma bolu, ze jak serwer wysypie sie w jakims oddziale, to firma
straci iles pieniazkow, bo nie bedzie mozna pracowac.
w takim awaryjnym wypadku pani Ania wklada DVD do serwera, wpisuje IP,
nazwe komputera, i za 20 minut nowy serwer stoi (partycje zakladane od
nowa, badblocki sie skanuja, pliki sie kopiuja, bootloader sie
instaluje, baza danych + ostatni backup sciaga sie przez internet po
instalacji).
i nie jest to jakis high-tech software, ot po prostu skrypt 1000 bajtow
czy cos w tym stylu.

i naprawde nie widze powodu, ze u ciebie takie cos nie mialoby zadzialac
- po prostu musisz pomyslec jak to zrobic, i zrobic to - bo jak widze, z
tym backupem obrazow to zabierasz sie troche od d. strony :)

>>ale jak zmienimy cos w srodku jednego z takich plikow (dwa bajty),
>>to od tego srodka do konca bedzie dociagane do konca (o ile sie
>>jasno wyrazilem).
>
>
> ZTCW mylisz się. Nawet we wstępie do opisu algorytmu rsync napisano,
> że (cytuję):
>
> "This report presents an algorithm for updating a file on one machine
> to be identical to a file on another machine. We assume that the two
> machines are connected by a low-bandwidth high-latency bi-directional
> communications link. The algorithm identifies parts of the source file
> which are identical to some part of the destination file, and only
> sends those parts which cannot be matched in this way. Effectively,
> the algorithm computes a set of differences without having both files
> on the same machine. The algorithm works best when the files are
> similar, but will also function correctly and reasonably efficiently
> when the files are quite different."
> http://rsync.samba.org/tech_report/

hmm, moze.
kiedys to testowalem w ten sposob:
- sciagam duzy plik przez ftp
- wyciagam wtyczke (uszkodzony koniec pliku)
- dociagam do konca dalej ftp

czyli sytuacja mniej wiecej taka, jak opisalem wczesniej ("zmienione dwa
bajty w srodku").
po takim czyms rsync dociagal plik mniej wiecej od momentu "wyciagniecia
wtyczki" - a wg. tego opisu, powinien dociagnac same "zmiany" - czyli
pare bajtow / kilobajtow / megabajtow uszkodzonych przez wyciagniecie
wtyczki.

ale byc moze cos robilem nie tak :)

-- 
Tomek