To jest 298. odcinek podcastu Porozmawiajmy.IT. W duecie z Łukaszem Drynkowskim z portalu pracy IT Solid Jobs, który współtworzę, bierzemy na tapet wpadki, fuck-upy i błędy w IT. Będzie trochę serio, trochę na luzie, ale zawsze na temat. Słuchawki na uszy i odpalamy.

Łukasz:
Cześć Łukasz. Cześć Krzysztof.

Krzysztof:
To już nasze drugie spotkanie w ramach serii podcastów o wpadkach i fuck-upach w IT. A dzisiaj będziemy mówić o tym, że ludzie dzielą się na dwie kategorie, na tych, którzy robią backupy i na tych, którzy dopiero będą je robić i jest to taki cheesy joke, albo jak to się ładnie po polsku mówi, żart z wąsem czy tam z brodą, ale okazuje się, że nawet w dzisiejszych czasach, w których o cyberbezpieczeństwie mówi się coraz więcej, to niestety backupy nadal gdzieś tam leżą. I to nie tylko robienie właśnie tych kopii zapasowych, można powiedzieć, leży wśród osób, które z IT nie mają nic wspólnego, ale jak sobie pewnie za chwilę tutaj opowiemy, również ci, którzy na co dzień się tą branżą zajmują, no to również mają istotne i poważne wpadki, jeśli chodzi o backupy. Zgodzisz się, Łukasz, z tym, że są właśnie takie dwie kategorie, czy może coś tu możemy dorzucić?

Łukasz:
Ja bym to nawet właśnie rozszerzył, bo powiedziałbym, że taka trzecia kategoria to ludzie, którzy myślą, że robią backupy, a tutaj się okazuje, że jednak tych backupów nie ma, nie umieją ich odtworzyć, albo są backupy, ale są w jakiś sposób uszkodzone, niezdatne do użytku i to chyba jest taki… Największy problem, o czym może tutaj trochę sobie opowiemy szerzej za chwilę.

Krzysztof:
No właśnie, bo jak nie robisz tych backupów, to przynajmniej możesz dzisiaj

Problemy z odtwarzaniem backupów

Krzysztof:
po tym odcinku mieć takie wyrzuty sumienia, że powinieneś coś z tym zrobić. A jak wydaje ci się, że robisz, a tak naprawdę masz różne problemy z tym związane, o czym dzisiaj będzie, no to jesteś w czarnej, no nie, bo właśnie dopóki coś się nie wysypie, dopóki coś się nie przewróci, to się o tym nie dowiesz, a jak wiadomo wtedy to być może będzie ci kosztowało dużo czasu i pieniędzy. No dobrze, to co,

Łukasz:
Zaczynamy o tych grzechach. Ja bym tutaj chciał właśnie zacząć może od tego problemu odtwarzania backupów, bo to mi się wydaje, że jest takie mniej oczywiste, no bo to, że ktoś nie robi backupów, no to… Jakby nie będziemy tutaj truli. Wydaje mi się, że taką fajną poradą to jest w ogóle, żeby to odtwarzanie backupów gdzieś wpleść w naszą działalność, bym to tak nazwał. I tutaj mogę taki fajny przykład podać. Załóżmy, że tworzymy instancje testowe dla użytkowników i mamy taki proces, że jakoś klient się do nas zgłasza i tworzymy dla niego taką instancję testową, no to w takim przypadku.

Łukasz:
Może to się dziać właśnie poprzez odtworzenie backupu i w ten sposób będziemy na żywo testować, znaczy na żywo może to jest złe słowo, ale po prostu te testy odtworzeniowe będą ciągłe i będziemy mieli taką jakby pewność, że udaje się odtworzyć te backupy. No i w ten sposób właśnie nie jest tak, że robimy coś dodatkowo, tylko jest to takie naturalne i wydaje mi się, że w ten sposób możemy nawet zapomnieć o tym, że jest taki problem, żeby przećwiczyć na przykład takie odtwarzanie, no bo to się zawsze dzieje i jest to w miarę regularne. Także taka moja porada, żebyśmy po prostu umieli odtworzyć, żebyśmy mieli to przećwiczone, a w miarę możliwości właśnie gdzieś to wpleść w takie procesy gdzieś biznesowe.

