18
cz.
2009
palikowski

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

Wpisał micromachine (niezweryfikowany) 12 December 2010 - 11:37pm.

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

Wpisał Daggerka (niezweryfikowany) 21 August 2011 - 1:47am.

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 ;-)