Jakub“Ludzie dzielą się na tych, którzy robią kopie zapasowe i tych, którzy będą je robili”. Te słowa często bawią lub wywołują ironiczny uśmieszek. Niestety, maszyny bywają zawodne. Dyski często lubią płatać nam figle i padać w najmniej odpowiednim momencie. Pół biedy, gdy zdarzy się to na naszym prywatnym komputerze lub na stanowisku pracy. Co możemy stracić? Kilka godzin naszej pracy (jeśli nie robimy częstych commitów) lub jakieś prywatne materiały, bez których da się żyć. Prawdziwy problem pojawia się, gdy stanie się to na serwerze produkcyjnym. Lub kiedy postanowimy odpalić truncate na jakiejś tabelce na live, bo zapomnieliśmy zmienić serwer po testowaniu nowego zapytania. Co wtedy? Tracimy ważne dane, których nie możemy odzyskać i odbieramy dziesiątki telefonów od klienta – “Dlaczego moja strona / aplikacja nie działa?”
Gdzie trzymać kopie?
Wiemy już, że musimy robić kopię zapasową. Teraz zastanówmy się jak powinniśmy to robić. Załóżmy, że mamy serwer VPS o pojemności 20GB, a nasza aplikacja (lub kilka) zajmuje łącznie z bazą danych 2GB. Oznacza to, że mamy 18 giga, które możemy sobie wykorzystać do przechowywania kopii zapasowych. Mamy szybki dostęp do wszystkich backupów i niestraszne nam awarie bazy danych, czy przypadkowe usunięcie jakiegoś pliku. Teoretycznie brzmi super. W praktyce – pojawia się problem, że nasze kopie nadal będą w tym samym miejscu, co nasza aplikacja. Nie uchroni nas to przed potencjalną awarią fizyczną.
Kopie u naszego providera
Ok. Ale za to odpowiada nasz provider. I tak i nie. Jeśli korzystamy z tanich rozwiązań, kopie zapasowe nie będą standardem. Przeważnie możemy je dokupić, co wiąże się ze wzrostem kosztów. Często koszt backupu przekracza cenę naszego serwera (mówimy oczywiście o tanich rozwiązaniach). Dodatkowo należy pamiętać, że kopia, jaką zrobi nam provider (raz lub dwa razy dziennie), będzie przechowywana tylko przez kilka dni. Wyobraźmy sobie (co prawda skrajną ale jednak) taką sytuację. Korzystamy z jakiejś małej aplikacji, którą sami stworzyliśmy, lub prowadzimy bloga, na którego nie zaglądamy codziennie i wyjechaliśmy na 3 tygodniowe wakacje. Nasz serwer postanowił ulec awarii już pierwszego dnia (np. jakiś wadliwy import danych w cron) i wywalił nam bazę danych. Nasz provider tworzył codziennie kopie zapasową, ale trzymał ją tylko 14 dni. Wracamy po 3 tygodniach, patrzymy, a tu ZONK. Nasza aplikacja leży, nie mamy kopii zapasowej, a nasz provider ma tylko wersje z ostatnich 14 dni, więc już od stanu, w którym wszystko leży. Wiem, jest to bardzo skrajny przypadek – ale nadal bardziej prawdopodobny niż trafienie szóstki w lotku.
Dodatkowa przestrzeń na kopie
Trzecia opcja – dokupujemy dodatkową przestrzeń dyskową i wysyłać tam nasze kopie. I znów mówimy o dodatkowych kosztach, które musimy ponosić. O ile w przypadku dużych projektów, dla których na prawdę trzeba dobrać optymalne rozwiązania ma to sens i szczerze do tego zachęcam. O tyle w jeśli mówimy o małej aplikacji, bądź stronie typu blog, mija się to z celem.
Ściągnijmy kopie do siebie!
“Jak Ci nic nie pasuje i nie chcesz płacić, to sobie ściągaj te kopie do siebie!”. Jest to masochistyczne rozwiązanie i na pewno znajdą się jego zwolennicy. Co sprytniejsi, ustawią sobie automatyczną synchronizację plików. Tylko pojawia się kolejny problem – czy nasze kopie będą bezpieczne. Czy czynnik ludzki nie spowoduje dodatkowej katastrofy? Nie dość że zaśmiecimy nasz prywatny komputer, to jeszcze nie sprawimy, że te dane będą bezpieczniejsze. Możemy iść dalej i robić kopię naszej kopii i nagrywać ją na DVD. Ok, chyba za bardzo odpłynąłem.
No dobra. To mamy przerobione wszystkie czarne scenariusze. Wnioski – nie ma optymalnego rozwiązania. Otóż jest. Możemy użyć darmowego dysku Google do przechowywania naszych danych. Ustawić automatyczną synchronizację i mieć pełny dostęp do do plików w każdym możliwym momencie.
Jak zacząć
Do rozpoczęcia pracy, potrzebować będziemy konta google oraz narzędzia do synchronizacji naszych plików (ja wybrałem rclone)
Instalacja rclone
Zaczynamy od zainstalowania rclone na naszym serwerze.
curl -O https://downloads.rclone.org/rclone-current-linux-amd64.zip
Po pobraniu archiwum, musimy je rozpakować
unzip rclone-current-linux-amd64.zip
Wchodzimy do wypakowanego katalogu
cd rclone-*-linux-amd64
Kopiujemy cały katalog rclone do /usr/bin i nadajemy mu odpowiednie prawa
sudo cp rclone /usr/bin/ sudo chown root:root /usr/bin/rclone sudo chmod 755 /usr/bin/rclone
Konfiguracja konta google
Przyszedł czas na ustawienie naszego konta Google. Przechodzimy do konsoli i wyszukujemy usługi Google Drive. Musimy ją włączyć. Aby to zrobić musimy najpierw utworzyć projekt (o czym Google nas informuje).
Następnie przechodzimy do zakładki “Dane logowania”. Pierwszym krokiem będzie skonfigurowanie ekranu zgody OAuth. Wymagane będzie tylko wybranie konta email oraz wprowadzenie nazwy usługi widocznej dla użytkowników.
Wracamy do zakładki “Dane logowania”. Tworzymy nowe dane logowania wybierając opcję “ID klienta OAuth”.
W kolejnym kroku wybieramy inny typ aplikacji i wprowadzamy jego nazwę. Po zatwierdzeniu otrzymamy informacje o naszym identyfikatorze klienta oraz kluczu. Będą one potrzebne do konfiguracji naszego rclone na serwerze.
Konfiguracja rclone
Wszystko przygotowane, więc zaczynamy. Na naszym serwerze musimy skonfigurować rclone. Używamy do tego następującej komendy:
rclone config
Następnie musimy skonfigurować nowy remote. Wybieramy opcję “New remote” [n] i zatwierdzamy enterem. Konfigurator poprosi nas o wprowadzenie nazwy (będziemy jej później używać przy rozpoczęciu synchronizacji). Kolejnym krokiem jest wybranie z listy rodzaju usługi. Nas interesuje Google Drive znajdujący się pod numerem 7. Nasz wybór zatwierdzamy enterem.
Następnie program zapyta nas o dane logowania do google (identyfikator i klucz). Po zatwierdzeniu, konfigurator spyta nas, czy użyć auto config. Wybieramy opcję “no” [N], a następnie otwieramy w naszej przeglądarce link, który pojawił się w naszej konsoli.
Po otworzeniu linku, musimy wybrać konto, którego dotyczy konfiguracja oraz zezwolić rclone na dostęp do usługi GoogleDrive. Po zatwierdzeniu, otrzymamy w przeglądarce kod weryfikacyjny, który musimy przekopiować do naszej konsoli. Po zatwierdzeniu kodu, nasza konfiguracja jest gotowa. Pojawi się ona w głównym ekranie konfiguracji rclone. Teraz możemy jej swobodnie używać.
Pierwsza synchronizacja
Gdy nasza konfiguracja jest już gotowa, możemy przystąpić do synchronizacji plików. Do celów demonstracyjnych utwórzmy folder backup, a w nim dowolny plik tekstowy. Teraz przy użyciu komendy rclone copy, zsynchronizujemy nasz folder. Pierwszym argumentem będzie nazwa folderu lokalnego (w naszym przypadku backup), drugim nazwa usługi (tę, którą podaliśmy podczas konfiguracji GoogleStorage) i nazwa folderu docelowego oddzielone dwukropkiem.
rclone copy backup GoogleStorage:backup
Po chwili na naszym koncie Google Drive pojawią się nasze pliki.
W przypadku, gdybyśmy przez przypadek usunęli jakieś pliki lokalnie, wystarczy, że ponownie wywołamy rclone copy, odwracając parametry (pierwszy GoogleStorage:backup). To pozwoli na skopiowanie wszystkich plików z naszego Google Drive do lokalnego folderu.
Rclone jest bardziej zaawansowanym narzędziem i posiada o wiele więcej możliwości. Ja przedstawiłem najprostszy możliwy sposób na szybkie robienie kopii naszych plików. Teraz wystarczy dodać zadanie do listy, tak aby wykonywało się bezpośrednio po stworzeniu kopii naszych plików.
Podsumowanie
Przedstawione rozwiązanie nie jest idealnym lekiem, które zalecam każdemu. Nie mniej jednak świetnie sprawdza się dla projektów małych, z niskim budżetem. Dysponujemy tutaj 15 GB darmowej przestrzeni. W łatwy sposób (i stosunkowo niskim kosztem), możemy rozszerzyć ją do 100 GB. Takie rozwiązanie pozwala nam w bezpieczny sposób zwolnić nieco miejsca i nie trzymać kopii na serwerze z aplikacją. Prosta konfiguracja, da nam również możliwość tworzenia kopii jednocześnie na kilku kontach.
A jakie są Wasze metody na trzymanie kopii zapasowych jak najniższym kosztem? A może jesteście w grupie, która dopiero będzie tworzyć kopie zapasowe? Podzielcie się swoją opinią i przemyśleniami na ten temat.
Jakub
