Back-up en herstel

De toepassing heet “Ticket System Backup & Restore”. Ze staat naast het ticketsysteem en heeft een eigen snelkoppeling op het bureaublad.

Er is een versie voor Windows en een voor Linux. Het is dezelfde toepassing, alleen voor elk besturingssysteem gebouwd.

Ze heeft zes tabbladen. “Restore” toont de back-ups die je hebt, “Create Backup” maakt een nieuwe, “Schedule” regelt de tijden, “Encryption” toont de herstelsleutel, “Settings” toont de paden en “Log” het protocol.

De instellingen zijn al ingevuld. Bij de eerste start zoekt de toepassing zelf uit waar het ticketsysteem staat.

De map voor de back-ups staat onder “Backup directory”. Die kun je wijzigen, bijvoorbeeld naar een andere schijf.

Op Windows vraagt de toepassing bij het starten om beheerdersrechten. Haar instellingen gelden voor elke beheerder van de computer en staan in “%ProgramData%\SMITEY\backup-app”.

De installatie richt de dagelijkse back-up zelf in. Die loopt om 23:00 in de tijdzone van het ticketsysteem.

Het schema leeft in het besturingssysteem. Op Windows is dat Task Scheduler, op Linux de cron-dienst. Er draait dus geen extra dienst alleen voor back-ups.

De back-up heeft niemand nodig die is aangemeld. Op een server waar nooit iemand inlogt, loopt hij toch.

De regel onder de knoppen zegt je of de taak werkelijk in het besturingssysteem bestaat. Een gezet vinkje zegt alleen wat er is opgeslagen.

Back-ups worden in vijf staffels bewaard: 14 dagen, 4 weken, 12 maanden, 4 kwartalen en 5 jaar. Een back-up blijft zolang hij in een van die staffels de nieuwste van zijn periode is.

Wat telt, zijn kalenderdagen, geen bestanden. Twee back-ups op één dag zijn één dag.

Back-ups die je met de hand maakt, worden nooit automatisch verwijderd. Dat is wat de 0 bij “Keep manual” betekent.

Wijzig je het schema, dan overleeft je wijziging een update. De installatie zet het alleen als je nooit een schema hebt ingesteld. Heb je de back-up uitgezet, dan blijft hij uit. Ook “Remove all scheduled tasks” blijft gelden: een update richt het schema daarna niet opnieuw in.

Een back-up bevat alles wat de toestand van je systeem uitmaakt. Dat zijn de database, de bijlagen, het archief en de sleutels. Alleen een database buiten SMITEY ontbreekt.

De sleutels zijn het deel dat je makkelijk over het hoofd ziet. Ze ontsleutelen opgeslagen toegangsgegevens, bijvoorbeeld die van je mailaccount. Zonder hen zou een herstel met dode toegangsgegevens terugkomen.

Elke nieuwe back-up is één versleuteld bestand dat eindigt op “.smbk”. Dat bevat per volume één bestand, een lijst van de inhoud en, als die is opgenomen, de database als tekstbestand.

Het systeem blijft ondertussen draaien. Je agenten merken helemaal niets van een back-up.

“Estimate size” zegt je vooraf hoe groot de database is. De volumes met de bijlagen komen daar nog bij. De back-up wordt niet gecomprimeerd.

Er wordt nooit iets overschreven. Elke back-up is een eigen bestand, en alleen het opruimen haalt oude weg.

Alleen beheerders kunnen de back-ups lezen. Hetzelfde geldt voor het configuratiebestand en het bestand met de eerste aanmelding in de installatiemap. Het installatieprogramma en elke update zetten deze rechten zelf.

Draait je database op een eigen server en niet in de SMITEY-container, dan kan de toepassing er geen back-up van maken. Maak er dan zelf een met je eigen hulpmiddelen. In dat geval bevat de back-up alleen de bijlagen, de archieven en de sleutels, versleuteld zoals altijd. Een update herkent zo’n database zelf en schakelt de toepassing om. Tot dan mislukt de dagelijkse back-up op zo’n installatie, tenzij je eerst met de hand omschakelt. Op de opdrachtregel kun je dat ook met de hand doen met “config --database external”. Met “config --database bundled” schakel je terug.

