Sikkerhetskopi og gjenoppretting

Programmet heter «Ticket System Backup & Restore». Det står ved siden av ticketsystemet og har sin egen snarvei på skrivebordet.

Det finnes en utgave til Windows og en til Linux. Det er det samme programmet, bare bygget til hvert operativsystem.

Det har seks faner. «Restore» regner opp sikkerhetskopiene dere har, «Create Backup» lager en ny, «Schedule» styrer tidspunktet, «Encryption» viser gjenopprettingsnøkkelen, «Settings» viser stiene og «Log» protokollen.

Innstillingene er allerede fylt ut. Ved den første starten finner programmet selv ut hvor ticketsystemet bor.

Mappa for sikkerhetskopiene står under «Backup directory». Dere kan endre den, for eksempel til en annen stasjon.

På Windows ber programmet om administratorrettigheter når det starter. Innstillingene i programmet gjelder for hver administrator på datamaskinen og bor i «%ProgramData%\SMITEY\backup-app».

Installasjonen setter selv opp den daglige sikkerhetskopien. Den kjører klokka 23:00 i ticketsystemets tidssone.

Planen bor i operativsystemet. På Windows er det Oppgaveplanlegging, på Linux cron-tjenesten. Så det kjører ingen ekstra tjeneste bare til sikkerhetskopier.

Sikkerhetskopien krever ikke at noen er pålogget. På en server der ingen noen gang logger på, kjører den likevel.

Linja under knappene forteller dere om oppgaven virkelig finnes i operativsystemet. En avkrysset boks sier bare hva som ble lagret.

Sikkerhetskopier blir holdt i fem lag: 14 dager, 4 uker, 12 måneder, 4 kvartaler og 5 år. En sikkerhetskopi blir stående så lenge den er den nyeste i perioden sin i ett av de lagene.

Det som teller, er kalenderdager, ikke filer. To sikkerhetskopier på én dag er én dag.

Sikkerhetskopier dere lager for hånd, blir aldri slettet automatisk. Det er det 0 ved «Keep manual» betyr.

Endrer dere planen, overlever endringen deres en oppdatering. Installasjonen setter den bare hvis dere aldri har satt en plan. Har dere slått av sikkerhetskopieringen, forblir den av. Også «Remove all scheduled tasks» varer: en oppdatering setter ikke opp planen igjen etterpå.

En sikkerhetskopi inneholder alt som utgjør tilstanden til systemet deres. Det er databasen, vedleggene, arkivet og nøklene. Bare en database utenfor SMITEY mangler.

Nøklene er den delen som er lett å overse. De dekrypterer lagrede påloggingsopplysninger, for eksempel dem til e-postkontoen deres. Uten dem ville en gjenoppretting kommet tilbake med døde påloggingsopplysninger.

Hver ny sikkerhetskopi er ei enkelt kryptert fil som slutter på «.smbk». Den rommer ei fil per volum, ei liste over innholdet og databasen som tekstfil, hvis den er med.

Systemet går videre imens. Agentene deres merker ikke en sikkerhetskopi i det hele tatt.

«Estimate size» forteller dere på forhånd hvor stor databasen er. Volumene med vedleggene kommer i tillegg. Sikkerhetskopien blir ikke komprimert.

Det blir aldri overskrevet noe. Hver sikkerhetskopi er si egen fil, og bare oppryddingen fjerner gamle.

Bare administratorer kan lese sikkerhetskopiene. Det samme gjelder konfigurasjonsfilen og filen med den første påloggingen i installasjonsmappen. Installasjonsprogrammet og hver oppdatering setter disse rettighetene selv.

Kjører databasen deres på en egen server og ikke i SMITEY-containeren, kan ikke programmet sikkerhetskopiere den. Sikkerhetskopier den da med egne verktøy. Sikkerhetskopien inneholder i så fall bare vedleggene, arkivene og nøklene, kryptert som vanlig. En oppdatering oppdager en slik database selv og stiller programmet om. Fram til da mislykkes den daglige sikkerhetskopien på en slik installasjon, med mindre dere stiller om for hånd først. På kommandolinjen kan dere også gjøre dette for hånd med «config --database external». Med «config --database bundled» går dere tilbake.