Krzysztof:
Mówiliśmy kiedyś o robieniu takich kata, czyli takich właśnie ćwiczeń, które mają nas wprawić w jakimś tam rzemiośle, w jakimś tam w języku, w frameworku i tak dalej, i tak dalej. No i tak samo jest z backupami, jeśli czegoś nie przetworzymy, a konkretnie nie przećwiczymy, a konkretnie odtwarzania tych backupów, no to później może nam to iść znacznie wolniej w momencie, kiedy będzie nam to potrzebne. Ja natomiast chciałbym jeszcze słówko o tym braku robienia backupów, bo myślę sobie, że może warto powiedzieć, że to wcale nie znaczy, że my musimy wszystko backupować, jednak jeśli podejmujemy taką decyzję świadomie, że na przykład pewnych serwisów, jakichś baz danych testowych i tak dalej nie warto backupować, no to jak najbardziej ma to sens. Czasem, kiedy rozwijamy jakiś projekt, kiedy jest to jakiś projekt hobbystyczny,

Kiedy nie robić backupów?

Krzysztof:
no pewnie też nie warto robić backupów. No musimy tylko uważać i mieć na względzie to, co niektóre startupy nieraz przeoczają, czyli kiedy już przechodzimy w jakąś fazę mniej lub bardziej produkcyjną, kiedy jakieś tam pieniądze i dane konkretne krążą w tym naszym systemie, no to musimy się jednak gdzieś tam przebudzić i do tego tematu backupów wrócić.

Krzysztof:
Często jest to temat jakiś tam nieprzyjemny albo wydaje się,

Wyzwania związane z retencją backupów

Krzysztof:
że przemy do przodu kolejne feature’y na produkcję. Kto by tam myślał o backupach, ale tak, to jednak trzeba się niestety zatrzymać za jakiś czas i ten temat wziąć na tapet.

Łukasz:
Ciekawe tutaj wątek poruszyłeś, bo rzeczywiście backupy to też jest trochę taki trade-off związany z kosztami tych backupów czy też czasem, który nam zajmuje zrobienie. Wiadomo, automatyzujmy i miejmy to zautomatyzowane, no ale czasami jednak jest choćby potrzebny czas, żeby to skonfigurować. Natomiast z tym się wiąże też pojęcie retencji backupu, czyli czasu, przez jaki przechowujemy dany zbiór danych. No i tutaj to jest, bym powiedział, taki szczególny przypadek braku backupu, czyli backup, który mamy, ale jest bardzo na przykład krótko żyjący, na przykład mamy backup tylko… Z ostatniej godziny i zauważamy jakiś problem po dwóch godzinach i już nie jesteśmy w stanie wrócić do sytuacji sprzed tego problemu. Może być też tak, że mamy właśnie backup, załóżmy plików i mamy w dwóch różnych lokalizacjach te pliki. W ogóle one są w innych geolokalizacjach, wszystko fajnie, ale co z tego, jeśli przy nadpisaniu plików w jednej lokalizacji automatycznie to się dzieje też w drugiej. I jeśli przez przypadek właśnie nadpiszemy jakimś uszkodzonym plikiem albo nie tym co trzeba, no to już nie jesteśmy w stanie tego odtworzyć. Czyli niby mamy backup, ale jednak się okazuje, że go nie ma.

Gdzie przechowywać backupy?

