Back-upstrategie voor websites die werkelijk werkt
Vrijwel iedereen heeft back-ups. Veel minder mensen hebben back-ups waarvan bewezen is dat ze terug te zetten zijn, en dat is het enige dat telt op de dag dat je ze nodig hebt.
Deze gids behandelt wat er in een back-up hoort, waar hij moet staan, hoelang je hem bewaart, en hoe je de terugzettest uitvoert die van een aanname een feit maakt.
Wat er in een volledige back-up hoort#
Een gedeeltelijke back-up voelt als een back-up tot het moment dat je hem nodig hebt. Dit is de complete lijst.
- Database: alle inhoud, gebruikers, instellingen, en bij een shop bestellingen en klanten.
- Geüploade bestanden: afbeeldingen, documenten, bijlagen — vaak het grootste deel in omvang.
- Code en thema's: vooral maatwerkaanpassingen die nergens anders bestaan.
- Serverconfiguratie: virtuele hosts, omleidingsregels, cronjobs.
- Certificaten en omgevingsvariabelen: de dingen die je vergeet tot het terugzetten vastloopt.
- Een genoteerd terugzetproces: in welke volgorde, welke inloggegevens, welke DNS-instellingen.
- Voor maatwerk vervangt versiebeheer de codeback-up, maar niet de database of de uploads.
Uploads zijn wat het vaakst uit geautomatiseerde back-ups valt omdat ze buiten het CMS-pad staan. Controleer specifiek dat ze meekomen.
Frequentie en bewaartermijn#
De juiste frequentie volgt uit één vraag: hoeveel werk kun je je veroorloven opnieuw te doen?
| Type site | Frequentie | Bewaartermijn |
|---|---|---|
| Statische brochuresite | Bij wijziging, plus maandelijks | Enkele maanden |
| Bedrijfssite met blog | Dagelijks | Dertig dagen, plus maandelijkse punten |
| Webshop | Elk uur of continu | Dertig dagen minimaal; orders langer |
| Applicatie met gebruikersgegevens | Continu met transactielogboek | Volgens bewaarbeleid |
| Vóór elke update | Handmatig, altijd | Tot de update bewezen goed draait |
Meerdere generaties bewaren telt zwaarder dan hoge frequentie. Een inbraak die pas na twee weken wordt ontdekt maakt elke back-up van de laatste twee weken waardeloos.
Waar back-ups horen te staan#
De opslagplaats bepaalt tegen welke soorten storingen je beschermd bent. Dit is waar de meeste opzetten tekortschieten.
| Locatie | Beschermt tegen | Beschermt niet tegen |
|---|---|---|
| Zelfde server | Per ongeluk verwijderen van inhoud | Serveruitval, gijzelsoftware, accountverlies |
| Zelfde hostingaccount | Serveruitval | Accountopschorting, gecompromitteerde toegang |
| Aparte cloudopslag | Vrijwel alles | Verlies van die opslagreferenties |
| Lokale kopie | Verlies van de aanbieder | Vraagt discipline om actueel te blijven |
| Drie kopieën, twee media, één extern | Praktisch alles | Niets van betekenis |
Ten minste één back-up hoort volledig buiten de infrastructuur en het account van je host te staan. Gijzelsoftware en accountopschortingen nemen alles mee dat binnen bereik ligt.
De terugzettest#
Dit is het onderdeel dat back-ups van een aanname in een feit verandert, en het onderdeel dat vrijwel iedereen overslaat.
- Zet elk kwartaal een back-up terug naar een testomgeving, niet naar productie.
- Klok hoelang het duurde. Dat cijfer is je werkelijke hersteltijd, en het is meestal langer dan verwacht.
- Controleer dat de inhoud compleet is — inclusief afbeeldingen, niet alleen tekst.
- Controleer dat formulieren, aanmelden en, bij een shop, het afrekenen werken.
- Noteer wat er miste of misging, en herstel het back-upproces.
- Leg het terugzetproces vast zodat iemand anders het kan uitvoeren wanneer jij niet bereikbaar bent.
- Herhaal na elke grote wijziging aan de site of de hosting.
De meest voorkomende ontdekking bij een eerste terugzettest is dat een deel van de bestanden ontbreekt of dat niemand de databasereferenties heeft. Dat is precies waarom je test op een rustige dag.
Veelgestelde vragen
Zijn de back-ups van mijn host voldoende?
Als enige back-up niet. Ze zijn nuttig en meestal snel, maar ze liggen binnen hetzelfde account dat je kunt verliezen bij een geschil, een opschorting of gecompromitteerde toegang. Houd de back-ups van je host én een onafhankelijke kopie elders. De tweede kopie is er precies voor het scenario waarin de eerste onbereikbaar is.
Hoe vaak moet ik back-uppen?
Vaak genoeg dat het verlies tussen twee back-ups acceptabel is. Een blog die wekelijks publiceert kan dagelijks. Een webshop kan dat niet — een dag bestellingen kwijtraken is een operationeel probleem, geen ongemak, dus daar hoort continu of elk uur. Bepaal het door te vragen hoeveel werk je bereid bent opnieuw te doen.
Hoelang moet ik back-ups bewaren?
Dertig dagen aan recente punten dekt het merendeel van de incidenten, plus maandelijkse punten voor de langere termijn. De reden voor de langere termijn is dat problemen vaak laat ontdekt worden — een beschadigde inhoudsimport of een inbraak van drie weken geleden. Bestel- en factuurgegevens vallen bovendien onder wettelijke bewaartermijnen.
Wat als ik geen back-up heb en de site is weg?
Vraag eerst je host — veel hebben momentopnamen die je niet zelf beheert, soms enkele dagen terug. Daarna: de Wayback Machine en de cache van zoekmachines kunnen zichtbare inhoud teruggeven, maar geen database, geen bestanden en geen bestellingen. Het is redding, geen herstel, en het is de reden dat de terugzettest bestaat.
website back-upback-upstrategiewebsite herstellendatabase back-upterugzettestback-up buiten locatie
