Blog

Strona główna / BLOG

Czy Microsoft 365 wymaga kopii zapasowej? 

W pierwszym artykule tego cyklu padło pytanie, które w praktyce budzi najwięcej nieporozumień: skoro dane leżą „w chmurze Microsoftu”, to czy firma musi je jeszcze samodzielnie backupować? Krótka odpowiedź brzmi: tak i wynika to wprost z zasad, na których działa cała platforma. Poniżej tłumaczymy dlaczego, co Microsoft faktycznie chroni, gdzie kończy się jego odpowiedzialność i jak zbudować sensowną ochronę danych. 

Model współodpowiedzialności – kto za co odpowiada 

Microsoft 365 działa w modelu współodpowiedzialności (shared responsibility model). Zasada jest prosta: Microsoft odpowiada za utrzymanie i dostępność platformy, klient – za swoje dane i tożsamości. Po stronie Microsoftu leży infrastruktura fizyczna, dostępność usług, redundancja między centrami danych i replikacja geograficzna. Kontrola dostępu, konfiguracja bezpieczeństwa, zgodność oraz odzyskiwalność danych zostają po stronie klienta. 

Co ważne, to nie interpretacja firm sprzedających backup lub marketing, tylko sam Microsoft rekomenduje regularne wykonywanie backupu swoich danych (mowa o tym w Microsoft Services Agreement). W Umowie o świadczenie usług Microsoft znajduje się rekomendacja regularnego tworzenia kopii zapasowych treści przechowywanych w usługach, także z użyciem aplikacji i usług firm trzecich. 

„Replikacja to nie backup” – dlaczego sama chmura nie chroni 

Najczęstsze nieporozumienie brzmi: „przecież Microsoft trzyma moje dane w kilku centrach danych, więc nic nie zginie”. To prawda, że OneDrive, SharePoint i Exchange przechowują wiele fizycznie redundantnych kopii, żeby przełączać się między nimi przy awarii sprzętu czy centrum danych. Tyle że replikacja chroni przed awarią infrastruktury, a nie przed błędem człowieka ani atakiem. 

Mechanizm replikacji odwzorowuje dane wiernie – łącznie z tym, co ktoś błędnie usunął, nadpisał albo zaszyfrował. Skasujesz folder, atakujący zaszyfruje pliki ransomware’em, a replika po prostu powiela ten stan. Skasowane i uszkodzone dane replikują się jako skasowane i uszkodzone. 

Natywne mechanizmy odzyskiwania – przydatne, ale ograniczone czasowo 

Microsoft 365 ma wbudowane narzędzia pozwalające odzyskać dane po drobnych wpadkach. Trzeba tylko rozumieć ich granice: wszystkie są ograniczone czasowo i żyją wewnątrz tego samego tenanta, który mają chronić. 

W Exchange Online usunięta wiadomość trafia do folderu elementów usuwalnych (Recoverable Items), gdzie standardowo leży 14 dni, konfigurowalnie do 30. W SharePoint i OneDrive działa dwuetapowy kosz, który łącznie utrzymuje usunięte elementy maksymalnie 93 dni. Do tego dochodzi historia wersji plików, pozwalająca cofnąć nadpisanie – o ile wersje nie zostały wyczerpane lub wyczyszczone. 

Osobnym narzędziem są zasady przechowywania w Microsoft Purview (retention policies), które zachowują dane niezależnie od działań użytkownika. To jednak mechanizm do zarządzania cyklem życia danych i zgodności, nie do operacyjnego odtwarzania. Co gorsza, źle skonfigurowana zasada retencji może sama trwale usunąć dane po upływie okresu przechowywania, bez ścieżki odzyskania przez narzędzia natywne. 

Gdzie natywne mechanizmy przestają wystarczać 

Różnica jest zasadnicza: retencja i kosze utrzymują dane dostępne przez pewien czas, ale nie dają niezależnej, odtwarzalnej kopii z punktem w czasie. W praktyce zostawia to firmę bez danych w trzech typowych sytuacjach:

  • Usunięcie wykryte za późno – pracownik kasuje witrynę SharePoint albo czyści OneDrive, nikt nie reaguje w oknie 93 dni (SharePoint) czy 30 dni (Exchange), dane znikają bezpowrotnie.
  • Odchodzący pracownik, który w ostatnim dniu celowo niszczy dane ważnymi poświadczeniami — dla systemu wygląda to jak normalna praca.
  • Przejęcie konta – atakujący z poprawnym loginem działa „legalnie”. Błędna zasada retencji, która po cichu kasuje dane, które powinny zostać.

