Porozmawiajmy o IT

Kopie zapasowe (backups). Gość: Łukasz Drynkowski - POIT 298

• Krzysztof Kempiński • Season 1 • Episode 298

Share episode

Witam w dwieście dziewięćdziesiątym ósmym odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy w serii podcastów o kopiach zapasowych czyli backups.

Dziś moim gościem jest Łukasz Drynkowski, z którym mam przyjemność współtworzyć portal z ofertami pracy dla branży IT o nazwie SOLID.Jobs.


Główne myśli o kopiach zapasowych z tego odcinka to:

  • lepszy jakikolwiek backup niż żaden
  • fuckupy związane z robieniem kopii zapasowych:
    • brak możliwości odtworzenia backupu
    • nie sprawdzenie logów z odtwarzania lub brak logów
    • backupy ręczne, brak automatyzacji
    • zbyt rzadkie punkty przywracania
    • brak szyfrowania
    • zbyt długi czas odtwarzania
    • brak planu awaryjnego, brak procedur
    • zła retencja backupów
  • zimne vs ciepłe backupy
  • robienie kopii zapasowych a kultura organizacyjna firmy


Subskrypcja podcastu:


Linki:


Wsparcie:


Jeśli masz jakieś pytania lub komentarze, pisz do mnie śmiało na krzysztof@porozmawiajmyoit.pl

https://porozmawiajmyoit.pl/298

Speaker 1:

To jest 298. odcinek podcastu. Porozmawiajmy IT W duecie z Łukaszem Dręgowskim z portalu pracy IT Solid Jobs, który współtworzem. 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. Cześć Łukasz.

Speaker 2:

Cześć Krzysztofie.

Speaker 1:

To już nasze drugie spotkanie w ramach serii podcastów o wpadkach i fuckupach 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ć?

Speaker 2:

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ę.

Speaker 1:

No właśnie, bo jak nie robisz tych backupów, to przynajmniej możesz dzisiaj 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, to jesteś w czarnej, Bo 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 zaczynamy.

Speaker 2:

Zaczynamy tak. 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 może to się dziać właśnie poprzez odtworzenie backupu, i w ten sposób będziemy na żywo testować, 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.

Speaker 2:

No, i w ten sposób właśnie nie jest tak, że robimy coś dodatkowo, 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.

Speaker 1:

Mówiliśmy kiedyś o robieniu takich kata, czyli takich właśnie ćwiczeń, które mają nas wprawić w jakimś rzemiośle, w języku, w frameworku, itd. Tak samo jest z backupami Jeśli czegoś nie przećwiczymy, a konkretnie odtwarzania tych backupów, 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ć. Tak Jednak, jeśli lubimy, jeśli podejmujemy taką decyzję świadomie, że na przykład pewnych serwisów, jakichś baz danych testowych i tak dalej nie warto backupować, nie warto backupować, no, to jak najbardziej ma to sens. Czasem, kiedy rozwijamy jakiś projekt, kiedy jest to jakiś projekt hobbystyczny, no, pewnie też nie warto robić backupów. 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 tam myślał o backupach. No, ale tak to jednak trzeba się niestety zatrzymać za jakiś czas i ten temat wziąć na tapet.

Speaker 2:

Ciekawy 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, 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, 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.

Speaker 1:

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ć. No, bo chyba takim najgzym wpadką czy najgorszym błędem jest robienie tych backupów lokalnie na tym samym dysku, na przykład gdzie znajduje się baza danych, system i tak dalej. 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. 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 to się może tylko wydarzyć na serwerze, 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, no, to wiadomo, że to jest kompletny antypatern, ponieważ z właśnie utratą całego systemu czy uszkodzeniem dysku wiąże się również utrata backupu.

Speaker 2:

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 nie wiem w jakiejś innej lokalizacji, tak u Nie wiem na poddaszu w domu rodziców. No, bo jakby 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, to myślę, że tutaj jednak jest potrzebna jakaś forma chmury czy też właśnie taki serwer NAS, gdzieś, nazwijmy, na poddaszu u rodziców.

Speaker 1:

Dokładnie dokładnie. 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, bo może się okazać że np odtworzyliśmy coś z backupu, ale np tam czegoś brakuje, coś nie działa po uruchomieniu systemu. Jeśli nie mamy takiego loga tego, co właściwie udało nam się odtworzyć, to ciężko jest zdebagować 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ć.

Speaker 2:

Ja bym w ogóle zaczął od tego, że musimy mieć nie wiem jak to się fachowo nazywa 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, no i jak długo je trzymamy, tak. I tu musimy mieć plan. To musi jakby brać pod uwagę częstotliwość, koszty i też to, co to są za dane, tak Czy to są też dane, czy trzymamy te dane też w jakimś takim hot? są za dane, czy to są też dane? czy mamy te dane też w jakimś takim hot storage'u czy w cold storage'u, czyli czy jakby potrzebujemy w razie nie wiem 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ś storage'ach, plików po prostu, i w razie czego jakiś mechanizm nam tą bazę przywróci, nam tą bazę przywróci. Ja tu mówię o bazie, ale oczywiście możemy tu sobie inne typy danych także podstawić.

