De meeste e-commerçanten denken dat ze gebackupt zijn. De meerderheid is het niet echt. In de audits die wij uitvoeren, heeft 6 op de 10 shops geen back-up die binnen 4 uur te herstellen is, heeft 3 op de 10 corrupte of onvolledige back-ups, en heeft ongeveer 1 op de 10 al meer dan een maand geen bruikbare back-up, vaak zonder het te weten.
De kosten van een incident zonder werkende back-up: tussen 24 uur en meerdere weken stilstand, verloren klantdata, en soms bedrijfsbeëindiging. Dit artikel beschrijft de back-upstrategie die men in 2026 op een PrestaShop-shop zou moeten hebben: de 3-2-1 regel, de versleuteling, de rotatie, en vooral: de geteste restore.
Waarom de standaard back-ups niet volstaan
“Mijn hoster maakt back-ups” is de zin die het vaakst terugkomt. Doorgaans waar, en in de praktijk onvoldoende:
- De hosterback-ups staan in hetzelfde datacenter. Een grote brand (OVH Straatsburg 2021), een ransomware-aanval of een gecompromitteerd adminpaneel van de hoster, en de back-ups branden mee met de data.
- De retentie is kort. 7 tot 14 dagen voor de standaardaanbiedingen. Ontdekt u een defacement of een corruptie 3 weken later, dan heeft de geïnfecteerde back-up de gezonde al vervangen.
- Bevat de back-up werkelijk alles? Veel hosters backuppen de database maar niet de bestanden, of omgekeerd. En de uploads (productafbeeldingen, PDF-facturen, exports) worden soms vergeten.
- De restore wordt nooit getest. Op de dag zelf ontdekt men dat de restoreprocedure niet werkt, of 36 uur duurt, of toegang vraagt tot een paneel dat men kwijt is.
- Geen versleuteling. Een onversleutelde back-up gehost bij een derde: uw hele klantendatabase blootgesteld bij een lek bij de dienstverlener.
De 3-2-1 regel: industriestandaard sinds 30 jaar
Geformuleerd door fotograaf Peter Krogh in 2005 voor digitale back-ups, overgenomen door het NCSC, het Amerikaanse CISA en vrijwel alle IT-beveiligingsframeworks:
3 kopieën van de data, op 2 verschillende dragers, waarvan 1 off-site.
Concreet voor een PrestaShop-shop:
- Kopie 1: de productie (uw productieserver).
- Kopie 2: lokale back-up of bij dezelfde hoster (snel te herstellen bij kleine incidenten).
- Kopie 3: off-site back-up, bij een externe opslagaanbieder (S3, Backblaze B2, Wasabi, Dropbox).
De off-site kopie is de laatste verdedigingslinie tegen grote rampen (brand, ransomware, faillissement van de hoster).
Wat er in een PrestaShop-shop gebackupt moet worden
1. De complete database
Alle tabellen, niet alleen de businesstabellen. Een mysqldump met de opties --single-transaction --quick --routines --triggers voor de coherentie en het meenemen van de stored procedures en triggers.
2. De geüploade bestanden
De map /img/ (afbeeldingen van producten, categorieën, fabrikanten), /upload/ (aan producten gekoppelde bestanden), /download/ (virtuele producten en hun leverbestanden), en alle mappen van externe modules die bestanden opslaan (PDF-facturen, boekhoudexports, logs).
3. De code en de modules
Zelfs met Git laat het backuppen van de productiecode toe de niet-geversioneerde hotfixes en de exacte staat van de geïnstalleerde modules vast te leggen. Omvat /modules/, /themes/, /override/, en de PrestaShop-root exclusief /var/cache/.
4. De systeemconfiguratie
De bestanden app/config/parameters.php, .htaccess, Nginx/Apache-configuraties, SSL-certificaten, crontabs. Vaak vergeten, maar kritiek om een installatie vanaf nul te kunnen herbouwen.
5. De uitgaande e-mails en recente logs
Voor de wettelijke verplichtingen (AVG, boekhouding): een kopie bewaren van de recente logs en transactionele e-mails. Niet systematisch, maar nuttig.
Versleuteling is niet langer optioneel
Een onversleutelde back-up opgeslagen bij een externe aanbieder is een groot AVG-risico: wordt de dienstverlener gecompromitteerd, dan lekt uw hele klantendatabase in leesbare vorm. Artikel 32 AVG: verplichting om “passende technische maatregelen” te implementeren, wat versleuteling at rest omvat voor back-ups met persoonsgegevens.
De standaard in 2026: AES-256 met een sleutel die apart van de back-ups wordt bewaard. Bewaar de versleutelingssleutel nooit bij de back-ups, anders dient de versleuteling nergens toe.
De rotatie: hoeveel versies bewaren
Hoe meer men bewaart, hoe beter, maar het kost geld. Beproefde GFS-strategie (Grandfather-Father-Son):
- Dagelijkse back-ups 7 dagen bewaard.
- Wekelijkse back-ups 4 weken bewaard.
- Maandelijkse back-ups 12 maanden bewaard.
- Jaarlijkse back-ups 5 tot 7 jaar bewaard (afhankelijk van de lokale boekhoudkundige verplichtingen).
Met deze strategie kunt u herstellen naar elke dag van de laatste 7 dagen, elke week van de laatste maand, elke maand van het laatste jaar. Dekt 99% van de herstelscenario’s.
De geteste restore: de enige back-up die telt
Een niet-geteste back-up is bijgeloof, geen back-up. De absolute regel:
Test de restore op een stagingomgeving minstens één keer per kwartaal.
Deze test moet verifiëren:
- Is de back-up compleet (alle tabellen, alle bestanden)?
- Is de dump zonder fouten te herstellen?
- Werkt de site na de restore (categoriepagina’s, winkelwagen, checkout, backoffice)?
- Hoelang duurt de complete restore (RTO: Recovery Time Objective)?
- Wat is het maximale dataverlies (RPO: Recovery Point Objective)?
Op de shops die deze kwartaaltest doen, daalt de restoretijd van 6-8 uur naar 1-2 uur in enkele iteraties. En de afwijkingen (ontbrekende tabel, verkeerde permissie, corrupt bestand) worden vóór het incident gedetecteerd, niet tijdens.
Onze module dfbackup: kant-en-klare back-up
Deze strategie handmatig implementeren vraagt het onderhoud van een dumpscript, een versleutelingssysteem, een rotatie en een upload naar S3-opslag. Onze module dfbackup voor PrestaShop 8 en 9 verpakt de hele stack:
- Geplande back-up van database + bestanden via cron, configureerbaar interval (dagelijks, wekelijks).
- AES-256 versleuteling met aparte sleutel, buiten de server op te slaan.
- Meerdere bestemmingen: S3 (en compatibelen: Wasabi, Backblaze B2, Scaleway), FTP/SFTP, Dropbox.
- Geautomatiseerde GFS-rotatie: bewaring per laag configureerbaar.
- 1-klik restore vanuit de backoffice, met optionele staging.
- Notificaties per e-mail of webhook bij falen of succes.
- Gedetailleerde logs van elke back-up (volume, duur, verificatiehash).
- Compatibel met multi-shop, meertalig, en met gedifferentieerde retentie per scope.
Voor 129 € installeert u een AVG-conforme, geïndustrialiseerde back-upstrategie, zonder afhankelijk te zijn van uw hoster.
Wat het kost om niet gebackupt te zijn
Op een shop die 100 K€ maandomzet genereert, kost 48 uur stilstand direct 6.700 € aan niet-gerealiseerde omzet. Tel de indirecte kosten erbij: herwinnen van verloren klanten, negatieve reacties bij de klantenservice, SEO-impact als de stilstand duurt (Google kan deïndexeren als de site meer dan enkele dagen 404 blijft), vertrouwensverlies bij partners. Realistisch totaal: 15 tot 30 K€ voor 48 uur stilstand. Bij een maand stilstand gaat het over de levensvatbaarheid van het bedrijf.
De kosten van een robuuste back-upstrategie: 130 € module + 5 tot 20 € per maand S3-opslag. De kosten/risico-verhouding is geen discussie.
FAQ
Volstaan incrementele back-ups?
Niet alleen. Een incrementele back-up hangt af van de vorige complete back-up. Is de complete back-up corrupt, dan is de hele incrementele keten onbruikbaar. De regel: een wekelijkse of maandelijkse complete back-up, aangevuld met dagelijkse incrementele. Niet omgekeerd.
Hoelang mag een restore duren?
De acceptabele RTO hangt af van de criticiteit. Voor een actieve e-commerce shop is minder dan 4 uur voor een complete restore het doel. Onder de 2 uur met een ingeoefende procedure en nabije opslag. Boven de 8 uur is er een probleem met de strategie of de tooling.
Moeten bestanden en database samen of apart gebackupt worden?
Samen, idealiter in een nauw tijdvenster (10-15 minuten). Een gedesynchroniseerde database en bestanden (bijvoorbeeld database ‘s ochtends gebackupt, bestanden ‘s avonds) creëren incoherenties bij de restore: producten in de database zonder afbeelding, gerefereerde facturen die als bestand niet bestaan.
Is cloudopslag (S3) AVG-conform?
Ja, als de aanbieder in de EU zit of de modelcontractbepalingen (SCC’s) aanbiedt voor transfers buiten de EU. AWS, Scaleway, OVH Object Storage en Backblaze zijn conform met de juiste configuratie. De versleuteling vóór de upload garandeert dat zelfs een gecompromitteerde aanbieder toegang geeft tot niets bruikbaars.
Wat is het verschil met realtime replicatie?
Replicatie (MySQL master-slave bijvoorbeeld) beschermt tegen een hardwarestoring, niet tegen menselijke fouten of logische corrupties. Verwijdert een script per ongeluk 10.000 producten, dan past de replica de verwijdering onmiddellijk toe. De geversioneerde back-up bewaart een eerdere gezonde versie. Beide zijn complementair, niet uitwisselbaar.
Om verder te gaan
De back-up is een schakel in een bredere keten: beveiliging, monitoring, incidentbeheer. Een goed gebackupte maar slecht gemonitorde site verliest alsnog data tussen het incident en de detectie ervan. Zie ook onze gids voor het installeren van PrestaShop-modules om te begrijpen waar dfbackup in de stack past, en het dossier over het opschonen van de PrestaShop-database: de database verlichten vóór de back-up deelt de back-uptijd en de opslagkosten door 5.
Om in actie te komen: onze modulesselectie voor onderhoud, back-up en betrouwbaarheid.
