Back-up en noodherstel voor PHP-websites: een praktische gids

Elke PHP-website rust op een stapel bewegende onderdelen: een webserver, PHP-runtime, MySQL- of PostgreSQL-database, configuratiebestanden, geüploade assets en vaak honderd kleine cronjobs. Elk van die onderdelen kan falen — een beschadigde tabel, een rogue rm -rf, een ransomware-vergrendeling — en als je maar één back-up van de database van vorige week hebt, zit je in de problemen. Bij DigiForge hebben we meer PHP-sites hersteld dan we ons kunnen herinneren, en het verschil tussen een herstel van vier uur en een nachtmerrie van vier dagen komt altijd neer op één ding: een goed ontworpen back-up- en disaster recovery-strategie.

Waarom back-up alleen niet genoeg is

Veel teams verwarren back-up met disaster recovery. Een back-up is een periodieke kopie van gegevens. Disaster recovery is het hele proces om je applicatie weer online te krijgen — gegevens herstellen, services herconfigureren, verkeer omleiden en valideren dat alles werkt. Zoals een IT-resilientierapport het stelde: "het beschermen van je gegevens met back-ups is niet langer voldoende om te overleven" (bron). Een back-up zonder een getest herstelplan is gewoon een verzekering die je nog niet hebt gelezen.

In een PHP-context is het verschil groot. Je databaseback-up kan perfect intact zijn, maar als je niet weet hoe je Apache of Nginx naar de herstelde database moet verwijzen, de .env-referenties moet wijzigen of de PHP-opcache moet herbouwen, ben je nog steeds offline. En downtime kost, zoals we allemaal weten, geld en vertrouwen. Een uitgebreid disaster recovery (DR)-plan moet elke laag van je serverstack dekken, niet alleen de gegevens.

De back-up- en herstelstack voor PHP-sites

We splitsen de back-up van een PHP-applicatie op in vijf afzonderlijke lagen. Het missen van één laag kan de andere nutteloos maken:

