Sikkerhedskopi og gendannelse

Programmet hedder »Ticket System Backup & Restore«. Det står ved siden af ticketsystemet og har sin egen genvej på skrivebordet.

Der findes en udgave til Windows og en til Linux. Det er det samme program, bare bygget til hvert styresystem.

Det har seks faneblade. »Restore« opregner de sikkerhedskopier, du har, »Create Backup« laver en ny, »Schedule« styrer tidspunktet, »Encryption« viser gendannelsesnøglen, »Settings« viser stierne og »Log« protokollen.

Indstillingerne er allerede udfyldt. Ved sin første start finder programmet selv ud af, hvor ticketsystemet bor.

Mappen til sikkerhedskopierne står under »Backup directory«. Du kan ændre den, for eksempel til et andet drev.

På Windows beder programmet om administratorrettigheder, når det starter. Dets indstillinger gælder for hver administrator på computeren og bor i »%ProgramData%\SMITEY\backup-app«.

Installationen sætter selv den daglige sikkerhedskopi op. Den kører klokken 23:00 i ticketsystemets tidszone.

Planen bor i styresystemet. På Windows er det Opgavestyring, på Linux cron-tjenesten. Så der kører ingen ekstra tjeneste bare til sikkerhedskopier.

Sikkerhedskopien kræver ikke, at nogen er logget ind. På en server, hvor ingen nogensinde logger på, kører den alligevel.

Linjen under knapperne fortæller dig, om opgaven virkelig findes i styresystemet. Et sat flueben siger kun, hvad der blev gemt.

Sikkerhedskopier bliver holdt i fem lag: 14 dage, 4 uger, 12 måneder, 4 kvartaler og 5 år. En sikkerhedskopi bliver stående, så længe den er den nyeste i sin periode i et af de lag.

Det, der tæller, er kalenderdage, ikke filer. To sikkerhedskopier på én dag er én dag.

Sikkerhedskopier, du laver i hånden, bliver aldrig slettet automatisk. Det er, hvad 0 ved »Keep manual« betyder.

Ændrer du planen, overlever din ændring en opdatering. Installationen sætter den kun, hvis du aldrig har sat en plan. Har du slået sikkerhedskopieringen fra, forbliver den slået fra. Også »Remove all scheduled tasks« holder: en opdatering sætter ikke planen op igen bagefter.

En sikkerhedskopi indeholder alt det, der udgør dit systems tilstand. Det er databasen, de vedhæftede filer, arkivet og nøglerne. Kun en database uden for SMITEY mangler.

Nøglerne er den del, det er let at overse. De dekrypterer gemte adgangsoplysninger, for eksempel dem til jeres mailkonto. Uden dem ville en gendannelse komme tilbage med døde adgangsoplysninger.

Hver ny sikkerhedskopi er én enkelt krypteret fil med endelsen ».smbk«. Den rummer én fil per volumen, en liste over indholdet og databasen som tekstfil, hvis den er med.

Systemet kører videre imens. Jeres agenter opdager slet ikke en sikkerhedskopi.

»Estimate size« fortæller dig på forhånd, hvor stor databasen er. Volumenerne med de vedhæftede filer kommer oveni. Sikkerhedskopien bliver ikke komprimeret.

Der bliver aldrig overskrevet noget. Hver sikkerhedskopi er sin egen fil, og kun oprydningen fjerner gamle.

Kun administratorer kan læse sikkerhedskopierne. Det samme gælder konfigurationsfilen og filen med det første login i installationsmappen. Installationsprogrammet og hver opdatering sætter selv disse rettigheder.

Kører din database på sin egen server og ikke i SMITEY-containeren, kan programmet ikke tage sikkerhedskopi af den. Tag så sikkerhedskopi af den med dine egne værktøjer. I så fald rummer sikkerhedskopien kun de vedhæftede filer, arkiverne og nøglerne, krypteret som sædvanligt. En opdatering opdager selv sådan en database og stiller programmet om. Indtil da mislykkes den daglige sikkerhedskopi på sådan en installation, medmindre du først stiller om i hånden. På kommandolinjen kan du også gøre det i hånden med »config --database external«. Med »config --database bundled« stiller du tilbage.

Hver ny sikkerhedskopi er krypteret. Det gælder sikkerhedskopier fra planen, sikkerhedskopier lavet i hånden og sikkerhedskopier før en opdatering. Du behøver ikke slå noget til.

Sikkerhedskopier krypteres med AES-256. Installationen opretter nøglen selv. På en eksisterende installation oprettes den med den første opdatering til en version med kryptering. Den ligger beskyttet på serveren. Kun administratorer kan læse den.

Det beskytter kopier uden for serveren. Den, der finder en sikkerhedskopi på et netværksdrev, en USB-nøgle eller i online-lager, kan ikke læse den uden nøglen. Den, der kontrollerer selve serveren, har også nøglen.

Gendannelsesnøglen er den samme nøgle i en form, du kan skrive ned. Den begynder med »SMBK-«. Du finder den på fanebladet »Encryption« og i filen »SMITEY-credentials.txt« i installationsmappen. Har du slettet den fil, finder du stadig nøglen på fanebladet »Encryption«.

