Ups - Dropbox-uheld slettede 8.000 billeder efter softwarefejl

16 kommentarer.  Hop til debatten
Brug ikke Dropbox til backup, lyder advarslen fra tjekkisk udvikler. Han fik uigenkaldeligt slettet hele sit billedarkiv ved et uheld, fordi Dropbox-softwaren gik i baglås.
31. juli 2014 kl. 10:35
errorÆldre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Dropbox er en nem og bekvem løsning til backup i skyen – men det er bestemt ikke klogt at satse på det som eneste backup.

Det har den tjekkiske udvikler og ph.d.-studerende Jan Curn måttet lære på den hårde måde, efter at han ved en fejl fik slettet stort set hele sit billedarkiv fra de sidste 11 år uden at have andre kopier af de uvurderlige fotos. Han har beskrevet hele forløbet i en artikel, som skal gøre andre opmærksomme på problemet – og måske hjælpe ham til at få billederne genskabt hos Dropbox, selvom firmaet har meldt ud, at der ikke er noget at gøre.

Jan Curn havde valgt at bruge Dropbox som eneste lagersted for sit billedarkiv og betalte også for ekstra plads hos Dropbox, men løb ind i pladsproblemer på sin bærbare computer. Derfor tog han funktionen Selective Sync i brug, hvor man kan fjerne filer fra en af sine computere, men beholde dem i Dropbox’ sky og på de øvrige maskiner.

I første omgang bad Jan Curn Dropbox om at fjerne alle billederne fra den bærbare computers Dropbox-mappe, men Dropbox-klienten frøs og svarede ikke i flere minutter. Derfor lukkede den tjekkiske udvikler processen for at prøve igen, hvor han så tog ét år ad gangen for ikke at ’overbelaste’ Dropbox-softwaren.

Artiklen fortsætter efter annoncen

Det så ud til at virke fint, så det var først to måneder senere, i slutningen af juni, at Jan Curn opdagede katastrofen: Alle mapper var stadig i hans Dropbox, men næsten alle billeder var væk. I alt var der slettet 8.343 filer i én omgang. Og den indbyggede gendannelsesfunktion hos Dropbox virker kun i en måned efter sletning. Henvendelser til kundeservice hos Dropbox hjalp heller ikke – der er ikke noget at gøre, når de 30 dage er gået, lød svaret.

Problemet, som førte til sletningen af billederne, er ifølge Jan Curn den måde, Dropbox har indrettet softwaren på. Da han bad om at få fjernet billederne fra sin bærbare computer, blev billederne slettet fra Dropbox-mappen på maskinen, hvorefter Dropbox-serveren får besked om, at den kun er en lokal sletning, som ikke skal spejles på Dropbox-serveren.

Men fordi softwaren frøs, og Jan Curn lukkede processen ned, blev den besked aldrig givet videre. Da Dropbox-softwaren kørte igen, blev sletningen af billederne derfor spejlet i resten af Jan Curns Dropbox-placeringer og centralt på serveren.

Moralen til andre Dropbox-brugere er – hvis man bruger tjenesten til vigtige filer – at tjekke event-loggen, hver gang man har lavet større ændringer, for at sikre, at der ikke blev slettet noget utilsigtet. Og opfordringen til Dropbox lyder, at softwaren må kunne skrues sammen, så en dårlig dag for Dropbox-klienten ikke kan føre til den slags uventede konsekvenser, skriver Jan Curn.

16 kommentarer.  Hop til debatten
Debatten
Log ind for at deltage i debatten.
settingsDebatindstillinger
15
2. august 2014 kl. 14:10

Dropbox er ikke til backup! Dropbox er til synkronisering!

Hovedproblemet i denne episode er ikke dropbox, men at personen har håndteret sine vigtige data på en meget dårlig og uforsigtig måde.

14
31. juli 2014 kl. 15:09

Når jeg læser sådan en historie, så har jeg svært ved at have ondt af personen.

  1. Når han laver sådan en operation, bør at kontrollere at tingene er som forventet efterfølgende. Så ville han have opdaget misæren i tide og kunnet reddet sine billeder. Det gælder sådan set for alt backup, at man ikke skal tro, men kontrollere at den ok.

  2. hvis man ikke mener 30dage er tilstrækkelig fortrydelses periode, så må man til lommerne og betale sig fra det: https://www.dropbox.com/business/pricing. Om dropbox så stadig er den bedste løsning, skal jeg ikke forholde mig til.

16
5. august 2014 kl. 15:17

Når jeg læser sådan en historie, så har jeg svært ved at have ondt af personen.

Delvist enig.

Som udgangspunkt vil jeg mene man burde kunne forvente at software gør som beskrevet - han havde jo trods alt aktivt valgt "selective sync". Det er pænt dårligt design at denne option ikke slår igennem, fordi processen bliver terminated undervejs.

