Af Christian Stage, Stage One Computing A/S

Myndighederne har de seneste år strammet grebet i forhold til backup og restore. I praksis har de kun indført samme type krav som enhver seriøs industrivirksomhed har benyttet de seneste årtier, men de må have ment (eller observeret) at der ikke nødvendigvis er ret meget styr på det i de farmaceutiske virksomheder.

Backup og restore er tæt knyttet til emnet dataintegritet, og eftersom dataintegritet har været ret højt på dagsordenen på det seneste, giver det også meget god mening at man fokuserer på backup og restore. En anden stor ændring er den mere udbredte brug af Cloud -ydelser inden for den farmaceutiske industri. Cloud er blevet massivt udbredt, men brugen af Cloud-ydelser gør backup og restore-billedet mere broget. Da det kan være svært at styre leverandørens virkelige indsats, især hvis det er en Cloud-leverandør af serveren, en anden leverandør af operativsystemet, en tredje leverandør af applikationen man bruger, en fjerde leverandør af backup-ydelsen, og måske en femte Cloud-leverandør af infrastrukturen.

Bemærk at dette kun er en hurtig og overfladisk indføring i backup og restore. Opgaven kræver i praksis kun begrænset IT-viden, men involverer mange beslutninger som er særdeles relevante for QA.

4 vigtige ingredienser

Der er 4 hovedingredienser indenfor emnet backup og restore, som man skal have styr på:

Backup er en valideret kopi af en fil eller data der kan benyttes til at genskabe en original ud fra, hvis originalen er gået tabt eller beskadiget. Kodeordet her er ”kopi”, men det vender vi tilbage til. Kopien er naturligvis verificeret, skabt og overført til sin destination på en valideret måde.

Restore er den handling, hvorved man på en valideret måde reetablerer sine originale data ud fra den kopi man har skabt ved backup. I farmaceutisk regi er det naturligvis ”den godkendte og verificerede handling, hvorved…”, idet en restore-handling skal godkendes af et passende ledelsesniveau.

Disaster Recovery er de procedurer der beskriver, hvorledes man skal komme tilbage til driftstatus (og i farmaceutisk regi er det naturligvis tilbage til den tidligere validerede tilstand). I praksis er det beskrivelser af de handlinger, hvorved man kan opnå sin restore, så vi ville normalt kalde det for vores ”restore-procedure”.

Business Continuity Plan er et dokument der beskriver, hvorledes man fortsætter med at håndtere sin produktion og de data man skaber, medens man reetablerer sine systemer. Business Continuity Plan er stedet, hvor de kreative medarbejdere kan udfolde sig for alvor: Hvis f.eks. man har lavet sine logbøger elektroniske, og datasystemet der håndterer logbøger er nede, skal man tænke dette ind i sin Business Continuity Plan, da restore bl.a. vil kræve at man skriver i logbøger.

I Business Continuity Planen tager man desuden stilling til, hvorledes man håndterer nedbrud der går ud over den, via risikovurderingen, forudsete tid (se RTO nedenfor). Det er her man beskriver, hvordan man iværksætter yderligere tiltag efter 4 timer, efter et døgn, efter en uge og efter en måned. Det er her man beskriver at når logbogs-applikationen er nede, skriver man en logbog i Word, får den samlet og godkendt af QA og begynder at bruge den, fordi alt andet er glippet.

RPO og RTO

Der er 2 andre vigtige begreber indenfor backup og restore der er væsentlige at få styr på. Disse er defineret af NIST SP 800-34 Rev. 1 (NIST = National Institute of Standards and Technology som er den amerikanske pendant til ISO. NIST er the go to place for ultimativ IT-compliance):

RPO [Recovery Point Objective] er det sidste tidspunkt, hvortil man kan reetablere data efter et nedbrud.

RTO [Recovery Time Objective] er det tidsrum et IT-system kan være nede før organisationen/produktionen er negativt påvirket af nedbruddet.

RPO og RTO er vigtige fordi de er indikatorer for, hvad man skal tage stilling til i sine procedurer og i sin Business Continuity Plan.

Backup-elementer

