Backup plików i baz danych na zdalny serwer
Kiedyś, dawno, dawno temu, obiecałem sobie i Wam - wiernym czytelnikom tego bloga (razem będzie jakieś 3 osoby), że będę prowadził "pamiętnik znaleziony w logu" czyli opisywał moje boje z linuxem a konkretniej z serwerem dedykowanym pod hosting moich stron www.
Dziś wrócę do tej tematyki opisując jak na systemie debian w wersji 5 (o ile pamiętam to jest lenny) zbudowałem prosty backup plików i baz danych.
System jest banalnie prosty, żeby nie powiedzieć prostacki, ale lepszego na razie nie potrafię zrobić, jak się nauczę - opowiem.
Zaczynamy od utworzenia w konsoli katalogów potrzebnych do trzymania kopii zapasowych i pliku gdzie będzie siedział sam skrypt, wydajemy komendy:
mkdir /root/skrypty
mkdir /root/backupysqltmp
nano /root/skrypty/backup
powinno pojawić się okno edytora nano, gdzie wklejamy:
echo "backup start"
# najpierw wyczyscimy conieco tabel w mysql, zawierajacych niepotrzebne dane, np. cache
# NaszeHasloMySql - tu musimy podac nasze haslo do konta z dostepem do tabel jakie mamy wyczyscic
mysql -u root -pNaszeHasloMySql < /root/skrypty/sqltrunccache
echo "trunc end"
# zrzucamy zawartosc 3 baz sql do lokalizacji /root/backupysqltmp
# pliki beda mialy nazwe z elementem zmiennym (aktualna data w formie timestamp)
# pliki beda spakowane za pomoca gzip
echo "basoofka sql start"
mysqldump -l --opt -u root -pNaszeHasloMySql baza1 | gzip -cq9 > /root/backupysqltmp/baza1_`date +%s`.sql.gz
echo "blogowisko sql start"
mysqldump -l --opt -u root -pNaszeHasloMySql baza2 | gzip -cq9 > /root/backupysqltmp/baza2_`date +%s`.sql.gz
echo "elimu sql start"
mysqldump -l --opt -u root -pNaszeHasloMySql baza 3| gzip -cq9 > /root/backupysqltmp/baza3_`date +%s`.sql.gz
# nastepnie z pomoca rsync wrzucamy pliki na zdalny serwer
# oczywiscie mozemy wrzucic wiecej katalogów
# na zdalnym serwerze powinny istnieć katalogi do których kopiujemy dane
echo "rsync publichtml start"
rsync -az /home/UserWWW/public_html/ userZdalnegoSystemu@ip.zdalnego.syste.mu:backupy/public_html/
echo "rsync sql start"
rsync -az /root/backupysqltmp/ userZdalnegoSystemu@ip.zdalnego.syste.mu:backupy/sql/
echo "koniec"
aby zapisać plik i wyjść z nano stosujemy kombinację CTRL+X i [enter]
następnie zakładamy plik gdzie będzie lista komend dla mysql
nano /root/skrypty/sqltrunccache
pojawi się okno edytora nano, gdzie wklejamy (w moim przypadku)
use baza1;
TRUNCATE `cache_filter`;
TRUNCATE `cache_menu`;
TRUNCATE `cache_page`;
use baza2;
TRUNCATE `cache_filter`;
TRUNCATE `cache_menu`;
TRUNCATE `cache_page`;
exit
wychodzimy z nano ( CTRL+X i [enter] ) i czynimy dalsze przygotowania. Instalujemy rsync
apt-get install rsync
a następnie najważniejsza część - generujemy klucze publiczne i prywatne, ja korzystałem z kilku poradników ( http://www.bqbackup.com/... , http://www.debian-admini... , http://www.gentoo.org/do... ), utknąłem w pewnym momencie ale jakoś się w końcu udało, zestaw komend do osiągnięcia stanu, który pozwoli wrzucić nasz skrypt do crontaba to mniej więcej:
ssh-keygen -t dsa
(na wszystkie pytania odpowiadamy enter, wygeneruje się nam para kluczy w katalogu .ssh)
scp ~/.ssh/id_dsa.pub userzdalnegohosta@adresip.zdalnego.hos.ta:
(ważny jest ten dwukropek na końcu, skopiujemy w ten sposób klucz publiczny na zdalnego hosta do katalogu domowego użytkownika "userzdalnegohosta")
potem logujemy się na zdalnego hosta i:
cat id_dsa.pub >> ~/.ssh/authorized_keys
potem już z lokalnego hosta próbujemy się zalogować po ssh na zdalny:
ssh userzdalnegohosta@adresip.zdalnego.hos.ta
jeśli się uda bez podawania hasła to jesteśmy w domu, możemy dodać zadanie do crontab:
crontab -e
odpali się nano z naszym crontabem, gdzie dodajemy linijkę:
0 20 * * * . /root/skrypty/backup
zamykamy nano ( ctrl + x, enter) zapisując zmiany w crontab'ie
powyższa linijka odpali codziennie o 20:00 (czasu serwera) nasz skrypt, możemy go najpierw przetestować odpalając poszczególne jego części (linie) w wierszu poleceń i sprawdzając czy robi co ma robić.
Jeszcze mały update - po kilku dniach działania skryptu może się okazać, że nasz dysk jest zapchany plikami ze zrzutami sql. Jest na to rada - zapuścić w cronie usuwanie plików starszych niż n dni, dodając taką oto linijkę (przykładową)
0 04 * * * find /root/backupysqltmp/ -mtime +3 -exec rm {} \;
powyższy zapis w cron oznacza - codziennie o 4 rano usuń pliki starsze niż 3 dni z katalogu /root/backupysqltmp/. Możemy najpierw potestować komendę find w wierszu poleceń, pisząc np.
find /root/backupysqltmp/ -mtime +3
co powinno wyświetlić nam pliki starsze niż 3 dni. dodanie do komendy ciągu ` -exec rm {} \;` spowoduje dodatkowo usunięcie znalezionych plików. Opis komendy znalazłem na http://www.howtogeek.com...
uff, teraz śpię nieco spokojniej :)

Bardzo przydatne jak się ma
Bardzo przydatne jak się ma malutkie bazy :)
U mnie dump nie ma szansy egzystować powód - barrrdzo duże bazy + długi czas dumpowania. Jako backup wykorzystuje replike + binlogi ma enginie innodb.
Od dobrych kilku dni strona
Od dobrych kilku dni strona przypięta w zakładkach, a ja się za to zabrać nie mogę... Może w końcu w poniedziałek wykorzystam te rady w praktyce ;-)