Krzysztof:
No właśnie, to jest duży problem, a jednocześnie ważna kwestia, którą ty rozpocząłeś, czyli gdzie my te nasze backupy chcemy umieścić, bo chyba takim najgorszą wpadką czy najgorszym błędem jest robienie tych backupów lokalnie, na tym samym dysku na przykład, gdzie znajduje się baza danych, system itd. No i sam raz miałem taki przypadek, czy też właśnie obserwowałem taką sytuację, kiedy dane z serwera były backupowane na dysku tego samego serwera i doszło do fizycznego uszkodzenia tego dysku i okazało się, że tylko nie ma produkcji, ale również nie ma backupu, z którego by tą produkcję dało się odzyskać. Jeśli wydaje wam się, że tak, to to się może tylko wydarzyć na serwerze, no to łatwo można sobie to przełożyć na swój własny gdzieś tam laptop z pracy, który jest po pierwsze urządzeniem, które łatwo można uszkodzić albo ukraść. Jeśli te backupy znajdują się tylko tam, to wiadomo, że to jest kompletnie antypattern, ponieważ z utratą całego systemu czy uszkodzeniem dysku wiąże się również utrata backupu.

Łukasz:
Także podsumowując to, co powiedziałeś, no to musimy zadbać o to, żeby te backupy nie leżały w tym samym miejscu, na tym samym dysku, czy też nawet w tym samym pokoju. Tutaj kradzież albo jakaś katastrofa, pożar, to to już także skreśla ten problem. Natomiast jeśli robimy takie backupy, załóżmy dla siebie, na przykład backup zdjęć, no to to jest trochę problematyczne, jeśli chcemy mieć ten backup lokalnie, a nie chcemy mieć go w chmurze, żeby mieć te zdjęcia… Na jakimś dysku, który jest w jakiejś innej lokalizacji na poddaszu w domu rodziców, bo nie jesteśmy w stanie wtedy tego backupu robić systematycznie, jeśli nie mamy dostępu do tego dysku. Możemy tu jakieś wprowadzić jakąś rotację tych dysków, jakieś tego typu wymyślić rozwiązania systemowe, natomiast jeśli byśmy chcieli mieć w pełni zautomatyzowany backup, no to myślę, że tutaj jednak jest potrzebna jakaś forma chmury, czy też właśnie taki serwer NAS gdzieś w nazwijmy, na poddaszu u rodziców. Dokładnie, dokładnie.

Testowanie procedur odtwarzania

Krzysztof:
To faktycznie ma duże znaczenie i do tego pewnie jeszcze dzisiaj wrócimy. Wspomniałeś tutaj o robieniu takich testów odtworzeniowych, czyli sprawdzania, czy ta nasza procedura odtworzenia z backupu faktycznie działa. Myślę, że możemy to rozszerzyć o logowanie tego sprawdzania, czy w ogóle tworzenia backupów, no bo może się okazać, że na przykład odtworzyliśmy coś z backupu, ale na przykład tam czegoś brakuje, coś nie działa po uruchomieniu systemu. No i jeśli nie mamy takiego loga tego, co właściwie udało nam się odtworzyć, to ciężko jest zdebugować, co tutaj poszło nie tak i najgorzej oczywiście, jeśli to się wydarzy już w realnej sytuacji. Natomiast podczas testów to jest świetny materiał do tego, żeby całą tą procedurę tworzenia backupu, jego odtworzenia po prostu ulepszać, więc o te logi warto z pewnością zadbać.

Łukasz:
Ja bym to w ogóle zaczął od tego, że musimy mieć nie wiem jak to się fachowo nazwać, ale plan backupu i wiedzieć właśnie z jaką retencją, czy mamy załóżmy, że mówimy znowu tu o bazach danych, no to, jak często robimy, backup całej bazy, jak często robimy backupy przyrostowe i jakiego typu backupy trzymamy i jak długo je trzymamy i tu musimy mieć, Plan to musi jakby brać pod uwagę częstotliwość, koszty i też to, co to są za dane, czy to są też dane, czy czy mamy te dane też w jakimś takim hot storage’u, czy w cold storage’u, czyli czy jakby potrzebujemy w razie awarii na przykład bazy danych mieć możliwość natychmiastowego przepięcia się z jednej bazy do drugiej, żeby ten produkcyjny system cały czas działał. Czy może te backupy mogą gdzieś być w tańszym rozwiązaniu, gdzieś sobie leżeć na jakichś storjach plików po prostu i w razie czego jakiś mechanizm nam tą bazę przywróci. Ja mówię o bazie, ale oczywiście możemy tu sobie inne typy danych także podstawić.