Hardware
Hvor hardware var en af de elementer man altid kiggede på ”i gamle dage”, er hardware i dag ikke i samme grad en væsentlig fejlfaktor i et system. Mange servere er blevet virtualiseret og kører på det der kaldes fail safe eller high availability clustre, der i praksis er en række maskiner, der arbejder sammen i et netværk for at udgøre en mængde datakraft som flere virtuelle maskiner kan køre på samtidig. I praksis betyder det at næsten enhver 12-årig skoleelev ville kunne skrive sig ud af hardware som en risikofaktor i en risikovurdering. Det er også fint nok fordi hardwaren sjældent giver problemer, men hvis den først holder op med at fungere bliver problemet massivt, og det kan i praksis være endog særdeles svært at komme op og køre igen, fordi mange interessenter er involveret i at reetablere basis for de systemer der skal køre. Man skal også tænke på at noget så simpelt som en netværksswitch er gået fra at være lagervare for et år siden, til typisk at være bestillingsvare med 14-18 måneders ledetid nu. Det er lang tid at være nede, hvis det er en kritisk komponent.

Aktion Gå derfor systemer og komponenter kritisk igennem og undersøge, hvad man kan få stumper til og hvad man kan finde alternativer til. Vurdér om hardware er en Cloud-komponent, og sørg for at sikre at der er en god og valideret serviceaftale der beskriver håndtering af nedbrud.

Automatiksystemer
Automatiksystemerne er i reglen ret stabile. Jeg var for nylig med til udskiftning af et automatiksystem der havde kørt drift siden 1952. Dermed ikke sagt at de ikke kan gå ned eller gå i stykker, og i disse tider med Corona-nedlukninger og krig kan det være endog særdeles svært at få erstatningsprodukter. Mange af de store leverandører af automatikkomponenter får produceret i Kina, og (baseret på egne erfaringer) kan f.eks. IO-moduler være helt umulige at få fat i. – Jeg var nødsaget til at ty til Ebay for nyligt for at få fat i et almindeligt 5.000 kroners IO-modul som jeg måtte slippe 62.000 kr. for, brugt!! Hele øvelsen tog næste 2 måneder, og det var ikke et modul man umiddelbart kunne erstatte med et alternativt modul eller produkt. Hvis det er en PLC (Programmable Logic Controller) der går ned, kræver det desuden at man har et software-værktøj i den rette version til at man kan restore systemet. Disse værktøjer kan typisk kun betjenes af specialister (nogle gange kun fra leverandøren), så man skal sikre sig at disse specialister findes, at man kan få fat på dem, samt finde ud af, hvor lang tid det tager for specialisten at komme til udstyret. Man skal desuden vurdere hvad impact rejserestriktioner eller lignende kan have, samt hvilke alternativer man kan benytte (Teams, Teamviewer, Netop og lignende) til at omgå eventuelle rejserestriktioner.

Aktion Gå systemer og komponenter kritisk igennem og se hvad man kan få stumper til, og hvad man kan finde alternativer til. Sørg for at definere metoder til fjernadgang, og sørg for at teste at de fungerer til formålet (også når systemer er nede).

Software
Software er her tænkt i bredeste forstand, lige fra det simple out-of-the-box program man afvikler på en PC til de mest komplicerede eller komplekse virksomhedssystemer (MIS, MES, LIMS, Finance og hvad alle de forkortelser man kan tænke på der ellers er). Software i sig selv er sjældent noget der giver den store anledning til bekymring rent driftsmæssigt, men restore kan blive besværliggjort af at versioner ikke forbliver tilgængelige, eftersom leverandører ønsker at pushe en over på de nyeste eller mest fejlrettede versioner. Det giver en risiko for påvirkning af den validerede tilstand.

Aktion Sørg derfor for at sikre at software er tilgængelig i den rette version på egne datamedier.

Applikationer
En applikation er det software man benytter, som er tilrettet specielt til virksomheden og dedikeret et bestemt stykke udstyr eller funktion. Hvis man er dygtig til at have konfigurationsstyring på sine applikationer, giver selve applikationen sjældent udfordringer.

Aktion Hav konfigurationen i kontrol, og sørg for at sikre at al applikation relateret til alle kritiske systemer er sikret i tilgængelige backups.