»Copy« lægger nøglen på udklipsholderen. »Save to file...« gemmer den med nøgle-id'et og datoen i en tekstfil. Opbevar den for eksempel i en adgangskodeadministrator eller på papir i et pengeskab.

Indtil du bekræfter, at nøglen er gemt, viser programmet en gul bjælke øverst. For at bekræfte klikker du på »I stored the key outside this server« og svarer »Yes« på spørgsmålet. Bjælken forsvinder så. Fanebladet viser derefter, hvornår du bekræftede.

Nøgle-id'et fortæller dig, hvilken server en sikkerhedskopi hører til. Hører en sikkerhedskopi ikke til denne server, nævner programmet dens nøgle-id. Derefter beder det om den passende gendannelsesnøgle.

Kan programmet ikke læse nøglen, laver det ingen sikkerhedskopi. Det laver heller ikke en ukrypteret. I så fald siger fanebladet »Encryption«, at nøglen ikke kan læses. Mangler nøglefilen helt, opretter den næste sikkerhedskopi en ny nøgle. Den gule bjælke vises så igen, fordi den nye nøgle også skal gemmes. Ældre sikkerhedskopier kan stadig kun åbnes med den gamle gendannelsesnøgle.

Ældre sikkerhedskopier i ZIP-format er ikke krypteret. Du kan stadig gendanne dem. Fanebladet viser, hvor mange der er. Oprydningen fjerner dem efter de samme regler som enhver anden sikkerhedskopi.

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

På fanebladet »Restore« vælger du den sikkerhedskopi, du vil have tilbage. Så klikker du på »Restore«.

Programmet spørger først. Det siger, hvad der kommer til at ske: dagens tilstand bliver overskrevet, og programmet genstarter containerne. Er der anonymiserede personer i dagens tilstand, kommer der et andet spørgsmål. Det nævner antallet og spørger, om de skal anonymiseres igen efter gendannelsen. »Yes« er valgt på forhånd. Med »No« bliver sikkerhedskopien gendannet uden dette skridt. Lukker du i stedet vinduet, bliver intet gendannet.

Fluebenet »Wipe target volumes before restore« tømmer volumenerne først. På den måde bliver der ingen fil tilbage, som ikke fandtes, da sikkerhedskopien blev lavet.

Skridtene dukker op på fanebladet »Log«. Der ser du ét ad gangen, hvad programmet gjorde. Har du svaret »Yes« på det andet spørgsmål, siger en linje til sidst, hvor mange anonymiseringer ticketsystemet anvender igen den følgende nat. Kan de ikke overføres, viser loggen i stedet en advarsel. Var der advarsler, nævner statuslinjen nederst i vinduet antallet.

Indeholder sikkerhedskopien databasen, kommer hele tilstanden tilbage. Sager, kommentarer, historik, vedhæftede filer, registreret tid og vidensbasen er der alle igen, som de var på sikkerhedskopiens tidspunkt.

Derefter kan systemet bruges igen. På en lille installation tager det under et minut.

Indeholder sikkerhedskopien databasen, kommer den tilbage helt eller slet ikke. Volumenerne følger efter den. Mislykkes en volumen, er databasen allerede tilbage, men filer kan mangle; fanebladet »Log« viser, hvilket trin der mislykkedes. Under alle omstændigheder starter programmet containerne igen bagefter, også hvis gendannelsen mislykkedes.

En sikkerhedskopi fra en ældre version kan gendannes i en nyere. Ved den næste start bringer systemet databasen op på sin egen version.

Samtykker og afmeldinger til tilfredshedsmålingen bliver overført uden spørgsmål. Det gælder også, hvis du svarer »No« på det andet spørgsmål. Programmet læser dem fra den kørende installation før gendannelsen. Bagefter angiver en linje på fanen »Log« antallet, for eksempel »12 consent and unsubscribe record(s) were carried over.« Sagssystemet overtager dem ved sin første start. Et samtykke eller en afmelding, der blev givet efter sikkerhedskopien, forbliver derfor gyldigt. Hvis overførslen mislykkes, viser loggen en advarsel. Gendannelsen tæller stadig som vellykket.

Programmet kontrollerer først en krypteret sikkerhedskopi fuldstændigt. Imens siger statuslinjen »Checking the encrypted backup before anything is changed...«. Først derefter stopper det containerne. Er filen beskadiget eller ændret, stopper det og melder »The backup file is damaged. Nothing was changed.«

Kommer sikkerhedskopien fra en anden server, beder programmet om den servers gendannelsesnøgle. Det sker efter spørgsmålene. Vinduet »Recovery key needed« nævner sikkerhedskopiens nøgle-id. Det samme vindue vises, hvis denne servers nøgle mangler.

En tastefejl opdages, før noget er ændret. Statuslinjen melder så »The recovery key has a typing error. Check each character.« Derefter spørger vinduet igen. Hører nøglen til en anden sikkerhedskopi, melder statuslinjen »This recovery key does not belong to this backup.« Med »Cancel« stopper programmet og melder »Restore cancelled. Nothing was changed.«

