Czy musimy robić backup danych z SaaS, czy Google albo Microsoft już się tym zajmuje?

Model współdzielonej odpowiedzialności, po ludzku

Platformy chmurowe dzielą obowiązki między dostawcę a klienta. Dostawca prowadzi fizyczną infrastrukturę, sieć, kod aplikacji i dostępność usługi. Klient odpowiada za konfigurację, kontrolę dostępu i same dane. Ten podział nazywa się modelem współdzielonej odpowiedzialności i to najważniejsza idea, jeśli chodzi o odpowiedź na pytanie o backup.

Microsoft i Google trzymają wiele redundantnych kopii twoich danych, żeby awaria dysku czy utrata centrum danych nie skasowała twojej poczty. Ta redundancja chroni przed ich awariami. Nie chroni przed twoimi. Jeśli użytkownik opróżni folder, atakujący zaszyfruje dysk, albo admin usunie niewłaściwe konto, ta zmiana zostaje wiernie skopiowana do każdej redundantnej lokalizacji. Replikacja zachowuje bieżący stan danych, w tym stan, w którym ich już nie ma.

Dostawcy są w tej kwestii jednoznaczni. Umowa o świadczenie usług Microsoft mówi wprost: „Zalecamy regularne wykonywanie kopii zapasowej Twoich treści i danych przechowywanych w ramach usług lub przy użyciu aplikacji i usług stron trzecich". Google ujmuje tę samą zasadę jako „twoje dane, twoja odpowiedzialność" i zaznacza, że wewnętrzne kopie zapasowe, które Google przechowuje, istnieją, żeby chronić Google przed jego własnymi błędami, nie są dostępne dla adminów ani użytkowników i są nadpisywane według ustalonego harmonogramu. Nie służą do przywracania twoich danych na żądanie.

Więc kiedy ktoś mówi „Google już to backupuje", dokładniejsza wersja jest taka, że Google utrzymuje działanie platformy i chroni samego siebie, a odpowiedzialność za odzyskanie twoich danych po twoich własnych błędach spoczywa na tobie.

Co faktycznie pokrywa natywne odzyskiwanie i przez jak długo

Obie platformy zawierają naprawdę użyteczne funkcje odzyskiwania. To kosze na śmieci i okna retencji, nie backup do dowolnego punktu w czasie, i wszystkie mają limity czasowe. Po zamknięciu okna dane są usuwane trwale i bez możliwości odzyskania.

Google Workspace

• Drive: pliki przeniesione do kosza są przechowywane przez 30 dni, potem Drive trwale je usuwa. Po opróżnieniu kosza przez użytkownika admin ma około 25 dni na odzyskanie elementów, zanim Google je wyczyści.
• Usunięci użytkownicy: admin może przywrócić usunięte konto użytkownika, wraz z jego danymi, przez maksymalnie 20 dni od usunięcia. Po 20 dniach dokumentacja pomocy Google wprost stwierdza, że dane zniknęły i nie da się ich odzyskać.
• Gmail: usunięta poczta trafia do kosza na 30 dni, po czym admin ma ograniczone dodatkowe okno na odzyskanie wiadomości przed trwałym usunięciem.

Microsoft 365

• Exchange Online: usunięta skrzynka jest domyślnie przechowywana przez 30 dni przed trwałym usunięciem.
• SharePoint i OneDrive: usunięte elementy przechodzą przez kosz pierwszego i drugiego etapu, a okres retencji 93 dni obejmuje oba. Po 93 dniach element zostaje trwale usunięty ze wszystkich miejsc, w których się znajdował. Kolekcje witryn są odzyskiwalne również przez 93 dni.
• Wersjonowanie: SharePoint i OneDrive przechowują historię wersji (domyślnie 500 głównych wersji), co pomaga odzyskać dane po nadpisaniu, dopóki plik i jego biblioteka nadal istnieją.

Te okna są krótkie jak na standardy prawdziwego zdarzenia utraty danych i łączy je wspólna słabość: zakładają, że ktoś szybko to zauważy. Konto odchodzącego pracownika jest często usuwane w jego ostatnim dniu pracy, dane, których nikt nie otwierał od dwóch miesięcy, nikomu nie brakuje, a powoli rozwijający się atak ransomware może psuć pliki przez tygodnie, zanim ktokolwiek je przywróci. Zanim strata zostanie odkryta, kosz może już być pusty.

