sie 28

Backup danych na serwerze

Linux Dodaj komentarz

W myśl pewnego stwierdzenia ludzie dzielą się na tych, którzy robią kopie zapasowe i na tych, którzy dopiero zaczną je robić :-P Ja należę do tych pierwszych, co ważniejsze dane staram się backupować. Niedawno skrypt, który wykonuje za mnie całą pracę przeszedł modyfikacje, a jego ostatnią wersją mam zamiar się podzielić z Wami.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

#!/bin/bash
 
CREATE=`date +%F`
DELETE=`date +%F -d"-28 day"`
 
#usunięcie najstarszego backupu
if [ -e ./backups/backup_$DELETE.tar.gz ]
then
  rm ./backups/backup_$DELETE.tar.gz
fi
 
#zrzut bazy danych
/usr/local/mysql/bin/mysqldump -A -uXXXXX -pXXXXX > ./dump_$CREATE.sql
 
#pakowanie zawartości konta
tar --exclude-tag-all=backup.sh -zcvf ./backups/backup_$CREATE.tar.gz ./
 
#usunięcie zrzutu bazy danych
rm ./dump_$CREATE.sql
 
#wysłanie kopii na inny serwer
scp ./backups/backup_$CREATE.tar.gz remote:~/backups/hosting
 
#usunięcie najstarszego backupu na zdalnym serwerze - odpowiednik linii 7-11
ssh remote "if [ -e ./backups/hosting/backup_$DELETE.tar.gz ]
then
  rm ./backups/hosting/backup_$DELETE.tar.gz
fi
exit"

Na początek ustalamy aktualną datę, która będzie występować w nazwach plików, oraz datę kopii, która jest najstarsza i zamierzamy się jej pozbyć. Skrypt wykonuje się u mnie raz na tydzień, więc zmienną $DELETE, pomniejszam o 28 dni. Dzięki temu na serwerze zawsze pozostają cztery ostatnie kopie (aktualnie wykonana i trzy poprzednie; czwarta zostanie usunięta).

Po usunięciu jednego z archiwów (jeśli oczywiście istnieje) zabieramy się za tworzenie bieżącej kopii. Na początek zrzut wszystkich naszych baz do pliku. Służy do tego narzędzie mysqldump. Przyjmowane opcje to kolejno:

  • -A – zrzut wszystkich dostępnych baz danych
  • -u – nazwa użytkownika baz danych
  • -p – hasło dla ww. użytkownika

Następnym krokiem jest tarowanie i kompresja zawartości katalogu domowego. Tu bardzo pomocna okazała się opcja –exclude-tag-all. Powoduje ona pominięcie katalogu, w którym znajduje się plik o nazwie podanej jako wartość tej opcji. Zapisując skrypt pod nazwą backup.sh w katalogu ./backups osiągnąłem to, co zamierzałem – folder, w którym lądują kopie nie jest dołączany do archiwum.

Dla porządku usuwam jeszcze plik z bazami danych. Został zarchiwizowany, więc nie musi już leżeć w katalogu głównym mojego konta.

W tym momencie z grubsza wszystko jest gotowe. Tyle że backup trzymany w tym samym miejscu, co reszta danych chroni mnie tylko przed własnymi „błędami” – przypadkowym usunięciem/nadpisaniem plików. W razie awarii dysku czy podobnej sytuacji i tak nie będę miał dostępu do kopii (wiem że administratorzy też archiwizują dane, ale ich uzyskanie może chwilę potrwać). A skoro mam możliwość wysłania ich na inny serwer, to czemu z niej nie skorzystać? :-D

Na sam koniec pozostaje usunięcie najstarszej kopii z zapasowego serwera. Wykonujemy mniej więcej to samo, co na początku skryptu, tylko że po zalogowaniu się na wspomniane konto.

Ostatecznie mamy kopię baz danych spakowaną razem z całą zawartością folderu domowego (wyłączając katalog ./backups) i dodatkowo wysłaną na zewnętrzny serwer. Teraz wystarczy dodać zadanie do crontab‘a, np.

0 10 * * 2 ./backups/backup.sh

i (dopóki nic złego się nie dzieje) można zapomnieć o całej sprawie, a kopia wykona się co wtorek o 10 rano ;)

Informacja

Autorem kodu, na którym częściowo oparłem swój skrypt, jest Filip Cierpich.

Odpowiedz