Krzysztof:
Dokładnie, pewnie nikogo nie zdziwisz, że lepiej jest mieć te rzeczy zautomatyzowane, zarówno tworzenia jak i odtwarzania, ale z tym się wiąże pewne ryzyko, że zbyt mocno polegamy na tej automatyzacji i po prostu nie weryfikujemy tego w żadną stronę, więc oczywiście automatyzacja będzie lepsza niż zapisywanie sobie w kalendarzu i robienie tego ręcznie, ale musimy być świadomi, że tą procedurę zarówno tworzenia, jak i odzyskiwania musimy właśnie weryfikować, sprawdzać, czy ona nadal działa, bo może się okazać, że z powodu podbicia jakichś paczek czy systemu i tak dalej nagle ten nasz skrypt na przykład ma problem, nie tworzy kopii albo nie będzie w stanie ją stworzyć, więc warto to monitorować.

Łukasz:
Ja bym powiedział, że taka sytuacja, że robimy backupy ręczne, to po prostu jest szczególna sytuacja braku backupów. Także jeśli nie jest to zautomatyzowane to możemy po prostu założyć, że,

Bezpieczeństwo backupów

Łukasz:
że nie ma takich backupów.

Krzysztof:
Tak, czyli co, robimy sobie backup, wrzucamy na publiczną S3-kę i wszystko będzie dobrze.

Łukasz:
Tak, to dochodzimy tutaj do kolejnego problemu, czyli bezpieczeństwo backupów i bezpieczeństwo.

Łukasz:
Często jest tak, że same pliki na przykład produkcyjne albo sama baza produkcyjna jest zaszyfrowana, jest w bezpiecznym miejscu, jest w prywatnej sieci, lokalnej dla naszego serwera aplikacyjnego. Natomiast często jest tak, że same backupy już mają zupełnie inny poziom bezpieczeństwa, inny poziom tej dokładności, może tak powiedzmy. Często bywa tak, że wycieki danych gdzieś tam w internecie to nie są wycieki właśnie danych tych właściwych produkcyjnych, tylko to są wycieki gdzieś danych właśnie kopii zapasowych. Tak, kopii zapasowych. Często jest tak, że na przykład jakieś kopie zapasowe gdzieś trafiły do programistów w celu jakiegoś zbadania jakiegoś problemu i tutaj ktoś na przykład nie zanonimizował wcześniej tej bazy danych czy tam innych plików backupowych. Tego typu sytuacja także nie powinna nigdy mieć miejsca. Te dane nigdy nie powinny opuścić w takiej formie niezanonimizowanej serwera aplikacyjnego. Także nie powinniśmy też dopuścić, żeby, nie wiem, słyszałem gdzieś, że kolega tak zrobił, żeby się połączyć do bazy produkcyjnej.

Łukasz:
Gdzieś tam na debugu z lokalnej instancji. To tego typu sytuacje powinny być niedopuszczalne i systemowo po prostu zablokowane.

Automatyzacja procesu backupów

Krzysztof:
No tak, to jest na pewno proszanie się o problemy. Z tym też wiąże się częsty problem, częsta wpadka związana z tym, że okej, co prawda sobie szyfrujemy, anonimizujemy dane i wszystko jest legitnie, ale okazuje się, że to tylko ten najwyższy w hierarchii programista, administrator, czy ktokolwiek posiada i wiedzę jak to zrobić, albo też jakieś klucze, które umożliwiają wykonanie tej procedury, jeśli jakoś tej osoby nie ma albo zabraknie, no to mamy problemy.

Łukasz:
Także częścią bezpieczeństwa backupów to jest tego, co mówiliśmy, czyli, umiejętności odtworzenia, to posiadanie tych kluczy, bo to też może być tak, że mamy backupy, ale nie mamy kluczy albo zostały właśnie, odeszły z jakąś osobą albo nie wiem, nie umiemy, może mamy kluczy, ale nie wiemy jaką metodą to było, zaszyfrowane, nie umiemy odszyfrować. To też słyszałem od kolegi, że tak się zdarza.

