M365-herstel voor OneDrive, SharePoint en Teams controleren

Bij M365-herstel moeten het juiste object, een geschikt backuptijdstip en een goedgekeurd doel bij elkaar passen. Een bestand kan succesvol zijn teruggeschreven en toch op de verkeerde plaats staan of zichtbaar zijn voor de verkeerde personen. Deze procedure loopt daarom van een afgebakende opdracht tot inhoudelijke acceptatie voor OneDrive, SharePoint en Teams.

Reikwijdte: Het gaat om Sophos Backup and Recovery M365 met het door Rubrik beheerde implementatiemodel. Beschikbare doelen en het gedrag bij overschrijven verschillen per workload en herstelmodus. De concrete workloadhelp en het getoonde dialoogvenster moeten bij de eigen tenant passen.

Inrichting, subscription, SLA-toewijzing en de afzonderlijke Exchange-test staan in Sophos Backup & Recovery M365 inrichten en een herstel controleren. De onderstaande procedure veronderstelt een ingerichte backup en breidt noch Microsoft-rechten noch de bestelde productscope uit.

De herstelopdracht afbakenen

Leg vóór toegang tot een snapshot brontenant, subscription en verantwoordelijke vast. Daarbij horen de betrokken gebruiker of site, het exacte objectpad, het vermoedelijke verlies- of wijzigingsincident met tijdzone en de gewenste toestand. Bij een beveiligingsincident moet een geschikt, nog niet gecompromitteerd tijdstip met de incidentverantwoordelijke worden afgestemd. De nieuwste backup is dan niet automatisch de juiste.

Gebruik voor een pilot uitsluitend goedgekeurde testaccounts en onschuldige testgegevens. backup-pilot@example.invalid, Restore-Pilot-2026-10-29.txt en Restore-Abnahme zijn voorbeelden van een testgebruiker, bestand en gewenst controledoel; het zijn geen bestaande tenantobjecten. Vervang ze vóór een echte opdracht door bevestigde eigen testwaarden.

Beslis schriftelijk of de gegevens op de oorspronkelijke plaats of daarvan gescheiden nodig zijn. Kies niet alleen een andere doelgebruiker, site of subscription omdat de wizard dit aanbiedt. Rechten, dataregio en verantwoordelijkheid voor het doel horen bij dezelfde goedkeuring.

Bestandsconflicten vóór het schrijven verduidelijken

In het doel kunnen gelijknamige bestanden, nieuwere bewerkingen of vergrendelde documenten aanwezig zijn. Vóór de bevestiging moet daarom duidelijk zijn of de concrete procedure overschrijft, hernoemt, overslaat of een afzonderlijke kopie maakt. Leid die varianten niet af uit het gedrag van een Exchange-herstel. Rubrik onderscheidt bij OneDrive bijvoorbeeld geslaagde en gedeeltelijke resultaten en kan objecten melden die vanwege naamconflicten zijn hernoemd. Daaruit volgt geen algemene conflictregel voor alle workloads.

Start nog geen herstel als de gevolgen van de aangeboden modus onduidelijk zijn. Verduidelijk eerst de workloadspecifieke help en zo nodig de supportcase. Een ogenschijnlijk snel in-place-herstel mag geen actuele bewerking zonder toestemming vervangen.

De juiste snapshot en workloadhelp openen

1. Open in Sophos Fusion (voorheen Sophos Central) My Products > Backup and Recovery M365. Controleer na de doorverwijzing de Rubrik-organisatie.
2. Open Inventory > SaaS > Microsoft 365. Bepaal de voor de opdracht bevestigde subscription; raad niet op basis van een vergelijkbare weergavenaam.
3. Controleer beschermingsscope, SLA-toewijzing en aanwezige backups van het betrokken object. Een groene integratiestatus bewijst nog geen snapshot met de benodigde bestandsversie.
4. Open vóór een schrijfopdracht het Help-symbool en in het Help Center de bij de workload passende help. Voor SharePoint is de gedocumenteerde helptitel Backup and recovery of SharePoint sites and site collections, voor Teams Teams data recovery. Zoek voor OneDrive in het Help Center op OneDrive en de geplande herstelroute.
5. Vergelijk het tijdstip met het incident en de tijdzone. Controleer het geselecteerde object in de snapshot aan de hand van bron, pad en verwachte inhoud. Vergelijk bron, omvang, doel en conflictgedrag vóór de laatste schrijfstap nogmaals met de opdracht.

De volgende controles vervangen de precieze workloadspecifieke klikroute niet. Een voor Exchange gedocumenteerde keuze zoals Recover to a new folder belooft niet dat hetzelfde dialoogvenster voor OneDrive, SharePoint of Teams bestaat. Stop vóór herstel als de help niet bij de aangeboden procedure past en verduidelijk het verschil.

OneDrive: een specifieke bestandsversie aantonen

Voor een beperkt testscenario maakt de goedgekeurde testpersoon een onschuldig tekstbestand met een unieke naam. De inhoud krijgt eerst de controlewaarde Alpha. Na een bevestigde snapshot wordt het bestand gewijzigd naar Bravo en opnieuw geback-upt. Noteer beide tijdstippen en de verwachte versies. Dit scenario is een controleplan, geen al waargenomen productresultaat.

