Verifiera M365-återställning för OneDrive, SharePoint och Teams

Vid en M365-återställning måste rätt objekt, en lämplig säkerhetskopieringstidpunkt och ett godkänt mål stämma överens. En fil kan ha skrivits tillbaka utan fel men ändå ligga på fel plats eller vara synlig för fel personer. Flödet går därför från ett avgränsat uppdrag till saklig verifiering för OneDrive, SharePoint och Teams.

Giltighetsområde: Här avses Sophos Backup and Recovery M365 med den leveransmodell som drivs av Rubrik. Kontrollera vilka mål-, överskrivnings- och återställningsalternativ som finns för den aktuella arbetsbelastningen innan återställningen bekräftas. Den specifika arbetsbelastningens hjälp och den visade dialogen måste passa den egna tenanten.

Konfiguration, Subscription, SLA-tilldelning och det separata Exchange-testet beskrivs i Konfigurera Sophos Backup & Recovery M365 och verifiera en återställning. Följande flöde förutsätter en konfigurerad säkerhetskopiering och utökar varken Microsoft-behörigheter eller beställd produktomfattning.

Avgränsa återställningsuppdraget

Före åtkomst till en snapshot dokumenteras källtenant, Subscription och ansvarig person. Ange berörd användare eller site, exakt objektsökväg, misstänkt förlust- eller ändringshändelse med tidszon och önskat tillstånd. Vid en säkerhetsincident måste en lämplig, ännu inte komprometterad tidpunkt stämmas av med incidentansvarig. Den senaste säkerhetskopian är då inte automatiskt rätt.

Använd enbart godkända testkonton och ofarliga testdata i en pilot. backup-pilot@example.invalid, Restore-Pilot-2026-10-29.txt och Restore-Abnahme är exempel på testanvändare, fil och önskat kontrollmål; de är inga befintliga tenantobjekt. Inför ett verkligt uppdrag ersätts de med bekräftade egna testvärden.

Besluta skriftligt om data behövs på den ursprungliga platsen eller separat. Välj inte en annan målanvändare, site eller Subscription enbart för att guiden erbjuder det. Behörigheter, dataregion och målansvar ingår i samma godkännande.

Klargör filkonflikter före skrivning

Målet kan innehålla filer med samma namn, nyare ändringar eller låsta dokument. Innan något bekräftas måste det därför vara klart om det konkreta flödet skriver över, byter namn, hoppar över eller skapar en separat kopia. Härled inte dessa alternativ från ett Exchange-Restore. För OneDrive skiljer Rubrik exempelvis mellan lyckade och partiella resultat och kan redovisa namnbytta objekt på grund av namnkonflikter. Detta är ingen generell konfliktregel för alla arbetsbelastningar.

Om följden av det erbjudna läget är oklar startas ännu ingen återställning. Klargör först arbetsbelastningens hjälp och vid behov ett supportärende. En till synes snabb In-place-Restore får inte ersätta aktuellt arbete utan medgivande.

Öppna rätt snapshot och arbetsbelastningens hjälp

1. Öppna My Products > Backup and Recovery M365 i Sophos Fusion (tidigare Sophos Central). Kontrollera Rubrik-organisationen efter omdirigeringen.
2. Öppna Inventory > SaaS > Microsoft 365. Identifiera den Subscription som bekräftats för uppdraget; gissa inte utifrån ett liknande visningsnamn.
3. Kontrollera skyddsomfattning, SLA-tilldelning och befintliga säkerhetskopior för objektet. Grön integrationsstatus bevisar ännu ingen snapshot med den filversion som behövs.
4. Före en skrivåtgärd öppnas Help-symbolen och rätt hjälp för arbetsbelastningen i Help Center. För SharePoint heter den dokumenterade hjälpen Backup and recovery of SharePoint sites and site collections, för Teams Teams data recovery. Sök för OneDrive efter OneDrive och den avsedda återställningsvägen i Help Center.
5. Jämför tidpunkten med händelsen och tidszonen. Kontrollera valt objekt i snapshoten mot källa, sökväg och förväntat innehåll. Stäm av källa, omfattning, mål och konflikthantering mot uppdraget igen före sista skrivande steget.

Kontrollerna nedan ersätter inte den exakta klickföljden för arbetsbelastningen. Ett alternativ som Recover to a new folder, dokumenterat för Exchange, garanterar inte att samma dialog finns för OneDrive, SharePoint eller Teams. Om hjälpen inte passar erbjudet flöde stoppas återställningen tills skillnaden har retts ut.

OneDrive: verifiera en viss filversion

För ett avgränsat testscenario skapar den godkända testpersonen en ofarlig textfil med entydigt namn. Innehållet får först kontrollvärdet Alpha. Efter en bekräftad snapshot ändras filen till Bravo och säkerhetskopieras igen. Notera båda tidpunkterna och respektive förväntad version. Detta scenario är en kontrollplan, inget redan observerat produktresultat.