1. Code en versiebeheer (Git-repositories, inclusief tags en branches).
2. Database-dumps (MySQL, PostgreSQL of MariaDB).
3. Webserverconfiguratie (Nginx/Apache virtual hosts, SSL-certificaten, PHP-FPM-pools).
4. Applicatieconfiguratie (.env, config-bestanden, hard-coded credentials).
5. Door gebruikers geüploade inhoud (afbeeldingen, PDF's, alle bestanden die buiten de database zijn opgeslagen).

Laten we elke laag doornemen met praktische aanbevelingen.

1. Code en versiebeheer

Je applicatiecode hoort in een Git-repository te staan — geen uitzonderingen. Maar een Git-push is geen back-up. We hebben teams gezien die vertrouwden op één enkele externe branch en weken werk verloren toen een force push of beschadigde repository toesloeg. Gebruik een Git-hostingsprovider (GitHub, GitLab, Bitbucket) en stel geautomatiseerde mirrors in naar een tweede locatie. Tag elke release voor productie-implementaties. Zo hoef je niet te raden welke commit live was als je moet terugdraaien naar een bekende goede staat.

2. Databaseback-ups

Databaseback-ups zijn het meest kritisch en het meest verwaarloosd. Een dagelijkse mysqldump naar een lokale map is beter dan niets, maar we hebben gezien dat die de schijf vult en stilletjes stopt met draaien. Automatiseer je dumps met een script dat oude back-ups roteert, ze comprimeert en offsite verzendt — naar S3, Backblaze of een aparte server. Gebruik mysqldump --single-transaction voor InnoDB-tabellen om leesvergrendelingen te voorkomen en test regelmatig je herstel. Een back-up die niet kan worden hersteld, is waardeloos.

3. Server- en webserverconfiguratie

Je PHP-site draait op meer dan alleen code en gegevens. Nginx- of Apache-configuratiebestanden, PHP-FPM-poolinstellingen, SSL-certificaten en cron-jobdefinities zijn allemaal uniek voor jouw server. We bewaren deze in een aparte Git-repository (of als onderdeel van de applicatierepo onder een deploy/-map) en back-uppen ze samen met de rest. Diensten zoals Certbot vernieuwen Let's Encrypt-certificaten automatisch, maar als je server uitvalt, zijn die certificaten verdwenen. Back-up /etc/letsencrypt/ of schakel over naar DNS-gebaseerde validatie die een rebuild overleeft.

4. Omgevings- en applicatieconfiguratie

PHP-applicaties hebben vaak een .env-bestand met database-inloggegevens, API-sleutels en geheimen. Deze mogen nooit in versiebeheer staan. Voor productie gebruiken we een secrets manager (zoals HashiCorp Vault of envkey), maar bewaar op zijn minst een versleutelde kopie van .env in je back-upsysteem. Als je dit bestand kwijtraakt, herstel je je site niet — je bouwt hem opnieuw op.

5. Gebruikersuploads en media

Afbeeldingen, PDF's en andere uploads worden vaak opgeslagen in een public/uploads-map. Ze groeien snel en kunnen databaseback-ups opzwellen als ze als BLOBs worden opgeslagen. Best practice: bewaar uploads op een apart volume of objectopslag (S3, DigitalOcean Spaces). Als ze op de bestandssysteem van de server staan, neem die map dan op in je offsite-back-up. Gebruik rsync of rclone om dagelijks naar cloudopslag te synchroniseren.

Automatiseren en testen van je herstelplan

Een back-upstrategie is slechts zo goed als het herstel. We zijn te vaak post-mortems tegengekomen waarbij de klant zei: 'We hebben back-ups', maar ze nooit hadden geprobeerd ze te gebruiken. Rampenherstel is een proces, geen product. Je moet opschrijven — en, belangrijker nog, oefenen — hoe je je PHP-site terugbrengt.

• Schrijf een runbook. Documenteer elke stap: waar back-ups worden opgeslagen, hoe de database te herstellen, welke commando's de webserver herbouwen, hoe DNS bij te werken als je IP verandert.
• Automatiseer herstel. Gebruik scripts of orchestratietools (Ansible, Puppet, of zelfs een eenvoudig Bash-script) om een nieuwe server in te richten en je applicatie te herstellen vanuit back-ups. Als je niet binnen een uur een kloon kunt opzetten, is je DR-plan te traag.
• Test elk kwartaal. Herstel je volledige PHP-stack op een nieuwe server (een nieuwe VPS of lokale VM) en controleer of de site werkt. Test DNS-propagatie, SSL, databaseverbindingen, cronjobs en elke gebruikersstroom. Los alles op wat kapot gaat.

In onze ervaring zijn de meest voorkomende fouten tijdens een hersteloefening: niet-overeenkomende inloggegevens (hardgecodeerde databasewachtwoorden die niet overeenkomen met het herstelde .env), ontbrekende PHP-extensies en onvolledige uploads. Elke fout is een geschenk — het onthult een hiaat dat je kunt oplossen voordat er een echte ramp plaatsvindt.

“Een back-up zonder getest herstelplan is slechts een hoop.” — DigiForge-engineeringprincipe

Opslaglocaties en -formaten kiezen

De oude 3-2-1-regel blijft van kracht: drie kopieën van je gegevens, op twee verschillende media, waarvan één kopie offsite. Voor PHP-websites is een gebruikelijke opzet: (1) het lokale back-upscript van de live server, (2) een offsite cloudbucket en (3) een cold storage-archief (bijv. Glacier) voor maandelijkse snapshots. Versleutel back-ups met GPG of client-side encryptie voordat je ze naar een derde partij uploadt.

Incrementele back-ups besparen bandbreedte en opslag, maar verhogen de complexiteit van het herstel. Voor een PHP-site met gemiddeld verkeer is een dagelijkse volledige database-dump plus elk uur binaire logs (indien nodig) een goede balans. Bestandssysteemback-ups kunnen incrementeel via rsync — zorg er wel voor dat je tooling een consistente staat uit incrementele back-ups kan reconstrueren.

Als het misgaat: het herstel-runbook

Laten we een worstcasescenario simuleren: een ransomware-aanval versleutelt je PHP-webroot en database. Hier is het herstelplan op hoofdlijnen dat we bij DigiForge gebruiken:

1. Isoleer de geïnfecteerde server — blokkeer alle externe toegang, maak een snapshot voor forensisch onderzoek indien nodig.
2. Zet een schone server op — een verse VPS met dezelfde OS- en PHP-versie.
3. Herstel code uit Git — clone de getagde release die voor de aanval draaide.
4. Herstel configuratie — kopieer .env, webserverconfiguraties, SSL-certificaten (of vraag ze opnieuw aan).
5. Herstel database — importeer de laatste schone dump, speel vervolgens binlogs af tot het moment van infectie (indien beschikbaar).
6. Herstel uploads — rsync van back-upopslag naar de uploads-directory van de nieuwe server.
7. Test alles — voer health checks uit, controleer databaseverbindingen, controleer of cronjobs worden uitgevoerd.
8. Wijs DNS om — verwijs je domein naar het IP van de nieuwe server (verlaag vooraf de TTL).
9. Monitor — houd logs en uptime 24 uur in de gaten. Verklaar herstel pas na aanhoudend groen.

Dit hele proces kan 2–4 uur duren als je back-ups goed georganiseerd zijn en je hebt geoefend. Zonder oefening kan het dagen duren.

Een cultuur van herstel opbouwen

Disaster recovery is geen eenmalig project, maar een doorlopende praktijk. Elke keer dat je je PHP-versie bijwerkt, een nieuwe cron-job toevoegt of een webserver-directive wijzigt, werk je je runbook bij en test je opnieuw. We hebben te veel teams gezien die back-ups als een afvinkpost behandelen. Een echte DR-strategie is verweven in je deployment-pijplijn, je monitoring en het spiergeheugen van je team.

Als je verantwoordelijk bent voor een PHP-website, begin dan vandaag. Controleer je back-updekking voor alle vijf lagen, automatiseer wat je kunt en plan je eerste hersteloefening. En als je een tweede paar ogen op je strategie wilt, neem dan contact op met DigiForge. Wij hebben genoeg PHP-sites gebouwd en hersteld om te weten wat werkt — en wat niet.