Sprawdzanie odzyskiwania M365: OneDrive, SharePoint i Teams

Podczas odzyskiwania M365 muszą do siebie pasować właściwy obiekt, odpowiedni punkt w czasie kopii i zatwierdzony cel. Plik może zostać poprawnie zapisany, a mimo to znaleźć się w niewłaściwym miejscu lub być widoczny dla niewłaściwych osób. Ta procedura prowadzi więc od ograniczonego zlecenia do merytorycznego odbioru OneDrive, SharePoint i Teams.

Ta instrukcja dotyczy Sophos Backup and Recovery M365 w modelu Rubrik-hosted. Opcje celu, nadpisywania i odzyskiwania zależą od workloadu i konfiguracji tenanta. Przed wykonaniem operacji sprawdź konkretny dialog odzyskiwania oraz pomoc dla danego workloadu.

Konfigurację, subskrypcję, przypisanie SLA i osobny test Exchange opisuje Konfiguracja Sophos Backup & Recovery M365 i kontrola odzyskania. Poniższa procedura zakłada istniejącą konfigurację kopii i nie rozszerza uprawnień Microsoft ani zamówionego zakresu produktu.

Precyzyjne określenie zlecenia odzyskiwania

Przed otwarciem snapshotu zapisuje się tenant źródłowy, subskrypcję i osobę odpowiedzialną. Należy wskazać użytkownika lub witrynę, dokładną ścieżkę obiektu, przypuszczalny moment utraty lub zmiany ze strefą czasową oraz oczekiwany stan. Przy incydencie bezpieczeństwa odpowiedni moment sprzed kompromitacji musi zostać uzgodniony z osobą odpowiedzialną za incydent. Najnowsza kopia nie jest wtedy automatycznie właściwa.

W pilotażu używa się wyłącznie zatwierdzonych kont testowych i nieszkodliwych danych. backup-pilot@example.invalid, Restore-Pilot-2026-10-29.txt i Restore-Abnahme to przykłady użytkownika testowego, pliku i żądanego celu kontroli; nie są istniejącymi obiektami tenanta. Przed rzeczywistym zleceniem zastępuje się je potwierdzonymi własnymi wartościami testowymi.

Dla celu pisemnie ustala się, czy dane są potrzebne w pierwotnym miejscu, czy oddzielnie. Innego użytkownika, witryny lub subskrypcji docelowej nie wolno wybrać tylko dlatego, że kreator udostępnia taką opcję. Uprawnienia, region danych i odpowiedzialność za cel należą do tego samego zatwierdzenia.

Wyjaśnienie konfliktów plików przed zapisem

W celu mogą znajdować się pliki o tej samej nazwie, nowsze zmiany lub zablokowane dokumenty. Przed potwierdzeniem trzeba więc wiedzieć, czy konkretna procedura nadpisuje, zmienia nazwę, pomija czy tworzy oddzielną kopię. Nie należy wywodzić tych wariantów z zachowania odzyskiwania Exchange. Rubrik rozróżnia na przykład w OneDrive wyniki pełne i częściowe i może wskazywać obiekty, których nazwy zmieniono z powodu konfliktów. Nie wynika z tego wspólna reguła konfliktów dla wszystkich workloadów.

Jeśli wpływ oferowanego trybu jest niejasny, nie uruchamia się jeszcze odzyskiwania. Najpierw należy wyjaśnić pomoc właściwą dla workloadu i ewentualne zgłoszenie do wsparcia. Pozornie szybkie odzyskanie in-place nie może bez zgody zastąpić aktualnej pracy.

Otwarcie właściwego snapshotu i pomocy dla workloadu

