Backup af webapps: 3-2-1-reglen og hvad du skal teste

En god backup af en webapp dækker databasen, de uploadede filer og den konfiguration der skal til for at starte appen igen. Mindst én kopi skal ligge hos en anden udbyder end din hosting, og den vigtigste del er testen: en backup tæller først når nogen har gendannet appen fra den og taget tid på det.

Du behøver ikke være teknisk for at tjekke om det er på plads. Midt i guiden finder du syv spørgsmål du kan stille din udvikler, og svarene afslører hurtigt om backuppen holder. Jeg tilbyder selv vedligehold af webapps, så læs med det forbehold.

Den korte version: 3-2-1 oversat til en webapp

Har du kun kopi 1 og 2, har du en backup der virker indtil den dag udbyderen selv har et problem. Kopi 3 er den der redder dig, men kun hvis den er testet.

Backup er en af seks faste opgaver jeg gennemgår i den samlede guide til drift og vedligehold af webapps. Her handler det kun om backup, og især om den del de fleste springer over: at prøve at gendanne.

Hvad 3-2-1-reglen betyder for en webapp

3-2-1-reglen er en gammel tommelfingerregel, og den amerikanske cybersikkerhedsmyndighed CISA anbefaler den stadig: tre kopier af vigtige data, på to forskellige typer lager, hvoraf én ligger et andet sted (CISA om backup i virksomheder). Reglen er skrevet til kontorer med harddiske og bånd, så den skal oversættes lidt til en webapp der kører i skyen.

"Et andet sted" betyder hos en anden udbyder, eller i det mindste på en anden konto og i et andet datacenter. Det er ikke teoretisk. Da en brand ødelagde et datacenter hos OVHcloud i Strasbourg i marts 2021 (OVHclouds egen redegørelse), mistede nogle kunder data fordi deres backup lå i samme bygning som serverne. En fransk domstol gav senere to af dem erstatning (Blocks & Files om dommene).

"To typer lager" handler om at kopierne ikke må kunne forsvinde af samme grund på samme tid. Serverens disk er én type. Objektlager (fillager i skyen, fx S3-kompatibel lagring) hos en anden udbyder er en anden.

Ransomware (angreb hvor dine data bliver krypteret, og der kræves løsepenge) og hackede konti har tilføjet et ekstra krav: mindst én kopi bør være offline eller uforanderlig, så den ikke kan slettes eller krypteres af en der har fået fat i serverens adgange. CISA anbefaler også krypterede og offline kopier. I en webapp løses det typisk med separate adgange til backuplageret og en låseperiode, så gamle kopier ikke kan slettes før efter fx 30 dage.

To ting tæller ikke som kopier: udviklerens bærbare computer og et Git-repository (kodearkiv). Det første er ikke dit, og det andet indeholder koden, ikke dine data.

Hvad skal med i backuppen?

Et af de mest almindelige huller er en backup der kun dækker databasen. Den er vigtigst, men den kan ikke starte appen alene. En komplet backup af en webapp har fem dele:

• Databasen. Kunder, ordrer, brugere og alt andet appen gemmer. Den skal tages med et værktøj der giver en sammenhængende kopi, ikke ved at kopiere databasefilerne mens databasen kører.
• Uploadede filer. Billeder, PDF'er, fakturaer og dokumenter som brugerne har lagt op. Ligger de i et fillager i skyen, er de ikke automatisk med i serverens backup, og de er ikke beskyttet mod sletning medmindre versionering er slået til.
• Konfiguration og hemmelige nøgler. I Laravel er det miljøfilen .env med adgangskoder og API-nøgler. Den hører ikke hjemme ukrypteret i en backupfil, men den skal kunne findes, fx i virksomhedens adgangskodemanager.
• Koden. Den ligger normalt i et repository på GitHub eller lignende. Det er fint, så længe det står i virksomhedens navn.
• Opskriften. En kort beskrivelse af hvordan appen sættes op fra bunden: PHP-version, baggrundsjob, planlagte opgaver, DNS og de tredjepartstjenester der skal forbindes. Uden den kan en gendannelse tage dage, selvom alle data er intakte.

Cache, sessioner og søgeindeks behøver som regel ikke backup, fordi de kan bygges op igen. Det skal bare stå i opskriften hvordan.

I Laravel-projekter er pakken spatie/laravel-backup en udbredt løsning. Den pakker databasen og udvalgte mapper i en zipfil, kan gemme den på flere lagre på én gang, rydder gamle kopier op og sender besked når noget går galt (dokumentationen for laravel-backup). Den gendanner til gengæld ikke for dig, så gendannelsen skal stadig beskrives og testes.

