Lekarzu, ulecz się sam czyli moje backupy nie działały

Do pisania tego tekstu siadam czerwony ze wstydu. Musiałem trochę powalczyć sam ze sobą, by napisać to publicznie: w ciągu minionych trzech miesięcy nie powstał ani jeden kompletny backup bloga Informatyk Zakładowy. Wstyd jest o tyle większy, że przecież rok temu opublikowałem trzyczęściowy cykl artykułów poświęconych tworzeniu kopii bezpieczeństwa (że o darmowym e-booku nie wspomnę), więc sam powinienem mieć wszystko zapięte na ostatni guzik, prawda? Aha…

W niniejszym tekście opisuję awarię mechanizmu tworzącego codzienny backup bloga oraz przyczyny, dla których nie dostrzegłem jej przez wiele miesięcy. Aby rozwiać wątpliwości – nie utraciłem danych. Wszystko wyszło na jaw, gdy wziąłem się za zupełnie inny temat. Planowałem opisać, ile czasu zajmie mi odtworzenie bloga od zera z wczorajszej kopii zapasowej. Zalogowałem się więc do AWS, by ją pobrać i wtedy…

Kopie zapasowe bloga wysyłane są do chmury Amazona, do kubełka S3. Oto, jak wyglądała lista plików tam obecnych:

Już na pierwszy rzut oka coś było nie tak. Choć backup robił się co noc, to jego rozmiar każdego dnia był inny – 778 MB, 464 MB a nawet marne 57 MB! Największy plik miał 984 MB i pochodził z końcówki 2021 roku. Kubełek na backupy trzyma pliki z ostatnich 90 dni, opisana usterka obejmowała cały ten okres. Czy miałem choć jeden sprawny backup?

Aby to sprawdzić, zalogowałem się do panelu administracyjnego WordPressa i sprawdziłem logi ostatnio wykonywanego zadania:

Co tu widzimy? Plugin BackWPup trzykrotnie próbuje spakować wszystkie pliki do archiwum dziennego. Za każdym razem proces jest przerywany po dwóch minutach i wznawiany od zera. Następnie archiwum – kompletne lub nie – jest wysyłane do kubełka S3.

Logi z wcześniejszych dni nie pozostawiały złudzeń.

Wspominałem, że największy plik miał 984 MB, tymczasem kompletny backup powinien zawierać 1378 MB. Przyczyna niekompletności archiwów jest trywialna. Blog Informatyk Zakładowy działa na zwykłym dzielonym hostingu na serwerach Dreamhost. To w zupełności wystarcza, nagłe skoki odwiedzalności pomaga obsłużyć Cloudflare. Jedną z cech takiego hostingu jest jednak brak kontroli nad niektórymi parametrami – między innymi nad limitem czasu wykonania pojedynczego żądania HTTP. Ograniczona jest też ilość pamięci i przydział mocy procesora, bo jedna maszyna obsługuje kilkunastu lub kilkudziesięciu klientów. Dwuminutowy timeout sprawiał, że do archiwum trafiało nie więcej niż kilkaset megabajtów…

Pierwotne źródło problemów

Dlaczego o awarii nie dowiedziałem się wcześniej? Poniżej opisuję sekwencję wydarzeń, które złożyły się na taką sytuację.

W marcu 2020, kilka miesięcy po założeniu bloga, skonfigurowałem jego automatyczny backup. Zdecydowałem się na plugin BackWPup do WordPressa ze względu na dużą elastyczność i konfigurowalność. Mi zależało na dwóch cechach – połączeniu kopii plików z kopią zawartości bazy danych MySQL oraz wysyłaniu backupów do AWS S3.

Zdefiniowane przeze mnie zadanie tworzyło kopię bezpieczeństwa raz na dobę. Przez następny tydzień kilkukrotnie upewniałem się, że kopia jest tworzona poprawnie, że zawiera wszystkie pliki, że zrzut zawartości bazy jest prawidłowy. Skonfigurowałem też w BackWPup e-maile z powiadomieniami o błędach.

W planach miałem przeorganizowanie domowych backupów, lecz zakup NAS-a był oddalony o kilka miesięcy. Nastawiłem więc cykliczne przypomnienia o sporządzaniu kopii bezpieczeństwa komputera na przenośny dysk oraz o testowaniu poprawności backupu bloga. W obu przypadkach – na półtora roku do przodu, do tego czasu nowy system backupów miał już działać.

