Als je aan een hostingbedrijf vraagt of ze backups maken, is het antwoord altijd ja. Dagelijks, automatisch, meerdere versies. Het staat in de brochure, het staat op de productpagina, het staat in de kleine lettertjes.

Maar er is een vraag die zelden gesteld wordt: waar staan die backups precies? En wat gebeurt er met ze als de server zelf het probleem is?

Het scenario dat de meeste backup-oplossingen niet overleven

Stel: een aanvaller krijgt toegang tot een server. Niet via jouw WordPress-installatie of een lek in je plugin, maar via de serversoftware zelf: het controlepaneel, de webserver, de onderliggende software. Vorige week zagen we hoe realistisch dat scenario is: bij de cPanel-kwetsbaarheid CVE-2026-41940 kregen aanvallers volledige administratieve toegang tot servers wereldwijd, en op een deel daarvan werd ransomware uitgerold.

Ransomware versleutelt alles wat bereikbaar is. En voor een aanvaller met root-toegang op een server is in principe alles bereikbaar, inclusief de backup-map op diezelfde server, inclusief een gemounte NAS in hetzelfde netwerk, inclusief een backup-account dat via dezelfde credentials benaderd wordt.

Een backup die op dezelfde machine staat als de data die je wilt beschermen, is in dat scenario geen backup. Het is een kopie van het probleem.

Waarom we voor Borg kozen

Wij gebruiken BorgBackup ( Borg ) voor onze volledige serverbackups, en die repo staat volledig offsite. Niet op dezelfde server, niet in hetzelfde datacenter, niet benaderbaar via dezelfde credentials als de productieomgeving.

Borg heeft een aantal eigenschappen die het voor dit doel bij uitstek geschikt maken. Backups worden lokaal versleuteld voordat ze verstuurd worden. De externe opslag ziet alleen versleutelde blokken, nooit de ruwe data. Borg werkt met deduplicatie, waardoor je efficiënt meerdere herstelpunten kunt bewaren zonder dat de opslagruimte explodeert. En de opzet is eenrichtingsverkeer: de productieserver kan data naar de repo schrijven, maar de repo heeft geen toegang tot de productieserver. Een gecompromitteerde server kan de backup-locatie niet bereiken en zeker niet wissen.

Dat laatste is het punt waar de meeste backup-oplossingen op vastlopen. Als de backup-client dezelfde rechten heeft als de server, is die client ook een aanvalsoppervlak.

Herstel is het echte criterium

Een backup is pas waardevol op het moment dat je hem nodig hebt. En op dat moment wil je twee dingen weten: is de backup er nog, en hoe snel ben je operationeel?

Bij een incident waarbij de server zelf gecompromitteerd is, is het antwoord op de eerste vraag bij lokale backups vaak onzeker. Bij offsite Borg-backups is het antwoord definitief: ja, de backup staat er, onbereikbaar voor de aanvaller, versleuteld, integraal.

Dat geeft een heel ander vertrekpunt voor herstel. Niet “laten we hopen dat de backups intact zijn”, maar “hier is het herstelpunt, we gaan aan de slag”.

Geen garantie, wel een bewuste keuze

Offsite backup lost niet alles op. Het beschermt je data, maar niet de reputatieschade als een site tijdelijk onbereikbaar is, niet de downtime tijdens herstel, en niet de oorzaak van het incident zelf. Beveiliging werkt in lagen. Backup is één van die lagen, niet de enige.

Maar het is wel een laag die je expliciet moet kiezen. De standaard in de hostingwereld is een lokale backup op dezelfde infrastructuur, omdat dat het makkelijkst is in te richten en het goedkoopst in opslag. Wij hebben daar bewust voor een andere aanpak gekozen. Niet omdat we verwachten dat het misgaat, maar omdat een backup die het juist in dat scenario laat afweten, geen backup is.

Dit artikel is het tweede in een korte reeks over de infrastructuurkeuzes achter Lionserve. Lees ook: 44.000 gecompromitteerde servers — wat de cPanel-crisis van april 2026 blootlegt.