Een back-upschema bepaalt hoeveel data je verliest als er iets misgaat, niet *of* het misgaat. Elke site-eigenaar denkt pas na over back-ups wanneer het al te laat is, meestal vlak na een foute update of een gehackte plugin die weken aan werk heeft weggevaagd. Daniel Okonkwo heeft genoeg van deze rampen hersteld om te weten dat de oplossing zelden in de back-up-plugin zelf zit. De echte oplossing is het schema erachter: hoe vaak het draait, waar het kopieën opslaat en of iemand het überhaupt controleert. Deze gids legt uit hoe je een back-upschema opstelt dat past bij jouw site, je budget en je tolerantie voor dataverlies.
Waarom je back-upschema belangrijker is dan de tool
De meeste site-eigenaren kiezen een back-up-plugin en denken er vervolgens niet meer over na. De plugin voert echter alleen het schema uit dat jij instelt; hij denkt niet voor je na. Een dagelijkse back-up en een maandelijkse back-up gebruiken dezelfde software, maar leveren compleet andere resultaten op als een site uitvalt. Daarom is het schema belangrijker dan de merknaam die op de instellingenpagina staat.
Bedenk wat er gebeurt als een database op dinsdagmiddag om vier uur uitvalt. Als de laatste back-up op zondag draaide, verlies je twee dagen aan bestellingen, reacties en formulierinzendingen. Een schema dat elke zes uur draait, beperkt dat verlies tot slechts een paar uur aan activiteit. Voor een drukke webshop of een ledensite bepaalt dat verschil of een storing een klein ongemak is of een serieuze financiële klap.
Daarnaast moet een back-upschema reflecteren hoe vaak je data echt verandert, in plaats van een generieke standaardinstelling uit een installatiewizard. Een brochure-site die zelden wordt bijgewerkt, heeft geen back-ups per uur nodig. Een boekingsplatform dat de klok rond bestellingen ontvangt echter wel. Beide sites op dezelfde manier behandelen is verspilling van opslag bij de een en een risico voor echte data bij de ander.
Hoe je een back-upschema bouwt dat past bij je risico
Begin met een simpele vraag: hoeveel recent werk kun je je veroorloven om te verliezen? Specialisten noemen dit de 'recovery point objective' (RPO), hoewel de term minder belangrijk is dan het eerlijke antwoord dat je jezelf geeft. Als het verliezen van een volledige dag aan bestellingen je bedrijf zou schaden, moet je back-upschema meerdere keren per dag draaien. Als je site zelden verandert, volstaat een wekelijkse back-up waarschijnlijk.
Kijk vervolgens naar hoe je site zich daadwerkelijk gedraagt, in plaats van hoe druk het voelt. Voor kleinere websites met minder berichten zouden back-ups wekelijks moeten worden gemaakt, terwijl websites met veel activiteit en veel berichten dagelijkse back-ups nodig hebben. Op dezelfde manier heeft een webshop met tientallen dagelijkse transacties een database-back-up nodig die vaker draait, omdat elke bestelling onbeschermd blijft totdat deze is vastgelegd. Een rustige portfolio-site heeft daarentegen zelden meer nodig dan een wekelijkse export.
Het helpt ook om je database-back-up te scheiden van je volledige site-back-up. Database-wijzigingen gebeuren constant door bestellingen, reacties en aanpassingen, terwijl site-bestanden alleen veranderen wanneer je updates of nieuwe plugins installeert. Als resultaat maken veel hosts frequente database-snapshots naast een tragere, wekelijkse volledige back-up. Deze splitsing verlaagt de opslagkosten zonder recente data onbeschermd te laten.
Opslag kiezen en je back-upschema testen
Een back-upschema werkt alleen als de kopieën de oorzaak van het defect overleven. De 3-2-1-back-upregel vereist dat je de originele productiedata behoudt, samen met ten minste twee extra back-upkopieën. In de praktijk betekent dit dat je ten minste één kopie buiten je hoofdserver opslaat, idealiter bij een compleet andere provider. Anders kan een enkele hostingstoring of accountblokkering zowel je enige back-up als je live site onbereikbaar maken.
Bovendien is een back-up die je nooit test een gok, geen plan. Je moet je back-upsystemen regelmatig testen om er zeker van te zijn dat ze werken wanneer er een ramp toeslaat. Herstel elke paar maanden een proefback-up om te bevestigen dat de bestanden daadwerkelijk openen en de database zonder fouten wordt geïmporteerd. Deze kleine gewoonte vangt defecte back-ups op, lang voordat je ze in een echte crisis nodig hebt.
Retentie is net zo belangrijk als frequentie. Bewaar genoeg versies om te herstellen van een probleem dat je laat opmerkt, aangezien sommige fouten pas dagen na de wijziging die ze veroorzaakte aan het licht komen. Een doorlopende set dagelijkse back-ups van twee weken, plus een paar oudere wekelijkse snapshots, dekt de meeste scenario's voor kleine bedrijven zonder de opslag vol te maken.
Veelvoorkomende fouten die een back-upschema om zeep helpen
Een veelgemaakte fout is het opslaan van back-ups op dezelfde server als de live site. Back-upkopieën op dezelfde server als de originele data opslaan, stelt ze bloot aan dezelfde risico's, waaronder hardwarestoringen, malware-aanvallen of per ongeluk verwijderen. Als de server uitvalt, verdwijnen zowel de site als het vangnet tegelijk, wat het hele doel van een back-up tenietdoet.
Een andere fout is vertrouwen op een back-upschema dat stilzwijgend draait, zonder enige controle of het daadwerkelijk is gelukt. Een mislukte back-up die niemand opmerkt, is erger dan helemaal geen back-up, omdat het schijnzekerheid geeft tot het moment dat je moet herstellen. Daarom moeten site-eigenaren waarschuwingen instellen voor mislukte taken en regelmatig back-uplogs controleren.
Tot slot stellen veel site-eigenaren een back-upschema één keer in en kijken er nooit meer naar om. Naarmate een site groeit en meer bestellingen of reacties krijgt, kan hetzelfde wekelijkse schema dat ooit veilig voelde, veel te veel risico met zich meebrengen. Het schema elke paar maanden bekijken houdt het afgestemd op hoe de site vandaag de dag daadwerkelijk werkt.
Je back-upschema goed instellen
Een goed back-upschema draait niet om back-ups zo vaak mogelijk uitvoeren. Het gaat erom dat frequentie, opslag en testen in balans zijn met hoeveel verlies je bedrijf daadwerkelijk kan opvangen. Begin klein: kies vandaag een realistisch back-upschema, sla een kopie op buiten je hoofdserver en test een herstel voordat je het in een crisis nodig hebt. Daniel heeft te veel site-eigenaren hun back-upschema zien falen pas nadat een ramp toesloeg, dus laat dat jou niet gebeuren. Zet een herinnering, controleer de logs en bevestig deze week nog dat je back-ups daadwerkelijk hersteld kunnen worden.