We wszystkich tych przypadkach wspólny mianownik jest ten sam: strata nie wynika z awarii Microsoftu, tylko z błędu człowieka, działania insidera albo ataku. Warto też pamiętać, że backup powinien obejmować cztery obszary: skrzynki Exchange, witryny SharePoint, pliki OneDrive i Teams. Teams pomija się najczęściej, bo jego dane są rozproszone — czat w Exchange, pliki w SharePoint, struktura zespołów w Entra ID. „Kompletny backup” to taki, który obejmuje Teams jawnie, a nie milcząco go zakłada.

Dwa realne przypadki 

Teoria robi wrażenie dopiero, gdy zobaczyć ją w praktyce. Oba poniższe przypadki są udokumentowane, oba dotyczą dokładnie tych mechanizmów, o których mowa wyżej. 

Ponad 10 lat dokumentów finansowych utraconych po wygaśnięciu licencji. Firma korzystała z planu Business Basic. Subskrypcja wygasła w grudniu 2025, ale użytkownik logował się do OneDrive jeszcze w połowie kwietnia 2026. Gdy 20 kwietnia ponownie przypisano licencję i zalogowano się na konto, wszystkie pliki OneDrive i SharePoint zniknęły. Wsparcie Microsoftu odpowiedziało, że dane zostały trwale usunięte i są nie do odzyskania — a wśród nich było ponad 10 lat krytycznych dokumentów finansowych. Sedno sprawy: po anulowaniu subskrypcji dane mogą zostać usunięte po 90 dniach i najpóźniej po 180, a to, że ktoś wciąż potrafi się zalogować, wcale nie znaczy, że okno odzyskiwania trwa. 

Kampanie ransomware wykorzystujące domyślne ustawienia Microsoft 365 (Sophos, styczeń 2025). Zespół Sophos X-Ops MDR opisał dwie grupy oznaczone jako STAC5143 i STAC5777, badane po incydentach u klientów z listopada i grudnia 2024. Atakujący prowadzili własne tenanty Microsoft 365 i wykorzystywali domyślną konfigurację Teams, która pozwala użytkownikom z zewnętrznych domen zaczynać czaty i spotkania z pracownikami. Scenariusz zaczynał się od zalania skrzynki spamem (nawet do 3 tys. maili w godzinę), a potem wiadomości lub połączenia na Teams od kogoś podszywającego się pod wewnętrzny dział IT, który namawiał do zainstalowania narzędzia zdalnego dostępu i przejmował urządzenie. Celem była kradzież danych i wdrożenie ransomware (m.in. Black Basta). Sophos odnotował ponad 15 takich incydentów w trzy miesiące, a wśród celów były także mniejsze organizacje, zwykle pomijane przez grupy ransomware. To ten sam mechanizm co wyżej, tylko w akcji: po zaszyfrowaniu plików zmiana synchronizuje się między urządzeniami i użytkownikami, a zanim ktokolwiek zauważy problem, czyste kopie mogą być już nadpisane. 

Microsoft 365 Backup — natywna usługa Microsoftu 

Od pewnego czasu Microsoft oferuje własną usługę kopii zapasowych — Microsoft 365 Backup — dostępną z centrum administracyjnego oraz przez aplikacje partnerskie zbudowane na jej platformie. Samo jej istnienie jest sygnałem: gdyby natywna retencja wystarczała, usługa nie byłaby potrzebna. 

Najważniejsze parametry według dokumentacji Microsoft (stan na wrzesień 2026): okno odzyskiwania konfigurowalne na 3 miesiące, 6 miesięcy, 1 rok lub 2 lata (domyślnie 1 rok). Punkty przywracania co 10 minut przez ostatnie 2 tygodnie i tygodniowo dla okresu 2–52 tygodni wstecz (dla Exchange — co 10 minut przez pełne 52 tygodnie). Kopie w modelu append-only, w granicach danych Microsoft 365, co chroni je przed nadpisaniem przez ransomware.

I tu dochodzimy do rzeczy, która w małych i średnich firmach umyka najczęściej: usługa Microsoftu trzyma kopie wewnątrz granicy zaufania Microsoft 365. To zaleta wydajnościowa – odtwarzanie jest bardzo szybkie, mediana 1–3 TB na godzinę, ale oznacza, że backup nie opuszcza ekosystemu Microsoftu. A to łamie fundamentalną zasadę 3-2-1: trzy kopie danych, na dwóch różnych nośnikach, z czego jedna poza główną lokalizacją. Jeśli jedyna kopia zapasowa leży w tym samym tenancie co dane produkcyjne, jeden poważny incydent – przejęcie konta administratora, błąd konfiguracji tenanta, problem z samym kontem Microsoft – może dotknąć oryginał i kopię naraz. 

Dlatego dla większości firm sensem backupu jest niezależna kopia poza tenantem: składowana w infrastrukturze odseparowanej od Microsoft 365, pod osobną kontrolą dostępu, odporna na incydent obejmujący całe konto. Ta niezależność decyduje o tym, czy backup ochroni firmę w najgorszym scenariuszu, czy tylko w tym drobnym.

