Porozmawiajmy o IT

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

• Krzysztof Kempiński • Season 1 • Episode 298

Share episode

Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.

0:00 | 27:58

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

Wprowadzenie do wpadek w IT

Speaker 1

, 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

Problemy z odtwarzaniem backupów

Speaker 1

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

Kiedy nie robić backupów?

Speaker 1

, 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

Wyzwania związane z retencją backupów

Speaker 1

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 .

Gdzie przechowywać backupy?

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

Testowanie procedur odtwarzania

Speaker 1

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

Bezpieczeństwo backupów

Speaker 2

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

Automatyzacja procesu backupów

Speaker 2

.

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

Strategie backupów w praktyce

Speaker 2

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

Pytania na rozmowie rekrutacyjnej

Speaker 2

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

Podsumowanie i wnioski

Speaker 1

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ę

Zakończenie i zaproszenie do Solid Jobs

Speaker 1

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