Hvor meget data må du miste, og hvor længe må appen være nede?

Før nogen kan sætte en fornuftig backup op, skal du svare på to spørgsmål. Fagfolk kalder dem RPO og RTO:

• RPO (recovery point objective): hvor meget data må du højst miste, målt i tid? Tager du backup hver nat, kan du miste op til et døgns ordrer og ændringer.
• RTO (recovery time objective): hvor længe må appen højst være nede, mens den bliver gendannet?

Svarene afhænger af forretningen, ikke af teknikken. Her er et groft skøn over hvad forskellige typer webapps typisk kan tåle:

Point-in-time recovery betyder at databasen kan spoles tilbage til et bestemt minut, fx lige før en fejl slettede data. Mange administrerede databaser tilbyder det, men tjek hvor mange dage tilbage det rækker hos din udbyder.

Jo lavere tal, jo dyrere. Selve lagerpladsen til en daglig ekstern backup af en mindre app koster typisk under 100 kr. om måneden. Det er opsætningen, overvågningen og testene der koster tid, og krav om minutter frem for timer ændrer hele arkitekturen.

Backup er ikke det samme som høj oppetid

En gendannelse tager tid, selv når alt virker. Skal appen være oppe igen inden for minutter, er backup ikke svaret. Så har du brug for redundans: en reservedatabase der hele tiden er opdateret, servere i flere datacentre og en driftspartner med vagtordning. Jeg kan hjælpe med at bygge det, men som freelancer kan jeg ikke ærligt love døgnovervågning. Det kræver et bureau, en driftsleverandør eller dit eget team.

Syv spørgsmål du kan stille din udvikler

Du behøver ikke kunne læse en backupkonfiguration for at vurdere om den holder. Stil de her spørgsmål, og læg mærke til om svarene er konkrete:

1. Hvad bliver der taget backup af? Et godt svar nævner database, uploadede filer og konfiguration. "Det tager hostingudbyderen sig af" er ikke et svar.
2. Hvor tit, og hvor længe gemmes kopierne? Fx hver nat, gemt i 30 dage, plus en ugentlig kopi der gemmes i et halvt år.
3. Hvor ligger kopierne? Mindst én skal ligge hos en anden udbyder eller på en anden konto end serveren. Behandler appen persondata, så spørg også om kopien ligger i EU, og om der er en databehandleraftale med lagerudbyderen.
4. Hvornår har du sidst gendannet fra en backup, og hvor lang tid tog det? Det er det vigtigste spørgsmål. Svaret skal være en dato og et tidsrum.
5. Hvem får besked hvis en backup fejler? Backups der stopper i stilhed er et klassisk problem. Der skal være en alarm, og den skal gå til en navngiven person, ligesom resten af din overvågning af webappen.
6. Kan en der har adgang til serveren, også slette backupperne? Svaret bør være nej: separate adgange og gerne en låseperiode.
7. Kunne en anden udvikler gendanne appen hvis du blev syg i morgen? Det kræver at adgange står i virksomhedens navn, og at opskriften findes, præcis som når du skifter udvikler midt i et projekt.

Få svarene på skrift, og læg dem ind i jeres aftale. Backup er et af punkterne i min tjekliste over hvad en serviceaftale med en udvikler skal dække.

Sådan tester du gendannelsen, trin for trin

Var svaret på spørgsmål 4 "aldrig", er det her næste skridt. En prøvegendannelse genskaber appen fra en backup i et separat miljø, mens alt stadig virker:

1. Vælg en backup fra den eksterne kopi. Tag gerne en der er nogle dage gammel, så du også tester at ældre kopier findes.
2. Gendan til et separat miljø, aldrig oven i produktionen. En gendannelse oven i den kørende app kan slette dagens ordrer og nye brugere. Det gælder også i en rigtig krise, hvor det første skridt er at finde ud af hvad der er galt, når din app er nede.
3. Start uret. Mål tiden fra beslutningen om at gendanne til appen kører igen. Det tal er dit reelle bud på nedetid ved et alvorligt nedbrud.
4. Følg opskriften, ikke hukommelsen. Må udvikleren improvisere eller lede efter adgangskoder, er det et fund i sig selv.
5. Tjek at data er hele og nye nok. Log ind som en testbruger, åbn en nylig ordre, hent en uploadet fil, og sammenlign antallet af rækker i de vigtigste tabeller med produktionen.
6. Tjek det der kører i baggrunden. Køer, planlagte opgaver og integrationer skal virke, men uden at nå rigtige kunder.
7. Skriv en kort rapport og ret fejlene. Notér dato, hvilken backup du brugte, tidsforbruget og hvad der manglede. Slet testmiljøet bagefter, fordi det indeholder rigtige persondata.