W drugiej połowie 2020 opublikowałem trzyczęściowy poradnik tworzenia backupów w domu i małej firmie, zaś w styczniu 2021 kupiłem sobie Synology DS220j oraz dwa dyski Seagate IronWolf ST6000VN001 spięte w RAID-1 (replikacja danych, backup odporny na awarię jednego napędu). Blog nadal backupował się jednak tylko na S3. Uznałem, że kopia w chmurze AWS będzie wystarczającym zabezpieczeniem. W końcu sprawdzałem ją regularnie.

W okolicach wakacji 2021 cykliczne powiadomienie wygasło a ja nie odnotowałem tego faktu. Blog obrastał w nowe treści, w artykułach osadzałem duże pliki audiowizualne, kopie bezpieczeństwa puchły i wtedy właśnie backup zawiódł po raz pierwszy. Potem po raz drugi, trzeci – aż do momentu, gdy powiódł się po raz ostatni. Ale ja wtedy nie sprawdzałem już poprawności archiwów, bo moją czujność uśpiło półtora roku prawidłowego działania.

Ale co z tymi alertami e-mailowymi, zapytacie? Zastanówmy się… czy wymusiłem wystąpienie błędu by sprawdzić doręczalność alertów? Pytanie niby retoryczne, ale napiszę to wprost: nie, nie sprawdziłem działania powiadomień o awariach, więc żadna z setek wiadomości nie trafiła do mojej skrzynki.

Co i jak naprawiłem

Pierwszym krokiem w ogarnięciu tej sytuacji było oczywiście sporządzenie i zabezpieczenie pełnej kopii bezpieczeństwa bloga. Ta historia jest już na tyle zawstydzająca, że zbędne jest ubarwianie jej dykteryjkami w stylu „… i wtedy właśnie naprawdę straciłem dane”. Zanim zabierzesz się do jakiejkolwiek pracy nad infrastrukturą, sporządź pełną kopię danych.

Krok drugi – naprawienie alertów. Tu przyczyna okazała się trywialna – adresem nadawcy alertu miał być e-mail w domenie @gmail.com. Mechanizmy wysyłki maili nie miały uprawnień do wysyłania maili w imieniu Gmaila. Gdy zmieniłem domenę na @informatykzakladowy.pl i odpaliłem backup, już po kilku minutach dostałem maila o tytule „[ERROR] BackWPup log 26-lut-2022 18:10: backuptos3”

Krok trzeci – rozdzielenie zadań backupowania na mniejsze części i dopasowanie ich do rzeczywistych potrzeb:

• backup bazy danych – wydzielony jako osobne zadanie, zawiera dane których nie dałoby się odtworzyć w sensowny sposób (np. komentarze czytelników)
• backup pluginów – choć serwis używa tylko dziesięciu, to w ich skład wchodzi prawie 9 tys. plików zgrupowanych w przeszło 2 tys. katalogów; są to pliki które dobrze się kompresują
• backup wszystkich pozostałych plików.

W przypadku tej ostatniej części zmian było najwięcej. Po pierwsze – wyłączyłem kompresję ZIP, bo lwia część objętości kopii bezpieczeństwa to pliki PNG, JPG i MP4, których nie da się skompresować jeszcze bardziej. Zamiast ZIP-a jest TAR (bez kompresji), więc operacje plikowe przyspieszyły. Po drugie – wyłączyłem backup plików cache (tymczasowych), one nie przydadzą się do niczego. Po trzecie – backupowane pliki nie zawierają teraz zasobów audio-wideo z minionych lat; ich kopie mam gdzie indziej.

Po wprowadzeniu opisanych zmian czas tworzenia każdej z trzech części backupu nie przekracza półtorej minuty. Aby uniknąć niepożądanych interakcji, startują co kwadrans. A skoro grzebałem już w ustawieniach WordPressa, to aktywowałem także automatyczne aktualizacje wszystkich pluginów. W przeszłości robiłem to ręcznie, w godzinach najmniejszego ruchu – za to z wielodniowym opóźnieniem. Ryzyko wynikające z używania nieaktualnych pluginów jest jednak większe, niż niedogodności związane z kilkuminutową niedostępnością witryny.

Czy w razie awarii/włamania utraciłbym dane na zawsze?