Programmet overtager ikke den nøgle, du har skrevet. Det beholder sin egen. Nye sikkerhedskopier laves stadig med denne servers nøgle. Gendanner du på en ny server, så gem også den servers gendannelsesnøgle.

En sikkerhedskopi uden database gendanner kun de vedhæftede filer, arkiverne og nøglerne. Eksisterende nøgler beholdes. Databasen forbliver, som den er. Programmet siger det før gendannelsen og spørger. Med »No« ændres der ikke noget.

Er installationen indstillet til sin egen database, springer programmet databasedelen over, også når sikkerhedskopien indeholder en database. Det gælder for eksempel en ældre sikkerhedskopi. Programmet spørger først. Med »No« ændres der ikke noget.

En server har tit intet skrivebord. Derfor virker det samme program også som en kommando.

Fem kommandoer er, hvad du skal bruge i hverdagen: »backup« gemmer, »list« viser de sikkerhedskopier, du har, »restore« henter en tilbage, »schedule« sætter tidspunktet og »config« viser indstillingerne. Til nøglen kommer »key« og »decrypt« oveni.

Bag dem ligger det samme program som i vinduet. Der findes ingen anden vej, der gør noget andet.

Programmet ligger i »/opt/smitey/Backup«. Du kalder det med »sudo« og tilføjer kommandoen. Containerne kører som »root«, så sikkerhedskopien har også brug for de rettigheder.

Du kan kopiere de seks kasser nedenunder. De dækker det, der virkelig er brug for i hverdagen.

En gendannelse spørger også her. Den kører først, når du tilføjer »--yes«. Den overfører så også anonymiseringerne fra dagens tilstand, ligesom »Yes« i vinduet. Med »--no-reapply« kører den uden dette skridt.

Der ligger en fil på serveren til at læse op på det hele. Den hedder »BACKUP-RESTORE.txt« og ligger i »/opt/smitey«. Den går planen, hver kommando og vejen tilbage igennem en gang til, i dit eget tempo. Den findes på tysk og på engelsk: valgte du tysk under installationen, får du den tyske, ellers den engelske. Begge versioner ligger også under »/opt/smitey/docs«.

»key --show« viser gendannelsesnøglen, nøgle-id'et og antallet af ukrypterede sikkerhedskopier. Når nøglen er gemt uden for serveren, bekræfter du det med »key --confirm-stored«.

En sikkerhedskopi fra en anden server gendanner du med »--key-file«. Filen, du angiver, indeholder gendannelsesnøglen. Filen fra »Save to file...« duer også til det. I stedet for filen kan du også bruge miljøvariablen »SMITEY_BACKUP_KEY«. Med »sudo« sætter du den lige foran programmet, altså »sudo SMITEY_BACKUP_KEY=<nøgle> /opt/smitey/Backup/TicketSystemBackup restore …«. Nøglen ender så i shellens historik. Passer nøglen ikke, ændres der ikke noget.

»decrypt« skriver indholdet af en sikkerhedskopi som ukrypterede filer i en tom mappe. Disse filer er ikke krypteret. De indeholder adgangskoder og personoplysninger. Slet dem, så snart du er færdig.

Sikkerhedskopierne er filer i den mappe, du har sat. Den mappe ligger på den samme maskine som ticketsystemet.

Til de almindelige tilfælde virker det godt. Data slettet ved en fejl, en opdatering der gik galt eller en fejl i dataene er alle dækket.

Det hjælper ikke, hvis disken går ned. Er disken væk, er sikkerhedskopierne væk med den.

Så kopiér filerne et andet sted hen. Et netværksdrev, en anden server eller lager i netværket er nok.

En kopieret fil kan lægges tilbage på enhver server. På en anden server skal du bruge gendannelsesnøglen til det. Med »Import backup file…« henter du filen ind i listen igen.

Kopierne er krypteret. Ingen kan læse dem uden gendannelsesnøglen. Opbevar derfor ikke nøglen ved siden af kopierne. Ældre sikkerhedskopier med endelsen ».zip« er ikke krypteret.

En opdatering tager sin egen sikkerhedskopi først. Det sker uafhængigt af din plan og uden at du sætter flueben nogen steder.

Den gemmer det samme som altid: databasen, de vedhæftede filer, arkiverne og nøglerne. Kører databasen uden for SMITEY, tager opdateringen kun sikkerhedskopi af de vedhæftede filer, arkiverne og nøglerne.

Denne sikkerhedskopi laves af programmet »Ticket System Backup & Restore«. Den er krypteret som alle andre og ligger i samme mappe. I listen er dens type »Update«. De tre nyeste af disse sikkerhedskopier beholdes. Ældre sletter programmet selv.

Bemærkningen før opdateringen siger det til dig. Du behøver ikke selv at huske at gemme først.

Mislykkes denne sikkerhedskopi, stopper opdateringen, før noget bliver erstattet. En database uden for SMITEY holder ikke opdateringen tilbage. Opdateringen stiller så programmet om, så den daglige sikkerhedskopi også udelader databasen. Tag sikkerhedskopi af denne database med dine egne værktøjer.