Uw back-up is voltooid. Kunt u uw bedrijf daadwerkelijk herstellen?

Een succesvolle back-up is geen bewijs van herstel. Leer wat u moet herstellen, hoe u downtime meet en hoe u uw back-ups controleert vóór een echt bedrijfsincident.

Een back-up hersteltest controleert of opgeslagen gegevens kunnen worden hersteld en gebruikt, en niet alleen of een back-uptaak is voltooid. Begin met een kleine, geïsoleerde test en leg vast hoe lang het duurt om tot een bruikbaar resultaat te komen.

Illustratie back-up hersteltest: een back-upserver die gegevens herstelt naar een geverifieerd document binnen een getimede herstelperiode

Kies een bedrijfsproces, niet alleen een map

Vraag uzelf af welk proces zou stoppen als de bijbehorende gegevens zouden verdwijnen. Salarisadministratie, klantorders en een gedeelde projectmap hebben verschillende afhankelijkheden. Een hersteld spreadsheet is van weinig nut als de applicatie, machtigingen of de encryptiesleutel die nodig zijn om het te gebruiken, ontbreken.

Spreek twee doelen af met de proceseigenaar: hoeveel recent werk er verloren mag gaan, en hoe lang het proces onbeschikbaar mag zijn. Dit zijn uw recovery point (RPO) en recovery time objectives (RTO). Deze moeten de behoeften van het bedrijf weerspiegelen, niet de standaardinstellingen van een back-upproduct.

Voer de back-up hersteltest uit buiten de live-omgeving

Gebruik een apart apparaat, een geïsoleerde virtuele machine of een testomgeving. Overschrijf geen live-bestanden om te bewijzen dat herstel werkt. Bevestig de herstelbestemming en machtigingen voordat u begint, en houd herstelde persoonsgegevens binnen dezelfde toegangscontroles als het origineel.

Test één recent item en één oudere versie. Open deze met de beoogde applicatie en controleer of de inhoud bruikbaar is. Voor een server of database moet u ook de configuratie, afhankelijkheden en een controle op bedrijfsniveau opnemen, in plaats van te stoppen bij een succesvolle opstart.

Meet het volledige herstel, inclusief toegang

Noteer de starttijd, het geselecteerde herstelpunt, de genomen stappen en het moment waarop een gebruiker weer aan het werk kan. Houd rekening met het downloaden van gegevens, het opnieuw opbouwen van een systeem en het herstellen van de toegang. Een bestandskopie van twee minuten kan nog steeds een onderbreking van vier uur worden als niemand het wachtwoord van het account kent.

Bewaar een korte herstelnotitie buiten het systeem dat wordt beschermd. Vermeld de eigenaar, de escalatiecontactpersoon en de locatie van de benodigde sleutels. Noteer fouten als taken, los ze op en herhaal de test.

Hoe vaak moet een klein bedrijf zijn back-ups testen?

Kies een frequentie op basis van hoe snel het systeem verandert en hoe kostbaar een uitval zou zijn. Driemaandelijkse tests kunnen een nuttig startpunt zijn, met extra tests na een migratie of grote configuratiewijziging. Voor kritischere processen kan een korter interval nodig zijn. De richtlijnen voor kleine bedrijven over het maken van back-ups van het Britse National Cyber Security Centre vormen een nuttige basis om te bepalen wat u moet beschermen.

Maakt Microsoft 365 een back-upplan overbodig?

Nee. Retentie, versiegeschiedenis en prullenbakken kunnen helpen bij sommige herstelsituaties, maar de dekking en tijdslimieten daarvan hangen af van uw configuratie. Controleer verwijdering, accountverlies en incidentherstel afzonderlijk voordat u beslist of die maatregelen voldoen aan uw bedrijfsdoelstellingen.

Zet testresultaten om in een herstelplan

ICT Shift beoordeelt herstel over on-premises, cloud- en hybride systemen. Onze Cybersecurity & Business Continuity-dienst koppelt hersteltesten aan incidentplanning, terwijl Cloud & Infrastructure management de onderliggende systemen beheert.

Als niemand onlangs een bruikbaar herstel heeft aangetoond, praat dan met een engineer over uw herstelplan. Neem uw laatste back-uprapport mee en een lijst met processen die u absoluut niet kunt missen.