Krzysztof:
Zdarza się, zdarza i to wcale nierzadko. No właśnie, bo tak naprawdę to ten proces tworzenia i odtwarzania można w dużym stopniu też zautomatyzować, jeśli chodzi o testowanie. W sensie to nie znaczy, że my tam musimy sobie to przeklikiwać wszystko ręcznie. Oczywiście jak najbardziej to pewnie jest potrzebne, ale żeby mieć taką pewność w miarę na bieżąco, to może być jakiś element automatyzacji, jakiś element procesu DevOpsowego, który pozwoli nam zweryfikować, czy ten skrypt do tworzenia i odtwarzania działa poprawnie, czy ten wynik na końcu jest poprawny. Więc nie musimy tylko polegać na wiedzy, na pamięci dewelopera czy administratora. Możemy sobie to też jak najbardziej zautomatyzować.

Łukasz:
Tutaj też troszkę chciałbym tylko zasygnalizować taki problem też związany z odtwarzaniem backupów, czyli problem też idem potentności operacji i wyobraźmy sobie, że mamy jakiś system, który kieruje na przykład dzieci na szczepienia i teraz dzieci dostały na przykład takie zlecenie szczepienia, a my tutaj odtworzymy jakiś starszy backup i dostaną drugi raz na przykład zlecenie tego szczepienia. I tutaj oczywiście gdzieś tam czynnik ludzki powinien zadziałać jakieś inne procedury, ale jak widzimy może dojść tutaj do takiego problemu, że odszyfrowaliśmy ten backup, odtworzyliśmy, wszystko jest ok, ale jakby wybraliśmy zły moment w czasie i ponownie jakaś operacja gdzieś zostanie wykonana, nie wiem,

Strategie backupów w praktyce

Łukasz:
obciążone konto gdzieś zostanie ponownie. Tego typu właśnie sytuacje, gdzie coś nie powinno zostać wykonane więcej niż raz, no a ponieważ jakby straciliśmy tą historię między, backupem, a tym momentem odtworzenia, no to może to generować różnego rodzaju problemy.

Krzysztof:
No tak, to jak gdyby nie tylko może być wina backupów, albo nie tylko jak gdyby przy pomocy samego robienia backupów można rozwiązać, no bo to wymaga pewnie jakiegoś innego podejścia do architektury, albo wręcz zaplanowania, przemyślenia jak system zachowa się właśnie w takiej sytuacji. A to z kolei sprowadza mnie do tego, co nieraz jest właśnie takim problemem i też swego rodzaju wpadką, jeśli chodzi o robienie backupów, że mamy założenie, że zbackupujemy sobie bazę danych, robimy sobie jakieś regularne backupy bazy danych i jesteśmy bezpieczni i wszystko jest załatwione. To jest oczywiście błąd i oczywiście niedopatrzenie, ponieważ nasza aplikacja to nie tylko dane, które tam gdzieś w jakimś postgresie MySQLu czy innej bazie danych się znajdują, ale cały ekosystem różnych usług, które z sobą współpracują i plików, które tworzą ten system. Więc musimy też pamiętać i mieć z tyłu głowy, co będziemy backupować, aby dało się w sposób sensowny odzyskać system, który będzie gotowy do działania, a nie tylko bazy danych. Tak, także jeśli wiemy, że backup bazy danych albo odtworzenie bazy danych to jest tylko jeden z elementów na całej tej naszej liście odtworzeniowej, no to może właśnie warto pomyśleć o planie. Co myślisz?

Łukasz:
Tak, myślę, że taki plan awaryjny jest ważny. Ważny jest też, Posiadanie odpowiednich procedur w firmie i ważne jest przećwiczenie takiej właśnie testowej awarii. Tak jak mówię, można tutaj też w ramach procesów biznesowych, na przykład postawienia takiej nowej instancji, mieć to gdzieś wpięte. Natomiast zawsze jakby taka awaria zasymulowana i takie ćwiczenie, nie wiem, choćby raz w roku dla zespołu senior deweloperów, devopsów, no to myślę, że to jest fajny pomysł też w takim kontekście budowania w zespole jakiejś tam wspólnoty, czy też budowania odpowiedzialności też za tego typu sprawy. Nie tylko zrobiłem swoje tutaj, ale w razie problemów, żeby też każdy miał przypisane