Infrastruktur
Mange systemer trækker på virksomhedens infrastruktur til at udføre handlinger eller levere data. Det gælder f.eks. brugerdatabasen (f.eks. Windows Active Directory) der styrer adgange til systemer, regler (såkaldte ”policies”) for IT systemers funktion, logiske netværk der ligger ovenpå det fysiske netværk og begrænser adgang mellem systemer eller firewalls og switches der styrer, hvilke systemer der kan tale med hinanden. Hvis ikke virksomhedens infrastruktur fungerer som de systemer, der benytter funktionerne, forventer og er valideret til, har systemerne måske ikke den validerede virkemåde, og virksomhedens infrastruktur udgør derfor en væsentlig del af den validerede tilstand for ethvert system der er tilkoblet virksomheden.

Aktion Sørg for at kontrollere at de funktioner, man benytter i netværket, er validerede, og at den validerede tilstand for de pågældende systemer kan reetableres efter et nedbrud. Hvis det f.eks. er Active Directory der er nede, vil al login være påvirket, og man skal nøje vurdere, hvordan man håndterer dette i sin Business Continuity Plan.

Cloud
Når det kommer til leverancer der stammer fra eksterne leverandører, der kører i Cloud-leverandørens faciliteter, er man naturligvis nødsaget til at stole på at de kan levere en fornuftig reetablering af et system der er gået ned. Denne trust SKAL være baseret på en serviceaftale (Service Level Agreement eller SLA). Serviceaftalen skal være detaljeret og indeholde både kontakttelefonnumre, tidsrum, backupintervaller, tider for restore, referencer til procedurer, godkendelsesworkflow osv., og man er nødsaget til at kontrollere at det holder. Overvej nøje hvilken leverandør man har med at gøre. Store firmaer (Microsoft, Amazon o.l.) kan være særdeles svære at arbejde med, hvis man er et lille medicinalfirma der kun omsætter nogle hundrede milliarder, og kun lægger nogle få millioner i en hosted ydelse hos det pågældende firma. Store firmaer har desuden særdeles gode advokater, og det bærer deres ansvarsfraskrivelseserklæringer i servicekontrakterne typisk også præg af. Vælg derfor altid nogen I kan stole på, og nogen der er fleksible nok til at man kan afprøve gyldigheden af servicekontrakten hos.

Aktion Vurdér leverandørens fleksibilitet og vurdér din egen virksomheds størrelse som kunde hos den pågældende virksomhed. Man har mere indflydelse, hvis man er en stor kunde hos en mindre virksomhed, end hvis man er en ubetydelig kunde hos en stor virksomhed. Kontakt straks leverandøren for at teste om det aftalte holder i praksis. Bed dem om at demonstrere en disaster recovery, evt. via en uanmeldt øvelse, som man kan sørge for at skrive ind i sin servicekontrakt.

OK – hvad går det så ud på?

Hele øvelsen går ud på at finde sandsynlige nedbrudsscenarier, og gøre det muligt at afhjælpe dem FØR de opstår. Det betyder at man skal have en realistisk mængde af hardware på lager (cold stand by), og man skal jævnligt verificere at det virker.

Man skal vide, hvor installationspakker til software ligger, at man kan få fat i dem, og at de fungerer. Man skal have styr på de metoder, der skal til for at få software til at fungere og de serienumre/optionskoder/aktiveringskoder/certifikater man skal bruge eller metoden til at få fat i dem. (Nogen gange skal man ringe til en leverandør for at få nyskabt en kode, da koder kan være afhængige af den fysiske hardware).

Man skal desuden vide hvor, hvordan og hvornår man kan få fat på de folk der faktisk kan gøre noget ved situationen.

Det er nødvendigt at have planlagt, hvilke valideringsscenarier man skal igennem for at opnå en realistisk valideret driftstatus, og man skal ikke satse på blot at genudføre sin oprindelige validering, da dette vil tage urealistisk lang tid.

Alt dette skal beskrives i Disaster Recovery Planen og til en hvis grad tages stilling til i Business Continuity Planen.

Test
Restore-procedurer skal valideres (myndighedskrav), så det er væsentligt at teste at man faktisk kan reetablere et system i praksis.