Elke nieuwe back-up is versleuteld. Dat geldt voor back-ups uit het schema, met de hand gemaakte back-ups en back-ups vóór een update. Je hoeft niets in te schakelen.

Back-ups worden versleuteld met AES-256. De installatie maakt de sleutel zelf aan. Op een bestaande installatie gebeurt dat met de eerste update naar een versie met versleuteling. De sleutel staat beschermd op de server. Alleen beheerders kunnen hem lezen.

Dat beschermt kopieën buiten de server. Wie een back-up vindt op een netwerkschijf, een USB-stick of in online opslag, kan die zonder de sleutel niet lezen. Wie de server zelf beheert, heeft ook de sleutel.

De herstelsleutel is dezelfde sleutel in een vorm die je kunt opschrijven. Hij begint met “SMBK-”. Je vindt hem op het tabblad “Encryption” en in het bestand “SMITEY-credentials.txt” in de installatiemap. Heb je dat bestand verwijderd, dan vind je de sleutel nog steeds op het tabblad “Encryption”.

“Copy” zet de sleutel op het klembord. “Save to file...” bewaart hem met de sleutel-ID en de datum in een tekstbestand. Bewaar het bijvoorbeeld in een wachtwoordbeheerder of op papier in een kluis.

Tot je bevestigt dat de sleutel is bewaard, toont de toepassing bovenaan een gele balk. Klik om te bevestigen op “I stored the key outside this server” en beantwoord de vraag met “Yes”. De balk verdwijnt dan. Het tabblad toont daarna wanneer je hebt bevestigd.

De sleutel-ID zegt bij welke server een back-up hoort. Hoort een back-up niet bij deze server, dan noemt de toepassing de sleutel-ID. Daarna vraagt ze om de bijbehorende herstelsleutel.

Kan de toepassing de sleutel niet lezen, dan maakt ze geen back-up. Ook geen onversleutelde. In dat geval zegt het tabblad “Encryption” dat de sleutel niet kan worden gelezen. Ontbreekt het sleutelbestand helemaal, dan maakt de volgende back-up een nieuwe sleutel aan. De gele balk verschijnt dan opnieuw, omdat ook de nieuwe sleutel moet worden bewaard. Oudere back-ups zijn nog steeds alleen te openen met de oude herstelsleutel.

Oudere back-ups in ZIP-indeling zijn niet versleuteld. Je kunt ze nog steeds herstellen. Het tabblad toont hoeveel het er zijn. Het opruimen verwijdert ze volgens dezelfde regels als elke andere back-up.

Op een server zonder bureaublad toont “key --show” hetzelfde op de opdrachtregel.

In het tabblad “Restore” kies je de back-up die je terug wilt. Daarna klik je op “Restore”.

De toepassing vraagt het eerst. Ze zegt wat er gaat gebeuren: de toestand van vandaag wordt overschreven, en de toepassing start de containers opnieuw. Zijn er in de toestand van vandaag personen geanonimiseerd, dan volgt een tweede vraag. Die noemt hun aantal en vraagt of ze na het herstel opnieuw geanonimiseerd moeten worden. “Yes” is vooraf geselecteerd. Met “No” wordt de back-up zonder deze stap teruggezet. Sluit je in plaats daarvan het venster, dan wordt er niets teruggezet.

Het vinkje “Wipe target volumes before restore” maakt de volumes eerst leeg. Zo blijft er geen bestand achter dat er ten tijde van de back-up niet was.

De stappen verschijnen in het tabblad “Log”. Daar zie je stuk voor stuk wat de toepassing heeft gedaan. Heb je de tweede vraag met “Yes” beantwoord, dan zegt een regel aan het eind hoeveel anonimiseringen het ticketsysteem de volgende nacht opnieuw toepast. Kunnen ze niet worden overgenomen, dan toont het logboek in plaats daarvan een waarschuwing. Waren er waarschuwingen, dan noemt de statusregel onderaan het venster hun aantal.