Hver ny sikkerhetskopi er kryptert. Det gjelder sikkerhetskopier fra planen, sikkerhetskopier laget for hånd og sikkerhetskopier tatt før en oppdatering. Dere trenger ikke slå noe på.

Sikkerhetskopiene krypteres med AES-256. Installasjonen lager nøkkelen selv. På en eksisterende installasjon lages den ved den første oppdateringen til en versjon med kryptering. Den lagres beskyttet på serveren. Bare administratorer kan lese den.

Dette beskytter kopier utenfor serveren. Den som finner en sikkerhetskopi på en nettverksstasjon, en USB-pinne eller i nettlagring, kan ikke lese den uten nøkkelen. Den som kontrollerer selve serveren, har også nøkkelen.

Gjenopprettingsnøkkelen er den samme nøkkelen i en form dere kan skrive ned. Den begynner med «SMBK-». Dere finner den i fana «Encryption» og i fila «SMITEY-credentials.txt» i installasjonsmappen. Har dere slettet den fila, finner dere fortsatt nøkkelen i fana «Encryption».

«Copy» legger nøkkelen på utklippstavla. «Save to file...» lagrer den med nøkkel-ID-en og datoen i ei tekstfil. Oppbevar den for eksempel i en passordbehandler eller på papir i et pengeskap.

Helt til dere bekrefter at nøkkelen er lagret, viser programmet en gul linje øverst. For å bekrefte klikker dere på «I stored the key outside this server» og svarer «Yes» på spørsmålet. Linja forsvinner da. Fana viser så når dere bekreftet.

Nøkkel-ID-en forteller dere hvilken server en sikkerhetskopi hører til. Hører en sikkerhetskopi ikke til denne serveren, oppgir programmet nøkkel-ID-en til den. Det ber så om den tilhørende gjenopprettingsnøkkelen.

Kan ikke programmet lese nøkkelen, tar det ingen sikkerhetskopi. Det lager heller ingen ukryptert. I så fall sier fana «Encryption» at nøkkelen ikke kan leses. Mangler nøkkelfilen helt, lager neste sikkerhetskopi en ny nøkkel. Den gule linja vises da igjen, fordi den nye nøkkelen også må lagres. Eldre sikkerhetskopier kan fortsatt bare åpnes med den gamle gjenopprettingsnøkkelen.

Eldre sikkerhetskopier i ZIP-format er ikke kryptert. Dere kan fortsatt gjenopprette dem. Fana viser hvor mange det er. Opprydningen fjerner dem etter de samme reglene som alle andre sikkerhetskopier.

På en server uten skrivebord viser «key --show» det samme på kommandolinjen.

På fana «Restore» velger dere sikkerhetskopien dere vil ha tilbake. Så klikker dere på «Restore».

Programmet spør først. Det sier hva som kommer til å skje: tilstanden i dag blir overskrevet, og programmet starter containerne på nytt. Er det anonymiserte personer i tilstanden i dag, kommer et andre spørsmål. Det nevner antallet og spør om de skal anonymiseres på nytt etter gjenopprettingen. «Yes» er forhåndsvalgt. Med «No» blir sikkerhetskopien gjenopprettet uten dette trinnet. Lukker dere vinduet i stedet, blir ingenting gjenopprettet.

Krysset «Wipe target volumes before restore» tømmer volumene først. På den måten blir det ikke igjen noen fil som ikke fantes da sikkerhetskopien ble laget.

Trinnene dukker opp på fana «Log». Der ser dere ett om gangen hva programmet gjorde. Har dere svart «Yes» på det andre spørsmålet, sier en linje på slutten hvor mange anonymiseringer ticketsystemet bruker på nytt den påfølgende natten. Kan de ikke overføres, viser loggen i stedet en advarsel. Var det advarsler, nevner statuslinjen nederst i vinduet antallet.