Kies voor herstel bewust de snapshot met Alpha. Controleer vóór de start de bevestigde doelgebruiker, het volledige pad en de omgang met het inmiddels aanwezige Bravo-bestand. Als een afzonderlijke kopie in de gekozen procedure wordt ondersteund en goedgekeurd, maakt dat vergelijken eenvoudiger. Zo’n modus wordt niet verondersteld; ga niet verder zolang overschrijven onduidelijk is.

Controleer na de opdracht eerst jobmelding en objectaantallen, inclusief waarschuwingen, gedeeltelijke fouten en hernoemingen. Daarna opent de testpersoon het daadwerkelijk gemaakte bestand op het gedocumenteerde doel. Het moet de verwachte controlewaarde bevatten. Is een extra doelmap of andere bestandsnaam gebruikt, leg dan precies dat pad vast. Een ongewijzigd bestand op de oude plaats is geen vervangend bewijs.

Controleer daarnaast toegang en gedeelde rechten: de bedoelde testpersoon moet het bestand kunnen openen; een onbevoegd testaccount mag hierdoor geen nieuwe toegang krijgen. Een in een pilot gecontroleerd tekstbestand bewijst nog geen volledig gebruikersherstel of behoud van alle deellinks en bestandseigenschappen.

SharePoint: inhoud, doel en eigenschappen afzonderlijk accepteren

Bij SharePoint begint de opdracht met de exacte site-URL. Leg daarna vast of een afzonderlijk bestand, map, bibliotheek, lijst of uitgebreidere structuur nodig is. Een gelijknamige bibliotheek in een andere site is een ander doel.

Voor de pilot is een goedgekeurde testbibliotheek met een klein bestand en een vooraf genoteerde controlewaarde geschikt. Documenteer, indien relevant voor later gebruik, ook een metadataveld en de verwachte rechtengroep. De snapshot moet precies die uitgangsgegevens bevatten. Bevestig versiegeschiedenis, lijststructuur of individuele rechten alleen als hersteld wanneer ze tot de geselecteerde scope behoren en afzonderlijk zijn gecontroleerd.

Controleer vóór de laatste schrijfstap doelsite, objectscope en mogelijke conflicten met actuele inhoud. Herstel niet uit voorzorg een hele site als slechts één bestand nodig is. Na de job controleert de verantwoordelijke de inhoud op het juiste doel, de bedoelde eigenschappen en de toegang. Een afgeronde job in het Rubrik-portaal bewijst nog niet dat een bedrijfsapplicatie met de herstelde structuur kan werken.

Wijkt de sitestructuur tussen snapshot en heden af, controleer dan bronpad en doeltoewijzing uitdrukkelijk. Maak bij een ontbrekend doel of onduidelijke rechten niet op goed geluk extra accounts, sites of rollen aan. Eerst moet de opdracht de ondersteunde doelroute en benodigde verantwoordelijkheden vastleggen.

Teams: bestanden en samenwerking niet gelijkstellen

Een opdracht ‘Teams herstellen’ is te onnauwkeurig. Ze moet benoemen of berichten, een kanaal, bestanden of andere inhoud nodig zijn. Microsoft documenteert dat bestanden van standaardkanalen in de SharePoint-site van het team staan; privé- en gedeelde kanalen hebben eigen sites. Alleen de kanaalnaam volstaat daarom niet om de passende bestandssnapshot te bepalen.

Spreek voor een beperkte pilot een goedgekeurd testteam, het kanaaltype en onschuldige testinhoud af. Gaat het om een kanaalbestand, leg dan de daadwerkelijke SharePoint-site, bibliotheek en het bestand vast en controleer die volgens het SharePoint-acceptatieplan. Een teruggehaald bestand bevestigt noch het herstel van kanaalberichten, noch van lidmaatschappen, tabbladen of de volledige Teams-configuratie.

Zijn berichten of kanaalstructuren nodig, verduidelijk dan vóór herstel in Teams data recovery welke objecttypen en doelen de concrete implementatiestand ondersteunt. Documenteer bronteam, kanaal, snapshot en doel afzonderlijk. Na de opdracht controleert een bevoegd testlid de benodigde inhoud in Teams; bij bestanden blijft daarnaast controle van de daadwerkelijke opslagplaats nodig. Zonder bevestigde scope en passende snapshot wordt geen algemeen volledig Teams-herstel toegezegd.

Resultaat vastleggen en de test beëindigen

Het acceptatierapport legt bronobject, snapshottijd met tijdzone, doel, gekozen modus en navolgbare jobverwijzing vast. Daarbij komen objectaantallen, waarschuwingen, hernoemingen, steekproefsgewijs gecontroleerde inhoud, toegang en gemeten duur. Verwacht resultaat en daadwerkelijk waargenomen resultaat blijven gescheiden.

Start bij een fout of onduidelijke afronding niet meteen hetzelfde herstel opnieuw. Verduidelijk eerst in het portaal en op het doel of al gegevens zijn geschreven. Zelfs gedeeltelijk succes kan objecten hebben gemaakt of gewijzigd. Geef bij escalatie exacte bron, tijdstip, doel en geschoonde melding op; kopieer geen bestandsinhoud, toegangsgegevens of volledige exportbestanden naar openbare tickets.

Een herstel heeft geen algemene ongedaanmakenknop. Ruim extra testkopieën pas na acceptatie op en uitsluitend binnen de overeengekomen testscope. Productiebestanden, herstelde bedrijfsinhoud of backups vormen geen algemene ‘rollback’. Zolang benodigde inhoud of een recht niet bevestigd is, blijft de opdracht open, ook als de technische jobweergave succesvol lijkt.