Back-ups voor je platform: twee opties vergeleken

Veel ondernemers gaan er vanuit dat hun website of webplatform goed beveiligd is omdat hun hostingprovider ergens een vinkje heeft staan bij 'dagelijkse back-ups'. Pas wanneer een update mislukt, een database corrupt raakt of een server fysiek uitvalt, blijkt wat dat vinkje in de praktijk waard is. Een back-up op papier is namelijk geen garantie. Een back-up is pas functioneel als je het herstelproces minstens één keer succesvol hebt uitgevoerd.

Infrastructuur en betrouwbaarheid bepalen voor een groot deel het vertrouwen van je klanten. Recent onderzoek van Search Engine Journal liet bijvoorbeeld zien dat alternatieve domeinextensies zoals .org soms tot 34 procent meer e-commerce omzet genereren dan traditionele .com domeinen. De verklaring daarachter is logisch: bezoekers kiezen onbewust voor aantoonbare betrouwbaarheid en autoriteit. Diezelfde logica geldt voor de technische achterkant van je platform. Als jouw systeem niet bereikbaar is of klantgegevens verliest, verdwijnt dat opgebouwde vertrouwen op slag.

In dit artikel vergelijken we twee concrete benaderingen van back-ups voor kmo-websites en webapplicaties: de ingebouwde hostingback-up versus de geïsoleerde off-site back-upstructuur. Aan het einde vind je een duidelijke keuzehulp om te bepalen welke optie aansluit bij het risicoprofiel van jouw bedrijf.

Waarom een back-upstrategie meer is dan een dagelijkse kopie

Bij het inrichten van een back-upomgeving draait het niet alleen om de vraag of er een kopie van je bestanden bestaat. Het draait om twee cruciale factoren uit de IT-wereld: de hersteltijd (Recovery Time Objective of RTO) en het toegestane dataverlies (Recovery Point Objective of RPO).

De hersteltijd bepaalt hoe lang je platform offline mag zijn nadat er iets ernstigs misgaat. Is dat tien minuten, twee uur of drie werkdagen? Het toegestane dataverlies bepaalt hoeveel gegevens je mag kwijtraken. Als je een back-up maakt om middernacht en het systeem crasht om elf uur 's avonds, ben je 23 uur aan nieuwe klantbestellingen, offertes of accountaanmaken kwijt. Voor een eenvoudige presentatiewebsite is dat overkomelijk, maar voor een maatwerk webapp of webshop met continue transacties is dat onacceptabel.

Daarnaast ontstaan problemen zelden door een totale servercrash alleen. Veel vaker gaat het om menselijke fouten, een foute database-migratie, beschadigde mediabestanden of een ongemerkte injectie van schadelijke code die al weken in je systeem zit. Als je back-upstrategie alleen bestaat uit het overschrijven van gisteren met vandaag, back-up je op een gegeven moment ook de beschadigde data of de malware.

Optie 1: De ingebouwde hosting- of plugin-back-up

De eerste optie is de benadering die het meest voorkomt bij kmo's. Dit is de back-upvoorziening die standaard bij een hostingpakket zit of via een geautomatiseerde plugin in een CMS draait. De hostingprovider maakt bijvoorbeeld elke nacht een snapshot van de server, of een script op de server pakt de database en bestanden in en bewaart deze in een specifieke map op dezelfde schijf.

Hoe deze optie werkt

In de praktijk werkt deze methode volledig op de achtergrond. Je stelt via een controlepaneel in dat het systeem elke nacht om 02:00 uur een back-up maakt. Deze bestanden blijven meestal zeven tot dertig dagen bewaren op de server van de provider. Met één druk op de knop kun je in het hostingdashboard een vorige status herstellen.

De voordelen

• Lage instapdrempel: Het kost vrijwel geen tijd om in te stellen en vereist geen diepgaande technische kennis van infrastructuur.
• Geen extra infrastructuurkosten: De opslag is meestal inbegrepen in de maandelijkse prijs van je hostingpakket.
• Snel herstel bij kleine fouten: Als je per ongeluk een bestand wist of een verkeerde instelling aanpast, herstel je dat snel via de hostinginterface.

De nadelen

• Single point of failure: Als de fysieke server uitvalt, het datacenter kampt met een grote storing of je hostingaccount wordt geblokkeerd, kun je ook niet meer bij je back-ups.
• Capaciteitsproblemen bij grote databases: Plugins of generieke scripts die op de live server draaien, verbruiken geheugen en processorkracht. Bij grotere databases of veel media lopen deze processen vaak vast vanwege een timeout.
• Geen Point-in-Time Recovery: Je kunt alleen terug naar het exacte tijdstip van het snapshot. Alles wat tussen twee snapshots gebeurt, is definitief weg.
• Geen automatische verificatie: Er is geen controle of het gemaakte back-upbestand wel compleet en bruikbaar is.

Optie 2: Geïsoleerde off-site back-ups met point-in-time recovery

De tweede optie scheidt het herstelmechanisme volledig van de live omgeving. Hierbij worden gegevens continu of op vaste intervallen geëxporteerd naar een onafhankelijke, beveiligde cloudinfrastructuur. Dit is de standaard bij maatwerkplatformen die gebouwd zijn met moderne stacks zoals React, TypeScript en Supabase.

Hoe deze optie werkt

Bij deze aanpak wordt de database niet simpelweg eenmaal per dag gekopieerd. Via technieken zoals Write-Ahead Logging (WAL) of geautomatiseerde database-dumps worden wijzigingen continu geregistreerd. De back-upbestanden en mediabestanden worden direct versleuteld verzonden naar een fysiek gescheiden object storage locatie, zoals Supabase Storage of een dedicated AWS S3 bucket in een ander datacenter.