Uwaga o archiwach compliance

Retencja w Microsoft Purview i Google Vault bywają mylone z backupem. To narzędzia governance i eDiscovery. Google Vault zatrzymuje, przeszukuje i eksportuje dane do celów prawnych i compliance, a z założenia dane, które przechowuje, mają być trudno dostępne, ograniczone do niewielkiej liczby adminów, i nie można ich przywrócić bezpośrednio do skrzynki czy dysku użytkownika. Biblioteka Preservation Hold w Microsoft podobnie istnieje po to, żeby spełniać polityki retencji, a nie dać ci samoobsługowe przywracanie. Narzędzie, które potrafi zachować i wyeksportować dane, to nie to samo co narzędzie, które potrafi przywrócić folder dokładnie taki, jaki był we wtorek.

Retencja to nie backup, a replikacja to nie backup

Warto być precyzyjnym co do trzech słów, których używa się tak, jakby były wymienne.

• Replikacja utrzymuje wiele żywych kopii bieżących danych, żeby awaria sprzętu albo lokalizacji ich nie skasowała. Obaj dostawcy robią to dobrze. Kopiuje dowolny stan, w jakim dane się znajdują, w tym stan usunięty albo zaszyfrowany.
• Retencja przechowuje usunięte albo zmodyfikowane elementy przez zdefiniowane okno, żeby można je było odzyskać w jego trakcie. To właśnie robią kosze na śmieci i polityki retencji. Jest ograniczona czasowo i sterowana polityką, nie jest kopią do dowolnego punktu w czasie, którą kontrolujesz.
• Backup to niezależna, izolowana kopia twoich danych, przechowywana osobno od źródła, z której możesz odtworzyć dane do wybranego punktu w czasie w ramach uzgodnionego celu odzyskiwania.

Backup definiują niezależność i możliwość odtworzenia. Natywne funkcje są mocne w dostępności, a słabe w niezależnym odzyskiwaniu do dowolnego punktu w czasie, kontrolowanym przez klienta. Ta luka to cała istota pytania.

Scenariusze utraty danych, dla których natywne narzędzia nie są zaprojektowane

Awaria sprzętu to scenariusz, z którym platformy radzą sobie dobrze i który większość ludzi sobie wyobraża. Scenariusze, które faktycznie powodują utratę danych SaaS, są ludzkie, i to tam natywne odzyskiwanie się kończy.

Ransomware i malware

Ransomware nie zatrzymuje się już na endpointach. Kiedy pliki ze stacji roboczej są zsynchronizowane z OneDrive albo Google Drive, szyfrowanie rozprzestrzenia się w chmurze. Historia wersji i kosze na śmieci mogą pomóc, jeśli zdarzenie zostanie wychwycone wcześnie, a jego zasięg jest mały, ale szerokie zdarzenie szyfrowania obejmujące tysiące plików szybko przerasta ręczne odzyskiwanie z kosza, zwłaszcza jeśli atakujący czaił się przez tygodnie, a czyste wersje już wypadły z retencji. Własny opis płatnego produktu backupowego Microsoftu jest zbudowany dokładnie wokół tego przypadku: przywracania „do zdrowego punktu w czasie sprzed ataku" po „ataku ransomware, który szyfruje duże połacie twoich danych".

Złośliwe albo przypadkowe masowe usunięcie

Niezadowolony użytkownik, przejęte konto admina albo automatyzacja, która poszła nie tak, mogą usunąć dane w skali i tempie, których model kosza na śmieci nigdy nie był zaprojektowany czysto cofnąć. Przypadkowe usunięcie to częstszy wariant: ktoś usuwa dysk współdzielony albo bibliotekę SharePoint, usunięcia nikt nie zauważa przez tygodnie, a okno odzyskiwania po cichu wygasa. Ten sam model, który chroni cię przez 30 albo 93 dni, działa przeciwko tobie, gdy ten zegar się skończy.