Bevat de back-up de database, dan komt de volledige toestand terug. Tickets, opmerkingen, historie, bijlagen, geboekte tijd en de kennisbank staan er allemaal weer zoals ze op het moment van de back-up waren.

Daarna is het systeem weer bruikbaar. Bij een kleine installatie duurt dat minder dan een minuut.

Bevat de back-up de database, dan komt die volledig terug of helemaal niet. De volumes volgen daarna. Mislukt een volume, dan is de database al terug, maar kunnen er bestanden ontbreken; het tabblad “Log” toont welke stap is mislukt. In elk geval start de toepassing de containers daarna weer, ook als het herstel is mislukt.

Een back-up van een oudere versie is in een nieuwere terug te zetten. Bij de volgende start brengt het systeem de database op zijn eigen versie.

Toestemmingen en afmeldingen voor het tevredenheidsonderzoek worden zonder vraag overgenomen. Dit geldt ook als je de tweede vraag met “No” beantwoordt. De toepassing leest ze vóór het terugzetten uit de draaiende installatie. Daarna geeft een regel in het tabblad “Log” het aantal aan, bijvoorbeeld “12 consent and unsubscribe record(s) were carried over.” Het ticketsysteem neemt ze bij de eerste start over. Een toestemming of afmelding die na de back-up is gedaan, blijft dus geldig. Mislukt de overdracht, dan toont het logboek een waarschuwing. Het terugzetten telt toch als geslaagd.

De toepassing controleert een versleutelde back-up eerst volledig. Ondertussen staat in de statusregel “Checking the encrypted backup before anything is changed...”. Pas daarna stopt ze de containers. Is het bestand beschadigd of gewijzigd, dan stopt ze en meldt “The backup file is damaged. Nothing was changed.”

Komt de back-up van een andere server, dan vraagt de toepassing om de herstelsleutel van die server. Dat gebeurt na de vragen. Het venster “Recovery key needed” noemt de sleutel-ID van de back-up. Hetzelfde venster verschijnt als de sleutel van deze server ontbreekt.

Een typefout wordt opgemerkt voordat er iets is gewijzigd. De statusregel meldt dan “The recovery key has a typing error. Check each character.” Daarna vraagt het venster opnieuw. Hoort de sleutel bij een andere back-up, dan meldt de statusregel “This recovery key does not belong to this backup.” Met “Cancel” stopt de toepassing en meldt “Restore cancelled. Nothing was changed.”

De toepassing neemt de sleutel die je hebt ingevoerd niet over. Ze houdt haar eigen sleutel. Nieuwe back-ups worden nog steeds met de sleutel van deze server gemaakt. Herstel je op een nieuwe server, bewaar dan ook de herstelsleutel van die server.

Een back-up zonder database herstelt alleen de bijlagen, de archieven en de sleutels. Bestaande sleutels blijven behouden. De database blijft zoals ze is. De toepassing zegt dat vóór het herstel en vraagt het. Met “No” wordt niets gewijzigd.

Is de installatie ingesteld op een eigen database, dan slaat de toepassing het databasedeel over, ook als de back-up een database bevat. Dat geldt bijvoorbeeld voor een oudere back-up. De toepassing vraagt het eerst. Met “No” wordt niets gewijzigd.

Een server heeft vaak geen bureaublad. Daarom werkt dezelfde toepassing ook als opdracht.

Vijf opdrachten heb je dagelijks nodig: “backup” bewaart, “list” toont de back-ups die je hebt, “restore” haalt er een terug, “schedule” regelt de tijden en “config” toont de instellingen. Voor de sleutel komen “key” en “decrypt” erbij.

Daarachter zit dezelfde toepassing als in het venster. Er is geen tweede weg die iets anders doet.

