Langtidsopbevaring af data
Af Christian Stage, Stage One Computing A/S
I har sikkert alle erfaring med opbevaring af store mængder papir: Adgangskontrol, endeløse rækker af mapper opbevaret i massive arkiver under styrede forhold, men har I for alvor overvejet konsekvensen af at gå over til at gemme alle data elektronisk ?
Historisk perspektiv
Under pres fra kong Philip af Frankrig opløste pave Clement de 5 tempelridderordenen. Kong Philip var bange for at tempelridderne havde fået for meget magt, og ville gerne sikre sig at han ikke mistede sin trone. Derfor blev alle tempelriddere arresteret fredag den 13. oktober 1312 (deraf fredag den 13.), hvorefter man torturerede og brændte dem alle.
Nogle år senere sad paven i Rom og tænkte at det måske var lige skrapt nok, så han forfattede en pavelig bulletin, hvoraf det fremgik at tempelridderne ikke var så slemme alligevel.
Dette dokument er forsynet med både signaturer og laksegl, og opfylder faktisk alle de krav vi måtte have indenfor GxP, samtidig med at det kan læses den dag i dag. Det er nok ikke den opbevaringsfaktor vi skal forvente af den dokumentation der kommer ud af det vi producerer, men det giver et vist historisk perspektiv på hvad langtidsopbevaring af data egentlig er. Samtidig er overgangen til elektronisk opbevaring af information stadig i sin spæde start, hvor nye dataformater og metoder konstant kommer til, og ældre formater og metoder forsvinder. Hvem af læserne kan f.eks. læse en 51/4” eller sågar 3½” diskette nu om dage – noget vi havde i tusindevis af for blot 25 år siden?
Tidsperspektiv
I kender allesamen anekdoten med at et menneskeår er 7 hundeår. En del data skal gemmes i (for en computer) rigtigt lang tid. Husk at en computer arbejder i mili- og microsekunder hvor vi andre tænker i sekunder og minutter. En del dokumentation skal gemmes i rigtigt længe i menneskeår, så regnet i computerår er det uoverskueligt længe. Derfor er der behov for at vi nøje overvejer metoder til langtidsopbevaring af data og dokumenter.
”I gamle dage” (1995-ish) var der 3 tekstbehandlingsprogrammer der regerede verden, og vi benyttede alle WordPerfect, DSI tekst eller Microsoft Works (den der kom gratis med DOS/Windows 3.11). Kun WordPerfect og de senere DSI formatterede filer kan stadig åbnes, resten af disse formater kan ikke længere åbnes af kendte applikationer.
Der var også Lotus Notes, der holdt ved rigtigt længe. Lotus Notes var et fantastisk databasebaseret system der gav mulighed for at kombinere tekst, regneark, og data i en pragtfuld og yderst fleksibel blanding, og enkelte installationer kører formodentlig endnu. Til gengæld kan dem der er gået væk fra Lotus Notes have endog rigtigt svært ved at tilgå sine data, da formatet ikke er understøttet af andre produkter.
Brugsperspektiv
Når man gemmmer data skal man huske at de også har en brugsværdi. Jeg er personligt af den holdning at man ALDRIG skal slette data, da de senere kan komme til ny og stor nytte. Det er det man idag på godt Dansk kalder ”big data”, og betyder at man graver nye informationer ud af historiske data.
Desværre ved man aldrig helt præcist på forhånd hvilke data der senere kan have en senere brugsmæssig værdi, og hvilke data der aldrig bliver til nytte. Det vil f.eks. derfor være meget dumt at gemme excelregneark i et ”fladt filformat” (som f.eks. PDF), da data er svært tilgængelige bagefter.
Plads til at opbevare data bliver iøvrigt typisk meget billigere som årene går, og da datamængderne ”i gamle dage” – det vil sige i går for et menneske, og for 86.400.000 milisekunder siden for en computer – altid var minimale, gør det ikke noget at man satser på at opbevare sine data til evig tid, blot for en sikkerheds skyld, hvis de skulle indeholde noget interessant.
GxP perspektiv
I tillæg til de øvrige perspektiver, skal vi jo indenfor den farmaceutiske industri lige huske de forskellige ”dirty words” vi kan: Dataintegritet, ALCOA+ (herunder ikke at forglemme Availability), Audit trail, og så videre. Det betyder at de data og dokumenter vi kan åbne og benytte, også skal være sikret imod utilsigtede og udokumenterede ændringer.
Men hvad så …?
Nu lyder det jo som om ligegyldigt hvad man vælger er det dårligt, men hvis man tænker sig om, planlægger tilstrækkeligt, er omhyggelig og lidt krativ (selvom det sidste typisk straffes hårdt i denne branche), kan man alligevel godt finde løsninger der gør at man kan opbevare sine data ”for evigt”.
Først og fremmest skal man sørge for at gemme sine data on-line, således at de i praksis er tilgængelige for alle brugere der måtte have behov. Dette kan man gøre enten internt eller hos en ekstern leverandør. Her skal man under alle omstændigheder huske at det skal være sikret adgang til den fysiske og logiske del, der skal være periodisk reviewet log på adgange.
Man skal under alle omstændigheder have et datacenter der er sikret fysisk imod alle typer af angreb, naturkatastrofer og uheld, herunder brand, forhøjet vandstand, terrorangreb, hackere, strømafbrydelser o.l.. Adgangen udefra skal være bekyttet af opdaterede firewalls med review’ede firewall regler og køre VPN, HTTPS eller anden krypteret forbindelse. Her skal man bare spørge IT – de kan komme med en laaang liste af ting man skal huske at have styr på.
Hvis det kører hos en ekstern underleverandør skal man have en underskrevet serviceaftale og man skal have auditeret leverandøren (som minimum via et spørgeskema hvor man ikke har givet dem for lang svartid, så de ikke drømmer for mange spændende ting op).
Herefter skal man vælge et praktisk brugbart dataformat – Og hvad er så det ?
Excel f.eks. er vildt praktisk, blot ikke til GxP formål. En database er fantastisk, men hvis man ikke har det der kan hente data ud på en passende vis, har man ingenting. PDF er et såkaldt ”fladt filformat” hvor man ikke har mulighed for at trække data ud på en passende måde, og maskiners og analyseapparaters log-, batch-, etc. -filer er typisk svært tilgængelige når man ikke længere har maskinens logik til at tilgå data o.s.v.
Det er så her man skal opstille sine krav til hvad man forventer af sine dataformater og hvad man forventer af retentionstid hhv. tilgængelighedstid. Hvis man kigger lidt på andre industrier, er der faktisk nogle stykker der i særdeles høj grad tager stilling til langtidsholdbarhed af data. I Danmark har vi f.eks. statens arkiver der har digitaliseret rigtigt meget, og satser på langtidsholdbarhed generationer frem. Vi har desuden et datahistorisk museum hvor de er begyndt at lure problematikkerne ved gamle data og gamle datasystemer.
Hvis vi kigger udenfor landets grænser er NASA et af de steder hvor man både teoretisk og i praksis har beskæftiget sig med langtidsholdbarhed af data. Man sender f.eks. en mængde digitaliseret information om jorden med de satelitter der sendes på safari ud i universet, og man har fra NASA’s side sat forventningen til levetid på mindst 1 million år på de data man sender ud, samtidig med man ikke har store forventninger til niveauet af intelligens hos den eventuelle modtager. Derfor har man været særdeles nøjeregnende med både lagringsmedier og dataformater.
Hvis jeg skal komme med et bud på brugbare filformater (og uden at kende den specifikke løsning det skal bruges i forbindelse med) ville jeg kigge på nogle af de mange PDF formater. PDF findes i det klassiske format, der er et mix af tilgængelighed, sikkerhed, og operativitet, men der findes også til brug for en mængde andre formål, herunder et format jeg særdeles godt kan lide, nemlig PDF/A.
PDF/A understøtter ikke at man har eksekverbar kode i sine dokumenter, men til gengæld indeholder det en række fonte der – hvis man har overvejet brugen af fonte i sine dokumenter på forhånd – giver visning der er identisk til den oprindelige. Man kan ikke passwordbeskytte data i dokumenterne, så alle og enhver kan læse dem eller klippe dem ud, og hvis man har været specifik om metoden til at generere sine PDF/A filer kan man også være heldig at klistre indholdet ind et andet sted. Man kan til gengæld ikke uopdaget ændre indholdet i et PDF dokument.
PDF/A’s store es i ærmet er muligheden for at inkludere, eller vedhæfte, andre dokumenter. Disse dokumenter kunne være råformater af indholdet der har skabt indholdet i dokumentet. Det betyder naturligvis stadig man er nødsaget til at understøtte råformatet, men man kan som udgangspunkt dokumentere at man kan få fat på det i med et uforfalsket og uændret indhold indtil det tages ud af PDF/A filen. PDF/A er i øvrigt en ISO standard, og Adobe ”garanterer” 30 års læsbarhed af PDF/A formatterede filer.
En anden mulighed er på valideret vis at lægge data over i en historisk database man selv har ejerskab af, eller som minimum, kontrol over. På denne måde er man selv ansvarlig for at kunne tolke data, og derfor uafhængig af andre, og kan således selv vedligeholde sine udtræk og datarelationer. Det kræver naturligvis arbejde, men kan være ganske givtigt over tid, da det også vil være her man kan lave sine big data udtræk.
Det kan også være en mulighed at gå efter nogle af de mest simple og oprindelige dataformater. Kommaseparerede tekstfiler er super simple og alment brugbare med et minimum af instruktion. Den moderne version af dette kunne være XML der i princippet kan fungere lidt som en flad tekstfil og som en database på én gang. Alle de nye versioner af Excel og Word er XML baserede (man kan selv teste det ved at tage sin Excel.xlsx fil og omdøbe til Excel.xml og åbne den med noget der kan læse XML filer).
Der vil naturligvis være situationer hvor andre dataformater giver bedre mening end det ovenstående og det vil være en vurdering fra system til system hvad der giver bedst mening, men man skal under alle omstændigheder benytte sin sunde fornuft.
Er man så i mål ?
Så tænker mange ”job done”, men realiteten er at det først er nu man kan begynde det lange og vedholdende arbejde med at vedligeholde sine data. Det er en fordel hvis man er gået efter en begrænset mængde af – helst standardiserede – dataformater. Alle benyttede dataformater skal registreres, og man skal i en 1-2 årlig cyklus reviewe de benyttede dataformaters egnethed til deres formål, og nøje vurdere den fortsatte egnethed i mindst 2 eller 3 reviewperioder frem. Man skal f.eks. se på hvis Officepakken kommer i nye versioner, om de vælger at ændre på deres dataformater, og vurdere om man skal konvertere de gamle gemte formater til de nye (f.eks. .doc til .docx).
Grunden til behovet for denne vurdering er at man på det tidspunkt en teknologi eller et dataformat ikke længere har en lang fremtid foran sig, har man tilstrækkeligt med tid til at finde en løsning, foretage migrering, og validere at den dataoverførsel man foretager er i orden.
Konklusion
Sæt et mål for hvor længe man vil bibeholde sine data i et operativt format, og vær ambitiøs.
Husk at dataformater er forgængelige, og sørg altid for at tænke exitstrategi når man overlader data eller dokumenter til et system – Især hvis det er cloudbaseret, da cloudydelsen kan forsvinde pludseligt.
Vælg dataformater omhyggeligt, og vurdér løbende deres egnethed. Sørg for at migrere eller opdatere data i god tid inden teknologien man benytter udgår.
Hav altid data tilgængelige og i et operativt format. Forsøg at undgå proprietære formater, og vælg i stedet formelt standardiserede formater hvis det på nogen måde er muligt.
