Back-ups van je website: wat gebeurt er als het misgaat?

Wat er misgaat is zelden een ramp op zichzelf

Een website gaat zelden plat door iets spectaculairs. Vaker is het een plugin-update die botst met een ander onderdeel, een hostingpartij die een server migreert en daarbij bestanden kwijtraakt, of een medewerker die per ongeluk een pagina verwijdert in plaats van aanpast. Ook een hack hoeft niet zichtbaar te zijn. Soms draait een site gewoon door, met onzichtbare code die spamlinks toevoegt of bezoekers stilletjes omleidt naar een andere pagina. Dat kan weken onopgemerkt blijven, tot Google de site als onveilig markeert.

Het probleem zit niet in het incident zelf, maar in wat erna gebeurt. Zonder back-up moet alles handmatig terug worden opgebouwd: teksten, afbeeldingen, instellingen, de structuur van het menu, de koppeling met je rekentools of je contactformulier. Dat kost dagen, soms weken, en in die tijd is je kantoor voor nieuwe klanten onvindbaar. Een bestaande klant die je adres intypt, krijgt een foutmelding te zien in plaats van je homepage. Dat is geen goede indruk. Zeker niet vlak voor een adviesgesprek. Lees ook waarom een offline site je aanvragen kost.

Wat een goede back-upstrategie inhoudt

Een back-up is pas bruikbaar als hij aan drie voorwaarden voldoet. Hij moet automatisch gebeuren, want een back-up die afhankelijk is van iemands geheugen wordt een keer vergeten. Hij moet op een andere plek staan dan de website zelf, anders verdwijnt de kopie samen met het origineel bij een serverstoring. En hij moet regelmatig teruggezet worden als test, want een back-up die nooit is uitgeprobeerd is in de praktijk een gok. Pas bij het terugzetten blijkt of de kopie compleet is. Alleen dan weet je het zeker.

Hoe vaak een site gekopieerd moet worden, hangt af van hoe vaak hij verandert. Een website die een paar keer per jaar wordt aangepast, is voldoende gedekt met een back-up per week. Een site met een actieve kennisbank of een blog dat regelmatig nieuwe artikelen krijgt, vraagt om een dagelijkse kopie. Anders ben je bij een storing toch een paar weken aan content kwijt, inclusief het werk dat daarin is gaan zitten. Bewaar ook meerdere versies terug in de tijd, niet alleen de meest recente. Eén back-up van gisteren helpt niet als de fout al twee weken geleden is ingeslopen en pas nu zichtbaar wordt. Veel hostingpartijen bewaren standaard dertig dagen terug; vraag na of dat bij jouw pakket ook zo is geregeld.

Wie dit regelt, en wat je moet navragen

Bij veel advieskantoren ligt deze verantwoordelijkheid impliciet bij de hostingpartij of de websitebouwer, zonder dat ooit hardop is afgesproken wat dat precies inhoudt. Vraag daarom na: hoe vaak wordt er een back-up gemaakt, hoe lang worden oude versies bewaard, en hoe snel kan een eerdere versie worden teruggezet als dat nodig is? Een antwoord als "dat zit goed" is geen antwoord. Vraag om een concreet aantal dagen en een concrete hersteltijd, bij voorkeur op papier in de overeenkomst.

Test die afspraak ook een keer in de praktijk, los van een echte storing. Vraag je beheerder om een pagina van een maand geleden terug te zetten op een testomgeving. Lukt dat binnen een uur, dan werkt de back-up zoals afgesproken. Lukt het niet, dan weet je dat liever nu dan tijdens een echte storing. Leg ook vast wie je belt als het misgaat buiten kantooruren, en of daar een vaste reactietijd tegenover staat. Een nette pagina bij een storing hoort bij dezelfde voorbereiding. Lees hoe je dat inricht.

Bij een Contaqt Site hoort dit technisch beheer standaard bij het pakket: dagelijkse back-ups, bewaard op een andere locatie dan de website zelf, met een team dat precies weet hoe snel een eerdere versie teruggezet moet worden. Je hoeft er zelf niet naar om te kijken. Bij een storing staat je site binnen een paar uur weer online, niet pas na weken puzzelen met losse bestanden.