Til gengæld vil jeg betegne det som rettidig omhu at man liiiiige undersøger om ting er forløbet som planlagt, hvis man har force-terminated en proces hvor man er i gang med at slette flere tusinde filer.

8
31. juli 2014 kl. 13:17

Igen et godt eksempel på at Cloud ikke er modent til seriøs anvendelse.

9
31. juli 2014 kl. 13:25

Ved ikke om jeg vil sige, det er helt fair at sammenligne ting som Amazon Cloud og en mindre leverandør som Dropbox.

13
31. juli 2014 kl. 14:52

Ja, men der er jo forskel på hvordan man arbejder med data. Mener blot, at datatab ved et "uheld" er mindre sandsynligt ved en amazon cloud opsætning, end så mange andre steder. Her er der nok bare mere tale om, at Dropbox har et andet brugsbehov og derfor sletter filer efter 30 dage. Synes bare det er forkert at afskrive alt hvad der hedder cloud, bare fordi Dropbox bruger en cloud backend. :)

NU begynder jeg jo at lyde som en cloud forkæmper, hvilket jeg absolut ikke er, ville bare lige uddybe! :)

5
31. juli 2014 kl. 11:35

Underrubrikken er forkert, for han havde ingen backup. Han havde et synkroniseringssystem kørende. Når han så - ved skal vi kalde det ulykkelig brug af synkroniseringsmekanismen - sletter fra en enhed, vil sletningen synkroniseres til de øvrige.

4
31. juli 2014 kl. 11:34

Problemet er at "almindelige mennesker" ikke er klar over at lagermedier, sky eller ej, kan gå i stykker. Og dét kan kun gentages for sjældent. Definitionen af "almindelig" må så bero på en lokal vurdering, for selv blandt mine egne kollegaer synes jeg der er mange med en lidt vel optimistisk tro på systemernes ufejlbarlighed.

2
31. juli 2014 kl. 10:49

Enhver kopi af data kan forsvinde når som helst. Derfor skal man have flere kopier. At tro 100% på en tjeneste som DropBox er naivt.

En harddisk kan gå i stykker. Det kan to diske i det samme dyre enterprise RAID også - har set det ske inden for samme time. Tyveri, brand, vandskade tager nemt livet af skuffen med brændte DVDer, mens online backup- og storagevirksomheder af og til går konkurs, lukker eller mister data.

Når man nu har mistet en kopi, er det godt at man havde en anden, men éns kopi nr. 2 kan forsvinde inden man kan lave en ny (fx downloade sine data eller køben en ny harddisk). Indtil man får lavet sin nye kopi nr. 2, skal der kun ét uheld til for at éns data er væk. Så hav gerne flere kopier.

Hvis éns private data er vigtige, synes jeg ikke man er paranoid hvis man har RAID (fx i en NAS) derhjemme og online backup. Eller af og til lægger en brændt DVD i en skuffe på jobbet eller hos forældrene.

Men kopier dog de billeder fra telefonen og kameraet ned på en computer og hav flere kopier på flere lokationer. Ellers forsvinder de.

1
31. juli 2014 kl. 10:44

Aldrig have "backup" ét enkelt sted, fordi så er det ikke længere en backup. Især når man så prøver at være "kreativ" samtidigt, som her.

8000 billeder? Selv hvis de fylder 50 megabyte hver, så kunne de snildt have ligget på en 500GB harddisk, og de kan jo fåes for tæt ved ingen penge. Men det har han nok lært til en anden gang.

Moralen af historien? Pessimistiske backups. Hav kopier i Dropbox, på din computer, på en harddisk, på en USB, på din gamle mobil, under dine forældres seng, og nedridset med blod i gulvbrædderne under tæppet i stuen.

11
31. juli 2014 kl. 13:59

Man kan købe sig til en Dropbox feature, der giver mulighed for at genskabe filer.

Packrat is a feature that gives you unlimited deletion recovery and version history.
Activate ($39.00 / year)

12
31. juli 2014 kl. 14:37

Man kunne også bare bruge Dropbox til synkronisering, og f.eks. Crashplan til backup :)

3
31. juli 2014 kl. 11:14

Helt enig Henrik, men jeg har endnu ikke benyttet mig af blod-backup, kan du sende mig nogen links til hvordan man gør dét? Jeg tænker vi må arbejde med binær kode på nano-niveau for at klare dét. ;)

6
31. juli 2014 kl. 11:52

Der var jo ingen der sagde hvor meget data vi skulle foretage blod-backup af. Min SRP i 3.g på STX blev i hvert fald nedskrevet med megen lille skrift på denne måde!