Fejl i supercomputers backup-system sletter 77 terabyte forskningsdata

Illustration: Morganka/Bigstock
14 forskningsgrupper data, svarende til 77 terabyte fordelt på 34 millioner filer, er slettet for Kyoto Universitet i Japan efter fejl i backup-system.

77 terabyte forskningsdata er gået tabt for Kyoto Universitet i Japan efter en fejl i dets Hewlett-Packard supercomputer backup-system. De 77 terabyte er fordelt på 34 millioner filer tilhørende 14 forskningsgrupper.

Fire af forskningsgrupperne får ifølge universitetets efterfølgende undersøgelse af hændelsen ikke gendannet deres data.

Det skriver Bleeping Computer.

Kyoto Universitet betragtes som en af Japans vigtigste forskningsinstitutioner og er blandt de bedste i verden inden for forskning i kemi.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (13)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#3 Ditlev Petersen

Er det mon en fejl i selve backup-systemet? Eller en menneskelig fejl i opsætningen? Eller er det brugt til noget, det ikke burde? Jeg mener at huske en historie om et RAID-system, der blev brugt som "backup". Det er ikke nogen strålende ide.

Hvis man nu bruger et system, hvor diske, foldere eller filer skal tilmeldes en backup, så kan man sove meget længe, før man opdager det. Det skulle så imødegås med en periodisk kørsel, der laver en opgørelse over, hvad der ikke er omfattet af backup. Og det skal folk så tage stilling til.

En uddybning ville være rar. Så vi ikke laver samme fejl andre steder.

I øvrigt er computere fantastiske. Tænk på hvor lang tid det ville have taget en hær af ildgerningsmænd at udslette så mange data, hvis der var tale om bøger. Man skal huske, at når noget går galt, så kan det gå meget galt meget hurtigt.

  • 10
  • 0
#4 Nis Schmidt

Kyoto Universitets supercomputer-installation er opbygget i flere omgange, se Bleeping Computer (BC) artiklen.

Som de fleste af nutidens supercomputere kører de muligvis en dialekt af Linux (har ikke tjekket). BC skriver ikke meget om sammenkobling og BU (backup) og HP er nok ikke glade for opmærksomheden.

Der er nok ikke så mange af os, som nogensinde kommer i nærheden af samme kompleksitet. Man kan forestille sig, at en taperobot har taget sig af BU og at den ikke har været vedligeholdt til opgaven.

Læring af denne hændelse er nok begrænset til de involverede. Så vi kan næppe begynde at lege med vores romantiske forestillinger om ITHK (IT-haverikomission) her; selvom her sikkert er flere, der vil/kan "kloge" sig på emnet.

  • 0
  • 0
#5 Brian Vinter

Bemærk at maskinen har 19PB effektiv storage! Data-tab skal naturligvis ikke ske, men backup af 19PB er ikke trivielt og race-conditions kan ske (det lyder til at være tilfældet her).

Da der ikke findes en ældre backup er der tale om nye data og dermed formodeligt resultatet af kørsler der kan laves om. Der ryger noget tid og CO2 men derudover behøver det ikke være så katastrofalt.

Bemærk forøvrigt at Japanerne faktisk er temmeligt aggresive i og med at de lave backup af hele systemet, det er temmeligt normalt at man kun laver backup af bruger-kataloger og det er op til brugerene at sikre at data der ikke trivielt kan genskabes bliver placeret et sted hvor der laves backup.

  • 2
  • 0
#9 Troels Henriksen

Bemærk at maskinen har 19PB effektiv storage! Data-tab skal naturligvis ikke ske, men backup af 19PB er ikke trivielt og race-conditions kan ske (det lyder til at være tilfældet her).

En sjov race condition: Man redigerede i et shell script mens det kørte, og da Unix shells ikke læser scripts ind i hukommelsen før de afvikles, men derimod læser linje-for-linje fra filen, så kan det gå galt. Jeg fatter ikke at shells stadigvæk fungerer sådan, da jeg ikke kan tænke mig at der findes nogen brug af denne "feature" i godhedens tjeneste.

Sådan kan det gå når man ikke trækker backup ud til proper tapes... og/eller ikke bruger en rigtig backup suite og/eller de rigtige specialister.. Tough shit...

Det var backupsystemet der fejlede og slettede kildefilerne. Det er svært at designe sig ud af netop denne fejlkilde (i hvert fald hvis man gerne vil have kildefilerne på et dyrt og meget hurtigt filsystem, så man ikke bare kan gemme alle skrivninger i ubegrænset tid).

  • 2
  • 0
#11 Nis Schmidt

Ja. Det er uheldigt at shell-scripts og native programmer fungerer forskelligt på dette punkt.

Sådan har det været siden unix/msdos blev udviklet (pre 1985). Hvorfor fortaber sig i historien, men at et filnavn og et linjenr fylder mindre i hukommelsen end hele scriptet, det er svært at komme uden om.

Der er mere præstige i at udvikle nyt end i ar vedligeholde legacy, det er langt fra nyt.

At det kan være nyttigt at kunne stoppe en process (script eller image), så man kan ændre i programmet, inden det kører videre, skal man nok have prøvet for at vide.

  • 0
  • 0
#12 Ditlev Petersen

Sådan har det været siden unix/msdos blev udviklet (pre 1985).

Det var så noget helt nyt for mig. Jeg har heller aldrig været i en situation, hvor det kunne have haft nogen betydning. Man kan sikkert argumentere for en ændring af funktionen. Meen - så vil der sikkert være en masse scripts, der pludselig fungerer anderledes.

Jeg kan egentlig ikke huske, at jeg har set problemet omtalt i de (ret få) bøger om UNIX, jeg har læst (jeg arbejder ikke med UNIX-lignende systemer). Er det noget, der udtrykkeligt bliver nævnt, når man lærer om den slags OS'er?

  • 1
  • 0
#13 Troels Henriksen

Jeg kan egentlig ikke huske, at jeg har set problemet omtalt i de (ret få) bøger om UNIX, jeg har læst (jeg arbejder ikke med UNIX-lignende systemer). Er det noget, der udtrykkeligt bliver nævnt, når man lærer om den slags OS'er?

Hvis man skulle nævne alle de tekniske detaljer og faldgruber i standardværktøjerne på Unix, så ville et sådan kursus ikke have tid til så meget andet. Man kan dog godt udlede denne opførsel af følgende principper:

  • Unix låser (næsten) aldrig filer.
  • Hvis en proces har en fildeskriptor svarende til en fil åben, og denne fil ændres, da vil processen se ændringen.

Derfor er det f.eks. potentielt farligt at ændre i kørende binaries og biblioteker, afhængigt af hvordan de har mappet filerne (mmap med MAP_PRIVATE giver desværre ikke garanti for fuld isolation). I stedet for at ændre en fil kan man også slette den og lave en ny med samme navn - det vil ikke påvirke processer der har den gamle fil åben.

Det usædvanlige ved specifikt shell script er at filens indhold bliver ved med at have betydning under hele kørslen. Alle andre fortolkede sprog jeg kan komme i tanke om læser hele filen fra starten af for at konstruere et syntakstræ i hukommelsen. Der findes sikkert undtagelser, men jeg håber jeg aldrig får behov for at lære om dem.

  • 0
  • 0
Log ind eller Opret konto for at kommentere