Een back-up is gemaakt maar nog nooit hersteld

Een statusmelding van je hostingpartij, plug-in of back-uptool bevestigt meestal dat een proces is afgerond. Ze bevestigt niet automatisch dat het resultaat volledig is, dat je het wachtwoord of de sleutel nog hebt, dat de database consistent is of dat je het bestand op een andere plek kunt openen.

Vier dingen kunnen onopgemerkt misgaan:

• De back-up bevat de bestanden maar niet de database, of omgekeerd.
• De kopie staat op dezelfde server of hetzelfde account als het origineel en deelt dus hetzelfde risico.
• Het bestand is beschadigd of afgekapt.
• Niemand weet nog welke stappen nodig zijn om het terug te zetten, of wie toegang heeft tot de opslagplaats.

Daarom meet je niet het maken, maar het herstellen. Kijk bij je eigen tool of provider na welke herstelopties bestaan en wie ze mag gebruiken. Exacte menu's en rechten kunnen wijzigen, dus noteer waar jouw beheerder dit vindt in plaats van op een onthouden schermnaam te vertrouwen.

Begin met een lijst van wat je écht nodig hebt om te kunnen blijven werken. Dat is niet 'alles', maar de kleinste set waarmee je bedrijf weer draait.

1. Noteer de noodzakelijke gegevens: bijvoorbeeld de websitebestanden, de database, uploads zoals productafbeeldingen, configuratiebestanden, en gegevens in je mailbox of boekhoudtool.
2. Kies de plek van de proef. Gebruik een aparte omgeving: een tijdelijk testaccount, een lokale machine of een staging-omgeving. Overschrijf nooit je live omgeving om te testen.
3. Kies welke back-up je test. Neem bij voorkeur niet de allernieuwste, maar ook een oudere. Zo zie je of je terug kunt naar een eerder moment.
4. Bepaal vooraf wat 'geslaagd' betekent. Schrijf criteria op, bijvoorbeeld: de website laadt, een inlog werkt, een testbestelling staat in de database, een specifiek document opent.

Omdat je een kopie van je gegevens naar een testomgeving brengt, behandel je die omgeving even zorgvuldig als de live. Er kunnen persoonsgegevens in zitten. MDN beschrijft webbeveiliging als het beschermen van sites en gebruikers tegen schade door kwaadwillende derden en noemt operationele veiligheid, zoals toegang tot broncode beperken en geheimen veilig beheren, als kernpraktijk (MDN over webbeveiliging). Pas dat toe op je testomgeving: beperk wie erin kan, zet geen wachtwoorden in gedeelde notities en ruim de omgeving na de proef op. Voor vragen over wat de privacywetgeving van je vraagt bij testkopieën, raadpleeg je een deskundige; dit artikel geeft daarover geen juridisch advies.

Voer de proef in deze volgorde uit en noteer bij elke stap wat je ziet, ook als het goed gaat.

1. Haal de back-up op uit de opslagplaats met de gewone werkwijze die een collega zou volgen. Merk op of je toegang had, hoe lang het duurde en of je hulp nodig had.
2. Controleer het bestand vóór het terugzetten: kan het worden geopend of uitgepakt, en klopt grofweg de omvang ten opzichte van wat je verwacht?
3. Zet de bestanden terug in de testomgeving.
4. Zet de database terug in een aparte testdatabase, niet in de live database.
5. Koppel bestanden en database aan elkaar en pas alleen de verbindingsinstellingen aan die de testomgeving nodig heeft.
6. Blokkeer uitgaande acties zoals e-mailverzending en betalingen in de testomgeving, zodat je geen echte klanten bereikt.
7. Voer je succescriteria uit en noteer per criterium geslaagd of niet geslaagd.
8. Ruim op: verwijder de testomgeving en de tijdelijk gedownloade kopieën.

Als je back-ups in een account staan dat met tweestapsverificatie is beveiligd, zoals een Google-account, test dan ook je eigen toegang. Google beschrijft dat tweestapsverificatie een extra beveiligingslaag toevoegt voor het geval je wachtwoord wordt gestolen en noemt onder meer back-upcodes voor als je telefoon kwijt is (Google-help over tweestapsverificatie). Die bron gaat over accountbeveiliging, niet over back-ups zelf. Controleer daarom of jij of een tweede bevoegde persoon kan inloggen met de beschikbare tweede stap en dat eventuele back-upcodes veilig bewaard zijn.

Vergelijk na het terugzetten wat er in de testomgeving staat met de live situatie. Gebruik deze lijst en beslisregels.

• Bestanden: vergelijk aantal en omvang van de belangrijkste mappen, en open drie à vijf willekeurige bestanden, waaronder een recent en een oud.
• Database: vergelijk het aantal records in de kerntabellen of lijsten, zoals klanten, bestellingen en producten, met de live situatie, rekening houdend met wat er sinds de back-up is bijgekomen.
• Functie: test een inlog, een zoekopdracht en een formulier of bestelstroom in de testomgeving.
• Leesbaarheid: controleer of speciale tekens, bijvoorbeeld accenten in namen, correct zijn weergegeven.
• Toegang: noteer of iemand anders dan jij de herstelstappen heeft kunnen volgen.

Een fictieve kmo heeft een webshop en een wekelijkse automatische back-up, maar heeft die nooit teruggezet. Dit zijn invoer en verwachte controles, geen resultaten.

Invoer: één back-upbestand van enkele weken geleden, een lege testomgeving, een lijst van vier noodzakelijke gegevens (shopbestanden, database, productafbeeldingen, configuratie) en vijf succescriteria.

Verwachte technische controles:

1. Het back-upbestand kan worden geopend en bevat zowel bestanden als een databasedump.
2. Na het terugzetten laadt de testwebsite zonder foutmelding.
3. Het aantal producten en klanten in de testdatabase komt overeen met wat je op het moment van de back-up verwacht.
4. Een testinlog en een proefbestelling werken, zonder dat er echte e-mail of betaling wordt verzonden.
5. Een collega zonder voorkennis volgt de genoteerde stappen en komt tot hetzelfde punt.

Een negatieve uitkomst is hier een nuttig resultaat: je weet nu wat je moet bijsturen voordat je het echt nodig hebt.

Plan daarna een vast moment voor een nieuwe proef, bijvoorbeeld na een grote wijziging aan je site of tool. Wil je ook de publieke signalen van je website laten bekijken, dan kan dat via Marketing Scan. Dat is een aanvulling; onze scan voert de herstelcontroles uit dit artikel niet uit.