Fem backup-systemer svigter efter GitLab.com sletter tonsvis af data ved en fejl

Sysadmin på overarbejde fjernede over 300 gigabyte fra kode-platformen.

Kode-platformen GitLab.com har mistet over 300 gigabyte produktionsdata, efter fem ud af fem backup-løsninger fejlede.

Det skriver The Register.

Tirsdag aften begyndte startup-selskabet at melde om problemer med produktionsdatabasen, efter en træt sysadmin i Holland ved en fejl slettede en mappe på den forkerte server.

Ud af 310 gigabyte produktionsdata var 4,5 tilbage, da han fik annulleret kommandoen.

Læs også: GitHub beklager forløb omkring fjernelse af hacker-liste med danske domæner

Men det var så først her, at de egentlige problemer begyndte for GitLab.com. I et Google Docs-dokument har selskabet delt al arbejdet med at genskabe de tabte data:

‘Ud af fem backup/replication-teknikker implementeret har ingen virket pålideligt eller været sat op ordentligt i første omgang,’ erkender GitLab.

Læs også: Harddiskfejl og manglende backup førte til 17 års tabt læringsmateriale

Selskabet konkluderer blandt andet, at en backup til ‘S3’ var tom, og at den almindelige backup - der kører en gang i døgnet - kun har produceret en fil på nogle få bytes. Oven i hatten har GitLab ikke haft nogle solide notifikationssystemer på plads, der kunne have advaret om, at backup-systemerne fejlede.

Ved et tilfælde blev der dog taget en manuel backup seks timer før, fejlen skete. Den er nu ved at blive genskabt.

Den slettede data tæller ikke de egentlige Git-repositories. Til gengæld er mange issues, kommentarer og brugere tabt.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (7)
Sune Marcher

Fandme ærgerligt for GitLabs (og deres kunder...) - men som Sidsel skriver, hatten af for deres åbenhed.

Og hvad kan vi så lære? Jeg ser umiddelbart to ret vigtige pointer:
1) pas på med at stole for meget på *-as-a-service og ze big magic cloud.
2) du har ikke en backup-strategi, hvis du ikke har verificerede test-restores.

Steen Secher Schmidt

Siden hackere nukede vores online subversion host for 2,5 år siden, har vi selv håndteret vore kritiske services. Det var CodeSpaces, produktionsdata og alle backups på AWS blev slettet af hackere. Hvorfor skulle jeg stole på at nogle tilfældige mennesker er bedre til at passe på mine ting end jeg selv er? Det er nemt at skrive et par rosenrøde sætninger på en hjemmeside, men hvor mange faktachecker rent faktisk deres cloud-leverandør?

Lige nu benytter vi Office365, men det er jeg faktisk heller ikke specielt tryg ved. Microsoft er et lækkert mål for hackere, så risikoen er bestemt til stede. Og typisk for Microsoft, så er det jo ikke ligetil at skaffe sig egne backups af O365 Exchange og Sharepoint data.

Log ind eller Opret konto for at kommentere
Pressemeddelelser

Welcome to the Cloud Integration Enablement Day (Bring your own laptop)

On this track, we will give you the chance to become a "Cloud First" data integration specialist.
15. nov 2017

Silicom i Søborg har fået stærk vind i sejlene…

Silicom Denmark arbejder med cutting-edge teknologier og er helt fremme hvad angår FPGA teknologien, som har eksisteret i over 20 år.
22. sep 2017

Conference: How AI and Machine Learning can accelerate your business growth

Can Artificial Intelligence (AI) and Machine Learning bring actual value to your business? Will it supercharge growth? How do other businesses leverage AI and Machine Learning?
13. sep 2017
Jobfinder Logo
Job fra Jobfinder