Wśród administratorów IT wciąż żyje przekonanie, że skoro firma siedzi w Microsoft 365, to dane „są w chmurze” i nic im nie grozi. Sam Microsoft pisze co innego: za infrastrukturę odpowiada on, za dane – Ty. Recycle Bin 93 dni i Recoverable Items 14 dni to mechanizmy odzyskiwania pomyłek, nie backup. Poniżej: scenariusze realnie kasujące dane i co powinien obejmować backup zewnętrzny.
Co Microsoft gwarantuje, a czego nie – model shared responsibility
Microsoft 365 działa w modelu współdzielonej odpowiedzialności. W warstwie SaaS dostawca utrzymuje datacenter, sieć i aplikację, replikując dane między strefami pod SLA. Dane, tożsamości i konfiguracja są po stronie klienta.
Microsoft formułuje to wprost: „you own your data and identities”. Idzie dalej: replikacja służy odporności i SLA, retencja, regularny backup i odzyskiwanie po przypadkowym usunięciu lub ransomware to obowiązek klienta.
Z perspektywy praktyka IT firm średniej wielkości to rozróżnienie ma konkretne konsekwencje. Replikacja gwarantuje, że gdy padnie region Microsoftu, dane będą podawane z drugiego, ale nie cofa czasu ani nie odtworzy pliku skasowanego trzy miesiące temu.
Najczęstsze scenariusze utraty danych w Microsoft 365
Firmy migrujące do M365 tracą dane w pięciu powtarzalnych sytuacjach – native retention pokrywa fragment.
- Usunięcie wykryte po ponad 93 dniach – Recycle Bin SharePointa i OneDrive trzyma elementy łącznie 93 dni. Po tym terminie pliki znikają trwale.
- Ransomware z opóźnionym wykryciem – atak szyfruje lokalnie, OneDrive synchronizuje wersję zaszyfrowaną do chmury, SharePoint Versioning zapisuje kolejne wersje jako „nowe”. Dwell time ataków liczy się w tygodniach.
- Były pracownik – po usunięciu konta w Entra ID OneDrive trafia do stanu „marked for deletion” na 30 dni, dalej do site collection recycle bin (93 dni).
- Złośliwe usunięcie i sabotaż – uprzywilejowany użytkownik z dostępem admina potrafi pominąć Recycle Bin i wyczyścić zawartość natychmiast.
- Błąd retention policy – polityka „auto-delete po 12 miesiącach” zaczyna kasować pliki zgodnie z konfiguracją. Cofnięcie polityki nie przywraca usuniętego.
Jak wygląda dobry backup Microsoft 365 – co powinien obejmować
Dobry backup to architektura spełniająca kilka twardych warunków naraz, nie kopiowanie plików gdzieś indziej.
Pełen zakres obejmuje cztery filary M365: Exchange Online, OneDrive, SharePoint Online i Teams – razem z czatami oraz plikami kanałów w SharePoincie. Kopia musi trafiać do niezależnej lokalizacji, oddzielonej od M365 i jego tożsamości administracyjnych. Storage powinien być immutable (WORM), by przejęcie konta admina nie pozwoliło skasować historycznych kopii. Restore granularny odtwarza pojedynczy mail lub plik, point-in-time recovery wybiera dzień i godzinę.
Te komponenty – niezależność od M365, immutable storage, granular restore z point-in-time recovery i testowane DR – składają się w standard, którego nie da się poskładać samodzielnie z natywnych funkcji. Firmy potrzebujące pełnego zestawu bez własnej budowy decydują się na usługę typu backup Microsoft 365 świadczoną przez wyspecjalizowanego dostawcę odpowiadającego za architekturę, retencję i odzyskiwanie niezależnie od M365. Taki układ rozdziela ryzyko.
Ostatni warunek to retencja zgodna z polityką firmy (rok, siedem lat, bezterminowo) i regularne testy odzyskiwania. Backup, którego nie odtworzono przez pół roku, jest backupem nieznanym.
Najczęstsze błędy w backupie M365
Nawet firmy z backupem zewnętrznym gubią jego wartość przez kilka powtarzalnych pomyłek:
- backup w tym samym tenancie co produkcyjny M365 – gdy ktoś przejmie konto admina, kopia idzie razem ze źródłem;
- brak testów recovery – DR drill raz na kwartał wykrywa problemy, których harmonogram nie pokaże;
- pominięcie Teams – rozwiązania kopiują Exchange i OneDrive, ale czaty, kanały i pliki Teams zostają poza zasięgiem;
- retencja krótsza niż czas wykrycia incydentu – kopia 30-dniowa przy ransomware ujawnionym po 60 dniach to wersje zaszyfrowane;
- brak immutability i WORM – atakujący w konsoli backupu kasuje kopie zanim zaszyfruje dane.
Kiedy native funkcje Microsoft 365 wystarczą
Uczciwie – są scenariusze, gdzie backup zewnętrzny bywa przerostem formy nad treścią. Organizacja kilkuosobowa, brak danych regulowanych, dane, których utrata nie zatrzymuje firmy – w tej skali 14-dniowy czas odzyskiwania i support-call recovery zwykle wystarczają.
Opcja pośrednia: Microsoft 365 Backup – płatny add-on Microsoftu, okno odzyskiwania rok, RPO około 10 minut. To, że Microsoft uruchomił komercyjną usługę backupu obok M365, pokazuje, że native retention nie projektowano jako disaster recovery.
W firmach od dziesięciu osób w górę, przetwarzających dane klientów lub w branżach regulowanych (RODO, ISO 27001, SOC 2), odpowiedź wygląda inaczej.
FAQ – najczęstsze pytania o backup Microsoft 365
Czy Microsoft robi backup moich danych w Microsoft 365?
Microsoft replikuje dane między datacenter pod SLA. To nie backup w rozumieniu point-in-time recovery. Odzyskanie po usunięciu, ransomware lub błędzie retencji to obowiązek klienta – tak mówi dokumentacja shared responsibility.
Jak długo Microsoft 365 trzyma usunięte pliki?
SharePoint i OneDrive: 93 dni w Recycle Bin (pierwszy i drugi etap). Exchange Recoverable Items: domyślnie 14 dni, max 30. Po przekroczeniu okien dane znikają trwale, chyba że obowiązuje Litigation Hold lub osobna polityka retencji.
Czy „backup OneDrive” w aplikacji desktopowej wystarczy?
Nie. „Backup OneDrive” w kliencie desktopowym to synchronizacja folderów Pulpit, Dokumenty i Obrazy do chmury. Gdy plik zostanie zaszyfrowany lokalnie, OneDrive zsynchronizuje wersję zaszyfrowaną. Wersjonowanie pomaga przy pojedynczych pomyłkach, nie chroni przed atakiem rozłożonym w czasie.
Co z Teams – czaty i pliki kanałów?
Teams to usługa rozsiana po kilku miejscach M365: pliki kanałów leżą w SharePoincie, czaty grupowe i prywatne w Exchange, uprawnienia zarządzane oddzielnie. Część rozwiązań „backup M365” kopiuje tylko skrzynki i OneDrive – sprawdź, czy oferta obejmuje również Teams.
Co zrobić w pierwszej kolejności
Pierwszy krok: zinwentaryzować krytyczne dane M365 (skrzynki zarządu i sprzedaży, biblioteki SharePoint, pliki Teams) i zestawić z retencją native. Drugi – ustalić, ile dni od incydentu firma potrzebuje na odzyskanie i porównać z 93/14/30. Jeśli liczby się rozjeżdżają, decyzja o backupie zewnętrznym przestaje być teoretyczna.
Źródła
- Microsoft Learn – Shared responsibility model, learn.microsoft.com, dane z 2026;
- Microsoft Learn – Retention and deletion in Microsoft 365, learn.microsoft.com, dane z 2026;
- Microsoft Tech Community – Microsoft 365 Backup announcement, techcommunity.microsoft.com, dane z 2024–2026.