Speaker 1:

Dokładnie. Pewnie nikogo nie zdziwi, ż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 odtworzyć. Więc warto to monitorować.

Speaker 2:

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 nie ma takich backupów.

Speaker 1:

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

Speaker 2:

Tak to dochodzimy tutaj do kolejnego problemu, czyli bezpieczeństwo backupów i bezpieczeństwo. 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 zapasowe gdzieś trafiły do programistów w celu jakiegoś zbadania, zbadania jakiegoś problemu. No, i tutaj ktoś na przykład nie zanonimizował wcześniej tej bazy danych czy tam innych plików backupowych, jakby to. Tego typu sytuacja także nie powinna nigdy mieć miejsca. Te dane nigdy nie powinny opuścić w takiej formie niezanonimizowanej z serwera aplikacyjnego. Także nie powinniśmy też dopuścić żeby słyszałem gdzieś, że kolega tak zrobił żeby się połączyć do bazy produkcyjnej gdzieś tam na debagu z lokalnej instancji. Tego typu sytuacje powinny być niedopuszczalne i systemowo po prostu zablokowane.

Speaker 1:

No, tak, to jest na pewno proszenie 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 wiedza, 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 problem Także częścią bezpieczeństwa backupów.

Speaker 2:

To jest i 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 klucze, ale nie wiemy jaką metodą to było zaszyfrowane, nie umiemy odszyfrować. To też słyszałem od kolegi, że tak się zdarza, Zdarza, się zdarza, i to wcale nierzadko.

Speaker 1:

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 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ć.

Speaker 2:

Tutaj też troszkę chciałbym tylko zasygnalizować taki problem też związany z odtwarzaniem backupów, czyli problem też idempotentnoś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 odtworzyliśmy, wszystko jest ok. Ale jakby wybraliśmy zły moment w czasie i ponownie jakaś operacja gdzieś zostanie wykonana, nie wiem, obciążone konto gdzieś zostanie ponownie. Tego typu właśnie sytuacje, gdzie coś nie powinno zostać wykonane więcej niż raz, a ponieważ straciliśmy tą historię między backupem a tym momentem odtworzenia, to może to generować różnego rodzaju problemy.

Speaker 1:

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, 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, mysql 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 bazę 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?

Speaker 2:

Tak myślę, że taki plan awaryjny jest ważny. Ważne 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łów, 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 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ł.

Speaker 1:

To po pierwsze, a po drugie no, sam fakt, czy firma w ogóle robi backupy, jak to robi, no, według mnie to dużo świadczy o kulturze i dojrzałości, prawda? Jeśli I 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, na przykład, 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ć się w środku nocy oblani potem, że coś się wydarzy, jeśli nagle jakaś baza danych przestanie działać, serwer przestanie działać i tak dalej.

Speaker 1:

Więc po prostu jest taka lepsza kultura codziennej pracy wed według mnie w firmie, która do backupów podchodzi, rozsądnie, bardzo dobrze powiedziane Krzpieczeniowych 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, no właśnie zasobów, można powiedzieć różnego typu, na dwóch różnych na przykład nośnikach, nie tylko 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 backupy.

Speaker 2:

To zawsze mówiliśmy, że w razie gdyby meteoryt uderzył w tą serwerownię, żeby ta druga musi być odpowiednio daleko.

Speaker 1:

Żeby odłamkami nie dostała.

Speaker 2:

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

Speaker 1:

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śniej. Czyli na przykład robienie backupu na pendrive 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. 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, 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ć. Można wtedy jednak się trochę zaskoczyć.

Speaker 1:

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ą. No, chyba że mamy oczywiście tam odpowiednie usługi wykupione. To jest 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. Tak no, to mamy wymówki. Nie łapcie się na to, bo można faktycznie się ostro przejechać. To co, łukasz, spróbujemy podsumować.

Speaker 2:

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 odbackupowania danych gdzieś do procesów biznesowych, na przykład utworzenia testowej instancji. Po drugie, pamiętajcie o bezpieczeństwie backupów, o ich szyfrowaniu, o tym, że tak żeby był efektywny kosztowo i żeby spełniał Wasze założenia biznesowe no-transcript backupy, bo to później niestety mocno boli.

Speaker 1:

My niezmiernie. niezmiennie 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ę, istotą wiedzę, więc już teraz możemy na nie zaprosić.

Speaker 2:

Tak dodam że Solid Jobs backupuje dane w dwóch geolokalizacjach niezależnych i wszystko szyfrujemy. Także możecie się czuć spokojni.

Speaker 1:

Wiemy o czym mówimy dokładnie Super to, dzięki, Łukasz, za dzisiaj.

Speaker 2:

Dzięki bardzo, do zobaczenia na razie.

Head Shot

Krzysztof Kempiński

Host