De toepassing staat in “/opt/smitey/Backup”. Je roept haar aan met “sudo” en voegt de opdracht toe. De containers draaien als “root”, dus heeft de back-up die rechten ook nodig.

De zes kaders hieronder kun je kopiëren. Ze dekken wat er in het dagelijks gebruik echt nodig is.

Een herstel vraagt het hier ook. Het loopt pas wanneer je “--yes” toevoegt. Het neemt dan ook de anonimiseringen van de toestand van vandaag over, net als “Yes” in het venster. Met “--no-reapply” loopt het zonder deze stap.

Er staat een bestand op de server om dit alles na te lezen. Het heet “BACKUP-RESTORE.txt” en staat in “/opt/smitey”. Het loopt het schema, elke opdracht en de weg terug nog een keer door, in je eigen tempo. Het bestaat in het Duits en in het Engels: heb je bij de installatie Duits gekozen, dan krijg je het Duitse, anders het Engelse. Beide versies staan ook onder “/opt/smitey/docs”.

“key --show” toont de herstelsleutel, de sleutel-ID en het aantal onversleutelde back-ups. Is de sleutel buiten de server bewaard, dan bevestig je dat met “key --confirm-stored”.

Een back-up van een andere server herstel je met “--key-file”. Het bestand dat je opgeeft bevat de herstelsleutel. Het bestand uit “Save to file...” werkt hiervoor ook. In plaats van het bestand kun je ook de omgevingsvariabele “SMITEY_BACKUP_KEY” gebruiken. Met “sudo” zet je die direct vóór het programma, dus “sudo SMITEY_BACKUP_KEY=<sleutel> /opt/smitey/Backup/TicketSystemBackup restore …”. De sleutel komt dan in de shellgeschiedenis terecht. Past de sleutel niet, dan wordt niets gewijzigd.

“decrypt” schrijft de inhoud van een back-up als onversleutelde bestanden naar een lege map. Deze bestanden zijn niet versleuteld. Ze bevatten wachtwoorden en persoonsgegevens. Verwijder ze zodra je klaar bent.

De back-ups zijn bestanden in de map die je hebt ingesteld. Die map staat op dezelfde machine als het ticketsysteem.

Voor de gebruikelijke gevallen werkt dat goed. Per ongeluk verwijderde gegevens, een update die misging of een fout in de gegevens zijn allemaal gedekt.

Tegen een schijf die uitvalt, helpt het niet. Is de schijf weg, dan zijn de back-ups mee weg.

Kopieer de bestanden dus ergens anders naartoe. Een netwerkschijf, een tweede server of opslag in het netwerk zijn genoeg.

Een gekopieerd bestand is op elke server weer in te laden. Op een andere server heb je daarvoor de herstelsleutel nodig. Met “Import backup file…” haal je het bestand terug in de lijst.

De kopieën zijn versleuteld. Niemand kan ze lezen zonder de herstelsleutel. Bewaar de sleutel dus niet naast de kopieën. Oudere back-ups die eindigen op “.zip” zijn niet versleuteld.

Een update maakt vooraf een eigen back-up. Dat gebeurt los van je schema en zonder dat je iets aanvinkt.

Hij bewaart hetzelfde als altijd: de database, de bijlagen, de archieven en de sleutels. Draait de database buiten SMITEY, dan bewaart de update alleen bijlagen, archieven en sleutels.

Deze back-up wordt gemaakt door de toepassing “Ticket System Backup & Restore”. Ze is versleuteld zoals elke andere en staat in dezelfde map. In de lijst is het soort “Update”. De drie nieuwste van deze back-ups worden bewaard. De toepassing verwijdert oudere zelf.

De melding vóór de update zegt dat. Je hoeft er dus niet zelf aan te denken om eerst te bewaren.

Mislukt deze back-up, dan stopt de update voordat er iets wordt vervangen. Een database buiten SMITEY houdt de update niet op. De update schakelt de toepassing dan zo om dat ook de dagelijkse back-up de database weglaat. Maak van deze database een back-up met je eigen hulpmiddelen.