Salesforce-kunder ser ud til at måtte vinke farvel til alle data, der skulle gemt i deres system tirsdag formiddag, efter en del af Salesforces sky blev ramt af et nedbrud, som fortsat plager cloudtjenesten. Det skriver The Register.
Den gode nyhed for Salesforce-kunder er, at det kun er en del af skyen og dermed et begrænset antal kunder der er ramt. Men den seneste melding er altså, at der er et vindue, hvor data ser ud til ikke at kunne gendannes.
Den anden gode nyhed er, at datatabet er foregået mellem 9:53 og 13:29 UTC, og den instans af skyen, der er ramt, blev fortrinsvis benyttet af nordamerikanske kunder. Selv medregnet sommertid vil det meste af tabet altså være for perioden før 9:30 om formiddagen på den amerikanske østkyst.
Fejlen ser ud til at være opstået først som en databasefejl, som dernæst har ført til kompromittering af filsystemet til databasen.
Det står endnu ikke klart, hvorfor Salesforce ikke kan gendanne data for det pågældende tidsrum fra backup.
- emailE-mail
- linkKopier link

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
Fortsæt din læsning
- Sortér efter chevron_right
- Trådet debat
Det kan endvidere konstateres at det ikke er muligt at udlede passwordet udfra ciphertext af samme grund (+ og - eller XOR).
- Plantekst skal være plaintext som er teksten der ikke er krypteret. - AV skal være IV (Initialization vector). .
Dropbox - bob, bob, bob, jeg mener ikke at NSA skal have adgang til mine filer.
Udover VeraCrypt er der BoxCryptor.com til sikring af DropBox filer. Begge baseret på AES 256 som meget simpelt sagt i sin kerneprocess addere plantext og password (+ flere andre processor) til ciphertext. Denne kerneprocess tror jeg ikke kan knækkes, heller ikke med kvantecomputere, fordi det ikke er muligt at udlede plantekst udfra et sumtal (ciphertext) hvis ikke man kender passwordet.
Illustrativt eks.: Plantext "A" og password "B" = ASCII code 65 + ASCII code 66 = 131. 131 kan lige så godt være plantext ASCII code 17 og password ASCII code 114. Er dog ikke direkte en addition der udføres. Men dette problem kan man ikke komme udenom og dermed er data sikret.
Dertil kommer som nævnt en række andre processor i AES. Fx.: Ved kryptering af samme plantext med samme password bliver ciphertext forskelligt (AV).
BoxCryptor gør det muligt at dele krypteret data uden udveksling af AES nøgle.
Hej,
rsync er ikke backup.... rdiff-backup (rsync + delta osv) er backup - ellers er der jo den med at synce den uopdagede fejl.
og når man så er nået til rdiff-backup og tænker "det er knagme smart!" - så får man øje på attic-backup, som forkes til borg-backup, og SÅ bliver det så appetiteligt som aldrig før.
Det er simpelthen snedigt. :-)
Brug så CrashPlan frem for BackBlaze, alene pga. deres bedre måde at restore, og manglende "30 days and you are dead" - hvis du overser en sletning. CP's Eula er lige blevet strammet, og de har brændt sig lidt, men det er teknisk (imho) en bedre løsning alligevel.
Hvis du laver en krypteret container med Vera Crypt i Dropbox folderen, så er dine data også skjult for NAS.
Men hvis du ellers opdager at dine data er væk, eller er blevet krypteret så skule Db være god nok. Pladsen er bare meget begræsnet. Men versions kontrol har redet mig en gang for tab af mange dages arbejde. Derfor jeg blæser lidt i horn for Db.
Ubegrænset gendannelse af filer 30 dage 30 dage Ubegrænset versionshistorik 30 dage 30 dage
Er det en Oracle-database?
Mvh. Mogens
Hej allesammen.
Tak for gode råd, som jeg vil forsøge at bruge efter bedste evne.
Mvh. Anne-Marie
Desværre har fysisk disk replikering den uheldige egenskab at den også kopierer de korrumperede data med over.
Her var det så 3 1/2 time! Løsningen er at lave database replikering, da det foregår på et andet lag, hvor korrumperinger i filsystemet ikke slipper med over.
Hej, først er det fysisk diskreplikering (disk firmware), dernæst filsystemreplikering (operativ system)? Der er stor forskel, hvilken mener du? Korrumperinger i databaselaget kan også forekomme, se: silent data corruption. Det væsentlige er at have god sikring af data integriteten, og dernæst hurtigt kunne opdage korruption i data.
Dropbox gemmer slettede filer i en slettet mappe i 30dage. Hvis man opgradere til betalings abn, kan dette og versionshistorikken forhøjes til 1år.
Nu har du nok næppe mange databaser på din egen computer at bekymre dig om, så database replikering er næppe det helt store problem.Kan du forklare for en teknisk ukyndig, hvordan man laver den slags database replikering som privatperson? (Hvis det kan lade sig gøre). Det lyder besnærende rigtigt, for en af mine bekymringer er netop at få tage backup af de korrumperede data, hvis jeg en dag skulle være rigtigt uheldig.
Men rent lavpraktisk, så er en god måde på en Linux maskine at lave backup vha. rsync til en ekstern usb disk, og så have flere af dem som du bytter rundt på, og evt. lader en ligge uden for huset.
Og hvis du har en højhastighedsforbindelse, så kan man også lave rsync over nettet til en anden part du kan stole på.
Dropbox - bob, bob, bob, jeg mener ikke at NSA skal have adgang til mine filer.
Det her er lidt OT (Off Topic) i forhold til artiklen... men kan være interessant for en hjemmeløsning.
Jeg kører OwnCloud server på en gammel PC med en nyere NAS... så har man i hvert fald altid en replika både hjemme og på laptoppen og der er også clienter til IOS (iPhone/iPad) men dem skal man betale for.
OwnCloud server kan så replikere til en anden maskine f.eks. i sommerhuset eller hos nørdede venner eller familie.
NB: Husk at en replikering er IKKE en backup - sletter du noget et sted så spreder sletningen sig til de andre på få sekunder.
"Altså at en computer kan slette alt på Dropbox drevet os så er den væk fra alle tilsluttede computere." Ja det kan ske, men hvis du er opmærksom på det, så gennem der kopi af også det slettet. Ved ikke helt hvad der sker hvis man fylder på til ens grænse igen.
"Dropbox tilbyder 30 dages versionshistorik i tilfælde af, at du utilsigtet sletter en fil eller ønsker at gendanne en tidligere version."
Problemet hvor personer har mistet data er hvis de ikke opdager det ingen for 30 dages perioden. Men du vil og kan også typisk have en lokal backup af dropbox ligende som du selv laver, ved et Copy-Past.
Det er nok fordi de har brugt mit råd i stedet for dit. :-)Transaktionslog backup kører man typisk meget oftere. Hver 5. eller 10. minut på store databaser.
Derfor under det mig at der er gået så meget tabt.
Når jeg nu tænker over det, så koster det det samme at tage backup af transaktionsloggen hver 5 minut, som det koster at tage den hvert 4 time. Det er den samme data der skal flyttes.
Så jeg tror bare at jeg skifter holdning.
Transaktionslog backup kører man typisk meget oftere. Hver 5. eller 10. minut på store databaser. Derfor under det mig at der er gået så meget tabt.Det er almindelig at tage en backup af sine databaser hver 4. time,
Jeg vidste ikke at DropBox kunne bruges som backup løsning. Jeg har nærmere hørt det modsatte. Altså at en computer kan slette alt på Dropbox drevet os så er den væk fra alle tilsluttede computere. Den største trudsel imod almindelige filer er i dag Ransome ware og hvis man bliver ramt af det så vil man gerne have data et sted der ikke er ramt endnu.
I denne sag er det dog ikke almindelige filer der blev ramt, men en database. Det er almindelig at tage en backup af sine databaser hver 4. time, så mund ikke det er det de er ved at sætte op igen. Det kunne være rart hvis de kom med eb udførlig rapport om hvad der var sket for dem. Ala harvarirapport.
Bruger Backblaze til remote backup her. Tror jeg har omkring 11TB liggende for 30,- med versions styring og det hele.
Tak for kommentar, Jimmy B. Carlsen.
Du har ret - der er meget, man skal være opmærksom på. Havde ikke lige tænkt på tyveri. Det vil jeg så gøre fremover - en ekstra harddisk et andet sted :-)
Mht. Cloud så går min mistillid mere på "overvågningssamfundet" og evt. hacking. Der er for meget "Ti fugle på taget" for min smag. Måske ikke logisk og sagligt begrundet - men jeg føler mig altså ikke tryg ved Clouden.
Jeg havde håbet på nogle råd om et godt gammeldags back-up-program, men har indtil videre ikke kunnet finde nogen, jeg trives med. Af en eller anden grund synes jeg, at det gik bedre "i gamle dage" - der klarede jeg mig fint med en incremental backuprutine. Men nu fungerer de ikke mere på den måde, som jeg forventer - jeg løber sur i dem, fordi de af en eller anden grund navngiver filer på uforståelige måder. Det er sikkert mig, der er noget galt med.
jeg kan bedst lide selv at have mine backupper i hænde
Men du opbevarer dem ikke på samme lokation/hus som originaldata, vel?
Det ville være ærgerligt at få nappet både pc og ekstern HDD ved et indbrud eller miste dem begge i en brand.
Og en Dropbox-løsning forhindrer jo ikke, at du også har en lokal løsning samtidig...
Hej Bent.
Mange tak for råd og forklaring. Jeg har dog indtryk af, at Dropbox vel er noget "Cloud"-noget? Det er desværre lidt for luftigt for mig - jeg kan bedst lide selv at have mine backupper i hænde (det burde jeg nok have skrevet). Det kan godt bunde i uvidenhed fra min side, men sådan har jeg det ...
Men tak alligevel, for at du gav dig tid til at give råd.
"Kan du forklare for en teknisk ukyndig, hvordan man laver den slags database replikering som privatperson?"
Brug DropBoks, så er der version kontrol og backup. Noget som vil rede noget af din data i denne situation. Ved godt det ikke er verdens bedste og "rigtigste" løsning.
Men den virker, og er gratis. Samt er meget nemt at gå til for alle.
Det er også en af grudene til at DB ikke giver så meget gratisplads, og er lidt dyre end andre. Det er ikke bare dum plads i skyen.
Ved ikke helt med google og MS. Men hubiC og Amanzon giver ikke samme sikkerhed, men de er til gengæld meget billigere og for Amazons vedkommen, så er det ubegræsnet data. De er også meget langsome, en måde at begræsne misbrug på. Men udmærket til privat brug.
Derfor burde de vel have T-logs for den berørte periode? Medmindre selvfølgelig de gemmer dem samme sted....
Asger Solvang:
Kan du forklare for en teknisk ukyndig, hvordan man laver den slags database replikering som privatperson? (Hvis det kan lade sig gøre). Det lyder besnærende rigtigt, for en af mine bekymringer er netop at få tage backup af de korrumperede data, hvis jeg en dag skulle være rigtigt uheldig.
De har muligvis et setup hvor de tager løbende "rigtig" database backup med et antal timers interval. Samtidig laver de disk replikering mellem 2 sites for at sikre at man kan starte op et andet sted hvis en site ryger ned. Desværre har fysisk disk replikering den uheldige egenskab at den også kopierer de korrumperede data med over. Pludselig har man så 2 ødelagte datasæt og skal hente den sidste "rigtige" backup ind. Ved sådan en operation vil man altid miste data, da backup pr. definition er "gamle". Spørgsmålet er kun hvor meget data man mister. Her var det så 3 1/2 time! Løsningen er at lave database replikering, da det foregår på et andet lag, hvor korrumperinger i filsystemet ikke slipper med over.
Det var da godt, at det ikke var livsvigtige sundhedsdata i skyen, det gik ud over.