fsckup #1 – kopia (nie)bezpieczeństwa

Chciałbym tym wpisem zapoczątkować nową serię artykułów nazwanych potocznie [fsckup/fakap/fackup/itd...]. Nie będą to wpisy w stylu kopiuj/wklej, a może zadziała, będą to raczej informacje spisywane w luźnej formie nawiązujące do starego przykazania, “ucz się na błędach”… oczywiście najlepiej cudzych ;-)

Czym jest fsckup? Wpadką? Niedopatrzeniem? Brakiem doświadczenia? Karą za pośpiech lub lenistwo? Chyba wszystkim po trochu. Każdemu z nas się zdarzają, niekiedy są to drobiazgi, a czasami doprowadzają do poważnych awarii. Nie ma chyba administratora któremu się nie pomyliły nigdy polecenia, lub nie przewidział niepoprawnego działania aplikacji i doprowadził do zatrzymania systemu.

fsckup, będzie zbiorem porad, wskazówek, lub bardziej oficjalnie – zbiorem dobrych praktyk.

Kopia (nie)bezpieczeństwa… tak nazwałem pierwszy wpis, ponieważ chcę poruszyć kwestię wykonywania backup’ów  lub synchronizacji danych. Każdy z nas wie, że doskonale do takich robótek nadaje się rsync. rsync jest świetnym narzędziem któremu nie można zbyt wiele zarzucić, ale też powinniśmy wiedzieć, że niepilnowany potrafi się rozpastwić w systemie i wyssać z niego ostatnie bajty pamięci oraz takty procesora.

Klasyczna sytuacja może wyglądać następująco, administrator robi synchronizację danych, ale, że chce mieć spójne dane (czasami nawet bardziej spójne niż to możliwe), więc uruchamia rsync’a z cron’a co kilka minut. System działa świetnie, rsync przesyła dane rozgrzewając switche, dyski kręcą się aż miło… ale nadchodzi czarny dzień i maszyna z rsynciem przestaje odpowiadać. Sprint do konsoli i logujemy się… po 30 sekundach mamy terminal, ps axuw i czekamy minutę na wynik (!@#$w%t^f&). Przeleciały 3 ekrany rsync’ów… Kończy się restartem serwera, bo killall -9 rsync “nie robi”.

Po restarcie za dużo już nie widzimy, ale chwila głębszego zastanowienia i coś nam zaczyna świtać, że ostatnio maszyna miała trochę więcej do roboty, bo doszły jakieś logi (albo inne dziwne avi^H^H^Hpliki), no i ze 100 plików do synchronizacji, serwer miał ich 1000… nikt nie lubi tej chwili kiedy zdaje sobie sprawę, że nie przewidział jednej rzeczy… synchronizacja danych może trwać czasami dłużej niż 5 minut.

rsync robił swoje i starał się jak najlepiej, ale odpalał się nowy proces synchronizujący pomimo, że poprzedni nie skończył swojej roboty i problem narastał, aż skończyły się zasoby w systemie. Czy można było uniknąć takiej sytuacji? Prawdopodobnie tak ;-) wystarczyło zastosować proste lockowanie na pliku, np. napisać krótki skrypt a’la takie coś:

#!/bin/bash
 
if [ -f /tmp/rsync.lock ]
then
echo "SPADAM... NIE MOJA KOLEJ";
exit 1;
fi
 
touch /tmp/rsync.lock
 
echo "KOPIUJE KOPIUJE KOPIUJE";
rsync -avh --progres ...
 
rm /tmp/rsync.lock
 
exit 0;

Jedne zdanie wytłumaczenia, skrypt się uruchamia, sprawdza czy istnieje plik /tmp/rsync.lock, jeśli nie istnieje to tworzy go i przechodzi do synchronizacji danych, po niej plik usuwa, tak więc w przypadku kiedy synchronizacja trwa dłużej niż 5 minut, kolejny uruchomiony skrypt wykryje plik /tmp/rsync.lock i zakończy od razu działanie.

Gdy mamy już nasze narzędzie do synchronizacji/backupu, to podpinamy je do cron’a, a nie bezpośrednio rsync’a, dodatkowo robimy sobie STDOUT na maila w razie niepowodzenia (np. plik lock’a istnieje) i wiemy na bieżąco co się dzieje.

Oczywiście nie jest to doskonały skrypt, jest to bardziej przedstawienie samej idei. Skrypt może sprawdzać dodatkowo, czy działa w systemie już proces rsync i jeśli nie ma takiego a plik /tmp/rsync.lock jest starszy niż 30 minut to go może usuwać, może też zapisywać datę uruchomienia rsync’a, kod wyjścia, itd… każdy sam wie najlepiej jakie dodatkowe funkcje będą mu przydatne.

Prawda, że proste i skuteczne…? ;-)

Tweet

oceń artykuł (5 gł., średnia: 4,80)

 Loading ...