Bij een gewone bedrijfswebsite is een wekelijkse back-up meestal prima. Gaat er iets mis, dan zet u de versie van zondag terug en bent u hooguit een blogartikel of een aangepaste openingstijd kwijt. Vervelend, maar te overzien.

Bij een webshop ligt dat anders. Elke bestelling, elke betaling, elke voorraadwijziging en elk nieuw klantaccount is een wijziging in de database. Zet u een back-up van zondag terug op donderdag, dan zijn de bestellingen van vier dagen weg, terwijl de betalingen wel binnen zijn en de pakketten misschien al onderweg. Daarom is een backup van een webshop iets anders dan een back-up van een website, en daarom is dagelijks voor de meeste shops het minimum. In dit artikel leg ik uit wat u precies kwijtraakt, hoe u een ritme kiest en waar de back-up thuishoort.

Wat er in een webshopdatabase per dag verandert

Het is verleidelijk om te denken dat de shop “hetzelfde” blijft zolang u geen producten toevoegt. Maar onder de motorkap gebeurt er continu iets. Een greep uit wat een gemiddelde dag aan wijzigingen oplevert:

  • Nieuwe bestellingen, met adres, producten, bedragen en betaalstatus.
  • Statuswijzigingen: van “in behandeling” naar “verzonden” naar “afgerond”.
  • Voorraadmutaties per verkocht product of per retour.
  • Nieuwe klantaccounts en gewijzigde adressen.
  • Gebruikte kortingscodes en de teller die bijhoudt hoe vaak.
  • Track-en-tracecodes die de verzendkoppeling terugschrijft.
  • Betaalbevestigingen van iDEAL of Mollie die via een webhook binnenkomen.

Geen van die wijzigingen kunt u achteraf reconstrueren zonder een back-up. U heeft de betaalgegevens bij Mollie, ja, maar niet welke producten erbij hoorden. U heeft de verzendlabels bij PostNL, maar niet de klantnotitie “bezorgen bij de buren”. Het reconstrueren van één dag bestellingen uit losse bronnen is uren werk; vier dagen is een week.

Wat u verliest bij een wekelijkse back-up

Stel, uw shop draait op een wekelijkse back-up van zondagnacht. Op donderdagmiddag gaat een pluginupdate mis en is de checkout onbruikbaar. De snelste oplossing is terugzetten. Dat betekent:

  • Alle bestellingen van maandag tot en met donderdag verdwijnen uit de shop.
  • De voorraad springt terug naar de stand van zondag, dus producten die uitverkocht zijn, staan weer als leverbaar.
  • Klanten die deze week een account hebben aangemaakt, kunnen niet meer inloggen.
  • Kortingscodes die “eenmalig” waren, zijn opnieuw bruikbaar.

U zult dus niet zomaar terugzetten. U gaat eerst proberen de fout te herstellen, wat langer duurt en de shop langer offline houdt. De wekelijkse back-up is er wel, maar u durft hem niet te gebruiken. Dat is het echte probleem: een back-up die u niet durft terug te zetten, is geen vangnet. Wat er precies gebeurt als u het toch doet, en hoe u de tussenliggende bestellingen redt, leest u in het artikel over verdwenen bestellingen na een terugzetactie.

Welk ritme past bij uw shop

Een handig uitgangspunt is de vraag: hoeveel bestellingen kan ik met de hand opnieuw invoeren zonder dat het een probleem wordt? Het antwoord bepaalt hoeveel uur er tussen twee back-ups mag zitten.

  • Enkele bestellingen per week: dagelijks is ruim voldoende. U verliest hooguit één bestelling, en die kunt u uit de betaalbevestiging terughalen.
  • Enkele bestellingen per dag: dagelijks is het minimum; overweeg een tweede back-up van alleen de database halverwege de dag.
  • Tientallen bestellingen per dag of meer: een databaseback-up elk uur, plus een dagelijkse volledige back-up van bestanden en database. Databaseback-ups zijn klein en snel; de bestanden (afbeeldingen, thema, plugins) veranderen veel minder vaak.
  • Rond acties en feestdagen: tijdelijk opschalen. Een Black Friday-weekend rechtvaardigt een back-up per kwartier van de database.

Dat onderscheid tussen database en bestanden is belangrijk. Een volledige back-up van een shop met tienduizend productfoto’s kan tientallen gigabytes zijn; die elk uur maken is onzinnig. De database is vaak maar enkele honderden megabytes en bevat alles wat per uur verandert.

Waar de back-up moet staan

Een back-up op dezelfde server als de shop helpt bij een mislukte update, maar niet bij een gehackte server, een schijf die stukgaat of een hostingpartij die het account blokkeert. Een van de twee kopieën hoort daarom extern te staan: bij een andere partij, in een andere ruimte, versleuteld. Voor een Nederlandse webshop is opslag binnen de EU bovendien een AVG-kwestie, omdat de database persoonsgegevens van klanten bevat.

Denk ook aan bewaartermijn. Een hack of een stille datacorruptie merkt u niet altijd dezelfde dag. Als u alleen de laatste zeven dagen bewaart en het probleem is tien dagen oud, heeft u alleen besmette back-ups. Bewaar dagelijkse kopieën een maand en wekelijkse een paar maanden.

Wat u zelf kunt controleren

  1. Wanneer is de laatste back-up gemaakt? Als u dat niet binnen een minuut kunt vinden, is dat het eerste probleem.
  2. Bevat hij de database én de bestanden?
  3. Staat er een kopie buiten de server van de shop?
  4. Is er ooit een terugzetactie geoefend, op een testomgeving? Een back-up die nooit is getest, is een aanname.
  5. Wordt u gewaarschuwd als een back-up mislukt? Back-ups die stilletjes stoppen na een pluginupdate komen vaker voor dan u denkt.

Een webshop in babyartikelen uit Haarlem kwam bij ons met een hostingback-up die één keer per week draaide. Ze dachten dat het genoeg was, totdat een defecte plugin op woensdag de ordertabel beschadigde. Wij konden de database uit een logbestand van de server grotendeels reconstrueren, maar het kostte twee dagen en drie bestellingen bleven onvindbaar. Sindsdien draait daar elk uur een databaseback-up naar externe, versleutelde opslag, wat bij WooCommerce-onderhoud op het Groei-niveau standaard is inbegrepen.

Volgende stap: zoek op waar en wanneer uw laatste back-up is gemaakt. Lukt dat niet in vijf minuten, dan weet u genoeg.