Kopia zapasowa w chmurze brzmi jak coś, co włącza się jednym kliknięciem. W praktyce wiele firm, które są przekonane, że ją mają, ma tak naprawdę tylko synchronizację plików z OneDrive albo Dropboxem. Różnicę widać dopiero wtedy, gdy trzeba coś odzyskać. W tym artykule pokażę, jak podejść do tematu tak, żeby backup danych firmowych w chmurze faktycznie zadziałał w dniu awarii. Omówię, jakie decyzje trzeba podjąć, w jakiej kolejności, i jak wygląda to w praktyce na przykładzie narzędzia, którego używam u swoich klientów.
Jeśli czytałeś mój wpis o zasadzie 3.2.1, to ten tekst jest jego ciągiem dalszym. Tam pisałem, dlaczego jedna kopia to za mało i dlaczego jedna z kopii powinna leżeć poza firmą. Tutaj zajmę się tym, jak tę kopię poza firmą skonfigurować.
1. Synchronizacja to nie kopia zapasowa
Synchronizacja robi jedną rzecz. Dba o to, żeby plik na komputerze i plik w chmurze były takie same. Jeśli usuniesz plik, zniknie on wszędzie. Microsoft pisze to wprost w dokumentacji OneDrive, gdzie czytamy, że usunięcie zsynchronizowanego pliku na urządzeniu usuwa go ze wszystkich urządzeń i z chmury. Ta sama logika dotyczy pliku nadpisanego złą wersją, uszkodzonego albo zaszyfrowanego przez ransomware. Synchronizacja grzecznie przeniesie zepsutą wersję do chmury.
Oczywiście jest kosz i historia wersji, ale mają one sztywne limity. Według pomocy technicznej Microsoftu pliki usunięte z firmowego konta OneDrive można przywrócić przez 93 dni, chyba że administrator zmienił to ustawienie. Po trwałym usunięciu z kosza nie da się ich już odzyskać. Funkcja przywracania całego OneDrive cofa zmiany tylko z ostatnich 30 dni. To dobre zabezpieczenie przed pomyłką z wczoraj, ale nie przed problemem, który ktoś zauważy po czterech miesiącach.
Jest też drugi powód, dla którego kopia musi być oddzielona od codziennej pracy. Atakujący doskonale wiedzą, że backup odbiera im argument do żądania okupu. W raporcie CERT Polska za 2025 rok zespół odnotował 179 ataków ransomware, najwięcej w historii swoich raportów, a większość zgłoszeń pochodziła od podmiotów prywatnych. Raport opisuje też, że operatorzy ransomware zwyczajowo starają się zniszczyć kopie zapasowe, a serwery kopii są jednym z ich pierwszych celów. Kopie na dyskach NAS w tej samej sieci atakujący po prostu wymazywali. Podobny obraz daje ankieta Sophos przeprowadzona wśród niemal 3 tysięcy organizacji. 94% ofiar ransomware zgłosiło próbę przejęcia kopii zapasowych, a w 57% przypadków ta próba się udała.
Wniosek jest prosty. Kopia zapasowa w chmurze ma sens wtedy, gdy jest osobnym, zaszyfrowanym repozytorium z historią wersji, do którego nie dostanie się nikt, kto przejmie komputer w biurze.
2. Co musi umieć dobra kopia w chmurze
Zanim wybierzesz narzędzie, ustal kilka wymagań. Po nich poznasz, czy masz do czynienia z prawdziwym backupem, czy z kolejnym folderem, który się synchronizuje.
Pierwsze i najważniejsze to szyfrowanie po stronie twojego komputera, zanim dane wyjdą do internetu. Wtedy dostawca przestrzeni w chmurze przechowuje wyłącznie zaszyfrowane bloki, z których nic nie odczyta. Dobre narzędzia używają do tego sprawdzonych algorytmów, takich jak AES w trybie GCM, opisanym w zaleceniu NIST SP 800-38D. Taki tryb nie tylko szyfruje dane, ale też wykrywa, czy ktoś je zmodyfikował. Drugie to historia wersji, czyli możliwość cofnięcia się do stanu z wczoraj, sprzed tygodnia albo sprzed pół roku, a nie tylko do ostatniej zsynchronizowanej kopii. Trzecie to deduplikacja. Jeżeli codziennie wysyłasz te same pliki, narzędzie powinno przesłać tylko to, co się zmieniło, bo inaczej po miesiącu zapłacisz za trzydzieści kopii tego samego.
Czwarte wymaganie łatwo przeoczyć. Backup musi działać w tle jako usługa systemu, a nie jako program, który ktoś musi uruchomić albo który startuje dopiero po zalogowaniu pracownika. Kopia, która zależy od tego, czy pani z księgowości pamiętała o kliknięciu, prędzej czy później przestanie się robić. Piąte to miejsce przechowywania danych. Jeśli w kopii są dane osobowe klientów albo pracowników, a w firmie prawie zawsze są, najprościej trzymać je w Unii Europejskiej. Unikasz wtedy analizowania zasad przekazywania danych do państw trzecich z rozdziału V RODO. Samo RODO w art. 32 wymienia zresztą wprost szyfrowanie danych, zdolność do szybkiego przywrócenia ich dostępności po incydencie i regularne testowanie zabezpieczeń. Dobrze skonfigurowany backup odpowiada na wszystkie trzy punkty.
Na tych założeniach zbudowałem R-Backup, własne narzędzie Ralkom do kopii zapasowych w chmurze dla komputerów i serwerów z Windows. Na jego przykładzie pokażę dalej, jak wygląda konfiguracja krok po kroku. Te same decyzje podejmiesz w każdym innym porządnym narzędziu, różnić się będą tylko nazwy przycisków.
3. Konfiguracja krok po kroku
Repozytorium i hasło szyfrujące
Pierwszym krokiem jest utworzenie repozytorium, czyli zaszyfrowanego miejsca w chmurze, do którego trafiają wszystkie kopie z danego komputera. W R-Backup robi to kreator, który uruchamia się sam przy pierwszym starcie aplikacji. Dane trafiają do centrum danych w Unii Europejskiej i nie opuszczają jej granic.
Najważniejszą decyzją na tym etapie jest hasło repozytorium. To ono szyfruje wszystkie kopie zapasowe, a kreator mówi wprost, że bez niego nie da się odzyskać żadnych danych, nawet z pomocą Ralkom. Brzmi groźnie, ale właśnie o to chodzi. Skoro ja jako dostawca nie znam twojego hasła, nie odczytam twoich danych, nie zrobi tego pracownik centrum danych ani nikt, kto przejmie dostęp do przestrzeni w chmurze. Hasło zapisz w menedżerze haseł i przechowuj też jego kopię w bezpiecznym miejscu poza komputerem, który backupujesz. Jeśli nie masz jeszcze w firmie menedżera haseł, tu opisałem, jak go wybrać i wdrożyć.
Klucze dostępu do chmury i hasło repozytorium R-Backup przechowuje lokalnie w postaci zaszyfrowanej mechanizmem Windows (DPAPI), a nie otwartym tekstem w pliku konfiguracyjnym. Dzięki temu usługa po restarcie komputera sama odblokowuje repozytorium i wraca do pracy, bez czekania na to, aż ktoś wpisze hasło.
Co backupować
Drugi krok to zadania. Każde zadanie to jedno źródło danych z własnym harmonogramem i własnymi zasadami przechowywania. R-Backup obsługuje trzy typy źródeł.
Pierwszy to zwykłe foldery na dysku, na przykład katalog z dokumentami firmy albo udział sieciowy na serwerze. Przy każdym zadaniu możesz dopisać wykluczenia, jeden wzorzec na linię, na przykład *.tmp albo katalog z plikami tymczasowymi programu. Nie ma sensu płacić za przechowywanie śmieci.
Drugi typ to bazy danych Microsoft SQL Server. Tu nie wystarczy skopiować plików bazy z dysku, bo kopia działającej bazy bywa niespójna i nie da się jej potem uruchomić. R-Backup łączy się z serwerem SQL, sam pobiera listę baz, a ty zaznaczasz te, które mają być chronione. Kopia powstaje natywnym poleceniem BACKUP DATABASE z weryfikacją sumy kontrolnej, dopiero potem trafia zaszyfrowana do chmury, a plik tymczasowy jest usuwany z dysku. Na SQL Serverze działa wiele programów księgowych i ERP popularnych w małych firmach, więc to w praktyce kopia twojej księgowości albo magazynu. Jak ważna jest dobra ochrona takich baz, widać na przykładzie migracji 78 baz Optima i zabezpieczenia biura rachunkowego.
Trzeci typ to biblioteki dokumentów SharePoint, czyli pliki trzymane w Microsoft 365. Wiele osób zakłada, że skoro dane są u Microsoftu, to są też tam zabezpieczone kopią. Tymczasem Microsoft trzyma usunięte elementy SharePoint w koszu łącznie przez 93 dni, jak podaje pomoc techniczna SharePoint, a potem kasuje je na stałe. R-Backup łączy się z SharePointem przez oficjalne API Microsoftu, pozwala wybrać witrynę i konkretne biblioteki, a przy kolejnych przebiegach pobiera tylko pliki zmienione od ostatniej kopii. Pliki usunięte w SharePoincie nie znikają z wcześniejszych kopii, więc historia zostaje, nawet gdy ktoś wyczyści folder.
Jeżeli nie chcesz sam zastanawiać się, co wrzucić do zadań, a czego nie, to jest to typowa część pracy, którą biorę na siebie, prowadząc szyfrowany backup danych firmowych w ramach outsourcingu IT.
Harmonogram
Trzeci krok to częstotliwość. W R-Backup ustawiasz interwał w minutach albo godzinach, domyślnie kopia robi się co godzinę. Dobierz go do tego, ile pracy jesteś gotów stracić. Jeśli w księgowości wprowadza się faktury przez cały dzień, utrata jednej godziny jest do przeżycia, utrata całego dnia już znacznie mniej. Dla folderu z archiwum, do którego zagląda się raz w miesiącu, wystarczy kopia raz na dobę.
Dzięki deduplikacji częste kopie nie oznaczają wysyłania wszystkiego od nowa. Pierwsza kopia jest pełna i przy dużej ilości danych oraz słabym łączu może potrwać nawet kilka dni. Warto więc zaplanować ją na weekend. Kolejne przesyłają już tylko zmiany i zwykle trwają chwilę.
Jest jeszcze jeden szczegół, który docenisz dopiero po pierwszej awarii prądu. Po restarcie komputera usługa backupu często startuje szybciej niż serwer SQL albo zanim wróci internet, więc pierwsza próba kończy się błędem. R-Backup w takiej sytuacji sam ponawia zadanie po minucie, dwóch, pięciu, dziesięciu i piętnastu minutach, zamiast czekać do kolejnego terminu z harmonogramu.
Retencja, czyli jak długo trzymać kopie
Czwarty krok to retencja. Określasz w nim, ile kopii i z jakiego okresu ma zostać w repozytorium. R-Backup domyślnie proponuje 7 kopii dziennych, 4 tygodniowe i 6 miesięcznych. W praktyce oznacza to, że możesz wrócić do dowolnego dnia z ostatniego tygodnia, do stanu z każdego z ostatnich czterech tygodni i do stanu z każdego z ostatnich sześciu miesięcy. Starsze kopie są usuwane automatycznie podczas konserwacji repozytorium, która także działa w tle.
Te liczby nie są przypadkowe. Ransomware potrafi siedzieć w sieci tygodniami, zanim zaszyfruje dane, a uszkodzony plik ktoś może zauważyć dopiero przy zamknięciu kwartału. Krótka historia kopii, na przykład tylko z ostatnich kilku dni, może w takiej sytuacji zawierać wyłącznie zepsute wersje. Jeśli przepisy albo umowy wymagają dłuższego przechowywania dokumentów, zwiększ liczbę kopii miesięcznych.
Na koniec warto zajrzeć do ustawień repozytorium. R-Backup pokazuje tam, ile miejsca zajmuje repozytorium w chmurze i ile danych faktycznie chroni. Różnica między tymi liczbami to efekt kompresji i deduplikacji.
4. Test przywracania, czyli jedyny dowód, że backup działa
Zielony status „ostatnia kopia udana” mówi tylko tyle, że coś zostało wysłane. Nie mówi, czy da się to odzyskać. Według raportu Veeam z 2025 roku 98% organizacji ma plan działania na wypadek ransomware, ale tylko 44% uwzględnia w nim weryfikację kopii zapasowych. Z kolei serwis gov.pl zaleca robienie kopii codziennie i przechowywanie jej w innej lokalizacji niż komputer. Dlatego po skonfigurowaniu zadań zrób próbne przywrócenie, a potem powtarzaj je regularnie, na przykład raz na kwartał.
W R-Backup zaczynasz od wyboru zadania i momentu w czasie. Aplikacja wybiera najnowszą kopię z tej chwili albo sprzed niej, a ty przeglądasz drzewo plików tak jak w Eksploratorze. Możesz przywrócić pojedynczy plik, folder albo całość, do oryginalnej lokalizacji albo do innej ścieżki. Na próbę zawsze wybieraj inną ścieżkę, żeby niczego nie nadpisać.
Z bazami SQL możesz zrobić dwie rzeczy. Albo odtworzyć bazę bezpośrednio na serwerze, także pod inną nazwą, co pozwala sprawdzić kopię obok działającej bazy produkcyjnej, albo zapisać plik .bak w wybranym folderze i odtworzyć go ręcznie. Test polega na tym, że otwierasz odtworzoną bazę w programie i sprawdzasz, czy są w niej ostatnie dokumenty.
Najpoważniejszy test to scenariusz „komputer przestał istnieć”, bo spłonął, został skradziony albo dysk odmówił posłuszeństwa. Wtedy instalujesz R-Backup na nowym komputerze, w kreatorze wybierasz połączenie z istniejącym repozytorium, podajesz hasło i masz dostęp do całej historii kopii. Właśnie dlatego hasło repozytorium nie może być zapisane wyłącznie na tym komputerze, który backupujesz.
5. Na co uważać
Kilka pułapek widzę najczęściej i warto je znać, zanim uznasz temat za zamknięty.
- Hasło repozytorium w jednym miejscu. Jeśli leży tylko w notatce na backupowanym komputerze, to po jego utracie tracisz też dostęp do kopii.
- Definicje zadań po awarii. Po podłączeniu do istniejącego repozytorium na nowym komputerze dane są dostępne od razu, ale harmonogramy i listę zadań trzeba odtworzyć ręcznie. Warto mieć je spisane.
- Brak testu przywracania. Backup, którego nikt nigdy nie przywrócił, jest tylko nadzieją.
- Pierwsza kopia przy słabym łączu. Kilkaset gigabajtów przez zwykłe łącze biurowe może zająć kilka dni i spowolnić internet w godzinach pracy.
- Tylko chmura. Kopia w chmurze to jedna z trzech kopii w zasadzie 3.2.1, nie jej zamiennik. Lokalna kopia na dysku albo serwerze NAS przyda się, gdy trzeba szybko przywrócić dużą ilość danych.
6. Podsumowanie
Dobrze skonfigurowana kopia zapasowa w chmurze to kilka świadomych decyzji. Szyfrowanie po twojej stronie z hasłem, którego nie zna nikt poza tobą, dane w Unii Europejskiej, rozsądny harmonogram, retencja sięgająca miesięcy wstecz i regularny test przywracania. Samo narzędzie jest ważne, ale jeszcze ważniejsze jest to, żeby ktoś pilnował, czy kopie faktycznie się robią i czy da się je odtworzyć.
R-Backup jest w cenie dla firm, którymi opiekuję się w ramach outsourcingu IT. Możesz też korzystać z niego jako z osobnej usługi, w abonamencie miesięcznym albo rocznym, jeśli resztę IT masz już zorganizowaną. Napisz do mnie, a sprawdzimy, jakie dane w twojej firmie wymagają ochrony i jak ustawić dla nich kopie.