Nu er øvelsen med at destruere et velfungerende valideret system ikke ret rar så man skal nøje gennemtænke, hvordan man tester. Det er en god idé at teste på en ekstra harddisk eller lignende, således at man er sikker på at man kan komme tilbage til driftstand.

Man kan med fordel teste sin restore som en del af sit interne IT-beredskab via øvelser der udføres uden for megen forberedelse. Man bør tage tid på, hvor lang tid det tager at reetablere et system, således at man kan revurdere om ens RTO er realistisk. Restore skal være valideret, dvs. der skal foreligge dokumentation for at restore faktisk er testet samt, hvad resultatet var. Det er en god idé at lade restore-test indgå som en del af det cykliske vedligehold af systemer lidt afhængigt af metoden der benyttes.

Beregning af RPO og RTO

RPO er det tidspunkt, hvortil man kan reetablere sine data. Et eksempel:
Hvis man har en maskine der kører produktion og kontinuerligt logger data der skal ende i en batchrapport der benyttes som grundlag for release af produktet, vil man gerne have mindst muligt datatab. Hvis vi for sjov sætter et acceptabelt datatab til 4 timer, hvad betyder det så?

For maskinen betyder det at data skal kunne nedbrydes i mindre grupper der skal kunne benyttes til reetableringen. Hvis man har en maskine der selv genererer en batchrapport, vil den typisk ikke være ret glad for at generere en rapport med manglende data. Man skal derfor sikre sig at maskinen kan lave en delrapport for et brugerdefineret tidsrum (fra batch start og frem til det tidspunkt, hvor man ikke længere har data). Hvis maskinen logger sine data i en database og logning pludselig afbrydes til databasen, vil datagrundlaget være ufuldstændigt og etablering af en batchrapport vil være svær at etablere.

Så kan man bryde sine batches op i mindre batches, men det påvirker typisk produktiviteten massivt på grund af batch change over, line clearance og lign.

Hvis backupdata overføres fra maskinen til et filshare, skal man være opmærksom på at backup af filshares ofte sker en gang i døgnet: et nedbrud der både rammer en maskine og et filshare vil derfor betyde væsentligt for det tidspunkt, hvortil man skal reetablere sine data. Hvis backuppen af filsharet er 2 timer og data på maskinen kan nedbrydes til 2 timers blokke der overføres til filsharet, kan man lige med nød og næppe overholde sine ønskede 4 timer. Med mindre der er andre faktorer der påvirker muligheden for restore, således at de tider man sætter, skal tænkes endnu nøjere igennem.

RTO er den tid man kan tåle at være foruden sit system og sine data. Dette tidsrum vil være meget forskelligt fra system til system. Tiden tæller fra RPO tidspunktet (som i eksemplet lige ovenfor var 4 timer) som skal lægges oveni den tid det tager at reetablere et system.

Tiden for reetablering indbefatter den tid det tager at erkende at man har et problem, den tid det tager at finde nogen der kan gøre noget ved det, den tid det tager at få fat i data der skal restores, de godkendelser det indbefatter samt den tid det tager at udføre den reelle reetablering. Man skal desuden huske at det skal være validerede dataoverførsler, og at test af at systemet virker som før nedbruddet, indbefatter en mængde dokumentation o.l., hvorfor en restore af et system til den validerede tilstand kan tage en rum tid.

Det er derfor altid en god idé at regne med at restore kan tage fra ”meget for længe” til at systemet i praksis ikke er muligt at reetablere. Amazon der er verdens største leverandør af hosting af rå diskplads havde for år tilbage et nedbrud

af nogle IT-systemer, og det lykkedes aldrig at genskabe alle de data man havde. Amazon er et stort firma med data som speciale og mange systemfolk til at vedligeholde systemerne. Mange medicinalvirksomheder er gode til at lave medicin, men systemadministration er ikke lige hovedbeskæftigelsen, og det skal man også tage med i sine overvejelser. RPO og RTO er noget myndighederne kan finde på at spørge til, og de kan bede om at se beregningerne for udstyr eller systemer.

