Schokkende waarheid over SharePoint disaster recovery

Geschreven door op 26 juni 2014

disasterRampen gebeuren. Netwerken falen, databases geraken corrupt, content wordt verwijderd. Gelukkig grijpt de IT in. Voor je het weet draait alles opnieuw zoals voorheen.

Jammer genoeg is dat voor de meeste bedrijven niet het geval.

Tijdens een recent event werd een kleine groep SharePoint administrators gevraagd naar hun disaster recovery plans en de tests die ze uitvoeren om ervoor te zorgen dat zij voorbereid zijn op het ergste.

De uitkomst was schokkend. Amper 1 op 4 bedrijven test zijn SharePoint recovery plans. Daarvan gaf nog eens 75% te kennen dat hun recovery tests faalden. Hoewel slechts weinig bedrijven dit publiekelijk zullen toegeven kan je makkelijk zelf de berekening maken: 75% van 25% van alle gebruikers. Stel je voor welke impact een ramp effectief zou hebben.

Heel wat te verliezen

SharePoint groeit en wordt steeds meer aanzien als het hulpmiddel om samenwerking binnen bedrijven te verbeteren. Voor velen is het een vaste tool geworden in hun dagdagelijkse taken. Een SharePoint storing kan dan ook resulteren in een verloren productiviteit van dagen of zelfs weken, verhoogde kans op verlies van data en veiligheidslekken. En toch wordt er zo weinig aandacht geschonken aan SharePoint disaster managagement. Onthoud:

Testen is geen eenmalig proces

Eenmaal testen is niet voldoende wanneer het aankomt op SharePoint disaster recovery plans. Er zijn periodieke, incrementele tests nodig om processen, documentatie, rechten en backups te testen. SharePoint is een actieve omgeving die constant veranderd, wat de kans dat een test faalt alleen maar groter maakt. Onderzoek heeft aangetoond dat bij 66 procent van de succesvolle recovery tests een aanpassing aan het recovery plan vooraf ging.

Niet elke ramp is uiteraard catastrofaal. Meestal gaat het zelfs om kleine storingen die met een disaster recovery in geen tijd opgelost kunnen worden.

Wat is het Recovery Point Objective?

Naargelang de content binnen SharePoint groeit, groeit ook het risico op een eventuele ramp exponentieel mee. Om de impact in te perken moet een Recovery Point Objective (RPO) ingesteld worden. Eenvoudig gezegd bepaalt dit punt het dataverlies dat op eender welk moment aanvaardbaar is. Hoe groter de content database, hoe meer tijd een backup in beslag neemt. Hoe belangrijker het systeem of de data, hoe korter de RPO.

Recovery Plan inmplementeren

Herstellen van een SharePoint database storing vergt meer dan enkel het herladen van een database bestand. De applicatie en omgeving met alle configuraties, permissies en workflows zal opnieuw opgezet moeten worden.

Drie zaken waarmee elke onderneming rekening moet houden bij het inplannen van een SharePoint Disaster recovery:

  1. Test de herstelmogelijkheden: kom in actie voor er zich effectief een crisis voordoet. Weekends zijn ideale momenten om dit te doen. Test daarna opniew, eens per kwartaal, of minstens eens per jaar. Doe een eerlijke evaluatie van recovery punten en tijden, zeker wanneer de SharePoint omgeving groeit. Wat vorig jaar werkte zal dat dit jaar misschien niet meer doen.
  2. Verlaag de impact van de SharePoint omgeving: plaats waar mogelijk content buiten SharePoint, waar deze gebackupt kan worden en ten allen tijde klaar staat, met minder druk op de database.
  3. Voer incrementele backups door zodat backup en recovery tijden verlaagd worden.

Heeft u vragen over de veiligheid van uw SharePoint omgeving, aarzel dan niet ons te contacteren, Cogn-IT kan de nodige SharePoint support bieden.

CONTACTEER ONS VRIJBLIJVEND!

Heeft u een vraag, aarzel niet ons te contacteren. Wij maken graag tijd voor u vrij.