Odchodzący pracownicy i offboarding

To najbardziej rutynowa strata i najłatwiejsza do przeoczenia. Kiedy pracownik odchodzi, jego konto jest często usuwane, żeby zwolnić licencję. W Google Workspace usunięty użytkownik, wraz z całą pocztą i danymi Drive tej osoby, jest odzyskiwalny tylko przez 20 dni. Jeśli pliki byłego pracownika są potrzebne do sprawy klienta, przekazania obowiązków albo sporu trzy miesiące później, natywne odzyskiwanie nie pomoże. Dane zostały usunięte w dniu offboardingu, a okno zamknęło się na długo przed tym, zanim ktokolwiek o nie zapytał. Dlatego pytanie o to, co backupować, tak ściśle łączy się z tym, jak przeprowadzasz offboarding.

Awaria dostawcy SaaS, zawieszenie albo zamknięcie konta

Rzadszą, ale realną kategorią jest utrata dostępu do samej platformy, a nie do pojedynczych elementów: spór o rozliczenia albo naruszenie regulaminu, które zawiesza tenant, przedłużająca się awaria, albo mniejszy dostawca SaaS, który bankrutuje i zabiera ze sobą twoje dane. Umowa o świadczenie usług Microsoft zaznacza, że po zamknięciu konta powiązane z nim dane są usuwane i nie da się ich odzyskać. Niezależny backup to jedyna kopia, która przetrwa utratę konta.

Własne produkty Microsoftu i Google mówią same za siebie

Najwyraźniejszym dowodem na to, że darmowy plan nie jest backupem, jest fakt, że dostawcy sami teraz sprzedają backup. Microsoft 365 Backup to płatny dodatek, rozliczany po 0,15 USD za GB miesięcznie, z retencją do roku dla OneDrive, SharePoint i Exchange. Oferuje przywracanie do dowolnego punktu w czasie, magazyn typu append-only, dzięki czemu backupów nie da się po cichu nadpisać przez malware, oraz 90-dniowy okres karencji po zakończeniu korzystania z narzędzia. Jest naprawdę użyteczny, a jego istnienie dowodzi tezy: gdyby kosze na śmieci i retencja były backupem, nie byłoby czego sprzedawać.

Warto znać dwa ograniczenia, jeśli go rozważasz. Po pierwsze, dane backupu zostają w granicach zaufania Microsoft 365, więc nie dają ci izolacji poza platformą, jaką daje osobny dostawca, co ma znaczenie, jeśli twoją obawą jest utrata dostępu do samego tenanta. Po drugie, w połowie 2026 roku obejmuje OneDrive, SharePoint i Exchange, nie cały ekosystem. Google nie oferuje odpowiednika własnego produktu backupowego, co po części tłumaczy, dlaczego backup od zewnętrznego dostawcy jest dobrze ugruntowaną kategorią dla Workspace.

Backup SaaS od zewnętrznego dostawcy i czym się różni

Zewnętrzne narzędzie backupowe łączy się z twoim tenantem przez jego API, wykonuje regularne, niezależne kopie skrzynek, plików, witryn, a często też Teams, Chat i kontaktów, i przechowuje je poza platformą, pod twoją kontrolą. Kluczowe różnice względem natywnego odzyskiwania to niezależność (kopia przetrwa utratę konta), retencja, którą sam wybierasz, zamiast sztywnych 30 czy 93 dni, oraz samoobsługowe przywracanie do dowolnego punktu w czasie na poziomie elementu, użytkownika albo całej domeny.

Przy porównywaniu natywnego rozwiązania z zewnętrznym, użyteczne są pytania praktyczne:

• Retencja: czy natywne okno pokrywa realny czas, jaki zajmuje ci wykrycie straty? Jeśli dane odchodzącego pracownika mogą być potrzebne rok później, okno 20-dniowe nie wystarczy.
• Granularność i szybkość przywracania: czy możesz przywrócić jednego użytkownika, jeden folder albo cały tenant do konkretnego punktu w czasie bez zgłoszenia do supportu i długiego czekania?
• Niezależność: gdybyś całkowicie stracił dostęp do konta, czy nadal miałbyś dane?
• Pokrycie: czy chroni obciążenia, od których faktycznie zależysz, w tym te, których natywny backup nie pokrywa?

