Jeśli kiedykolwiek z powodu utraty ważnych danych wyrywałeś sobie włosy, bez wątpienia określenie 'kopia zapasowa’ (potocznie backup) nabiera specjalnego znaczenia w twoim życiu. Bazy danych mają spore możliwości katalogowania danych, ale biorąc pod uwagę ilość informacji powierzanych do przechowywania przez serwery MySql’a skutki niewłaściwego użycia komendy DROP DATABASE, nieoczekiwanej awarii systemu, ręcznej edycji struktury tabeli zakończonej niepowodzeniem, mogą być katastrofalne i nie do naprawienia – chyba że posiadamy kopię zapasową z której możemy odtworzyć utracone dane.
MySQL posiada wbudowane narzędzie nazywające się mysqldump które służy do tworzenia niezależnych od platformy plików tekstowych które zawierają pełną kopię tego co znajdowało się w bazie , która przez przypadek została utracona
Aby utworzyć kopię zapasową bazy db_przykładowa, należy wykonać poniższą komendę:
# mysqldump -u
MySQL użyje username, password oraz host aby sprawdzić, czy posiadamy uprawnienia dostępu do bazy. Po udanej autentykacji, przekierowujemy cały potok wyjścia wytworzony przez polecenie mysqldump do wskazanego przez nas pliku. Dobrą praktyką jest dodawanie do nazwy plików z backupem daty. W niektórych przypadkach, gdy kopie robione są kilka razy dziennie, przydatne jest również wstawianie informacji o czasie ich utworzenia.
Dopisek: W dalszych przykładach dla łatwiejszego zobrazowania działania polecenia mysqldump pominę używanie opcji -u , -p, oraz -h , ty powinienes ich używac – w przeciwnym wypadku MySQL będzie się skarżył, że ich nie podałeś 🙂
Jeśli mamy do czynienia z bazą w której niektóre z tabel są używane znacznie częściej niż inne, wtedy mysqldump pozwala nam wykonać tylko ich kopię:
# mysqldump db_przykladowa artykuly komentarze linki > /usr/backups/mysql/db_przykladowa.art_kom_lin.2004-12-27
Powyższe polecenie zrobi zrzut tabel artykuly, komentarze oraz linki naszej bazy. Oczywiście plik wyjsciowy nazwaliśmy tak, aby było wiadomo, co w nim się znajduje. Ta funkcja jest pomocna gdy mamy do czynienia z dużymi bazami (np. systemy zarządzania treścią), tam również spotykane jest kilka typów tabel, które razem mogą być pogrupowane w jedną sekcję dzięki czemu uzyskamy mniejsze łatwiejsze do zarządzania pliki z kopiami bezpieczeństwa. Przykładowo, nazwa sekcji moze być wykorzystana jak poniżej:
# mysqldump db_przykladowa gracz punkty sezon > /usr/backups/mysql/db_przykladowa.graczinfo.2004-12-27
Aby zaoszczędzić miejsca na dysku, możemy w locie kompresować pliki za pomocą gzipa:
# mysqldump db_przykladowa | gzip > /usr/backups/mysql/db_przykladowa.2004-12-27.gz
Dumpy po sieci
Przechowywanie kopii zapasowych na tej samej maszynie co oryginalna baza jest jak pokazywanie swojej swej sekretnej broni swojemu najwiekszemu wrogowi. Jednym z najprostszych sposobów przechowywania backupów na innej maszynie w sieci jest przekopiowanie ich ręcznie. Ludzie, żyjemy chyba w erze cyfrowej – od czego jest automatyzacja?!
W tym przykładzie posłużymy się dwoma maszynami: główna posiada adres IP 192.168.1.11, natomiast maszyna na którą będziemy kopiować to 192.168.1.22.
No dobrze, zacznijmy od tego, iż dobrze jest stworzyć oddzielną partycję (w tym przykładzie będziemy ją nazywać 'archive’) na zdalnej maszynie i zamontowac ją. W tym wypadku, nawet gdy system na zdalnej maszynie będzie niezdatny do użycia, możemy zainstalować nowy system bez obawy o pliki naszych kopii zapasowych.
Do wykonywania kopii zapasowych na zdalnej maszynie linuksowej musisz posiadać skonfigurowaną obsługę NFS (Network File System). Lektura Understanding NFS oraz Implementing NFS będzie pomocna aby uruchomic NFS.
Natomiast gdy do przechowywania kopii będziemy wykorzystywać maszynę z Windows na pokładzie, będziemy musieli zainstalować i skonfigurować Sambę. Jeśli mamy z tym problemy, pomocne będą dokumenty znajdujące się tutaj (polskojęzyczna książka na ten temat: samba.txt.gz).
Zakładam, że posiadasz NFS na swojej zdalnej maszynie, otwórz więc /etc/exports w swoim ulubionym edytorze tekstowym i dodaj poniższą linijkę:
/archive 192.168.1.11 (rw, no_root_squash) Uwaga od redakcji: jak wskazują nasi czytelnicy, nie jest to najbezpieczniejsze rozwiązanie!
W ten oto sposób informujemy NFS, żeby wspołdzielił katalog /archive z systemem, na którym znajduje się baza. Katalog ten zarówno na maszynie lokalnej jak i zdalnej posiada prawa do odczytu i do zapisu, a użytkownik łączący się z maszyny bazodanowej posiada uprawnienia roota na maszynie zdalnej. Po zachowaniu efektów naszej pracy wydajemy następującą komendę:
# exportfs -a -r
Dzięki czemu przeeksportujemy wszystkie katalogi, tak jak to mamy zapisane w pliku /etc/exports. Po więcej informacji na temat exportfs zapraszam do do man exportfs.
Teraz restartujemy usługę NFS:
/etc/rc.d/init.d/nfs start
Powyższe polecenie ustawi naszą zdalną maszynę. W katalogu /mnt na maszynie z MySQL’em tworzymy katalog backup_share za pomocą polecenia:
mkdir /mnt/backup_share
Następnie montujemy katalog archive z maszyny zdalnej w tym katalogu:
mount u2013o soft 192.168.1.22:/archive /mnt/backup_share
Mamy podmontowany folder, czas więc na wykonanie kopii zapasowej. Wracając do naszej bazy, będzie to wyglądało mniej więcej tak:
# mysqldump db_przykladowa > /mnt/backup_share/db_przykladowa.2004-12-27
Na maszynie wyposażonej w system Windows ze skonfigurowaną usługą Samby, musimy utworzyć katalog archive oraz udostępnić go z prawami do odczytu i zapisu. Następnie tworzymy katalog backup_share w /mnt na naszym serwerze bazodanowym tak jak w poprzedniej sekcji i montujemy go :
# mount -t smbfs -o username=
Oczywiście należy zastąpić
# mysqldump db_przykladowa > /mnt/backup_share/db_przykladowa.2004-12-27
Automatyzacja procesu
Teraz, gdy wiemy już w jaki sposób tworzyć kopie baz i ich tabel oraz wiemy jak przechowywac je na zdalnych lokalizacjach, nadszedł czas aby Linux pokazał swoją siłę i wykonywał te zadania za nas. Do tego celu użyjemy demona o nazwie cron. cron jest linuksowym programem który uruchamia w tle zadania w określonych przez nas przedziałach czasowych. Demon crona budzi się raz na minutę i sprawdza plik crontab czy zawiera on jakieś zadania i jeśli jakieś znajdzie to je wykonuje – czyż to nie proste ?:)
Napiszemy więc sobie prosty skrypt który będzie wykonywal kopie zapasowe i do odpalania go zaprzegniemy crona. Otwórzmy więc nasz ulubiony edytor tekstowy i przekopiujmy to, co znajduje się poniżej, do nowego pliku:
## Jeśli robisz kopie na maszynie linuksowej, odkomentuj linie poniżej
# mount u2013o soft 192.168.1.22:/archive /mnt/backup_share
## W przeciwnym wypadku (jeśli masz maszynę z Windowsami), odkomentuj poniższą linię i uzupełnij username oraz password
# mount -t smbfs -o username=
## Na koniec komenda $(date +%F) poda aktualne informacj
e na temat daty
mysqldump -u
#odmontowujemy system plikow
umount /mnt/backup_share
Zapisujemy efekty naszej pracy jako db_przykladowa_backup.sh
Należy zwrócić uwagę na to iż jest to skrypt napisany szybko i troche 'na kolanie’. W konkretnej implementacji powinniśmy sprawdzić, czy zdalna partycja jest zamontowana, czy plik z naszą kopią bezpiecznie został przesłany do zdalnego systemu i wiele innych rzeczy.
Nadajemy prawo do wykonywania dla naszego skryptu:
chmod +x ./db_przykladowa_backup.sh
Teraz przyszła kolej na crona. Jeśli należymy do grupy ludzi leniwych, to możemy wykorzystać jedną z 4 opcji do uruchomienia naszego skryptu: raz na godzine, raz na dzien, tydzien, oraz miesiac. W zależności od tego którą opcję wybierzemy, musimy przekopiować nasz skrypt do właściwego katalogu /etc/cron.przedzialczasu, gdzie przedzialczasu jest interwałem czasowym, co który chcemy wykonywać kopie zapasowe. Ja przekopiowałem skrypt do /etc/cron.daily gdyż chce aby backupy były robione raz dziennie. Gdy będziesz gotowy, przeładuj demon crona (nie we wszystkich dystrybucjach jest to konieczne)
/etc/rc.d/init.d/crond restart
No i to by było na tyle. Po więcej informacji odsyłam na strony dla crontaba.
Używanie dumpów
Pliki backupowe generowane przez mysqldump’a są zwykłymi plikami tekstowymi w których znajduje się wiele poleceń CREATE TABLE oraz INSERT przywracających bazę danych. Oto zawartość przykładowego pliku:
-- MySQL dump 8.23 -- -- Host: localhost Database: geeklog --------------------------------------------------------- -- Server version 3.23.58 -- -- Table structure for table `gl_commentcodes` -- CREATE TABLE gl_commentcodes ( code tinyint(4) NOT NULL default '0', name varchar(32) default NULL, PRIMARY KEY (code) ) TYPE=MyISAM; -- -- Dumping data for table `gl_commentcodes` -- INSERT INTO gl_commentcodes VALUES (0,'Comments Enabled'); INSERT INTO gl_commentcodes VALUES (-1,'Comments Disabled');
Żeby przywrócić bazę z tego przykładowego pliku, musiymy najpierw stworzyć pustą bazę. Aby wypełnić ją tabelkami, a tabelki danymi, musimy wybrać właściwy plik z kopią bazy:
mysql -u
W tym momencie trzeba podać niezbędne do autoryzacji informacje i gotowe! Teraz nasza baza jest taka, jaką widzieliśmy ją ostatnim razem.
Podsumownie
mysqldump jest niewątpliwie niezmiernie ważnym narzędziem dla administratorów serwerów MySQL oraz wspaniałym narzędziem utrzymania integralności i 100% dostępności krytycznych danych przetwarzanych przez nasze serewery danych.
Autorem oryginalnego artykułu jest: Mayank Sharma - freelance technology writer and FLOSS migration consultant in New Delhi, India. Oryginalny takst znajduje się na stronach : NewsForge
Archiwalny news dodany przez użytkownika: Marcin Federowicz.
Kliknij tutaj by zobaczyć archiwalne komentarze.