Back-up valkuilen: 6 redenen waarom je denkt veilig te zijn (maar het niet bent)
Bijna elk MKB-bedrijf heeft “een back-up”. En toch gaat het bij incidenten opvallend vaak mis. Niet omdat niemand eraan gedacht heeft, maar omdat back-ups in de praktijk vol aannames zitten: dat ze lopen, dat ze compleet zijn, dat je kunt herstellen, en dat het snel genoeg gaat om door te werken.
Een goede back-up is geen vinkje. Het is een proces: maken, bewaren, beveiligen én regelmatig testen. Hieronder staan zes valkuilen die we het meest zien en hoe je ze voorkomt zonder er een IT-project van te maken.
Valkuil 1: “We hebben een back-up” (maar niemand controleert of hij echt slaagt)
Veel back-ups lijken goed te gaan omdat er “geen meldingen” zijn. Maar als je nooit actief controleert op mislukte jobs, foutmeldingen, volle schijven of verlopen accounts, kan het weken duren voordat je ontdekt dat er niets bruikbaars meer wordt weggeschreven.
Wat werkt in de praktijk:
- automatische monitoring/alerts op mislukte back-ups
- een korte, vaste menselijke check (wekelijks of maandelijks)
- duidelijke ownership: wie is verantwoordelijk?
Back-ups zijn te belangrijk om pas te bekijken als je ze nodig hebt.
Valkuil 2: Je back-up staat op dezelfde plek (brand, diefstal, ransomware)
Een back-up op een NAS naast de server is beter dan niets, maar beschermt je niet tegen de grote risico’s: brand, diefstal, waterschade of ransomware die óók je back-upschijf versleutelt. Als een aanvaller toegang heeft tot je netwerk, heeft hij vaak ook toegang tot je back-ups, tenzij je ze apart en beschermd opslaat.
Wat werkt:
- minimaal één kopie offsite (cloud/ander datacenter) of offline
- duidelijke retentie
- waar mogelijk: immutability / “niet zomaar verwijderbaar of overschrijfbaar”
Valkuil 3: Je back-upt de verkeerde dingen (of mist “stille” data)
Veel MKB’s back-uppen “de server”, maar vergeten dat data verspreid is: laptops, Microsoft 365, SaaS-apps, databases, of een branchesysteem dat op een aparte machine draait. Of andersom: er wordt wel een map geback-upt, maar niet de applicatiecomponenten die nodig zijn om het systeem werkend terug te zetten.
Een simpele oefening die bijna altijd helpt:
Maak een lijst van wat morgen nodig is om te kunnen werken (functioneel, niet technisch), zoals:
- klantdossiers
- boekhouding
- projectdata/planning
- telefoon/telefonieconfig
- databases/branchesystemen
Pas daarna bepaal je: wat moet je back-uppen om dit ook écht te kunnen herstellen.
Valkuil 4: “Herstellen kan altijd” (maar je hebt het nooit getest)
De grootste schok bij een incident is vaak niet dat data weg is, maar dat herstel veel langer duurt dan gedacht. Of dat herstel faalt door permissies, corrupte back-ups of onduidelijke stappen.
Een back-up zonder hersteltest is een hoop. En hoop is geen strategie.
Testen hoeft niet groot te zijn. Een maandelijkse of kwartaaltest waarbij je bijvoorbeeld terugzet:
- één mailbox
- één SharePoint-map
- één database
- of één server naar een testlocatie
…geeft al enorm veel zekerheid. Je leert hoe lang het duurt, welke afhankelijkheden er zijn en waar documentatie ontbreekt.
Valkuil 5: Retentie is te kort (of juist onhandig lang)
Sommige problemen ontdek je pas later: een bestand is per ongeluk overschreven, een map is weken geleden opgeruimd, of ransomware keek al “stil” mee. Als je retentie maar een paar dagen is, kun je vaak nét niet ver genoeg terug.
Andersom kan “alles jaren bewaren” ook nadelen hebben: kosten lopen op, en je bewaart mogelijk data die je niet meer mág of hoeft te bewaren.
Wat werkt:
- retentie afstemmen op je processen (hoe snel ontdek je fouten?)
- rekening houden met bewaarplicht/AVG
- bewaarbeleid per type data (niet alles hoeft hetzelfde)
Valkuil 6: Back-ups zijn niet beveiligd (en worden een extra aanvalsvector)
Back-upsystemen bevatten vaak de kroonjuwelen: alle data, op één plek. Als die omgeving slecht is beveiligd (zwakke wachtwoorden, geen MFA, te brede toegang, geen logging), maak je het een aanvaller juist makkelijker.
Back-upbeveiliging hoort bij de basis:
- sterke accounts + minimale rechten
- MFA waar mogelijk
- logging en monitoring
- beheerproces dat niet afhankelijk is van één persoon
De vraag die je wél moet stellen: hoe snel moeten we weer draaien?
Een goede back-upstrategie begint bij twee bedrijfsvragen:
- Hoeveel downtime is acceptabel? (uren, dagen?)
- Hoeveel data mogen we maximaal kwijt zijn? (een uur werk, een dag, een week?)
Die antwoorden bepalen je aanpak. Niet elk bedrijf heeft dezelfde eisen. Maar elk bedrijf heeft wél eisen, ook als ze niet uitgesproken zijn.
Wil je een back-up & hersteltest (zodat je het zeker weet)?
Justdata kan jullie back-upopzet controleren en vooral: een hersteltest uitvoeren op de onderdelen die voor jullie het meest kritisch zijn. Je krijgt daarna een praktisch overzicht: wat is goed, waar zit risico, hoe lang duurt herstel, en welke 2–3 verbeteringen geven de meeste zekerheid.