1. W Sophos Fusion (dawniej Sophos Central) otworzyć My Products > Backup and Recovery M365. Po przekierowaniu sprawdzić organizację Rubrik.
2. Otworzyć Inventory > SaaS > Microsoft 365. Ustalić subskrypcję potwierdzoną dla zlecenia; nie zgadywać na podstawie podobnej nazwy wyświetlanej.
3. Sprawdzić zakres ochrony, przypisanie SLA i dostępne kopie danego obiektu. Zielony stan integracji nie dowodzi jeszcze istnienia snapshotu z potrzebną wersją pliku.
4. Przed zleceniem zapisu otworzyć ikonę Help, a w Help Center pomoc dla odpowiedniego workloadu. Dla SharePoint udokumentowany tytuł to Backup and recovery of SharePoint sites and site collections, dla Teams Teams data recovery. Dla OneDrive wyszukać w Help Center OneDrive i planowaną ścieżkę odzyskiwania.
5. Porównać czas ze zdarzeniem i strefą czasową. Sprawdzić wybrany obiekt w snapshocie względem źródła, ścieżki i oczekiwanej treści. Przed ostatnim krokiem zapisującym ponownie porównać źródło, zakres, cel i zachowanie konfliktów ze zleceniem.

Poniższe kontrole nie zastępują dokładnej ścieżki kliknięć dla workloadu. Wybór udokumentowany dla Exchange, taki jak Recover to a new folder, nie gwarantuje istnienia takiego samego dialogu dla OneDrive, SharePoint lub Teams. Jeśli pomoc nie pasuje do oferowanej procedury, przed odzyskaniem należy się zatrzymać i wyjaśnić różnicę.

OneDrive: potwierdzenie konkretnej wersji pliku

W ograniczonym scenariuszu zatwierdzona osoba testowa tworzy nieszkodliwy plik tekstowy o jednoznacznej nazwie. Początkowo treść zawiera wartość kontrolną Alpha. Po potwierdzonym snapshocie plik zmienia się na Bravo i ponownie zabezpiecza kopią. Zapisuje się oba momenty i oczekiwaną wersję w każdym z nich.

Do odzyskania celowo wybiera się snapshot z Alpha. Przed rozpoczęciem sprawdza się potwierdzonego użytkownika docelowego, pełną ścieżkę i sposób postępowania z istniejącym już plikiem Bravo. Jeśli wybrana procedura obsługuje oddzielną kopię i taki tryb został zatwierdzony, ułatwia to porównanie. Nie zakłada się dostępności takiego trybu; przy niejasnym nadpisywaniu nie kontynuuje się.

Po zleceniu najpierw sprawdza się komunikat i liczby obiektów, wraz z ostrzeżeniami, błędami częściowymi oraz zmianami nazw. Następnie osoba testowa otwiera faktycznie utworzony plik w udokumentowanym celu. Musi on zawierać oczekiwaną wartość kontrolną. Jeśli użyto dodatkowego folderu docelowego albo innej nazwy pliku, rejestruje się dokładnie tę ścieżkę. Niezmieniony plik w starym miejscu nie zastępuje tego dowodu.

Dodatkowo kontroluje się dostęp i udostępnienia: wskazana osoba testowa musi móc otworzyć plik; nieuprawnione konto testowe nie może w ten sposób otrzymać nowego dostępu. Jeden plik tekstowy sprawdzony w pilotażu nie potwierdza pełnego odzyskania użytkownika ani zachowania wszystkich linków udostępniania czy właściwości pliku.

SharePoint: osobny odbiór treści, celu i właściwości

W SharePoint zlecenie zaczyna się od dokładnego URL witryny. Następnie określa się, czy potrzebny jest pojedynczy plik, folder, biblioteka, lista czy większa struktura. Biblioteka o tej samej nazwie w innej witrynie jest innym celem.

Do pilotażu nadaje się zatwierdzona biblioteka testowa z małym plikiem i zapisaną wcześniej wartością kontrolną. Jeśli ma to znaczenie dla późniejszego zastosowania, dokumentuje się również pole metadanych i oczekiwaną grupę uprawnień. Snapshot musi zawierać dokładnie te dane początkowe. Historię wersji, strukturę listy lub indywidualne uprawnienie potwierdza się jako odzyskane tylko wtedy, gdy należą do wybranego zakresu i zostały osobno sprawdzone.