Pytania na rozmowie rekrutacyjnej

Łukasz:
jakieś role i żebyśmy umieli tutaj zadziałać. Także dam takiego Wam hinta, bo często jest takie pytanie też rekrutacyjne, czy też może nie konkretne pytanie, tylko w czasie rekrutacji czas na pytania od kandydata do rekrutera. To warto zadać na przykład pytanie jak często robicie backupy, jakie macie właśnie procedury związane z backupami, w jaki sposób ćwiczycie awarię, to myślę, że jakby ktoś zadał takie pytania na… Rozmowie rekrutacyjnej, to u mnie od razu by tutaj kilka punktów zyskał.

Krzysztof:
To po pierwsze, a po drugie sam fakt, czy firma w ogóle robi backupy, jak to robi, według mnie to dużo świadczy o kulturze i dojrzałości. Jeśli na pewnym etapie rozwoju firmy, czy też projektu pojawiła się taka potrzeba, bo wręcz wyszła ta potrzeba ze strony np. Zespołu technicznego, no to jest to też okazja do tego, żeby się czegoś nauczyć, jest to też okazja do tego, żeby właśnie zaznajomić się z takimi procedurami i zaznajomić z tym, jakie doświadczenie ten zespół nabył, więc według mnie… To jest zdecydowanie plus dla takiej firmy, która faktycznie w sposób dojrzały i odpowiedzialny do backupów podchodzi. To jest też po prostu problem z głowy dla zespołu technicznego, dla inżynierów. Jeśli takie backupy się tworzą, to po prostu nie musimy budzić w środku nocy oblani potem, że coś się wydarzy, jeśli nagle właśnie jakaś baza danych przestanie działać, serwer przestanie działać itd. Więc po prostu jest taka lepsza kultura codziennej pracy według mnie w firmie,

Podsumowanie i wnioski

Krzysztof:
która do backupów podchodzi rozsądnie.

Łukasz:
Bardzo dobrze powiedziane Krzysztofie. Chciałbym Ci jeszcze zadać jedno pytanie odnośnie strategii backupów. Jakie tutaj z Twojego doświadczenia są patterny często występujące?

Krzysztof:
Tak, pewnie bardzo takim już przerobionym, można powiedzieć często spotykanym patternem strategią jest 3.2.1. Strategia, którą mogliście słyszeć, jeśli gdzieś tam jakieś tematy takie związane z cyber security krążą wokół was, ale ona jak najbardziej tutaj nadal można powiedzieć działa i nie tylko w przypadku banków i dużych instytucji ubezpieczeniowych, ale również w przypadku mniejszych firm. Strategia 3.2.1 polega na tym, że robimy trzy kopie, trzy różne kopie tych naszych zasobów, można powiedzieć, różnego typu na dwóch różnych nośnikach, tak? Nie tylko można powiedzieć na dysku twardym, ale może właśnie gdzieś w inny sposób i oczywiście na trzech rozsianych różnie geograficznie lokalizacjach. Najlepiej, jeśli jedna z nich jest gdzieś zupełnie poza tym naszym bezpośrednim obszarem działania, naszą na przykład serwerownią, wtedy mamy jakiś tam poziom bezpieczeństwa zapewniony, ale też pewność, że w razie czego będziemy w stanie sprawnie odtworzyć te wykupy.

Łukasz:
My to zawsze mówiliśmy, że w razie gdyby meteoryt uderzył w tą serwerownię, żeby… Ta druga musi być odpowiednio daleko.

Krzysztof:
Żeby odłamkami nie dostała.

Łukasz:
Okej, myślę, że na tym powoli będziemy kończyć tą rozmowę.

Krzysztof:
Tak, ja jeszcze może podrzucę kilka takich wymówek, które gdzieś tam się słyszy nieraz wśród ludzi zajmujących się IT, które świadczą o tym, że ten temat nie został zaopiekowany odpowiednio wcześnie, czyli na przykład robienie backupu na pendrive’ie, Niby backupy były robione, ale ktoś tam z zespołu kiedyś ten mityczny pendrive zabrał, gdzieś zawiruszył i tak naprawdę backupów nie mamy.