Välj avsiktligt snapshoten med Alpha för återställningen. Kontrollera före start bekräftad målanvändare, fullständig sökväg och hanteringen av den Bravo-fil som nu finns. Om en separat kopia stöds och är godkänd i valt flöde underlättar den jämförelsen. Ett sådant läge förutsätts inte; fortsätt inte om överskrivning är oklar.

Efter uppdraget kontrolleras först jobbmeddelande och objektantal, inklusive varningar, partiella fel och namnbyten. Därefter öppnar testpersonen filen som faktiskt skapats på det dokumenterade målet. Den måste innehålla förväntat kontrollvärde. Om en extra målmapp eller ett annat filnamn användes dokumenteras exakt den sökvägen. En oförändrad fil på den gamla platsen är inget ersättande bevis.

Kontrollera dessutom åtkomst och delningar: avsedd testperson ska kunna öppna filen; ett obehörigt testkonto får inte därigenom få ny åtkomst. En textfil som verifierats i en pilot bekräftar ännu inte en fullständig användaråterställning eller att alla delningslänkar och filegenskaper bevaras.

SharePoint: verifiera innehåll, mål och egenskaper separat

För SharePoint börjar uppdraget med exakt site-URL. Bestäm sedan om en enskild fil, mapp, bibliotek, lista eller större struktur behövs. Ett bibliotek med samma namn på en annan site är ett annat mål.

För piloten passar ett godkänt testbibliotek med en liten fil och ett i förväg noterat kontrollvärde. Dokumentera dessutom ett metadatafält och förväntad behörighetsgrupp om de är relevanta för senare användning. Snapshoten måste innehålla exakt dessa utgångsdata. Versionshistorik, liststruktur eller individuell behörighet bekräftas bara som återställd om den ingår i vald omfattning och har kontrollerats separat.

Kontrollera före sista skrivsteget målsite, objektomfattning och möjliga kollisioner med aktuellt innehåll. Återställ inte en hel site i förebyggande syfte om bara en fil behövs. Efter jobbet kontrollerar ansvarig innehållet på rätt mål, avsedda egenskaper och åtkomst. Att Rubrik-portalen visar ett slutfört jobb bevisar ännu inte att ett verksamhetsprogram kan använda den återställda strukturen.

Om sitestrukturen skiljer sig mellan snapshot och nutid kontrolleras källsökväg och målmappning uttryckligen. Skapa inte extra konton, sites eller roller på chans om ett mål saknas eller behörigheter är oklara. Uppdraget måste först ange stödd målväg och nödvändigt ansvar.

Teams: likställ inte filer med samarbete

Uppdraget ”återställa Teams” är för oprecist. Ange om meddelanden, en kanal, filer eller annat innehåll behövs. Microsoft dokumenterar att standardkanalernas filer ligger på teamets SharePoint-site; privata och delade kanaler har egna sites. Kanalnamnet räcker därför inte för att bestämma rätt filsnapshot.

Avtala för en begränsad pilot ett godkänt testteam, kanaltyp och ofarligt testinnehåll. För en kanalfil registreras den faktiska SharePoint-siten, biblioteket och filen, och de kontrolleras enligt SharePoint-planen. En återhämtad fil bekräftar varken återställda kanalmeddelanden, medlemskap, flikar eller hela Teams-konfigurationen.

Om meddelanden eller kanalstrukturer behövs klargörs före återställningen i Teams data recovery vilka objekttyper och mål den konkreta leveransen stöder. Dokumentera källteam, kanal, snapshot och mål separat. Efter uppdraget kontrollerar en behörig testmedlem innehållet som behövs i Teams; för filer krävs dessutom kontroll av den faktiska lagringsplatsen. Utan bekräftad omfattning och rätt snapshot utlovas ingen generell fullständig Teams-återställning.

Dokumentera resultatet och avsluta testet

Verifieringsrapporten anger källobjekt, snapshottid med tidszon, mål, valt läge och spårbar jobbtillhörighet. Till detta kommer objektantal, varningar, namnbyten, stickprovsvis kontrollerat innehåll, åtkomst och uppmätt tid. Förväntat resultat och faktiskt observerat resultat hålls åtskilda.

Vid fel eller oklart avslut startas inte omedelbart samma återställning igen. Klargör först i portalen och på målet om data redan har skrivits. Redan en partiell framgång kan ha skapat eller ändrat objekt. Vid eskalering anges exakt källa, tidpunkt, mål och sanerat meddelande; kopiera inte filinnehåll, autentiseringsuppgifter eller fullständiga exporter till offentliga ärenden.

En återställning har ingen allmän ångra-knapp. Extra testkopior städas först efter verifieringen och bara inom överenskommen testomfattning. Produktionsfiler, återställda verksamhetsdata eller säkerhetskopior är ingen generell ”rollback”. Så länge nödvändigt innehåll eller en behörighet inte har bekräftats förblir uppdraget öppet även om den tekniska jobbvisningen verkar lyckad.