Inneholder sikkerhetskopien databasen, kommer hele tilstanden tilbake. Saker, kommentarer, historikk, vedlegg, registrert tid og kunnskapsbasen er alle der igjen slik de var på tidspunktet for sikkerhetskopien.

Deretter kan systemet brukes igjen. På en liten installasjon tar det under et minutt.

Inneholder sikkerhetskopien databasen, kommer den tilbake helt eller ikke i det hele tatt. Volumene følger etter den. Mislykkes et volum, er databasen allerede tilbake, men filer kan mangle; fana «Log» viser hvilket trinn som mislyktes. I alle tilfeller starter programmet containerne igjen etterpå, også hvis gjenopprettingen mislyktes.

En sikkerhetskopi fra en eldre versjon kan gjenopprettes i en nyere. Ved neste oppstart bringer systemet databasen opp til sin egen versjon.

Samtykker og avmeldinger for tilfredshetsmålingen blir overført uten spørsmål. Det gjelder også hvis du svarer «No» på det andre spørsmålet. Programmet leser dem fra den kjørende installasjonen før gjenopprettingen. Etterpå oppgir en linje i fanen «Log» antallet, for eksempel «12 consent and unsubscribe record(s) were carried over.» Sakssystemet overtar dem ved første start. Et samtykke eller en avmelding som ble gjort etter sikkerhetskopien, forblir derfor gyldig. Hvis overføringen mislykkes, viser loggen en advarsel. Gjenopprettingen teller likevel som vellykket.

Programmet kontrollerer først en kryptert sikkerhetskopi fullstendig. Imens står det i statuslinja «Checking the encrypted backup before anything is changed...». Først deretter stopper det containerne. Er fila skadet eller endret, stopper det og melder «The backup file is damaged. Nothing was changed.»

Kommer sikkerhetskopien fra en annen server, ber programmet om gjenopprettingsnøkkelen til den serveren. Det skjer etter spørsmålene. Vinduet «Recovery key needed» oppgir nøkkel-ID-en til sikkerhetskopien. Det samme vinduet kommer opp hvis nøkkelen til denne serveren mangler.

En skrivefeil blir oppdaget før noe er endret. Statuslinja melder da «The recovery key has a typing error. Check each character.» Deretter spør vinduet på nytt. Hører nøkkelen til en annen sikkerhetskopi, melder statuslinja «This recovery key does not belong to this backup.» Med «Cancel» stopper programmet og melder «Restore cancelled. Nothing was changed.»

Programmet overtar ikke nøkkelen dere skrev inn. Det beholder sin egen. Nye sikkerhetskopier lages fortsatt med nøkkelen til denne serveren. Gjenoppretter dere på en ny server, må dere lagre gjenopprettingsnøkkelen til den serveren også.

En sikkerhetskopi uten database gjenoppretter bare vedleggene, arkivene og nøklene. Eksisterende nøkler beholdes. Databasen blir som den er. Programmet sier fra om dette før gjenopprettingen og spør. Med «No» endres ingenting.

Er installasjonen satt opp med sin egen database, hopper programmet over databasedelen selv om sikkerhetskopien inneholder en database. Det gjelder for eksempel en eldre sikkerhetskopi. Programmet spør først. Med «No» endres ingenting.

En server har ofte ikke noe skrivebord. Derfor virker det samme programmet også som en kommando.

Fem kommandoer er det dere trenger i hverdagen: «backup» lagrer, «list» viser sikkerhetskopiene dere har, «restore» henter en tilbake, «schedule» setter tidspunktet og «config» viser innstillingene. For nøkkelen kommer «key» og «decrypt» i tillegg.

Bak dem ligger det samme programmet som i vinduet. Det finnes ingen annen vei som gjør noe annet.

