6 timer med data tapt for alltid: Gitlab-medarbeider tastet inn feil kommando og slettet 300 gigabyte med data fra serverne

[Kurt Lekanger]

6 timer med data tapt for alltid: Gitlab-medarbeider tastet inn feil kommando og slettet 300 gigabyte med data fra serverne

[myhken]

Han kjørte faktisk rm -rf kommandoen i feil SSH vindu...

[Gjest Slettet-Pqy3rC]

Han kjørte faktisk rm -rf kommandoen i feil SSH vindu...

En smålei "ut-av-kroppen-følelse" griper godt tak ett sted bak i nakken i det øyeblikket en oppdager sånt.

 

Har selv klart å "rydde" feil sted, men i mitt tilfelle var det ikke værre enn at en måtte starte kopieringen på nytt. Det ble bare noen timer ekstra nedetid.

Endret 2. februar 2017 av Slettet-Pqy3rC

[asshole]

Skummelt at man kan slette filer som er i bruk i Linux. I Windows kan man iaf ikke slette databaserfiler hvis SQL serveren kjører.

[myhken]

Rm -rf fikser biffen. Og ja skummel kommando. Windows beskytter os filer bedre der. Men man kan jo med få/en kommando slette hele Windows disker også.

[Gavekort]

Det er fordi det er folk som ikke har lært at det å bruke -f flagget, eller kjøre rm som sudoer ikke er nødvendig. Det at Linux tillater deg å gjøre dette er en styrke, men de tar det for gitt at du bruker fornuft, og ikke bare nuker alt med 'sudo rm -rf ./*'

Endret 2. februar 2017 av Gavekort

[quantum]

Skummelt at man kan slette filer som er i bruk i Linux. I Windows kan man iaf ikke slette databaserfiler hvis SQL serveren kjører.

 

vel, det har nok hendt at folk har sletta feil fil i windows óg. git og sqlserver er to helt forskjellige ting, og du får nok ikke slette låste filer under sybase eller sqlserver på linux heller ...

[quantum]

svært forunderlig hvis disse brukerne ikke har alt de trenger i sitt eget lokale repo ... kanskje ikke alle, men jeg vil jo tro de fleste har mista null og nix ...

[henrikwl]

Det var ikke repoene som ble slettet her, folkens. GitLab er som Github, og har prosjekthåndtering, issues, brukere og diverse. Alt dette her er metadata som ikke har noe med git å gjøre i det hele tatt, og det var slike data som ble slettet.

 

Databasen det var snakk om var PostgreSQL, og jo - rm -rf er nådeløs. Utenfor /dev og /proc tar den rått og råte, uten å still ett eneste spørsmål.

Endret 3. februar 2017 av henrikwl

[Anders Jensen]

uhm streaming replication?

[HawP]

[...] jo - rm -rf er nådeløs. Utenfor /dev og /proc tar den rått og råte, uten å still ett eneste spørsmål.

Og dermed en uting å venne seg til å alltid bruke -f vil jeg si. Bedre da å få varsel om at noe ikke kunne slettes (evt. spørsmål om å slette) og at en da faktisk sjekker at en sletter der en hadde tenkt å slette.

[henrikwl]

Og dermed en uting å venne seg til å alltid bruke -f vil jeg si. Bedre da å få varsel om at noe ikke kunne slettes (evt. spørsmål om å slette) og at en da faktisk sjekker at en sletter der en hadde tenkt å slette.

 

 

Det er helt sant hvis det kun er et fåtall filer man skal slette - i dette tilfellet skulle han bare slette en tom mappe og det beste hadde vært å droppe -f (eller bruke rmdir for å være 100% eksplisitt på hva han drev med). Men i praksis så er det rm -rf som sitter, for i de aller fleste tilfeller skal man slette tmp-mapper eller cache-mapper med flere tusenvis av filer i, og da sitter man selvsagt ikke og bekrefter hver eneste fil man vil slette.

 

Kort fortalt: alle har gjort minst én rm -rf blunder, og kommer til å gjøre flere i løpet av karrieren. Det er bare sånn det er.

[Jan Vidar Krey]

Skummelt at man kan slette filer som er i bruk i Linux. I Windows kan man iaf ikke slette databaserfiler hvis SQL serveren kjører.

 

Hvis filen er i bruk i Unix generelt så forsvinner ikke dataene, kun forbindelsen mellom data og filnavn. Man kan dermed gjenopprette disse filene fra /proc-filsystemet, men dersom serveren eller prosessen stoppes mister man denne muligheten.

[Gavekort]

Linux har også file locking, det er bare det at rm driter i dette om du bruker force-flagget som administrator.

Endret 3. februar 2017 av Gavekort

[quantum]

Det var ikke repoene som ble slettet her, folkens. GitLab er som Github, og har prosjekthåndtering, issues, brukere og diverse. Alt dette her er metadata som ikke har noe med git å gjøre i det hele tatt, og det var slike data som ble slettet.

 

 

Vel, da hjelper lokalt repo null og niks...

[tHz]

svært forunderlig hvis disse brukerne ikke har alt de trenger i sitt eget lokale repo ... kanskje ikke alle, men jeg vil jo tro de fleste har mista null og nix ...

 

Godt poeng. Er vel litt av poenget med git at det ikke er sentralisert.

[quantum]

 

svært forunderlig hvis disse brukerne ikke har alt de trenger i sitt eget lokale repo ... kanskje ikke alle, men jeg vil jo tro de fleste har mista null og nix ...

Godt poeng. Er vel litt av poenget med git at det ikke er sentralisert.

 

 

 

Hm, nja, men det var visst ikke git i seg selv som var problemet, men diverse infrastruktur rundt ... se innlegg over ...

[TheSjark]

svært forunderlig hvis disse brukerne ikke har alt de trenger i sitt eget lokale repo ... kanskje ikke alle, men jeg vil jo tro de fleste har mista null og nix ...

Det var ikke repo's som gikk tapt så vidt jeg vet, kun Merge requests, issues o.l.

 

Repo's vil folk i de aller fleste tilfeller fortsatt ha lokalt i tillegg ja, en av de store fordelene med git.

 

Edit: Så at du selv skrev dette senere ja.

Endret 7. februar 2017 av TheSjark

[quantum]

 

Edit: Så at du selv skrev dette senere ja.

 

 

 

Litt foruroligende at sånt skjer likevel, men det er jo en del former for menneskelige feil det er vanskelig å sikre seg mot ...