Het herstelproces staat los van je hostingprovider. Mocht de complete serverprovider omvallen, dan kan de applicatie binnen korte tijd worden opgebouwd op een nieuwe server aan de hand van de losstaande code repository en de externe data-opslag.

De voordelen

• Maximale isolatie: Een probleem op de applicatieserver heeft geen enkele invloed op de veiligheid van de back-updata.
• Point-in-Time Recovery (PITR): Je kunt de database herstellen naar een specifiek minuut voor de fout of crash plaatsvond. Dit beperkt dataverlies tot een minimum.
• Geen belasting van de live server: De opslag en verwerking vinden extern plaats, waardoor de snelheid van de live website of applicatie gegarandeerd blijft.
• Onafhankelijkheid van leveranciers: Je zit niet vast aan één specifieke hostingpartij. Je behoudt altijd de volledige controle over je eigen data.

De nadelen

• Hogere inrichtingskosten: Dit vereist maatwerk en een correct afgestelde infrastructuur door een ervaren ontwikkelaar.
• Aparte cloudkosten: Er zijn kleine, periodieke kosten verbonden aan de externe opslagruimte en datatransfer.
• Onderhoud vereist: De opslag- en herstelscripts moeten periodiek gecontroleerd en getest worden.

Wat er concreet misgaat zonder een doordacht plan

In de praktijk zien we regelmatig waar het misgaat bij bedrijven die dachten dat hun back-up goed geregeld was. De onderstaande drie scenario's laten zien hoe een gebrekkige strategie uitpakt bij een incident.

Scenario A: De beschadigde back-up

Een bedrijf voert een grote update uit aan het CMS. De update mislukt en de website vertoont alleen nog foutmeldingen. De ontwikkelaar klikt in het hostingpaneel op 'Herstel back-up van gisteren'. Het herstelproces geeft een succesmelding, maar de database blijkt incompleet te zijn omdat het back-upscript halverwege was afgebroken door een limiet in het geheugen. Omdat het bestand nooit automatisch werd gecontroleerd, is de meest recente werkende staat van de website definitief verloren.

Scenario B: De server valt fysiek uit

Door een hardwarefout in het datacenter raakt de schijf van de server onleesbaar. De ondernemer neemt contact op met de hostingpartij en vraagt om het laatste snapshot terug te zetten. De hostingpartij meldt dat de snapshots op dezelfde fysieke serverruimte werden bewaard als de live website. Zowel de live omgeving als de back-ups zijn onherstelbaar beschadigd.

Scenario C: De silent data corruption

Een kwaadwillend script krijgt toegang tot de database en past op de achtergrond ongemerkt klantgegevens en prijzen aan. Het bedrijf merkt het probleem pas na drie weken op. Omdat de hostingprovider slechts zeven dagen aan back-ups bewaart, bevatten alle beschikbare back-ups reeds de gecorrumpeerde data. Zonder een langetermijnarchief of geavanceerde logging is er geen schone versie meer terug te halen.

Keuzehulp: Welke aanpak past bij jouw organisatie?

Om te bepalen welke back-upstructuur noodzakelijk is voor jouw kmo, kun je onderstaand overzicht gebruiken. De keuze hangt af van het type platform en de impact van eventuele stilstand op je bedrijfsvoering.

Criterium	Optie 1: Hosting / Plugin Back-up	Optie 2: Geïsoleerd & Off-site
Type platform	Statische informatiepagina's, eenvoudige corporate websites	Webshops, klantportalen, custom CRM's, SaaS-applicaties
Maximale hersteltijd (RTO)	Enkele uren tot meerdere dagen	Binnen een uur direct inzetbaar
Toegestaan dataverlies (RPO)	24 uur aan dataverlies is accepteerbaar	Maximaal enkele minuten tot een uur dataverlies
Afhankelijkheid van hosting	Volledig afhankelijk van één partij	Onafhankelijk, data staat op gescheiden cloudopslag
Herstelgarantie	Zelden vooraf getest	Periodiek getoetst via geautomatiseerde of handmatige testen
Kosten	Inbegrepen in standaard hosting	Vraagt investering in inrichting en externe opslag

Kies voor Optie 1 als:

Je website louter dient als digitaal visitekaartje. Er worden geen transacties verwerkt, bezoekers maken geen accounts aan en de inhoud verandert slechts een paar keer per jaar. Als de website een dag offline is, leidt dit niet direct tot omzetverlies of juridische problemen. Zorg er in dit geval wel voor dat je af en toe handmatig een kopie van de bestanden en database downloadt en op een eigen veilige locatie opslaat.

Kies voor Optie 2 als:

Je platform een essentieel onderdeel is van je bedrijfsvoering. Dit geldt voor webshops, custom dashboards, klantportalen of applicaties waar dagelijks nieuwe data, bestellingen of leads binnenkomen. Het verlies van een dag aan gegevens betekent directe financiële schade of reputatieschade. Met een geïsoleerde off-site back-upstructuur en point-in-time recovery borg je de continuïteit van je onderneming, ongeacht wat er met de server of leverancier gebeurt.

Het bouwen van een solide webplatform stopt niet bij een mooi ontwerp of snelle code. De manier waarop je omgaat met data, veiligheid en herstelprocedures bepaalt of je platform klaar is voor de lange termijn.

Wil je controleren of jouw huidige back-upstructuur en infrastructuur voldoende bescherming bieden bij calamiteiten? Neem gerust contact op voor een vrijblijvend, gratis gesprek van dertig minuten via ferhat.io/contact.