Programmet ligger i «/opt/smitey/Backup». Dere kaller det med «sudo» og legger til kommandoen. Containerne kjører som «root», så sikkerhetskopien trenger også de rettighetene.

Dere kan kopiere de seks boksene nedenfor. De dekker det som virkelig trengs i hverdagen.

En gjenoppretting spør også her. Den kjører først når dere legger til «--yes». Den overfører da også anonymiseringene fra tilstanden i dag, slik som «Yes» i vinduet. Med «--no-reapply» kjører den uten dette trinnet.

Det ligger ei fil på serveren for å lese opp på alt dette. Den heter «BACKUP-RESTORE.txt» og ligger i «/opt/smitey». Den går gjennom planen, hver kommando og veien tilbake en gang til, i deres eget tempo. Den finnes på tysk og på engelsk: valgte dere tysk under installasjonen, får dere den tyske, ellers den engelske. Begge versjonene ligger også under «/opt/smitey/docs».

«key --show» viser gjenopprettingsnøkkelen, nøkkel-ID-en og antallet ukrypterte sikkerhetskopier. Når nøkkelen er lagret utenfor serveren, bekrefter dere det med «key --confirm-stored».

Dere gjenoppretter en sikkerhetskopi fra en annen server med «--key-file». Fila dere oppgir, inneholder gjenopprettingsnøkkelen. Fila fra «Save to file...» fungerer også til dette. I stedet for fila kan dere bruke miljøvariabelen «SMITEY_BACKUP_KEY». Med «sudo» setter dere den rett foran programmet, altså «sudo SMITEY_BACKUP_KEY=<nøkkel> /opt/smitey/Backup/TicketSystemBackup restore …». Nøkkelen havner da i skallets historikk. Passer ikke nøkkelen, endres ingenting.

«decrypt» skriver innholdet i en sikkerhetskopi som ukrypterte filer til en tom mappe. Disse filene er ikke kryptert. De inneholder passord og personopplysninger. Slett dem så snart dere er ferdige.

Sikkerhetskopiene er filer i mappa dere har satt. Den mappa ligger på den samme maskinen som ticketsystemet.

Til de vanlige tilfellene virker det godt. Data slettet ved en feil, en oppdatering som gikk galt eller en feil i dataene er alle dekket.

Det hjelper ikke hvis disken svikter. Er disken borte, er sikkerhetskopiene borte med den.

Så kopier filene et annet sted. Et nettverksdrev, en annen server eller lagring i nettverket holder.

Ei kopiert fil kan legges tilbake på hvilken som helst server. På en annen server trenger dere gjenopprettingsnøkkelen til det. Med «Import backup file…» henter dere fila inn i lista igjen.

Kopiene er kryptert. Ingen kan lese dem uten gjenopprettingsnøkkelen. Oppbevar derfor ikke nøkkelen ved siden av kopiene. Eldre sikkerhetskopier som slutter på «.zip» er ikke kryptert.

En oppdatering tar sin egen sikkerhetskopi først. Det skjer uavhengig av planen deres og uten at dere krysser av noe sted.

Den lagrer det samme som alltid: databasen, vedleggene, arkivene og nøklene. Kjører databasen utenfor SMITEY, sikkerhetskopierer oppdateringen bare vedlegg, arkiver og nøkler.

Denne sikkerhetskopien lages av programmet «Ticket System Backup & Restore». Den er kryptert som alle andre og ligger i samme mappe. I lista har den typen «Update». De tre nyeste av disse sikkerhetskopiene beholdes. Programmet sletter eldre selv.

Merknaden før oppdateringen sier det til dere. Dere trenger ikke selv å huske å lagre først.

Mislykkes denne sikkerhetskopien, stopper oppdateringen før noe blir erstattet. En database utenfor SMITEY holder ikke oppdateringen tilbake. Oppdateringen stiller da programmet om, slik at den daglige sikkerhetskopien også utelater databasen. Sikkerhetskopier denne databasen med egne verktøy.