Man skal nøje overveje, hvordan man håndterer sine systemer og det er en fordel altid at have et ”tomt” system, således at man fører sine data væk fra produktionssystemer og hen i andre og mere egnede systemer. Derved vil restore scenariet for mange systemer kunne reduceres til restore af et tomt system, hvor man kun skal restore data fra seneste igangværende batch. Hvis man har mulighed for at skabe sine rapporter offline frem for at skulle producere dem på det udstyr der har skabt data, har man dermed også typisk flyttet sine problemer over i et mere kontrolleret og mere højniveausystem end hvis data partout skal behandles på et produktionssystem.

Det med ”kopi”
Den lille ting med ”kopi” som jeg nævnte i starten er faktisk en del af en vigtig pointe. Ofte skaber vi data i en maskine – måske i en database. Så tager vi en kopi til vores GxP filshare, og en backup til vores backup-share. Fra filsharet tager vi en delmængde af data til vores LIMS-system og lidt til vores MES-system. Vi tager desuden nogle data til vores effektivitetsmålingssystem og lidt til vedligehold.

Vi har nu 6 kopier af data.

Døgnet efter tager vi en ny kopi af databasen fordi vi ikke ved, hvad der er de gamle data og hvad der er de nye. Data distribueres herefter på samme vis som før.

Efter et år har vi nu 6 x 365 (altså knap 2.200) kopier af data.

Myndighederne har en forventning om at man kan pege på, hvor ens originale data befinder sig.

I det ovenstående eksempel kan det være svært præcist at definere, hvad der er originalen og hvad der er en kopi, samtidig med at kravet om validering af dataoverførslerne øger mængden og kompleksiteten af dokumentation betragteligt.

Man skal derfor sikre sig at man overfører data fra maskinen til sit GxP filshare frem for at kopiere. Overføre betyder i denne sammenhæng slette originalen når man har kopieret den et andet sted hen. Efter overførslen skal man verificere/dokumentere at kopien er identisk med originalen, og først herefter kan den gamle original slettes. Nu har man en ny original.

Arbejder man i en database skal man tømme de gamle data ud af databasen før næste batch. Betragt det som en slags IT Line Clearance, så giver det pludselig mening.

Konklusion
Backup og restore er stadig aktuelt – måske mere nu end tidligere. Data spiller en større og større rolle i produktionen og udgør en væsentlig del af det produkt, man leverer. Selv en kort ”glitch” i datastrømmen kan betyde tab af en hel batch og dermed kæmpe omkostninger. Manglende data kan desuden udgøre et stort problem ift. dataintegritet, og samtidig er data spredt mere rundt end tidligere og håndteres af flere firmaer eller individer end dengang vi selv ”hostede” vores egne servere.

Backup og restore scenarier er dynamiske og påvirkes af teknologiske ændringer, adgang til ressourcer og mennesker, samt de restriktioner samfundet eventuelt måtte finde på at påføre os. Det betyder at man som virksomhed er forpligtiget til kontinuerligt at vurdere om de procedurer og planer man har er dækkende og realistiske for den aktuelle situation.

Man bør basere sin backup og restore på risikovurderinger der omfatter alle aspekter af backup og restore.

Og så lige et sidste ”word of advice”: Husk at sikre at jeres backup tager højde for et ransomware angreb. En stor tysk maskinleverandør som jeg arbejder sammen med var nede i 4 måneder for nylig. Når jeg siger ”nede” er det i denne sammenhæng: Ingen adgang til logistik og lager, ingen adgang til telefoni, ingen adgang til produktionsdata,

produktionsplaner, tegninger o.l., ingen adgang til løn- og personaledata. De overlevede heldigvis, men tænk lige over om din virksomhed kan håndtere den type datanedbrud. Jeg ved at den pågældende virksomhed efterfølgende har strammet deres Business Continuity Plan noget op i forhold til tidligere.

Backup og restore er potentielt et spørgsmål om virksomhedens overlevelse, og måske i praksis i væsentligt højere grad end mange af de andre udfordringer, vi har i hverdagen. Det er derfor ikke bare noget man skal affeje som værende noget teoretisk pladder, men noget der både er konkret, håndgribeligt og testbart.

Afslutningsvis kommer her dagens tip: Ryd op i data, og sørg for kun at have et datasæt!