Bij een kennismaking met een nieuwe klant stellen we altijd dezelfde vraag: “Heeft u een back-up?” Het antwoord is meestal ja. De vervolgvraag is lastiger: “Waar staat die?” En dan wordt het stil, of komt er een antwoord als “op de server, in een map van de plugin”. Dat is technisch gezien een back-up. Praktisch gezien is het een kopie die in bijna elk scenario waarin u hem nodig heeft, tegelijk met de site verdwijnt.

Een website-back-up extern opslaan, dus op een andere plek dan de server waarop de site draait, is een van de goedkoopste maatregelen met de grootste opbrengst. In dit artikel leggen we uit wat er misgaat als u het niet doet, welke scenario’s ondernemers vaak over het hoofd zien en hoe u het wel goed regelt zonder ingewikkelde techniek.

Wat “op dezelfde server” in de praktijk betekent

Veel back-upplugins slaan hun bestanden standaard op in een submap van uw website, iets als wp-content/updraft of wp-content/backups. Dat is de standaardinstelling omdat het altijd werkt: er hoeft geen koppeling met een externe dienst te worden ingesteld. Maar het betekent dat de back-up in dezelfde webruimte staat, op dezelfde schijf, achter hetzelfde wachtwoord en bij dezelfde hostingpartij als de site zelf.

Ook de dagelijkse snapshot van uw hostingpartij is vaak minder “extern” dan het lijkt. Die staat meestal wel op een andere schijf, maar bij dezelfde partij, in hetzelfde datacenter en gekoppeld aan hetzelfde klantaccount. Dat is beter dan een submap, maar het dekt niet alle risico’s.

Vijf scenario’s waarin die back-up niets helpt

  1. De site wordt gehackt. Een aanvaller die toegang heeft tot uw bestanden, heeft ook toegang tot de back-upmap. In sommige besmettingen worden back-ups doelbewust verwijderd of zelf besmet. U herstelt dan een besmette versie, of er is niets meer om te herstellen.
  2. De schijf van de server valt uit. Zeldzaam bij goede hosting, maar het gebeurt. Alles op die schijf is dan weg, inclusief de map met back-ups.
  3. Het hostingaccount wordt geblokkeerd of opgezegd. Een niet-betaalde factuur, een geschil met de hostingpartij, een bureau dat de hosting op zijn naam had en verdwijnt: in alle gevallen bent u de toegang kwijt, en daarmee de back-ups.
  4. Iemand verwijdert per ongeluk de webruimte. Een verkeerde klik in het hostingpaneel bij het opruimen van een oude site, en de map met de back-ups gaat mee.
  5. Ransomware of een vergrendeld account. Bij een besmetting waarbij bestanden worden versleuteld, geldt dat ook voor de back-upbestanden op dezelfde plek.

Merk op dat het in geen van deze gevallen om een fout in de back-up zelf gaat. De back-up was prima. Hij stond alleen op de verkeerde plek.

Wat een goede opslaglocatie is

De vuistregel is simpel: een back-up hoort op een plek die u nog kunt bereiken als uw website, uw hosting en uw beheerdersaccount alle drie onbereikbaar zijn. In de praktijk komen daarvoor een paar opties in aanmerking:

  • Cloudopslag op uw eigen naam, zoals Google Drive, Dropbox, OneDrive of een Europese aanbieder. De meeste back-upplugins kunnen daar rechtstreeks naartoe schrijven.
  • Objectopslag zoals Amazon S3, Backblaze B2 of een Nederlandse tegenhanger. Technischer om in te stellen, maar goedkoop en betrouwbaar voor grote sites.
  • De servers van een back-updienst die niet uw hostingpartij is. Diensten als BlogVault werken zo, en ook beheerders met een onderhoudspakket met back-ups en monitoring bewaren de back-ups vrijwel altijd op eigen, aparte opslag. WebMaintor doet dat versleuteld, binnen de EU.

Let bij cloudopslag op waar de gegevens staan. Uw website bevat vaak persoonsgegevens, al is het maar van klanten die een formulier hebben ingevuld. Opslag binnen de EU maakt het gesprek over de AVG een stuk eenvoudiger.

De 3-2-1-regel, vertaald naar een website

In de wereld van IT-beheer bestaat een oude vuistregel: bewaar drie kopieën van uw gegevens, op twee verschillende soorten opslag, waarvan één op een andere locatie. Voor een website komt dat neer op: de site zelf, een back-up bij de hosting en een back-up ergens anders. Wie die derde kopie heeft, is beschermd tegen vrijwel alle scenario’s hierboven.

Hoe vaak die kopie moet worden gemaakt, hangt af van hoe vaak uw site verandert; daarover gaat het artikel over de juiste back-upfrequentie. Maar frequentie komt op de tweede plaats. Een wekelijkse back-up op de juiste plek is meer waard dan een dagelijkse op de verkeerde.

Een voorbeeld dat wij vaker zien dan ons lief is

Een schoonheidssalon in Nijmegen liet in 2023 haar site bouwen door een klein bureau. De back-upplugin stond netjes ingesteld, wekelijks, naar een map op de server. Een jaar later stopte het bureau met de hosting en werd het account opgeheven, met een mail die in de spam belandde. Site weg, back-ups weg. De site is uiteindelijk opnieuw opgebouwd uit de teksten die nog in Word-bestanden stonden en de foto’s die de fotograaf nog had. Een koppeling met Google Drive had dat verhaal in tien minuten anders laten aflopen.

Wat u vandaag regelt

Open de instellingen van uw back-upplugin en kijk naar de opslaglocatie. Staat daar alleen “lokaal” of een map op de server, koppel dan een externe opslag. Dat is bij de meeste plugins een kwestie van inloggen bij uw clouddienst en toestemming geven. Controleer daarna dat de eerstvolgende back-up er daadwerkelijk aankomt. Vanaf dat moment heeft u een echte back-up.