Rozważmy następujący scenariusz – ktoś zyskuje możliwość wykonania kodu na serwerze Informatyka Zakładowego, usuwa zawartość bazy danych WordPressa i kasuje wszystkie pliki. Zauważam to kilka godzin później, wtedy też odkrywam uszkodzone backupy. Co mi pozostaje?

Po pierwsze – Dreamhost

Mój dostawca hostingu to Dreamhost, z usług tej firmy korzystam od roku 2005. Robią świetną robotę i jestem bardzo zadowolony z ich usług, choć nie są najtańsze. Gdyby ktoś szukał rzetelnego hostingu, oto link afiliacyjny (59% zniżki).

W panelu zarządzania witryną można odnaleźć następującą opcję:

Dreamhost oferuje automatyczne przywrócenie witryny z własnych backupów – najnowszy, „środkowy” lub najstarszy. Po wybraniu odpowiedniej opcji pliki zaczęły spływać na moje konto w ciągu minuty, kompletna zawartość katalogu została przywrócona w ciągu niecałego kwadransa.

Co z bazą danych? Podobnie – do dyspozycji mam opcję przywrócenia zawartości bazy z jednej z siedmiu kopii tworzonych codziennie przez miniony tydzień. To oznacza, że teoretycznie byłbym w stanie podnieść serwis w ciągu kilkunastu minut. W praktyce jednak zacząłbym od analizy powłamaniowej, by blog przywrócony z kopii bezpieczeństwa nie został shackowany ponownie.

Po drugie – niekompletny backup to też backup

WordPress składa się z dużej liczby plików oraz jednej bazy danych. Utrata plików składających się na mechanizm publikacji treści jest nieistotna, odzyskamy je po świeżej instalacji. Podobnie będzie z pluginami oraz wystrojem graficznym. Do odtworzenia jest znakomita większość obrazków używanych w blogonotkach – mam je w domowym komputerze.

Pozostaje temat tekstowego zrzutu zawartości bazy danych. Ten plik ma 50 MB, po kompresji około 10 MB. I tu dobra wiadomość – był obecny w każdym z niekompletnych backupów, bo kopia bazy sporządzana jest w pierwszym kroku. Nawet uszkodzona kopia bezpieczeństwa może więc zawierać kluczowe zasoby! Te dane byłyby o tyle cenniejsze, że w domowych backupach nie miałem finalnych treści blogonotek w takiej postaci, w jakiej trafiały do publikacji.

Po trzecie – archive.org

Gdyby wszystkie metody odzyskania danych zawiodły, ostatnią opcją byłaby ich rekonstrukcja. Serwis Internet Archive (archive.org) sporządził zrzuty zawartości bloga Informatyk Zakładowy 41 razy. Najprawdopodobniej byłbym w stanie wyciągnąć stamtąd treść wszystkich opublikowanych dotąd artykułów oraz część obrazków.

Jak widać, mimo wielu wielomiesięcznej awarii backupów bloga, sytuacja po ewentualnym włamaniu byłaby trudna ale nie beznadziejna. Zauważmy jednak, że mowa o stronie internetowej na WordPressie, publikowanej w internecie. Gdyby w grę wchodziły dokumenty lub dane księgowe małej lub średniej firmy, uszkodzony backup mógłby stanowić dużo większe zmartwienie.

Moja prywatna strategia kopii bezpieczeństwa

Swoje backupy tworzę według zasad, które opisałem w darmowym e-booku o kopiach bezpieczeństwa w domu i małej firmie.

Kopia odporna na ransomware to dysk zewnętrzny WD My Passport 1TB z kontenerem VeraCrypta. Kopiuję tam ręcznie (według ustalonego harmonogramu) te pliki, których utrata byłaby najbardziej bolesna.

Kompletna lokalna kopia danych leci na NAS Synology DS220j, do którego włożyłem dwa dyski Seagate IronWolf ST6000VN001 spięte w RAID-1. Ten backup wykonywany jest automatycznie oprogramowaniem kopia.io.

Kopię przechowywaną w innym miejscu realizuję za pomocą Backblaze, usługi zdalnego backupu do chmury (czytaj: na cudze komputery).

Uprzedzając pytanie – tak, czasem sprawdzam, czy ten albo tamten plik daje się wyciągnąć z opisanych wyżej backupów i czy jego zawartość jest prawidłowa.

