🚀 go-pugleaf

W dniu 15.08.2016 o 20:52, Jan Stożek pisze:
> Witam,
>
> 	Mam backup zrobiony na rsyncu: frontend (back-in-time) + rsync
> w tle. Backup chodzi w sposób dość skomplikowany, bo najpierw tworzy
> rsynkiem hardlinkowaną "kopię" poprzedniego backupu (drzewo katalogów
> + hardlinki do ostatniej wersji plików), a potem również rsynkiem
> nadpisuje ją nowszymi wersjami tych plików, które zostały zmienione.
> Wygląda to dość skomplikowanie, ale jest skuteczne i od dwóch lat
> działało bez zarzutu: mam szereg kompletnych "obrazów" kopiowanych
> folderów, a przy tym zajętość miejsca jest taka, jakby była kopia
> pełna i odpowiednia liczba kopii różnicowych. No i jest to szybkie, bo
> poza pierwszą kopią, która wymaga skopiowania wszystkich danych,
> kolejne kopie są robione dosłownie w ciągu kilku minut (ostatnio -
> około ośmiu).
>
> 	Teraz problem, który nastąpił dziś: po godzinie pracy backupu
> zauważyłem, że rsynk nadal chodzi - zajmuje dość dużo procesora
> (procesor mam całkowicie obciążony), ale niczego nie pisze na dysku.
> Przebutowałem, wyczyściłem foldery robocze - ale kolejna próba backupu
> doprowadziła do tego samego efektu trwającego wiele godzin: procesor
> całkowicie obciążony, na dysku nic się nie dzieje.
>
> 	Jak to zdiagnozować? Bo na razie nie mam za bardzo pojęcia, co
> tam się właściwie dzieje.
>
> 	Z góry dziękuję za podpowiedzi.
>

fsck ?

i ku pewności przedstawię swoją wersję przy użyciu jednego rsynca:

for i in {14..1};
do
         if [ -e home.$i ]
         then
                 mv home.$i home.$((i+1))
         fi
done

if [ -e home.15 ]
then
         mv home.15 home.1
else
         mkdir home.1
fi
rsync -q -a --no-D --delete -z --timeout=3600 -H --link-dest=../home.2 
${login}@${host}::home/ home.1


-- 
Pozdrawiam
Lemat

Po głębokim namyśle Lemat napisał w poniedziałek, 15 sierpnia 2016 
21:37:

> fsck ?

	Zrobiłem, ale nic nie wykrył. Zresztą fsck powinien chyba być 
robiony automagicznie, bo backup trzymam na partycji, którą montuję 
tylko na czas backupu - czyli codziennie.

> i ku pewności przedstawię swoją wersję przy użyciu jednego rsynca:

	Ale potrzebujesz miejsce na 14 kopii home'a, prawda? I do tego 
podczas pierwszych 14 wykonań kopiujesz całą zawartość home. Tymczasem 
back-in-time potrzebuje minimalnego czasu już od drugiego kopiowania i 
potrzebowałaby tylko tyle miejsca, ile zajmuje jedna kopia + 13 
diffów. O ile, oczywiście, kopiując po sieci jest w stanie obsłużyć 
hardlinki.

	Tak, czy owak - dziękuję. 

-- 
Pozdrawiam,

(js).

PS. Odpowiadając bezpośrednio proszę usunąć minus wraz ze wszystkimi 
kolejnymi literami.

W dniu 15.08.2016 o 23:30, Jan Stożek pisze:

>> i ku pewności przedstawię swoją wersję przy użyciu jednego rsynca:
>
> 	Ale potrzebujesz miejsce na 14 kopii home'a, prawda?

nie

> I do tego
> podczas pierwszych 14 wykonań kopiujesz całą zawartość home.

nie

> Tymczasem
> back-in-time potrzebuje minimalnego czasu już od drugiego kopiowania i
> potrzebowałaby tylko tyle miejsca, ile zajmuje jedna kopia + 13
> diffów.

dokładnie.

-- 
Pozdrawiam
Lemat

Po głębokim namyśle Lemat napisał w wtorek, 16 sierpnia 2016 01:28:

>> Tymczasem
>> back-in-time potrzebuje minimalnego czasu już od drugiego
>> kopiowania i potrzebowałaby tylko tyle miejsca, ile zajmuje jedna
>> kopia + 13 diffów.
> 
> dokładnie.

	OK, czyli rozumiem, że rsync robi w jednym przebiegu linkowanie 
poprzedniej kopii backupu i nakłada na nią przesłane dane z maszyny 
backupowanej - tak? 

-- 
Pozdrawiam,

(js).

PS. Odpowiadając bezpośrednio proszę usunąć minus wraz ze wszystkimi 
kolejnymi literami.

W dniu 16.08.2016 o 19:41, Jan Stożek pisze:
> Po głębokim namyśle Lemat napisał w wtorek, 16 sierpnia 2016 01:28:
>
>>> Tymczasem
>>> back-in-time potrzebuje minimalnego czasu już od drugiego
>>> kopiowania i potrzebowałaby tylko tyle miejsca, ile zajmuje jedna
>>> kopia + 13 diffów.
>>
>> dokładnie.
>
> 	OK, czyli rozumiem, że rsync robi w jednym przebiegu linkowanie
> poprzedniej kopii backupu i nakłada na nią przesłane dane z maszyny
> backupowanej - tak?
>

tak.

-- 
Pozdrawiam
Lemat

Witam,

	Właśnie się zorientowałem, że wbrew obyczajowi nie zostawiłem 
śladu dla potomnych. Niniejszym naprawiam. 

Po głębokim namyśle Jan Stożek napisał w poniedziałek, 15 sierpnia 
2016 20:52:

> Mam backup zrobiony na rsyncu: frontend (back-in-time) + rsync
> w tle. 

	(...)

> Teraz problem, który nastąpił dziś: po godzinie pracy backupu
> zauważyłem, że rsynk nadal chodzi - zajmuje dość dużo procesora
> (procesor mam całkowicie obciążony), ale niczego nie pisze na dysku.

        Odpaliłem backup w oknie terminala (żadnych 
komunikatów istotnych dla sprawy nie było), a jak się przywiesił - 
zatrzymałem go STOP-em, sprawdziłem na liście procesów parametry 
rsynca i uruchomiłem rsynca z tymi samymi parametrami, ale w 
terminalu, oglądając wyjście - byłem bowiem ciekaw, na którym pliku 
stanie. 

        Przyczyna problemu okazała się bardzo prozaiczna. Otóż wśród 
backupowanych folderów jest folder /var (w całości, bo nie chciało mi 
się rozkminiać, gdzie w nim są ważne rzeczy, a gdzie tymczasowe). 
Wszystko działało dobrze, dopóki parę dni temu nie zainstalowałem 
jakiegoś narzędzia, które działało w klatce. Bo wtedy biedny rsync 
zaczął się zacinać próbując zrobić backup pliku  
/var/lib/cośtam/proc/kcore - bo choć "/proc" był na liście wykluczeń, 
to "proc" już nie. 

        Dziękuję wszystkim za podpowiedzi. 

-- 
Pozdrawiam,

(js).

PS. Odpowiadając bezpośrednio proszę usunąć minus wraz ze wszystkimi 
kolejnymi literami.