Min tommelfingerregel er at teste mindst to gange om året for de fleste webapps, hvert kvartal når appen er forretningskritisk, og altid efter store ændringer som skift af hosting, database eller en ny hovedversion af frameworket.

Når backuppen svigter alligevel

Når en backup svigter, er det sjældent teknikken. Oftere har ingen kigget efter. Her er de fejl der går igen:

• Backuppen er stoppet uden at nogen opdagede det, fx på grund af en fuld disk eller en udløbet adgang til lageret.
• Kun databasen er med. De uploadede filer mangler.
• Alle kopier ligger hos samme udbyder eller på samme konto.
• Backuppen er krypteret, men nøglen ligger kun på den server der er væk.
• Kun den udvikler der satte det op, ved hvordan man gendanner.
• Gendannelsen tager længere tid end forretningen kan tåle, og det opdages først under en rigtig krise.

En prøvegendannelse fanger alle seks, og det er hele pointen med at teste.

Backup og GDPR

Behandler appen personoplysninger, er backup og test ikke kun god praksis. GDPR artikel 32 kræver passende sikkerhed og nævner blandt andet evnen til rettidigt at genoprette tilgængeligheden af og adgangen til personoplysninger efter en fysisk eller teknisk hændelse, og en procedure for jævnligt at teste sikkerhedsforanstaltningerne.

Datatilsynets katalog over sikkerhedsforanstaltninger beskriver netop at man bør teste om backup tages som forventet, om data reelt kan genindlæses og bruges, og om det sker hurtigt nok (Datatilsynet om backup). Husk også at backupperne selv indeholder persondata. De skal beskyttes lige så godt som produktionen. Det her er ikke juridisk rådgivning, så tal med en rådgiver hvis du behandler følsomme data.

Næste skridt

Start med spørgsmål 4. Har ingen nogensinde gendannet fra en backup, så planlæg en prøvegendannelse først, og brug derefter tjeklisten til at finde resten af hullerne.

Du har ikke brug for en udvikler til det her, hvis din løsning kører på en standardplatform som Shopify, hvor udbyderen har ansvaret for backup af systemet. Så er din opgave at eksportere dine egne data jævnligt. Har du allerede en driftsleverandør der laver dokumenterede prøvegendannelser, så brug spørgsmålene til at tjekke dem i stedet for at købe det samme to gange.

Vil du have hjælp til at sætte backup op eller teste den, kan du se hvordan jeg arbejder med vedligehold og videreudvikling af webapps. Du får direkte kontakt med den udvikler der laver arbejdet.

Ofte stillede spørgsmål

Er hostingudbyderens backup nok?+

Sjældent alene. Udbyderens backup ligger typisk på samme konto og ofte i samme datacenter som serveren, så den forsvinder hvis kontoen bliver lukket eller hacket. Opbevaringstiden er ofte kort, og mange løsninger kan kun gendanne hele serveren, ikke en enkelt tabel. Brug den som kopi 2, og læg en ekstern kopi ved siden af.

Hvor længe skal jeg gemme backups?+

Længe nok til at fange fejl der opdages sent. CISA anbefaler at du kan rulle mindst syv dage tilbage. En almindelig opsætning er daglige kopier i et par uger kombineret med ugentlige eller månedlige kopier i længere tid. Gem dem ikke længere end nødvendigt, hvis de indeholder persondata. Opbevaringstiden bør passe til dine regler for sletning.

Kan jeg gendanne en enkelt slettet ordre uden at rulle hele appen tilbage?+

Ja, som regel. Udvikleren gendanner backuppen i et separat miljø, finder de rækker der mangler, og kopierer dem tilbage til produktionen. Så mister du ikke det der er sket siden backuppen blev taget. Det kræver lidt håndarbejde, men det er langt sikrere end at gendanne hele databasen oven i den kørende app.

Skal backuppen krypteres?+

Ja, i hvert fald den kopi der ligger uden for din egen server. Den indeholder typisk alt hvad appen ved om dine kunder, og Datatilsynet nævner kryptering før overførsel og opbevaring som et relevant tiltag. Opbevar krypteringsnøglen et andet sted end backuppen og serveren, fx i virksomhedens adgangskodemanager. Ellers kan du ikke åbne den den dag du har brug for den.