Nie ma jednej uniwersalnie słusznej odpowiedzi. Zespół, którego krytyczne dane żyją niemal wyłącznie w osobnym systemie linii biznesowej, może uznać, że natywne okna wystarczają dla poczty i plików. Zespół, który prowadzi swoją działalność ze wspólnych dysków i skrzynek, zwykle stwierdza, że ta luka ma znaczenie.

Jak zdecydować, co backupować

Backup to nie decyzja wszystko-albo-nic, a próba backupowania wszystkiego po równo to sposób na zatrzymanie rozmowy o budżecie. Traktuj to jako ćwiczenie z krytyczności danych.

1. Zmapuj, gdzie żyją twoje ważne dane. Poczta i kalendarze, wspólne dyski i witryny SharePoint, historia Teams i Chat, kontakty oraz aplikacje SaaS poza Google i Microsoftem, które trzymają realne dane biznesowe. Większość zespołów jest zaskoczona tym, jak dużo danych siedzi w miejscach, o których backupowaniu nikt by nie pomyślał.
2. Uszereguj według wpływu straty. Dla każdego magazynu zapytaj, co się stanie, jeśli zniknie na zawsze: ekspozycja regulacyjna, zobowiązania umowne, koszt odtworzenia i to, jak długo firma może działać bez tych danych.
3. Ustal cel odzyskiwania dla każdego magazynu. Jak daleko wstecz musisz umieć przywrócić dane (punkt odzyskiwania) i jak szybko musisz je odzyskać (czas odzyskiwania)? Porównaj to uczciwie z natywnym oknem. Tam, gdzie natywne okno jest krótsze niż twoja tolerancja, masz lukę.
4. Backupuj magazyny, w których strata naprawdę by zabolała. Skoncentruj budżet na danych o wysokim wpływie i długim czasie odzyskiwania. Udokumentuj decyzję, w tym to, czego świadomie zdecydowałeś się nie backupować i dlaczego, żeby ta decyzja była widoczna, a nie przypadkowa.
5. Przetestuj przywracanie. Backup, z którego nigdy nie przywracałeś danych, to nadzieja, nie kontrola. Regularnie przywracaj próbkę, żeby potwierdzić, że dane wracają nienaruszone i w czasie, jaki zakładałeś.

Efektem jest krótkie, obronne stanowisko: tu żyją nasze krytyczne dane, to pokrywa natywne odzyskiwanie, tu jest luka, a to backupujemy, żeby ją domknąć.

Źródła

• Microsoft Services Agreement (zalecenie backupu, zamknięcie konta i usunięcie danych) · https://www.microsoft.com/en-us/servicesagreement/
• Learn about retention for SharePoint and OneDrive, Microsoft Learn (93-dniowy kosz pierwszego i drugiego etapu, biblioteka Preservation Hold, wersjonowanie) · https://learn.microsoft.com/en-us/purview/retention-policies-sharepoint
• Delete or restore user mailboxes in Exchange Online, Microsoft Learn (30-dniowa retencja usuniętej skrzynki) · https://learn.microsoft.com/en-us/exchange/recipients-in-exchange-online/delete-or-restore-mailboxes
• Overview of Microsoft 365 Backup, Microsoft Learn (roczna retencja, przywracanie do dowolnego punktu w czasie, magazyn append-only, 0,15 USD/GB/miesiąc, scenariusze ransomware i usunięcia, 90-dniowa karencja po offboardingu) · https://learn.microsoft.com/en-us/microsoft-365/backup/backup-overview
• Restore a recently deleted user, Google Workspace Admin Help (limit odzyskania usuniętego użytkownika 20 dni) · https://support.google.com/a/answer/1397578
• Recover deleted files and folders for Drive users, Google Workspace Admin Help (kosz Drive 30 dni, ~25-dniowe odzyskiwanie przez admina) · https://support.google.com/a/answer/6052340
• How retention works, Google Vault Help (Vault jako governance i eDiscovery, nie backup ani przywracanie) · https://support.google.com/vault/answer/2990828