Een nuttig back-upplan voor uw website legt uit wat kan worden hersteld, hoe ver u terug kunt gaan en wie het herstel uitvoert. Vraag voordat u akkoord gaat met “back-ups inbegrepen” om een lijst van de gedekte systemen, bewaarde herstelpunten en een veilige demonstratie dat de afgesproken website kan worden hersteld. Alleen een melding dat een back-up is geslaagd, beantwoordt die vragen niet.
Deze checklist voor websiteback-ups en herstel helpt een bedrijf om hersteleisen af te spreken met de websiteleverancier of hostingprovider. De juiste aanpak hangt af van wat de website opslaat en hoe het bedrijf deze gebruikt. Een dienstenwebsite van vijf pagina's, een redactionele website en een webwinkel kunnen heel verschillende herstelbehoeften hebben.
1. Breng in kaart waarvan de website afhankelijk is
Begin met de onderdelen die nodig zijn om de website te laten werken, in plaats van met de naam van een back-upproduct. Neem pagina-inhoud, afbeeldingen, code, configuratie en een eventuele database op. Noteer gekoppelde diensten vervolgens afzonderlijk: een formulierbestemming, boekingssysteem, betaalprovider of CRM-systeem kan informatie buiten het hostingaccount van de website bewaren.
Een kopie van de zichtbare pagina's bevat niet noodzakelijk ook die andere gegevens. WordPress legt bijvoorbeeld uit dat voor een gebruikelijke volledige back-up zowel de websitebestanden als de database nodig zijn. Alleen de bestanden downloaden levert geen kopie van de database op. De bestanden en database moeten ook een onderling passend moment uit de geschiedenis van de website vertegenwoordigen, vooral rond updates.
Vraag bij een website die vanuit een coderepository wordt gebouwd wat er verder nodig is om deze opnieuw op te bouwen en te publiceren. De back-uprichtlijnen van GitHub maken onderscheid tussen de gegevens die verschillende back-upmethoden bevatten. Een repositorykopie is nuttig, maar ga er niet van uit dat deze elk geüpload bestand, extern record, iedere accountinstelling of alle vereisten voor publicatie bevat.
Maak deze grenzen zichtbaar met een kleine dekkingstabel. Dit is een werkblad voor de planning, geen bewering dat elke website elke rij nodig heeft. Vervang de voorbeelden door de systemen die uw bedrijf werkelijk gebruikt en noteer voor elk systeem de verantwoordelijke.
| Onderdeel | Te beantwoorden vraag | Te bewaren bewijs |
|---|---|---|
| Pagina's, code en ontwerpbestanden | Kan de afgesproken versie opnieuw worden opgebouwd of hersteld? | Versie, locatie en herstelinstructies |
| Database en geüploade media | Zijn beide opgenomen in een onderling passende herstelset? | Back-updatums, dekking en herstelresultaat |
| Configuratie en toegang | Wie kan de instellingen herstellen en geautoriseerde toegang verkrijgen? | Verantwoordelijke en procedure voor veilige toegang |
| Aanvragen, boekingen of bestellingen | Welk systeem bewaart deze gegevens daadwerkelijk? | Afzonderlijke provider en herstelafspraken |
| Domein en gekoppelde diensten | Welke afhankelijkheden moeten werken voordat de website kan worden gebruikt? | Accountverantwoordelijken en checklist van afhankelijkheden |
2. Spreek aanvaardbaar gegevensverlies en uitvaltijd af
Twee vragen in gewone taal maken het plan nuttiger: hoeveel recente informatie kan het bedrijf zich veroorloven te verliezen, en hoelang mag de betreffende dienst onbeschikbaar zijn? Beantwoord ze voor het bedrijfsproces, niet alleen voor de homepage. Een statische informatiepagina en een systeem dat betaalde bestellingen aanneemt, kunnen verschillende antwoorden verdienen.
Deze vragen komen overeen met de recovery point objective, of RPO, en de recovery time objective, of RTO. AWS definieert deze hersteldoelstellingen in termen van een aanvaardbaar tijdvenster voor gegevensverlies en de maximaal aanvaardbare onderbreking van de dienstverlening. Beschouw ze als afgesproken planningsdoelen. Ze bewijzen niet dat een bepaalde leverancier ze bij elk incident kan halen.
Een dagelijks herstelpunt kan bijvoorbeeld een gat laten met wijzigingen die na de laatste geslaagde back-up zijn aangebracht. Het bestaan ervan zegt op zichzelf niets over hoe snel iemand het kan vinden, toegang kan krijgen, het herstel kan uitvoeren en het resultaat kan controleren. Vraag de leverancier om het voorgestelde schema en herstelproces te verbinden aan uw vastgelegde doelen.
Kies niet voor “geen gegevensverlies” of “direct herstel” alleen omdat die woorden geruststellend klinken. Leg uit welke informatie niet opnieuw kan worden gemaakt en welke bedrijfsactiviteiten tijdelijk een alternatieve route kunnen gebruiken. Spreek vervolgens een haalbare aanpak af, inclusief kosten en eventuele beperkingen. Leg vast op welke tijden herstelhulp beschikbaar is en hoe een incident buiten die tijden wordt afgehandeld.
3. Bewaar bruikbare herstelpunten lang genoeg
Back-upfrequentie en bewaartermijn beantwoorden verschillende vragen. Frequentie gaat over hoe vaak een nieuw herstelpunt wordt gemaakt. De bewaartermijn bepaalt hoelang oudere punten beschikbaar blijven. Een frequente back-up die telkens de enige kopie vervangt, helpt mogelijk weinig wanneer een ongewenste wijziging pas enkele dagen later wordt ontdekt.
Vraag hoeveel versies worden bewaard, hoe hun datums herkenbaar zijn en wat er gebeurt wanneer opslaglimieten worden bereikt of een abonnement verandert. Houd rekening met de tijd die uw team nodig kan hebben om een probleem op te merken. Als niemand de inhoud gedurende enkele weken controleert, kan een zeer korte bewaartermijn al zijn verstreken voordat een onbedoelde verwijdering wordt ontdekt.
Maak duidelijk hoe de herstelkopieën van de live omgeving zijn gescheiden en wie ze kan wijzigen of verwijderen. Een kopie die door dezelfde verkeerde accounthandeling of hetzelfde beveiligingsincident wordt getroffen, biedt mogelijk niet de onafhankelijkheid die u verwachtte. Bespreek toegangsbeheer en bescherming met de verantwoordelijke provider in plaats van aan te nemen dat een tweede map of automatische synchronisatie voldoende is.
Houd het plan praktisch: benoem de herstellocatie en de verantwoordelijke voor het account zonder wachtwoorden, geheime sleutels of klantgegevens in een gedeelde briefing te zetten. Leg vast waar instructies voor geautoriseerde toegang worden bijgehouden. Spreek ook af wie foutmeldingen ontvangt en wat diegene doet wanneer een geplande back-up niet wordt voltooid.
4. Onderscheid rollback, selectief herstel en volledig herstel
Verschillende problemen vragen om verschillende herstelmethoden. Een deploymentrollback zet de gepubliceerde website terug naar een eerdere versie. Selectief herstel haalt een specifiek bestand, een pagina of een record terug. Volledig herstel reconstrueert de gedekte omgeving vanuit een herstelset. Vraag welke van deze methoden uw afspraken ondersteunen en wat elke methode verandert.
Cloudflare Pages beschrijft bijvoorbeeld het terugzetten naar een eerdere geslaagde productiedeployment. Dat is nuttig bij een probleem dat door een deployment is ontstaan. Het bewijst niet dat een afzonderlijk boekingsplatform of een externe klantendatabase ook naar dat moment terugkeert. Bevestig het gedrag van elke afhankelijkheid in plaats van “rollback” te behandelen als een universele knop om alles ongedaan te maken.
Breng voordat u oudere gegevens terugzet de wijzigingen sinds dat herstelpunt in kaart. Een volledig databaseherstel kan naast de ongewenste wijziging ook geldige nieuwere informatie vervangen. Bepaal of die latere gegevens kunnen worden behouden, afgestemd of afzonderlijk hersteld. De persoon die toestemming geeft voor het herstel moet die afweging begrijpen voordat een destructieve handeling begint.
Leg de beslisroute vast in gewone taal: wie beoordeelt het probleem, wie keurt het gekozen herstelpunt goed en wie voert het werk uit? Neem waar passend een manier op om de huidige toestand beschikbaar te houden voor onderzoek. Het herstelplan moet uitleggen hoe het team een methode kiest, niet een ondernemer aanmoedigen om op de live website te experimenteren.
5. Demonstreer herstel in een veilige omgeving
Vraag om een gecoördineerde hersteltest voordat u op het plan vertrouwt. AWS beveelt periodieke hersteltests aan om te controleren of back-upgegevens kunnen worden hersteld en gebruikt. De praktische vraag is of de afgesproken herstelset een bruikbare website oplevert, niet of er een archiefbestand bestaat.
Gebruik een geïsoleerde testbestemming die met de technisch verantwoordelijke is afgesproken. Beperk de toegang tot herstelde klantinformatie en voorkom dat testkopieën echte meldingen versturen, betalingen accepteren of live integraties overschrijven. Het verantwoordelijke team moet bepalen welke gegevens geschikt zijn voor de test en hoe ze daarna worden verwijderd.
Beoordeel de herstelde pagina's, afbeeldingen, navigatie en noodzakelijke configuratie. Controleer een representatief bedrijfsproces met gecoördineerde testafspraken. Een pagina die correct wordt weergegeven, bewijst niet dat de gekoppelde dienst correct is ingesteld. Leg vast wanneer een afhankelijkheid niet veilig kan worden getest, in plaats van het hele proces als aangetoond af te vinken.
Bewaar een kort testverslag: het gebruikte herstelpunt, de gedekte systemen, de bestemming, begin- en eindtijd, uitgevoerde controles en openstaande problemen. Meet de stappen die voor uw afgesproken hersteldoelstelling belangrijk zijn, inclusief toegang en verificatie. Herhaal de relevante controles na wezenlijke wijzigingen aan de website, hosting of herstelafspraken, met een beoordelingsfrequentie die op uw situatie is afgestemd.
6. Werk één realistische herstelbeslissing uit
Denk aan een hypothetisch adviesbureau met een kleine dienstenwebsite. De pagina's worden vanuit een repository gepubliceerd en aanvragen worden in een afzonderlijk systeem bewaard. Op dinsdagmiddag ontdekt het team dat een deployment op maandag een dienstenpagina heeft verwijderd. Op dinsdagochtend is een nieuwe aanvraag binnengekomen.
De eerste vraag is of het probleem alleen de gepubliceerde pagina's raakt of ook het aanvraagsysteem. Als een eerdere deployment de ontbrekende pagina bevat, kan het team een deploymentrollback beoordelen zonder aan te nemen dat het ook de afzonderlijke aanvraaggegevens moet terugzetten. Het controleert welke andere websitewijzigingen eveneens ongedaan zouden worden gemaakt en of alleen die ene pagina terughalen een betere optie is.
In een geïsoleerde preview demonstreert de verantwoordelijke leverancier de voorgestelde versie en controleert deze de afgesproken links en formulierconfiguratie. De verantwoordelijke binnen het bedrijf beoordeelt de betrokken wijzigingen en geeft via het bestaande proces toestemming voor het herstel op de live website. Het nieuwere record in het aanvraagsysteem wordt afzonderlijk behandeld, omdat de opslag en herstelafspraken daarvan afzonderlijk zijn geregeld.
Dit voorbeeld beschrijft een beslismethode, geen gerapporteerd klantresultaat of belofte over hersteltijd. Voor een webwinkel die bestellingen in de websitedatabase bewaart, zou dezelfde beslissing rekening moeten houden met bestellingen die na het voorgestelde herstelpunt zijn geplaatst. De bruikbare les is om eerst in kaart te brengen waar informatie staat, voordat u kiest wat u terugzet.
7. Leg herstelverantwoordelijkheden vast in de overeenkomst
Sluit af met een korte checklist die beide partijen kunnen beantwoorden. Bewaar deze bij de overdrachtsdocumentatie van de website en bekijk haar opnieuw wanneer de website verandert. De checklist moet begrijpelijk blijven voor degene die een incident moet melden, ook als die persoon geen opdrachtgever van het oorspronkelijke project was.
- We weten welke websiteonderdelen en externe systemen zijn gedekt.
- We hebben hersteldoelstellingen, back-upfrequentie en bewaartermijn afgesproken.
- We weten wie fouten controleert en wie geautoriseerde toegang voor herstel kan verkrijgen.
- We begrijpen de ondersteunde herstelmethoden en het risico voor nieuwere gegevens.
- We hebben een gedateerd verslag van de hersteltest, met beperkingen en vervolgstappen.
- We hebben verantwoordelijkheid, beschikbaarheid en eventuele afzonderlijke herstelkosten afgesproken.
Voeg openstaande eisen toe aan de projectbriefing voor de website. Als herstelplanning samengaat met een vervangende website, gebruik dan de checklist voor een websitevernieuwing voor de bredere overgang. Duidelijke herstelafspraken verminderen giswerk bij een incident; ze moeten beschrijven wat is geregeld en aangetoond.
De websitedienst van Digital Studio begint bij EUR 2.190 voor een eenmalige bouw van maximaal vijf pagina's op basis van aangeleverde inhoud, met responsief ontwerp, een SEO-basis, één leadformulier en lancering op uw domein. Back-upafspraken, hersteltests en doorlopende herstelondersteuning moeten voor uw project worden besproken en expliciet worden afgebakend. Beschrijf uw website en hersteleisen zodat verantwoordelijkheden en eventueel aanvullend werk kunnen worden afgesproken voordat de bouw begint.
