Joomla backups: strategie, tools en herstel tests
Vraag een willekeurige Joomla-specialist naar zijn of haar ergste supportgesprekken, en in elk verhaal komen back-ups ter sprake. Niet omdat back-ups moeilijk zijn, maar omdat ze ontbraken, beschadigd waren of nooit waren getest, en tegen de tijd dat iemand het doorhad, was de site al verdwenen. Een goede back-up maakt van een ramp slechts een ongemak. Een slechte back-up maakt van een ongemak een ramp.
Dit artikel legt uit hoe Joomla-back-ups echt werken. Het behandelt de basis voor eigenaren en redacteuren, back-upstrategie en gereedschappen voor beheerders, en de technische details voor ontwikkelaars die back-up en herstel willen automatiseren. Je leert wat er precies in een Joomla-back-up moet zitten, hoe de 3-2-1-regel werkt, hoe je met de hand een back-up maakt en terugzet, hoe je een site naar een andere server verhuist, en waarom een ongeteste back-up helemaal geen back-up is.
Niemand heeft een back-up nodig - tot het ene moment waarop hij of zij niets anders nodig heeft.
Het doel is eenvoudig: je een back-uproutine laten bouwen waar je echt op kunt vertrouwen.
1. De basis
1.1 Wat een Joomla-back-up is
Een Joomla-site bestaat uit twee dingen die altijd samen moeten reizen:
| Deel | Bevat |
|---|---|
| De bestanden | Joomla zelf, je extensies en templates, geuploade afbeeldingen en documenten, en configuration.php. |
| De database | Alle content: artikelen, categorieen, menu's, modules, gebruikers, instellingen, en de data van je extensies. |
Een back-up van alleen de bestanden geeft je een lege site zonder artikelen. Een back-up van alleen de database geeft je content zonder site eromheen en zonder afbeeldingen. Een echte Joomla-back-up bevat altijd beide, gemaakt op hetzelfde moment.
1.2 Wat Joomla core wel (en niet) biedt
Joomla zelf levert geen back-upfunctie. Het dichtstbijzijnde dat de core biedt is een herinnering: de Joomla Update-component toont een checkbox "Ik ben me ervan bewust dat een back-up voor elke update sterk wordt aanbevolen" voordat je mag updaten (de optie backupcheck, standaard ingeschakeld). Joomla herinnert je eraan; de back-up zelf is jouw taak, met een hostingtool, een extensie of een eigen script.
Dat is een bewuste keuze, geen gat. Back-ups moeten weg van de site worden opgeslagen om iets waard te zijn, en dat regel je makkelijker buiten het CMS dan erbinnen.
1.3 Waartegen back-ups je beschermen
- Hacks: zet een schone site terug in plaats van een gecompromitteerde bestand voor bestand schoon te maken.
- Mislukte updates: rol terug wanneer een core- of extensie-update misgaat.
- Menselijke fouten: een verwijderde categorie, een leeggemaakt artikel, een kapotte template-aanpassing.
- Serverstoringen: schijven gaan stuk, hosts verdwijnen, accounts worden geblokkeerd.
- Ransomware: een externe back-up is de ene kopie die een aanvaller niet kan versleutelen.
2. Wat je precies moet back-uppen
2.1 De bestandskant
Alles onder de webroot hoort in de back-up, maar sommige mappen zijn belangrijker dan andere:
| Pad | Waarom het telt |
|---|---|
configuration.php |
Je instellingen, databasegegevens en de $secret-sleutel. Onvervangbaar. |
images/ |
Alle geuploade media. Meestal de grootste en minst vervangbare map. |
templates/ |
Je templates, child templates en elke override die je ooit schreef. |
media/ |
Assets van geinstalleerde extensies. |
administrator/, components/, plugins/, modules/, libraries/ |
Joomla en je extensies. In theorie vervangbaar, in de praktijk gedoe. |
Veilig uit te sluiten: cache/, administrator/cache/, tmp/ en logbestanden. Ze worden opnieuw aangemaakt en maken het archief alleen maar groter.
2.2 De databasekant
Alles woont in de tabellen met jouw prefix (#__content voor artikelen, #__users, #__menu, #__extensions, enzovoort). Dump ze allemaal: de kosten van een paar tabellen te veel zijn niets vergeleken met de kosten van een ontbrekende. De ene tabel die je veilig kunt overslaan is #__session - sessiedata is waardeloos na een herstel.
2.3 De vergeten stukken
Twee dingen wonen buiten de webroot op goed ingerichte sites en worden in precies die volgorde vergeten:
- Verplaatste
tmp- enlog-mappen (als je ze verplaatst hebt, zoals het artikel over security hardening aanraadt). - Serverconfiguratie die je hebt aangepast: de
.htaccess- of nginx-regels, PHP-instellingen en cronjobs. Bewaar een kopie of documenteer ze; een nieuwe server kent ze niet.
3. Back-upstrategie: de 3-2-1-regel
3.1 De regel
De industriestandaard heet de 3-2-1-regel:
3 kopieen van je data (productie + 2 back-ups)
2 verschillende soorten opslag
1 kopie extern, weg van de webserverDe externe kopie is het hart van de regel. Een back-up op dezelfde server sterft met de server, wordt bij een ransomware-aanval samen met de site versleuteld, en verdwijnt met een geblokkeerd hostingaccount. "Extern" kan cloudopslag zijn, een andere server, of een schijf op kantoor - elke plek die het lot van productie niet deelt.
3.2 Hoe vaak back-uppen
Stem het schema af op hoe snel de site verandert en hoeveel je kunt missen:
| Type site | Verstandig schema |
|---|---|
| Brochuresite, zelden bewerkt | Wekelijks, plus voor elke update. |
| Actief blog of bedrijfssite | Dagelijks de database, wekelijks volledig. |
| Webshop of communitysite | Dagelijks volledig, elk uur de database als er bestellingen op het spel staan. |
En altijd, zonder uitzondering: een extra back-up vlak voor elke update of grote wijziging. Het is de goedkoopste verzekering in webdevelopment.
3.3 Generaties en bewaartermijn
Bewaar meerdere generaties, niet een doorrollende kopie. Een hack die na drie weken wordt ontdekt, maakt elke back-up van de laatste drie weken verdacht; je wilt een oudere, schone generatie om op terug te vallen. Een gangbaar schema: 7 dagelijkse, 4 wekelijkse en een paar maandelijkse back-ups.
Denk hier ook aan de privacywetgeving: back-ups bevatten persoonsgegevens, dus je AVG-beloften over bewaartermijnen gelden ook voor hen. Een back-up die je jaren bewaart, spreekt stilletjes een privacybeleid tegen dat verwijdering op verzoek belooft.
3.4 Volledig, incrementeel en differentieel
Back-upgereedschappen bieden drie manieren om een archief op te bouwen, en de woorden duiken op in de opties van elk serieus gereedschap:
| Type | Wat het kopieert | Afweging |
|---|---|---|
| Volledig | Alles, elke keer. | Het grootst en traagst om te maken, maar elk archief is op zichzelf terug te zetten. |
| Incrementeel | Alleen wat veranderde sinds de vorige back-up. | Klein en snel, maar een herstel heeft de hele keten tot de laatste volledige back-up nodig - een kapotte schakel breekt het herstel. |
| Differentieel | Alles wat veranderde sinds de laatste volledige back-up. | Middenweg: een herstel heeft de laatste volledige plus de nieuwste differentiele nodig. |
Voor de meeste Joomla-sites is een nachtelijke volledige back-up de simpelste en robuustste keuze; opslag is goedkoop en onafhankelijkheid betaalt zich uit op de dag dat je terugzet. Incrementele schema's verdienen zich terug op erg grote sites - een enorme images/-map, krappe opslagquota - waar elke nacht alles kopieren niet realistisch is.
3.5 Onveranderbare back-ups
Moderne ransomware valt eerst de back-upopslag aan, daarna de site: versleutelde back-ups laten slachtoffers betalen. Het antwoord is onveranderbare opslag (immutable storage): back-upruimte waar bestanden tijdens een ingestelde bewaarperiode niet gewijzigd of verwijderd kunnen worden, zelfs niet met de inloggegevens van het opslagaccount zelf. Cloud-objectopslag biedt dit als optie (bijvoorbeeld S3 Object Lock en vergelijkbare functies bij andere aanbieders), en sommige NAS-systemen bieden onveranderbare snapshots.
Ondersteunt je externe opslag een object lock- of immutability-optie, zet die dan aan voor je bewaarperiode. Het verandert je externe kopie van "waarschijnlijk veilig" in "aantoonbaar buiten bereik".
Naar boven4. Back-upgereedschappen voor Joomla
4.1 De drie wegen
| Aanpak | Goed voor | Let op |
|---|---|---|
| Back-upextensie (Akeeba Backup is de de facto standaard) | Volledige back-ups met een klik, planning, externe upload, overal makkelijk terugzetten. | Back-ups staan standaard binnen de webroot; verplaats of upload ze naar buiten. |
| Back-ups van het hostingpanel (cPanel, Plesk, host-snapshots) | Nul moeite, draait ook als Joomla kapot is. | Zelfde server, zelfde account, bewaartermijn bepaald door de host. Nooit je enige kopie. |
| Eigen scripts (mysqldump + tar + cron) | Volledige controle, ideaal voor ontwikkelaars met veel sites. | Jij bent de leverancier: jij moet bewaken, testen en onderhouden. |
4.2 Waarom Akeeba Backup de standaard werd
Akeeba Backup verpakt bestanden en database in een archief (het JPA-formaat) samen met een herstelwizard. Terugzetten vereist niet eens een werkende Joomla: je uploadt het archief plus het kleine Kickstart-script naar een lege map, opent het in de browser, en de wizard pakt het archief uit, importeert de database en herschrijft configuration.php voor de nieuwe locatie. Dat laatste maakt het meteen een verhuisgereedschap tussen servers en domeinen.
4.3 Het juiste antwoord is meestal een combinatie
Serieuze sites combineren lagen: een back-upextensie of script voor het geplande, externe, terugzetbare archief, en de hostingpanel-back-up als tweede, onafhankelijk vangnet. Twee verschillende mechanismen falen om verschillende redenen - en dat is precies de bedoeling.
Naar boven5. Een handmatige back-up maken
5.1 Wanneer handmatig het juiste gereedschap is
Elke beheerder zou minstens een keer met de hand een back-up gemaakt moeten hebben: het leert je precies wat een back-up bevat, en het werkt wanneer niets anders werkt - een kapotte backend, een geblokkeerde extensie, een site die je net hebt overgenomen.
5.2 Stap voor stap op de commandoregel
De gegevens die je nodig hebt staan in configuration.php ($host, $user, $password, $db). Daarmee:
# 1. Optioneel: haal de site offline tijdens de back-up
php cli/joomla.php site:down
# 2. Dump de database (single transaction = consistente dump)
mysqldump --single-transaction -h localhost -u dbuser -p sitedb \
> site-$(date +%F).sql
# 3. Archiveer de bestanden, zonder de hergenereerde mappen
tar --exclude='./cache' --exclude='./tmp' \
--exclude='./administrator/cache' \
-czf site-$(date +%F).tar.gz .
# 4. Breng de site terug
php cli/joomla.php site:up
# 5. Verplaats beide bestanden WEG van de server
scp site-*.sql site-*.tar.gz backup-user@backup-host:/backups/Stap 5 is niet optioneel. Een back-up die in de webroot blijft staan is een beveiligingsrisico (wie de naam raadt, downloadt je hele site inclusief inloggegevens) en sterft met de server.
5.3 Zonder shell-toegang
Op shared hosting zonder SSH: exporteer de database met phpMyAdmin (selecteer de database, Exporteren, SQL-formaat) en download de bestanden met de bestandsbeheerder van het hostingpanel als gecomprimeerd archief. Vermijd kale FTP voor duizenden kleine bestanden; het is traag en laat vaker stilletjes bestanden vallen dan mensen denken.
Naar boven6. Back-ups automatiseren
6.1 Een back-up die je moet onthouden, is een back-up die je vergeet
Handmatige back-ups verwateren: ze gebeuren wekelijks, dan maandelijks, dan nooit. Automatiseer de routine en bewaar de handmatige vaardigheid voor noodgevallen en pre-update-snapshots.
6.2 De planningsopties
- Server-cron: de betrouwbaarste trigger. Een cronjob draait je back-upscript (of het CLI-commando van de back-upextensie) op een vast uur, meestal 's nachts.
- Joomla's taakplanner: de core levert geen back-uptaak, maar back-upextensies registreren hun eigen taak-plugins, en de taakplanner (aangestuurd door echte cron of de webcron-URL) draait ze. Handig zonder shell-toegang.
- Het hostingpanel: automatische account-snapshots. Zet ze aan als extra laag, niet als primaire.
6.3 Bewaak de automatisering
De gevaarlijkste back-up is degene die maanden geleden stopte terwijl iedereen rustig sliep. Sluit de cirkel:
- Laat de back-uptaak een melding sturen - en behandel stilte als het alarm, niet de foutmail. Een dode taak stuurt niets.
- Controleer regelmatig de leeftijd en grootte van de nieuwste back-up; een plotselinge daling van 90% betekent dat er iets stilletjes brak.
- Zet er een agendaherinnering op: kijk een keer per maand met eigen ogen naar de back-upopslag.
7. Een back-up terugzetten
7.1 Terugzetten met een wizard
Met een Akeeba-achtig archief: upload het archief en Kickstart naar de (lege) doelmap, open Kickstart in de browser en volg de wizard. Die pakt de bestanden uit, maakt en vult de database, vraagt om de nieuwe databasegegevens, schrijft configuration.php en ruimt zichzelf op. Tien minuten, waarvan het meeste wachten.
7.2 Handmatig terugzetten
De handmatige route spiegelt de handmatige back-up:
- Upload en pak het bestandsarchief uit in de webroot.
- Maak een lege database en gebruiker aan, en importeer de dump:
mysql -u dbuser -p sitedb < site.sql - Open
configuration.phpen herstel wat veranderd is:
public $host = 'localhost'; // nieuwe DB-host
public $user = 'new_dbuser'; // nieuwe DB-gebruiker
public $password = '...'; // nieuw DB-wachtwoord
public $db = 'new_sitedb'; // nieuwe DB-naam
public $dbprefix = 'jos_'; // moet overeenkomen met de dump!
public $tmp_path = '/new/path/tmp'; // absolute paden: werk ze bij
public $log_path = '/new/path/logs';
public $live_site = ''; // leeg laten tenzij je weet waarom- Controleer eigendom en rechten van bestanden (bestanden
644, mappen755, eigendom van de PHP-gebruiker). - Test de frontend, de backend-login en een afbeeldingsupload. Draai Systeem → Database (of
php cli/joomla.php maintenance:database) om het schema te controleren.
7.3 Terugzetten na een hack
Er geldt een speciale regel: zet terug naar een punt van voor de inbraak, niet alleen van voordat je het merkte, en onderzoek het toegangspunt voordat je weer live gaat - anders zet je de kwetsbaarheid samen met de site terug. De incident response-sectie van het artikel over security hardening beschrijft die werkvolgorde.
Naar boven8. Een site verhuizen naar een andere server of domein
8.1 Een verhuizing is een herstel
Het inzicht dat verhuizingen rustig maakt in plaats van eng: een Joomla-site verhuizen is exact een back-up ergens anders terugzetten. Zelfde archief, zelfde stappen, ander doel. Als je back-uproutine werkt, weet je al hoe je verhuist.
8.2 De extra stappen voor een nieuw thuis
- Zet de back-up terug op de nieuwe server (wizard of handmatig, zoals hierboven).
- Werk
configuration.phpbij voor de nieuwe database en paden. - Test de site via een tijdelijke URL of een lokale hosts-regel die het domein naar de nieuwe server wijst, voordat je aan DNS komt.
- Installeer het SSL-certificaat op de nieuwe server voordat je omschakelt, zodat HTTPS nooit breekt.
- Verlaag de DNS-TTL een dag van tevoren, schakel de DNS om, en houd de oude server nog een paar dagen alleen-lezen draaiend als terugvaloptie.
8.3 Domeinwijzigingen
Joomla slaat interne links relatief op, dus een domeinwijziging is milder dan hij klinkt. Controleer de paar absolute plekken: hard gecodeerde URL's in artikelen of eigen modules, $live_site (hoort normaal leeg te blijven), en het domein in je SEF-/redirect-regels in .htaccess. Stel daarna 301-redirects in vanaf het oude domein en werk Search Console bij, zoals het artikel over redirects beschrijft.
9. Je back-ups testen
9.1 Een ongeteste back-up is een hoop
Back-ups falen stilletjes: afgebroken dumps, archieven waar de halve images-map in ontbreekt, wachtwoorden die niet meer ontsleutelen, een formaat dat de nieuwe PHP-versie niet kan lezen. Niets daarvan zie je tot je terugzet. Het enige bewijs dat een back-up werkt, is een afgerond testherstel - al het andere is optimisme.
9.2 De hersteloefening
Twee keer per jaar (en na elke wijziging aan de back-upopzet) draai je de oefening:
- Pak een actuele back-up uit de externe opslag - niet van de server.
- Zet hem terug op een aparte locatie: een lokale Docker-omgeving, een subdomein of een wegwerp-VPS.
- Loop een checklist af: frontend rendert, backend-login werkt, nieuwste artikel aanwezig, afbeeldingen laden, een formulier verstuurt.
- Noteer hoe lang het duurde. Dat getal is je echte hersteltijd, en die wil je kennen voor een storing.
De oefening heeft een bonus: een teruggezette kopie is een perfecte testomgeving voor de volgende grote update.
Hij kost ook minder moeite dan het lijkt, want een wizard-restore is een voorspelbare browserflow - en die kun je dus automatiseren. Ik draai mijn eigen hersteltests met een klein Playwright-script (een browser-automatiseringstool) dat het archief uploadt, door de Kickstart-wizard heen klikt en een verse kopie van de site draaiend achterlaat in een lokale Docker-stack: een site terugzetten is een commando. Hoe lager je de drempel maakt, hoe vaker de oefening echt gebeurt - en een oefening die gebeurt verslaat een perfecte procedure die theorie blijft.
9.3 Van back-up naar disaster recovery-plan
Professionals beschrijven herstel met twee getallen, en beide zijn beslissingen die je bewust per site zou moeten nemen:
- RPO (Recovery Point Objective): hoeveel data je kunt missen. Een nachtelijke back-up betekent een RPO van maximaal 24 uur - acceptabel voor een brochuresite, pijnlijk voor een webshop.
- RTO (Recovery Time Objective): hoe snel de site weer online moet zijn. Je hersteloefening meet of de werkelijkheid bij de ambitie past.
De tweede helft van een disaster recovery-plan is documentatie, want een back-up herstelt alleen een site als iemand het herstel ook echt kan uitvoeren. Schrijf op: waar de back-ups en hun versleutelingswachtwoorden staan, de stap-voor-stap herstelprocedure, de benodigde inloggegevens (hosting, DNS, database), en wie je moet bellen. Bewaar dat document buiten de site zelf - een wiki, een notitie in de wachtwoordmanager, een geprinte pagina in een la. De test is simpel: zou een collega de site kunnen terugzetten terwijl jij onbereikbaar op vakantie bent?
Naar boven10. Onder de motorkap (ontwikkelaarsblik)
10.1 Waar dingen echt wonen
Weten wat waar staat, vertelt je meteen wat een gedeeltelijk verlies kost:
| Content | Database | Bestanden |
|---|---|---|
| Artikelen, categorieen, tags | #__content, #__categories, #__tags |
- |
| Menu's, modules, hun instellingen | #__menu, #__modules |
- |
| Gebruikers, groepen, ACL-regels | #__users, #__usergroups, #__assets |
- |
| Geuploade afbeeldingen en documenten | alleen de verwijzingen | images/ |
| Template-overrides, eigen CSS | - | templates/, media/templates/ |
| Extensiecode | registratie in #__extensions |
hun mappen |
| Site-configuratie | - | configuration.php |
De klassieke valkuil bij gedeeltelijk verlies: database teruggezet, images/ vergeten. Elk artikel rendert, elke afbeelding is kapot, en het CMS meldt helemaal geen fout - want de verwijzingen in de database zijn intact.
10.2 Consistentie: bestanden en database van hetzelfde moment
Een dump van maandag met bestanden van donderdag is een subtiel kapotte site: artikelen die verwijzen naar afbeeldingen die nog niet bestaan, extensies waarvan de tabellen niet bij hun code passen. Maak de back-up van beide delen in een run, het liefst met de site kort offline of tijdens het rustigste uur. Voor de dump zelf geeft mysqldump --single-transaction je een consistente momentopname van InnoDB-tabellen zonder de site te vergrendelen.
10.3 De geheime sleutel hoort bij de back-up
De waarde $secret in configuration.php wordt gebruikt in token- en HMAC-berekeningen, inclusief de tokens van de Web Services API. Herstel een site met een andere secret en elk uitgegeven API-token sterft meteen. Dit is nog een reden waarom configuration.php in de back-up moet zitten, en waarom het back-uparchief zelf wachtwoordbeveiliging of versleuteling verdient: het bevat databasegegevens en deze sleutel in platte tekst.
10.4 Handige CLI-commando's rond back-ups
php cli/joomla.php site:down # onderhoudsmodus aan
php cli/joomla.php site:up # onderhoudsmodus uit
php cli/joomla.php config:get # configuratiewaarden lezen
php cli/joomla.php maintenance:database # schema controleren/repareren na herstel
php cli/joomla.php scheduler:run # geplande taken uitvoerenDe core levert geen backup:*-commando - de commando's hierboven zijn het steigerwerk rond je eigen mysqldump- en tar-aanroepen, of de CLI die een back-upextensie meelevert.
11. Back-ups en de Web Services API
De Joomla Web Services API heeft geen back-up-endpoints: je kunt met de core alleen geen back-up starten of downloaden via /api/index.php/v1/.... Dat is verstandig - een volledig site-archief streamen door het CMS dat het moet beschermen, zou fragiel en riskant zijn.
Externe back-upautomatisering loopt daarom over andere rails: SSH voor script-opstellingen, de JSON-API's die back-upextensies bieden voor beheertools (zo starten diensten die veel Joomla-sites beheren op afstand hun nachtelijke back-ups), of de API van de hostingprovider voor account-snapshots. Waar de Web Services API in deze context wel goed voor is: monitoring. Een beheerscript kan de API van een site aanroepen om te controleren of hij draait en op de verwachte Joomla-versie zit nadat een herstel is afgerond.
Naar boven12. SEO en metadata
Back-ups beschermen je SEO directer dan de meeste mensen beseffen. Posities wonen in je content, je URL-structuur, je redirects en je metadata - allemaal in de database. Een site verliezen zonder back-up kost je niet alleen een website; het kost je jaren opgebouwde zoekautoriteit, want de herbouwde site komt nooit exact overeen met de oude URL's, en elke afwijking lekt positie weg.
Twee praktische punten. Ten eerste: een snel, volledig herstel houdt de downtime kort; langdurige storingen laten pagina's uit de index vallen, en herstel daarvan is traag. Ten tweede: test je hersteloefeningen op een publieke testlocatie, blokkeer daar dan indexering (een noindex-header of robots-regel): een crawlbare kopie van je site op een andere URL zorgt voor duplicate content die met het origineel concurreert. Het artikel over robots.txt behandelt de techniek.
13. Veelvoorkomende fouten en valkuilen
13.1 De back-up woont op de server die hij beschermt
Symptoom: er zijn back-ups, maar de servercrash / hack / accountblokkade nam ze samen met de site mee.
Oplossing: pas de 3-2-1-regel toe. Minstens een actuele kopie moet ergens staan die het lot van de webserver niet deelt, en de webroot is de slechtste plek van allemaal - daar is hij ook nog downloadbaar voor aanvallers.
13.2 Alleen de database, of alleen de bestanden
Symptoom: na een herstel een site zonder artikelen - of alle artikelen met elke afbeelding kapot.
Oplossing: een Joomla-back-up is bestanden plus database van hetzelfde moment. Controleer dat beide in het archief zitten en dat images/ en configuration.php er echt in staan.
13.3 De ongeteste back-up die niet terug te zetten is
Symptoom: het herstel mislukt op de slechtste dag - corrupt archief, onvolledige dump, vergeten wachtwoord van de versleutelde back-up.
Oplossing: draai de hersteloefening uit sectie 9 twee keer per jaar. Bewaar het versleutelingswachtwoord van de back-up in je wachtwoordmanager, niet alleen in het gereedschap dat de back-up maakte.
13.4 Alleen op de host vertrouwen
Symptoom: "de hostingpartij maakt back-ups" blijkt 7 dagen bewaartermijn te betekenen, en de hack is 12 dagen oud.
Oplossing: host-back-ups zijn een bonuslaag. Houd je eigen schema met je eigen bewaartermijnen (dagelijks, wekelijks, maandelijks), onder je eigen controle.
13.5 De automatisering die stilletjes stierf
Symptoom: de laatste back-up is van maart. Het is november.
Oplossing: bewaak de afwezigheid van back-ups, niet alleen mislukkingen: een maandelijkse controle van datum en grootte van het nieuwste bestand, en alarmering die merkt wanneer de nachtelijke taak stopt met rapporteren.
13.6 Terugzetten over het enige bewijs heen
Symptoom: na een hack werd de site meteen teruggezet - en nu kan niemand meer achterhalen hoe de aanvaller binnenkwam, en is hij binnen een week terug.
Oplossing: bewaar voor het terugzetten een kopie van de gecompromitteerde toestand (bestanden + logs) voor onderzoek, zet dan terug naar een schoon punt en sluit het toegangsgat. Eerst indammen, dan terugzetten.
Naar boven14. Best practices
Als je maar een paar dingen uit dit artikel onthoudt, onthoud dan deze:
- Een Joomla-back-up is altijd bestanden plus database, van hetzelfde moment.
- Volg 3-2-1: drie kopieen, twee soorten opslag, een extern.
- Automatiseer het schema, bewaak dat het blijft draaien, en bewaar generaties (dagelijks/wekelijks/maandelijks).
- Maak een extra back-up voor elke update - de checkbox in Joomla Update staat er niet voor niets.
- Laat back-uparchieven nooit in de webroot staan; versleutel archieven die de server verlaten.
- Test twee keer per jaar een volledig herstel en klok het; een ongeteste back-up is een hoop, geen plan.
- Documenteer de herstelprocedure - waar back-ups staan, hoe je terugzet, wie je belt - zodat herstel nooit van het geheugen van een persoon afhangt.
- Behandel een verhuizing als een herstel naar een nieuwe locatie - zelfde routine, ander doel.
- Zet na een hack terug naar een punt van voor de inbraak en vind eerst het toegangspunt.
- Denk aan de AVG: back-ups bevatten persoonsgegevens, dus bewaartermijnen gelden ook voor hen.
15. In het kort
INHOUD bestanden: configuration.php, images/, templates/, media/,
extensiemappen (sla cache/, tmp/, logs over)
db: alle #__ tabellen (sla #__session over)
REGEL 3 kopieen - 2 soorten opslag - 1 extern
extra back-up voor ELKE update
generaties: 7 dagelijks / 4 wekelijks / paar maandelijks
volledig = zelfstandig herstel, incrementeel = keten
onveranderbare opslag (object lock) weerstaat ransomware
HANDMATIG php cli/joomla.php site:down
mysqldump --single-transaction -u USER -p DB > site.sql
tar --exclude='./cache' --exclude='./tmp' -czf site.tar.gz .
php cli/joomla.php site:up
scp beide bestanden WEG van de server
HERSTEL bestanden uitpakken > db aanmaken > dump importeren
configuration.php herstellen: $host $user $password $db
$dbprefix $tmp_path $log_path
rechten 644/755, test frontend + backend + upload
php cli/joomla.php maintenance:database
VERHUIZEN = herstel op de nieuwe server
test via tijdelijke URL > SSL installeren > dan DNS omzetten
TESTEN hersteloefening 2x/jaar op een aparte locatie
check: pagina's, login, nieuwste content, afbeeldingen,
formulieren; noteer de hersteltijd
RPO = max dataverlies, RTO = max downtime
documenteer: locaties, procedure, inloggegevens, contacten
TOOLS extensie (Akeeba: JPA + Kickstart, herstelt overal)
+ hostingpanel-back-ups als tweede laag
+ eigen mysqldump/tar-scripts voor volledige controle
BEWAKEN alarm bij ontbrekende back-ups, niet alleen mislukte
maandelijks leeftijd + grootte nieuwste bestand checken
API/CLI geen core backup:*-commando, geen REST-back-up-endpoint
site:down / site:up / config:get / maintenance:database16. Samenvatting
Back-ups zijn het ene deel van site-onderhoud waar "bijna goed" gelijk staat aan "fout":
- Beide helften: bestanden en database samen, van hetzelfde moment - Joomla core herinnert je eraan voor updates, maar maakt geen back-up voor je.
- Strategie: de 3-2-1-regel, generaties met verstandige bewaartermijnen, en een extra snapshot voor elke wijziging die ertoe doet.
- Gereedschap: een back-upextensie of eigen scripts voor het echte, externe, terugzetbare archief; host-back-ups als onafhankelijke tweede laag.
- Herstel: wizard of handmatig, de stappen leer je in een middag - en een verhuizing is gewoon een herstel gericht op een nieuwe server.
- Testen: de hersteloefening maakt van een stapel archieven een echt vangnet, en vertelt je je werkelijke hersteltijd.
- Zorg: houd archieven uit de webroot, versleutel wat de server verlaat, bewaak de automatisering en respecteer bewaartermijnen.
De ongemakkelijke waarheid over back-ups is dat hun kwaliteit pas blijkt op het slechtst denkbare moment. De geruststellende waarheid is dat een degelijke routine - geautomatiseerd, extern, met generaties, getest - niet duur en niet ingewikkeld is om op te zetten. Het is een middag eerlijk werk.
Weet je op dit moment niet hoe oud je nieuwste back-up is, waar hij staat en hoe lang een herstel zou duren, dan is dat het waard om deze week uit te zoeken in plaats van tijdens een storing. Een back-upopzet doorlichten en met een hersteloefening testen is een klein, methodisch klusje - en precies het soort werk dat een Joomla-specialist een keer inricht zodat het daarna jaren stilletjes werkt.
Naar boven
