Backupowanie danych
W ramach tworzenia backupów danych wykorzystywane są:
- usługa Amazon S3 - magazyn kopii zapasowych
- maszyna hcigbck - zapasowe środowisko
Schemat mechanizmu backupowania danych
Amazon S3
Jako magazyn danych zawierających kopie zapasowe wykorzystywana jest usługa Amazon S3. Usługa ta wchodzi w skład Amazon Web Services. Utworzony został bucket o nazwie coigdzie.pl, w którym istnieją następujące katalogi:
- db_dumps - zrzuty bazy danych
- export - aktualny backup exportów
- imports - aktualny backup importów
- gfx - backup obrazków
- logs - kopie zapasowe logów (logi dostępu przez api i logi apache'a w oddzielnych katalogach)
Usługa S3 oferuje 3 rodzaje storage'u (wymienione od najdroższego):
- Standard
- Standard - Infrequent Access
- Glacier
Pliki w najtańszym Glacierze dostępne są na żądanie - po upływie ok. 4h. "Wydobywanie" większej ilości danych z Glaciera może być kosztowne - miesięczny koszt zależy od szczytowej prędkości transferu (wydobycia) danych.
W LifecycleRules (we właściwościach bucketu) można definiować reguły, które przenoszą pliki między poszczególnymi rodzajami storage'ów, czy też usuwają je po określonym okresie czasu.
Operacje na strukturze plików na S3 mają pewne ograniczone - nie jest możliwa zmiana nazwy folderu, przenoszenie plików wiąże się z przekopiowaniem ich (co w przypadku plików składowanych w Glacierze oznacza konieczność płatnego wyciągnięcia danych).
Zrzuty bazy danych
W katalogu db_dumps na chmurze Amazon przechowywane są backupy bazy danych. W katalogu db_dumps/recent znajdują się poranne backupy z ostatnich 30 dni (starsze są automatycznie usuwane). W katalogu db_dumps/friday przechowywane są wszystkie piątkowe backupy. Codziennie o 7 i 19 na serwerze ovh uruchamiany jest skrypt /cronjobs/backup/ovh/backup-amazon.sh służący do utworzenia backupu bazy danych i ewentualnego załadowania go na chmurę Amazona. Skrypt tworzy backupy bazy danych za pomocą narzędzia pg_dump w katalogu /home/backup-baz/db_dumps (backupy starsze niż 2-dniowe są usuwane przez skrypt /cronjobs/backup/ovh/removeOldBackups.sh. Na podstawie daty odpalenia skryptu determinowane jest czy plik wysyłany jest na serwery Amazon (godzina < 12, czy dzień tygodnia to piątek). Tworzone pliki kopii zapasowych nazywane są zgodnie z konwencją: imprezownik20160821T0700.sql.gz
W katalogu db_dumps/sqlite przechowywane są backupy sqlite'owej bazy danych formularza dodaj imprezę. Skrypt backupujący /cronjobs/backup/master/backup-sqlite.sh uruchamiany jest codziennie o 8:05. Skrypt wstawia piątkowe zrzuty do katalogu /db_dumps/sqlite/retain, pozostałe do katalogu /db_dumps/sqlite/temp. Z katalogu temp usuwane są zrzuty starsze niż 30-dniowe. Tworzone pliki kopii zapasowych nazywane są zgodnie z konwencją: formularz20170224.sqlite3.bck.gz
Synchronizacja katalogów export, imports, gfx oraz logów
Z chmurą Amazon synchronizowane są również katalogi z plikami exportów, importów, gfx, a także logi (dostęp przez api - z katalogu /home/api; logi apache'a - z katalogu /var/log/apache2). Za synchronizację odpowiada skrypt /cronjobs/other/syncAmazon.sh , uruchamiany codziennie o godz. 4:05. Kopie zapasowe trafiają odpowiednio do katalogów exports, imports, gfx i logs w buckecie coigdzie.pl. Pliki kopii zapasowych po 30 dniach od utworzenia przenoszone są do storage'u Standard - Infrequent Access.
hcigbck
Maszyna hcigbck (IP: 192.168.16.49) jest środowiskiem zapasowym, wykorzystywanym także w celach testowych i deweloperskich.
Podmiana bazy danych
Tworzone codziennie backupy głównej bazy danych wdrażane są na środowisko znajdujące się na maszynie hcigbck. Odpowiedzialny za to jest skrypt /cronjobs/backup/hcigbck/db-restore.sh uruchamiany codziennie o 7:30 i 19:30. Skrypt wczytuje ostatni, niewdrożony plik backupu z synchronizowanego folderu /cronjobs/backup/hcigbck.
Synchronizacja katalogów (ovh -> hcigbck)
Przy użycia narzędzia rsync synchronizowane są katalogi zawierające pliki exportów, zrzuty głównej bazy danych oraz gfx. Za synchronizację odpowiadaja skrypt /cronjobs/backup/hcigbck/rsync-tasks.sh uruchamiany co godzinę.
Zależności czasowe
Nie mamy mechanizmu synchronizacji we wdrażaniu backupów, więc opieramy się na odpowiednim doborze zegarów dla zadań w crontabie.
ovh:
#### Backup bazy danych, wysłanie backupu na Amazon s3
0 7,19 * * * /cronjobs/backup/ovh/backup-amazon.sh >> /cronjobs/backup/ovh/backup-amazon.log
czas trwania zrzutu backupu bazy danych do synchronizowanego folderu to ~2min.
hcigbck:
#### Synchronizacja folderów z ovh
5 * * * * /cronjobs/backup/hcigbck/rsync-tasks.sh >> /cronjobs/backup/hcigbck/rsync-tasks.log
Czas synchronizacji dla backupu bazy danych to ~0.5 min
.
#### Skopiowanie backupu bazy danych z ovh, podmiana bazy danych oraz update image_url
10 7,19 * * * /cronjobs/backup/hcigbck/db-restore.sh >> /cronjobs/backup/hcigbck/db-restore.log
Wdrożenie całej bazy wraz z podmianą url dla obrazków to ~35 min
.
Najnowsza kopia bazy danych wdrożona jest na hcigbck rano o godzinie ~7:45 i wieczorem ~19:45