Natywne odzyskiwanie a backup – porównanie 

Cecha Natywna retencja / kosze Backup (natywny lub firm trzecich) 
Główny cel Zarządzanie cyklem życia danych, zgodność Odtwarzanie po utracie danych 
Okno czasowe 14–30 dni (Exchange), do 93 dni (SharePoint/OneDrive) Miesiące–lata, konfigurowalne 
Odtwarzanie do punktu w czasie Ograniczone Tak (point-in-time) 
Ochrona przed ransomware / masowym usunięciem Częściowa, zależna od okna Tak 
Niezależność od tenanta Nie — żyje w tym samym tenancie Firm trzecich: tak, poza tenantem 
Odporność na błędną zasadę retencji Nie Tak 

Co to oznacza w praktyce dla małej i średniej firmy?

Dla firmy zatrudniającej kilkanaście czy kilkadziesiąt osób wniosek jest konkretny: przejście na Microsoft 365 nie załatwia kwestii kopii zapasowej, a natywne mechanizmy to za mało, by spać spokojnie. Sensowna ochrona danych opiera się na trzech warstwach, które się uzupełniają, a nie zastępują. 

Pierwsza to poprawnie skonfigurowana retencja i wersjonowanie — natywne siatki bezpieczeństwa na codzienne wpadki. Druga to backup z odtwarzaniem do punktu w czasie, obejmujący wszystkie cztery obszary (Exchange, SharePoint, OneDrive, Teams). Trzecia, w MŚP pomijana najczęściej, to niezależność tej kopii od tenanta — składowanie danych poza Microsoft 365, żeby jeden incydent nie dotknął jednocześnie oryginału i backupu. 

Najtrudniejsza nie jest przy tym decyzja „czy backupować”, tylko zaprojektowanie tych warstw pod realne wymagania: jak szybko musimy wrócić do pracy po awarii, jak długo musimy trzymać dane ze względu na zgodność, ile możemy na to wydać. A potem — utrzymanie tego w czasie. Bo backup skonfigurowany raz i zostawiony sam sobie zestarzeje się dokładnie tak samo jak środowisko po migracji: dojdą nowi użytkownicy, zmienią się zespoły, ktoś zmieni konfigurację i nikt tego nie sprawdzi. Testy odtwarzania, weryfikacja, czy nowe skrzynki i witryny faktycznie trafiają do polityki backupu, kontrola, czy kopia wciąż jest niezależna — to już nie projekt z datą zakończenia, tylko element bieżącej administracji środowiskiem. Backup, którego nikt nie pilnuje, daje złudzenie ochrony, a jego brak wychodzi na jaw w najgorszym możliwym momencie — przy próbie odtworzenia po incydencie.

Infografika wyjaśniająca dlaczego potrzebny jest backup dla danych trzymanych na Microsoft 365

Podsumowanie 

Pytanie „czy Microsoft 365 wymaga kopii zapasowej?” ma jednoznaczną odpowiedź, wynikającą z konstrukcji samej platformy. Microsoft gwarantuje dostępność, utrzymanie usługi i redundancję infrastruktury, ale ochrona i odtwarzalność treści to obowiązek klienta. Natywne mechanizmy — kosze, historia wersji, retencja — są wartościowymi siatkami bezpieczeństwa na drobne wpadki, ale są ograniczone czasowo i nie zastępują backupu z odtwarzaniem do punktu w czasie. 

Do wyboru jest natywna usługa Microsoft 365 Backup oraz rozwiązania firm trzecich składujące dane poza tenantem i to właśnie niezależność kopii, zgodna z zasadą 3-2-1, najczęściej rozstrzyga, czy backup ochroni firmę w najgorszym scenariuszu. Właściwa strategia powinna wynikać z wymogów odtwarzania, zgodności i budżetu, a nie z założenia, że „chmura sama to robi”. 

FAQ 

Czy Microsoft robi kopie zapasowe moich danych za mnie? 

Nie w sensie, którego oczekuje większość firm. Microsoft utrzymuje redundancję i dostępność platformy oraz krótkoterminową retencję, ale — zgodnie z modelem współodpowiedzialności — ochrona i odtwarzanie danych to obowiązek klienta. 

Czym różni się retencja od backupu? 

Retencja zarządza tym, jak długo dane zostają w systemie, zanim zostaną usunięte (cel: zgodność i porządek). Backup tworzy niezależną, odtwarzalną kopię z punktami w czasie (cel: odzyskanie po incydencie). To dwa różne narzędzia do dwóch różnych problemów. 

Jak długo Microsoft przechowuje usunięte dane? 

Zależy od usługi i konfiguracji. Dla Exchange elementy usuwalne to standardowo 14 dni (konfigurowalnie do 30). Dla SharePoint i OneDrive dwuetapowy kosz utrzymuje dane łącznie do 93 dni. Potem dane są trwale usuwane.