Back-up en disaster recovery voor hosting bepaalt of een storing eindigt als een korte onderbreking of als uren, dagen of zelfs permanent dataverlies. Voor veel websites is dat verschil direct voelbaar in omzet, leads, reputatie en interne werkdruk. Een webshop die 4 uur offline is, verliest niet alleen bestellingen, maar ook advertentiebudget, klantvertrouwen en mogelijk zoekverkeer. Continuïteit vraagt daarom om meer dan “er draait ergens een back-up”. Het vraagt om heldere hersteldoelen, getest herstel en een disaster recovery plan dat past bij de technische en zakelijke impact van uitval.
De basis is simpel: je wilt weten wat je beschermt, hoe vaak je data veiligstelt, hoe snel je kunt herstellen en wie daarbij welke taak heeft. Wie dat niet vooraf vastlegt, ontdekt pas tijdens een incident dat de hosting back-up te oud is, dat databases niet zijn meegenomen of dat restore website hosting meer handwerk vraagt dan gedacht.
Wat back-up en disaster recovery voor hosting minimaal moet afdekken
Een bruikbare aanpak bestaat uit vier onderdelen:
- Data-back-up: websitebestanden, databases, mediabibliotheken, configuraties en waar relevant e-mail of applicatiedata.
- Herstelprocedures: stap-voor-stap instructies om een site, server of omgeving terug te zetten.
- Failover of uitwijk: een alternatief als de primaire hostingomgeving niet beschikbaar is.
- Testen en documentatie: bewijs dat herstel echt werkt binnen de afgesproken tijd.
Daarbij zijn twee meetwaarden leidend:
- RPO (Recovery Point Objective): hoeveel data je maximaal mag verliezen. Een RPO van 1 uur betekent dat je in het slechtste geval 1 uur aan wijzigingen kwijt bent.
- RTO (Recovery Time Objective): hoe lang herstel maximaal mag duren. Een RTO van 2 uur betekent dat de dienst binnen 2 uur weer beschikbaar moet zijn.
Voor een brochurewebsite is een RPO van 24 uur en een RTO van 8 uur soms acceptabel. Voor een webshop met doorlopende orders ligt dat vaak veel strakker, bijvoorbeeld een RPO van 15 minuten en een RTO van 1 uur. Dit hangt af van omzetverlies, contractuele verplichtingen en de rol van de website in de bedrijfscontinuïteit IT.
Welke data je altijd moet meenemen in een hosting back-up
Een hosting back-up is pas bruikbaar als alle kritieke onderdelen erin zitten. In de praktijk worden vooral databases en configuraties vergeten. Dat levert een schijnveiligheid op: de site lijkt teruggezet, maar formulieren, inloggegevens of productdata ontbreken.
Neem minimaal deze componenten op:
- Websitebestanden en broncode
- Databases, inclusief tabellen van CMS, webshop en formulieren
- Uploads en mediabestanden
- Serverconfiguraties, cronjobs en omgevingsvariabelen
- DNS-instellingen of in elk geval documentatie daarvan
- SSL-certificaatinformatie en verlengingsproces
- Gebruikersrechten en beheeraccounts
- Plug-ins, thema’s en versies van afhankelijkheden
Voor WordPress geldt bijvoorbeeld dat een kopie van alleen wp-content niet genoeg is. Zonder database mis je pagina-inhoud, gebruikers, instellingen en bestellingen uit WooCommerce. Voor maatwerkapplicaties geldt hetzelfde: bestanden zonder configuratie of secrets zijn zelden direct inzetbaar.
Drie back-upniveaus voor verschillende risico’s
Voor de meeste organisaties werkt een indeling in drie niveaus goed:
1. Dagelijkse basisback-up
Geschikt voor websites met beperkte mutaties. Denk aan een corporate site of kennisbank. Vaak volstaat:
- 1 back-up per 24 uur
- Bewaartermijn van 14 tot 30 dagen
- Herstel op bestands- of siteniveau
2. Verhoogde frequentie voor transactiesites
Geschikt voor webshops, portals en sites met veel formulierinzendingen. Gebruik dan bijvoorbeeld:
- Back-ups elke 1 tot 4 uur
- Databaseback-ups frequenter dan bestandsback-ups
- Bewaartermijn van 30 tot 90 dagen
3. Bedrijfskritische bescherming
Voor omgevingen waar uitval direct geld kost of processen blokkeert:
- Snapshots of replicatie per 5 tot 15 minuten
- Offsite opslag in een gescheiden omgeving
- Documenteerde uitwijkprocedure
- Geplande restore-tests per maand of per kwartaal
De 3-2-1-regel blijft hierbij een sterk uitgangspunt: bewaar 3 kopieën van data, op 2 verschillende media, waarvan 1 offsite. Het Amerikaanse Cybersecurity and Infrastructure Security Agency noemt offline back-ups expliciet als maatregel tegen ransomware: CISA-richtlijn voor ransomware en back-ups.
Het verschil tussen back-up en een disaster recovery plan
Een back-up is een middel. Een disaster recovery plan is het draaiboek. Zonder plan weet je wel dát er data is, maar niet hoe je die onder tijdsdruk veilig terugzet.
Een praktisch disaster recovery plan bevat minimaal:
- De scope: welke websites, applicaties en servers vallen onder het plan
- Prioriteiten: wat moet eerst terug online
- RPO en RTO per dienst
- Contactpersonen: hostingpartij, ontwikkelaar, domeinbeheerder, intern verantwoordelijke
- Toegangen: waar credentials veilig zijn opgeslagen
- Herstelstappen: van diagnose tot livegang
- Communicatie: wie informeert klanten, management en leveranciers
- Testfrequentie en evaluatie na incidenten
Een voorbeeld: een organisatie draait een webshop, een klantportaal en een marketingwebsite. Dan kan de prioriteit zijn: 1) webshop, 2) klantportaal, 3) marketingsite. Die volgorde voorkomt discussie tijdens druk. Het is ook verstandig om afhankelijkheden te benoemen, zoals payment providers, e-mailverzending en DNS.
Restore website hosting: waar herstel in de praktijk vaak misgaat
Restore website hosting klinkt eenvoudiger dan het is. Veel incidenten lopen vertraging op door details die vooraf niet zijn getest. De meest voorkomende problemen:
- Back-up bevat geen complete database
- Versies van PHP, database of dependencies wijken af
- DNS-wijzigingen zijn nodig maar niet gedocumenteerd
- Beheeraccounts zijn niet bereikbaar door MFA-problemen
- Back-up staat in dezelfde omgeving als de productieomgeving
- Er is wel een serverherstel, maar geen controle op applicatiewerking
Een geslaagde restore is pas geslaagd als de website functioneel werkt. Controleer daarom altijd:
- Laadt de homepage correct?
- Werken formulieren, checkout en inlog?
- Zijn afbeeldingen en downloads compleet?
- Klopt de SSL-configuratie?
- Werken redirects, caching en zoekfunctie?
- Worden e-mails of notificaties verzonden?
Voor veel mkb-sites is een testrestore per kwartaal een realistische ondergrens. Voor bedrijfskritische omgevingen is maandelijks testen verdedigbaar. Zonder test weet je niet of je RTO haalbaar is.
Minimale eisen voor bedrijfscontinuïteit IT bij hosting
Wie hosting serieus koppelt aan bedrijfscontinuïteit IT, kan deze minimale eisen als checklist gebruiken:
- Er is een gedocumenteerde inventaris van alle kritieke websites en afhankelijkheden.
- Per website zijn RPO en RTO vastgelegd.
- Er draait een automatische hosting back-up zonder handmatige tussenstappen.
- Back-ups staan versleuteld opgeslagen en minimaal één kopie staat offsite.
- Er is retentiebeleid, bijvoorbeeld 30 dagelijkse en 12 maandelijkse herstelpunten.
- Er is een disaster recovery plan met rollen, contactgegevens en herstelvolgorde.
- Restore website hosting is aantoonbaar getest.
- Toegang tot back-ups is beperkt, gelogd en niet afhankelijk van één persoon.
- Monitoring signaleert uitval, opslagproblemen en mislukte back-ups.
Voor kleinere organisaties hoeft dit niet complex te zijn. Een compacte set documenten van 2 tot 5 pagina’s is vaak al voldoende, zolang die actueel en uitvoerbaar is. Voor grotere organisaties past dit vaak in een breder continuïteits- of securitybeleid. Voor de bredere context van hostingbeveiliging en samenhang met andere maatregelen past ook Hosting beveiliging: van Zero Trust tot back-ups en DDoS-bescherming.
Hoe vaak moet je back-uppen en hoe lang moet je bewaren?
Er is geen universeel schema, maar wel een bruikbare vuistregel: stem frequentie af op mutatiesnelheid en retentie op herstelbehoefte.
- Statische website: dagelijks back-up, 14 tot 30 dagen bewaren
- Blog of contentsite: dagelijks of 2 keer per dag, 30 dagen bewaren
- Webshop: elk uur of elke 15 minuten voor databases, 30 tot 90 dagen bewaren
- Portaal met klantdata: hoge frequentie plus maandarchieven voor langere terugzoekbehoefte
Let op twee nuances. Ten eerste: langere bewaartermijnen helpen bij laat ontdekte fouten, zoals corrupte data of ongewenste wijzigingen die pas na weken opvallen. Ten tweede: meer back-ups betekenen ook meer opslagkosten en beheer. Reken voor eenvoudige cloudopslag vaak op enkele euro’s tot enkele tientallen euro’s per maand voor kleine websites, maar voor meerdere omgevingen, snapshots en langere retentie kan dat snel oplopen.
Wanneer je extra bescherming nodig hebt
Back-up en disaster recovery voor hosting vraagt extra maatregelen in drie situaties:
Bij ransomware of accountcompromis
Als aanvallers ook beheeraccounts raken, kunnen zij back-ups verwijderen. Gebruik daarom gescheiden toegangen, MFA en waar mogelijk immutable of write-once opslag.
Bij infrastructuuruitval
Als een complete host, regio of datastore uitvalt, heb je weinig aan back-ups in dezelfde omgeving. Offsite opslag of replicatie naar een tweede platform verkleint dit risico.
Bij complexe applicaties
Sites met API-koppelingen, queues, externe authenticatie of meerdere databases vragen meer dan een standaard herstel. Test daarbij niet alleen de website, maar ook de integraties.
Zo beoordeel je een hostingprovider op back-up en herstel
Vraag niet alleen óf een provider back-ups maakt, maar hoe herstel werkt. Deze vragen geven snel duidelijkheid:
- Hoe vaak worden bestanden en databases geback-upt?
- Wat is de standaard retentie?
- Staan back-ups in dezelfde infrastructuur of offsite?
- Kan ik zelf herstelpunten terugzetten?
- Wat is de verwachte hersteltijd voor een volledige site?
- Worden restore-tests uitgevoerd en gedocumenteerd?
- Zijn back-ups inbegrepen of betaal je per restore?
Let ook op de kleine lettertjes. Sommige hostingpakketten noemen back-ups “best effort”. Dat is geen harde continuïteitsgarantie. Voor bedrijfskritische websites is dat vaak onvoldoende.
Veelgestelde vragen
Is een dagelijkse back-up genoeg voor hosting?
Voor een statische of weinig gewijzigde website vaak wel. Voor een webshop, reserveringssysteem of portaal meestal niet. Als je elk uur nieuwe orders of aanvragen ontvangt, kan een dagelijkse back-up te veel dataverlies betekenen. Bepaal daarom eerst je RPO.
Wat is het verschil tussen een back-up en hoge beschikbaarheid?
Een back-up helpt je herstellen na verlies of fouten. Hoge beschikbaarheid beperkt downtime door redundantie, failover of clustering. Het ene vervangt het andere niet. Een redundante omgeving zonder goede back-up beschermt je niet tegen verwijderde data of ransomware.
Hoe test je restore website hosting zonder risico?
Door een herstel uit te voeren in een staging- of testomgeving. Daar controleer je bestanden, database, logins, formulieren, checkout en koppelingen. Documenteer de duur van het herstel en de gevonden fouten. Dat levert direct input op voor je disaster recovery plan.
Hoe lang moet ik back-ups bewaren?
Voor veel mkb-sites is 30 dagen een bruikbare ondergrens. Bij financiële transacties, compliance-eisen of laat ontdekte fouten is langere retentie verstandig, bijvoorbeeld 60 tot 90 dagen plus maandelijkse archieven. Dit hangt af van risico, opslagkosten en wettelijke bewaarplichten buiten de hosting zelf.
Kan ik volledig vertrouwen op de back-ups van mijn hostingprovider?
Niet blind. Providerback-ups zijn waardevol, maar controleer frequentie, retentie, offsite opslag en herstelprocedure. Voor kritieke websites kiezen veel organisaties voor een extra onafhankelijke kopie buiten de primaire hostingomgeving. Dat verkleint de kans op een single point of failure.