Przed ostatnim krokiem zapisującym kontroluje się witrynę docelową, zakres obiektów i możliwe kolizje z aktualną treścią. Jeśli potrzebny jest tylko plik, nie odzyskuje się zapobiegawczo całej witryny. Po zadaniu osoba odpowiedzialna sprawdza treść we właściwym celu, wymagane właściwości i dostęp. Zakończony job w portalu Rubrik nie dowodzi jeszcze, że aplikacja biznesowa może korzystać z odtworzonej struktury.

Jeśli struktura witryny różni się między snapshotem a stanem bieżącym, wyraźnie sprawdza się ścieżkę źródłową i mapowanie celu. Przy brakującym celu lub niewyjaśnionych uprawnieniach nie tworzy się na próbę dodatkowych kont, witryn ani ról. Najpierw zlecenie musi określać obsługiwaną ścieżkę docelową i potrzebną odpowiedzialność.

Teams: pliki to nie całość współpracy

Zlecenie „odzyskać Teams” jest zbyt nieprecyzyjne. Musi określać, czy potrzebne są wiadomości, kanał, pliki czy inne treści. Microsoft dokumentuje, że pliki kanałów standardowych znajdują się w witrynie SharePoint zespołu; kanały prywatne i udostępnione mają własne witryny. Sama nazwa kanału nie wystarcza więc do wybrania odpowiedniego snapshotu plików.

Dla ograniczonego pilotażu ustala się zatwierdzony zespół testowy, typ kanału i nieszkodliwą treść. Jeśli chodzi o plik kanału, zapisuje się rzeczywistą witrynę SharePoint, bibliotekę i plik, a następnie sprawdza je według planu odbioru SharePoint. Odzyskany plik nie potwierdza odzyskania wiadomości kanału, członkostw, kart ani całej konfiguracji Teams.

Jeśli potrzebne są wiadomości lub struktury kanałów, przed odzyskaniem w Teams data recovery ustala się, jakie typy obiektów i cele obsługuje konkretny stan wdrożenia. Zespół źródłowy, kanał, snapshot i cel dokumentuje się osobno. Po zadaniu uprawniony członek testowy sprawdza potrzebną treść w Teams; dla plików nadal wymagana jest dodatkowa kontrola rzeczywistego miejsca zapisu. Bez potwierdzonego zakresu i właściwego snapshotu nie obiecuje się ogólnego pełnego odzyskania Teams.

Udokumentowanie wyniku i zakończenie testu

Raport odbioru zawiera obiekt źródłowy, czas snapshotu ze strefą czasową, cel, wybrany tryb i identyfikowalne powiązanie zadania. Dodatkowo obejmuje liczby obiektów, ostrzeżenia, zmiany nazw, wyrywkowo sprawdzoną treść, dostęp i zmierzony czas. Wynik oczekiwany i wynik faktycznie zaobserwowany pozostają oddzielone.

Jeśli zadanie pokazuje błąd lub niejednoznaczne zakończenie, nie uruchamia się natychmiast tego samego odzyskiwania ponownie. Najpierw należy w portalu i celu ustalić, czy zapisano już dane. Nawet częściowy sukces mógł utworzyć lub zmienić obiekty. Podczas eskalacji podaje się dokładne źródło, czas, cel i zanonimizowany komunikat; nie kopiuje się treści plików, danych dostępowych ani pełnych eksportów do publicznych zgłoszeń.

Odzyskanie nie ma uniwersalnego przycisku cofania. Dodatkowe kopie testowe usuwa się dopiero po odbiorze i wyłącznie w uzgodnionym zakresie testu. Pliki produkcyjne, odzyskane treści biznesowe ani backupy nie są ogólnym „rollbackiem”. Dopóki potrzebna treść lub uprawnienie nie zostały potwierdzone, zlecenie pozostaje otwarte, nawet jeśli techniczny stan zadania wygląda na udany.