Test odtworzenia bloga z backupu

Za chwilę pojawi się żargon, nie będzie opatrzony objaśnieniami. Bez większej straty możesz pominąć ten rozdział i przeskoczyć bezpośrednio do zakończenia.

W końcu możemy przejść do tematu, od którego zaczęła się cała ta historia – test odtworzenia bloga z backupu. Sam nie zajmuję się administracją systemów i nigdy nie utrzymywałem ani nie zabezpieczałem publicznie dostępnych serwerów WWW, więc jako kryterium sukcesu przyjąłem dostępność serwisu w izolowanej od sieci maszynie wirtualnej.

Uruchomiłem świeżo zainstalowanego Ubuntu 21.04, przeniosłem do niego trzy pliki z backupem bloga.

0:00
Czas start.

0:05
zainstalowałem Apache oraz MariaDB, zgodnie z tym tutorialem

0:10
zainstalowałem phpMyAdmin prawie zgodnie z tym tutorialem, utworzyłem użytkownika bazodanowego z wszystkimi przywilejami, spróbowałem zaimportować plik SQL. Nie udało się, wygooglałem komunikat błędu. Przyczyna problemu – maksymalny domyślny rozmiar uploadu to 2 MB, backup bazy ma 50 MB. Odnajduję plik konfiguracyjny PHP, zmieniam tę wartość na 200 MB. Maksymalny rozmiar uploadu rośnie do… 8 MB. Odnajduję inny parametr, maksymalny rozmiar żądania POST, podbijam wartość. Tym razem import startuje, minutę później baza jest przywrócona. Wyłączam maszynie wirtualnej połączenie z siecią.

0:15
rozpakowuję backup do katalogu z którego Apache serwuje witrynę, zmieniam w pliku wp-config.php ustawienia bazy danych, próbuję załadować zawartość http://localhost. Zostaję przekierowany na adres domenowy. Przypominam sobie, że muszę przestawić w tabeli wp_options bazowy adres bloga na „localhost”. Potem trzeba jeszcze wyczyścić cache przeglądarki, by zapomniała o przekierowaniu, i…

0:20
lokalna kopia bloga działa.

Cały proces przebiegł bezproblemowo, ale nie mogłem tego wiedzieć, póki nie sprawdziłem. Oczywiście – tak postawiony i skonfigurowany serwer nie nadawałby się do wystawienia na świat, ale skoro WordPress odtworzony z backupu działa na localhoście, to zadziała też po przywróceniu na docelowym hostingu (zarządzanym przez ludzi wiedzących co robią).

Zakończenie

Uszkodzone backupy odkryłem, zanim stały się potrzebne. Mogłem w spokoju przeprowadzić analizę problemu, zastanowić się nad ewentualnym planem „B” i „C”, naprawić alerty itd. Takiego komfortu nie miałbym w obliczu rzeczywistej awarii i konieczności przywracania serwisu z niekompletnych kopii bezpieczeństwa.

Jeśli robisz backupy – sprawdź ich integralność teraz! (no i daj znać w komentarzu, jeśli właśnie na jaw wyszły jakieś problemy)

Jeśli nie robisz backupów ale chcesz zacząć, zapisz się na newsletter – od razu po potwierdzeniu subskrypcji otrzymasz e-booka, dzięki któremu JUŻ DZIŚ zabezpieczysz kopię najważniejszych plików.

Nie masz gdzie trzymać backupów? Musisz kupić odpowiedni sprzęt albo usługę? Będzie mi bardzo miło, jeśli skorzystasz z linków afiliacyjnych obecnych w tym artykule. Ty zapłacisz tyle samo, a ja dostanę niewielką prowizję od twoich zakupów. Polecam sprzęt i oprogramowanie, którego sam używam:

• Backblaze – backup do chmury bez limitu wielkości. Działa w tle i non stop backupuje zawartość twojego komputera. Korzystam od wielu lat. Cena: 70 USD rocznie (marzec 2022)
• WD My Passport 1TB / 2TB / 4 TB – dyski zewnętrzne z interfejsem USB 3
• SanDisk Ultra Dual Drive USB-C 128GB / 256 GB – pendrive z podwójną wtyczką USB A / USB C
• NAS Synology 220j – do domu i małego biura, miejsce na 2 HDD (tutaj zestaw z 2 x HDD 4 TB)