Een klant van ons belde ons vorig jaar op een dinsdagochtend in paniek: zijn webshop was overgenomen door ransomware. Geen man overboord, dachten we eerst — er stond een back-up klaar. Tot we die probeerden terug te zetten. Het bestand was er, de melding “back-up voltooid” stond er elke nacht netjes bij, maar het databasebestand was al drie maanden corrupt. Niemand had het ooit gecontroleerd. Resultaat: vier dagen stilstand, handmatig bestellingen reconstrueren uit e-mailbevestigingen, en een rekening die niemand had begroot.
Dit is geen uitzondering. In de praktijk zien wij dat zeker één op de vijf MKB-bedrijven die zeggen dat ze “back-ups hebben”, dat nog nooit hebben geverifieerd door daadwerkelijk iets terug te zetten. Een back-up die je niet hebt getest is in essentie een gok.
Wat downtime echt kost — een rekenvoorbeeld
Stel, uw webshop of dienstverlenende website genereert €150.000 omzet per jaar. Dat is gemiddeld €410 per dag. Vier dagen uitval kost u dus niet alleen €1.640 aan gemiste omzet, maar ook:
- Uren van uzelf en personeel om handmatig data te reconstrueren (reken 15–25 uur bij een gemiddelde webshop)
- Klanten die tijdens de uitval naar een concurrent zijn gegaan en niet terugkomen
- Mogelijk een boete of claim als u B2B-klanten met een SLA heeft
Bij elkaar opgeteld praat je al snel over een bedrag tussen €3.000 en €8.000 voor een relatief klein incident. En dat is nog zonder reputatieschade als klanten op sociale media melden dat uw site al dagen niet werkt.
De 3-2-1-regel, maar dan praktisch toegepast
De bekende back-upregel klinkt zo: drie kopieën van je data, op twee verschillende soorten media, waarvan één op een andere locatie. Voor een MKB-website vertalen we dat naar:
- Kopie 1: de automatische back-up van uw hostingpartij, meestal dagelijks
- Kopie 2: een back-up die fysiek of netwerktechnisch losstaat van de server zelf — dus niet in dezelfde map of hetzelfde datacenter
- Kopie 3: een handmatige of geautomatiseerde export die u zelf download, bijvoorbeeld maandelijks
Veel ondernemers denken dat hun hostingpakket dit automatisch regelt. Dat klopt soms, maar bij gedeelde hosting of goedkope pakketten wordt vaak alleen de laatste 7 dagen bewaard, op dezelfde server als de website. Als die server crasht of versleuteld raakt door ransomware, verdwijnt de back-up gewoon mee.
RTO en RPO: de twee vragen die u zichzelf moet stellen
Twee termen uit de IT-wereld die voor elke ondernemer relevant zijn:
- RPO (Recovery Point Objective): hoeveel data mag u maximaal kwijtraken? Als uw back-up eens per 24 uur draait, kunt u in het slechtste geval bijna een volledige dag aan bestellingen of formulierinzendingen verliezen.
- RTO (Recovery Time Objective): hoe snel moet u weer online zijn? Voor een brochurewebsite is 48 uur misschien acceptabel, voor een webshop met dagelijkse omzet niet.
Beantwoord deze twee vragen eerst, en pas dan weet u welke back-upfrequentie en welk type back-up u echt nodig heeft — niet andersom.
Stappenplan: test uw back-up in 30 minuten
Dit hoeft geen IT-project van een dag te zijn. Plan één keer per kwartaal dit korte stappenplan in:
- Stap 1: Download de meest recente back-up (database én bestanden) en noteer de bestandsgrootte. Een database van 2 MB terwijl die vorige maand 40 MB was, is een alarmsignaal.
- Stap 2: Zet een testomgeving op — een staging-site of lokale installatie — en zet de back-up daar terug.
- Stap 3: Controleer concreet: logt u in als klant? Staan recente bestellingen erin? Werkt het contactformulier?
- Stap 4: Meet hoe lang het hele proces duurde, van download tot werkende site. Dat getal is uw werkelijke RTO, niet de theoretische.
- Stap 5: Leg de uitkomst vast in één regel in een document: datum, resultaat, duur. Bij drie keer achter elkaar “goed” weet u dat het systeem betrouwbaar is.
Bij Rondom Internet voeren we deze restore-test standaard uit bij nieuwe klanten in managed hosting, juist omdat we te vaak zien dat een “back-up” op papier iets anders blijkt te zijn dan in de praktijk.
De fout die we het vaakst tegenkomen
De meest voorkomende fout is niet het ontbreken van een back-up, maar het ontbreken van een versiehistorie. Veel back-upsystemen overschrijven namelijk gewoon de vorige versie. Als een hack of fout drie dagen onopgemerkt blijft — wat vaker voorkomt dan u denkt, gemiddeld duurt het bij kleinere sites 11 tot 18 dagen voordat malware wordt opgemerkt — dan heeft u alleen besmette back-ups beschikbaar.
Vraag daarom expliciet aan uw hostingpartij: hoeveel versies worden bewaard, en hoe ver terug kan ik? Bij een serieus managed hostingpakket is dat minimaal 14 tot 30 dagen terug, met dagelijkse versies. Is het antwoord “alleen de laatste back-up”, dan loopt u onnodig risico op precies het scenario dat onze klant trof.