Krzysztof:
Inną taką wymówką albo w ogóle błędnym pojmowaniem czym backupy są jest powiedzenie, że mamy wszystko przecież na Google Drive, więc Google robi dla nas backupy, te serwerownie są tam bezpieczne, więc my też jesteśmy bezpieczni. I nie musimy się w ogóle martwić o robienie backupów naszych danych, to oczywiście polecam tutaj, żeby zajrzeć sobie do umowy z Google. Myślę, że można wtedy jednak się trochę zaskoczyć. No i pewnie taką jeszcze kolejną wymówką jest powiedzenie, że przecież nasz dostawca chmurowy właśnie robi backupy, więc my nie musimy się już o to martwić, czyli jak gdyby delegujemy w sposób taki niewłaściwy to robienie backupów na firmy, które po prostu się tym dla nas nie zajmują. Chyba, że mamy oczywiście tam odpowiednie usługi wykupione, to jest jak gdyby inna bajka, ale myślę, że na koniec można tak jasno to powiedzieć, że to my jesteśmy odpowiedzialni za robienie naszych kopii zapasowych i za trzymanie tego procesu tworzenia i odzyskiwania up-to-date. Nikt tego za nas nie zrobi, lepiej sobie to uświadomić wcześniej niż później.

Zakończenie i zaproszenie do Solid Jobs

Krzysztof:
Tak, no to mamy wymówki, nie łapcie się na to, bo można faktycznie się ostro przejechać. To co Łukasz, spróbujemy podsumować?

Łukasz:
No jasne, to tak, po pierwsze, musicie nie tylko robić backupy, ale także umieć odtworzyć backupy, czyli czyćcie to regularnie, miejcie odpowiednie procedury, może też włączcie właśnie taki proces odbuckowywania danych gdzieś do procesów biznesowych, na przykład utworzenia testowych instancji. Po drugie pamiętajcie o bezpieczeństwie backupów, o ich szyfrowaniu, o tym, że dane zapasowe powinny być traktowane z taką samą pieszołowością jak dane produkcyjne, ponieważ często to one właśnie są tym słabym ogniwem bezpieczeństwa. Po trzecie pamiętajcie o tym, żeby przygotować odpowiedni plan retencji danych, plan backupowania, tak żeby był efektywny kosztowo i żeby spełniał Wasze założenia biznesowe. Ostatni punkt, no to pamiętajcie o tym, żeby nie tylko backupować bazę danych, ale żeby też zwrócić uwagę na inne elementy ekosystemu i zwróćcie uwagę na to, że takie właśnie odtworzenie bazy danych, jaki ma wpływ po prostu na Wasz system. Czy gdzieś nie będzie problemów związanych z tym, że… Pewne rzeczy, które już się wykonały, nie wykonają się na przykład po raz kolejny.

Krzysztof:
Dokładnie, czyli jednym zdaniem mówiąc, nie bądźcie w grupie ludzi, którzy myślą, że robią backupy, bo to później niestety mocno boli. My niezmiernie zapraszamy na Solid Jobs, gdzie możecie znaleźć mnóstwo ciekawych ofert z IT i nie tylko, zawsze z widełkami wynagrodzeń. Tam też możecie wystawić ogłoszenie, jeśli w waszym zespole brakuje jakiegoś specjalisty. Zapraszamy jeszcze raz na Solid Jobs. No i co? Oczywiście kolejne odcinki również wyniosą, myślę, istotną wiedzę, więc już teraz możemy na nie zaprosić.

Łukasz:
Tak, dodam, że Solid Jobs backupuje dane w dwóch geolokalizacjach niezależnych i wszystko szyfrujemy. Możecie się czuć spokojni wiemy.

Krzysztof:
O czym mówimy, dokładnie super, to dzięki Łukasz za dzisiaj dzięki bardzo,

Łukasz:
Do zobaczenia, na razie.