MacOS: Backup-data risikerer at forsvinde ud i ingenting

Illustration: Nikki Zalewski/Bigstock
En løjerlighed i MacOS betyder, at data under visse omstændigheder risikerer ikke at blive backet up, selvom det ser sådan ud.

Selvom alt på overfladen ser fint ud, så kan en fejl i MacOS bevirke, at der reelt ikke bliver taget backup af data, selvom det ser sådan ud.

Sådan lyder en advarsel fra Mike Bombich i et blogindlæg, som The Register er faldet over, og som en læser også har tippet Version2 om.

Bombich står bag et backup-værktøj til MacOS kaldet Carbon Copy Cloner (CCC).

Fejlen relaterer sig til, når data bliver kopieret over i et APFS (Apple File System) formateret disk-image af typen sparse disk-image. Det er en fil, der agerer som en tilkoblet disk, og som dynamisk ændrer størrelse, når der bliver flyttet eller kopieret flere data over i filen.

Problemet opstår, når der bliver kopieret flere data over i et APFS-formateret sparse disk-image, end der faktisk er plads til på den underliggende fysiske disk.

Ifølge Bombichs blogindlæg forløber kopieringsprocessen umiddelbart uden problemer, selvom der ikke er plads på den fysiske disk. Bombich testede med en videofil, som blev flyttet uden problemer. Og videofilen kunne også afspilles efterfølgende, ligesom filens checksum passede med kilde-filen.

Men da han unmountede disk-imaget og mountede det igen, så var videofilen korrumperet.

To bugs

Bombich har identificeret to bugs i den forbindelse. Den ene er, at den plads, der ser ud til at være ledig ved et APFS-formateret disk-image, ikke reflekterer den faktiske plads på den underliggende disk. Hvis det var den eneste bug, så ville det være til at leve med, som Bombich bemærker.

Problemet bliver forstærket af, at systemet ikke melder fejl, når den fysiske disk er fyldt op. Det hænger ifølge Bombich sammen med diskimages-helper applikationen, der fungerer som en slags formidler (eng. broker) mellem programmet, der gerne vil skrive data, og filsystemet.

Diskimages-helper bliver nemlig ved med at acceptere skrive-forespørgsler, selvom der ikke er mere plads. Så datakopieringen ser ud til at være vellykket.

Og hvad der er med til at forstærke problemet er, at det ser ud, som om filen faktisk ligger på den virtuelle disk, når kopieringsprocessen er færdig. Ligesom filen også ser ud til at have den rigtige størrelse. Ifølge Bombich skyldes det, at filsystemets metadata er opdateret, så det ser ud, som om alt er vel - selvom data som sådan ikke ligger på disken.

Når det også kan lade sig gøre at generere en checksum på den delvise fil, som matcher kildefilen, så hænger det ifølge Bombich antageligt sammen med, at diskimages-helper bibeholder noget af filen i ram, eftersom data ikke er nået over på den fysiske disk.

Den gode nyhed er, at der ikke er mange, der risikerer at få problemer som følge af fejlen, vurderer Bombich. I hvert fald ikke blandt brugere af CCC. Her skulle statistikken vise, at mindre end 7 pct. af CCC-backup-opgaver foregår til et sparse disk-image, og af disse er mindre end 12 pct. APFS-formateret.

Fejlen er rapporteret til Apple, fortæller Bombich. Indtil problemet er fikset, så er APFS-understøttelse af disk-images fjernet fra CCC.

Bombich har lavet en video for at illustrere problematikken.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (5)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Casper Pedersen

Når man siger OSX og backup-date i samme sætning, så tænker mange mennesker på Time-Machine som ikke har dette problem (bruger indtil vidre HFS+).

Personen som har problemet bruge APFS (det nye filsystem fra Apple) til hans images (sparcebunle / dmg), og det er APFS som har problemet. At han bruger det til at holde styr på hans egen backup er jo lidt noget andet end at sige at Apple har problemer med backup data...

Så overskriften er jo lidt af en storm i et glas vand...

  • 2
  • 5
Jakob Damkjær

Bare så alle ved hvad Sparse files er

NB! Lad være med at bruge fancypants fil system features hvis du ikke ved hvad de gør eller ikke kan overskue hvad konsekvensen kan være...

Så det her er ikke rigtigt noget der vil påvirke nogen der bruger APFS i langt størstedelen af use cases. Der er nogen der har fundet en exoterisk bug og vil ha mere opmærksomhed en bare at blive nævnt i releasenoten som almindelige mennesker gør. Det skal vel ikke ha noget at gøre med at carbon copy laver backup software og snapshot featuren i APFS er en trussel mod deres levebrød... sikkert helt urelateret...

“Sparse Files

Apple File System supports sparse files, a more efficient way of representing empty blocks on disk.

With sparse files, storage is allocated only when actually needed. This allows the logical size of files to be greater than the physical space occupied on disk. APIs can query both the logical and physical size of sparse files, with functionality to seek through and rewind back to the beginnings of holes and data sections.”

  • 0
  • 8
Deleted User

Det problematiske er, at sparse files (APFS eller HPFS+) i en del sammenhænge bruges til placering af sjældent anvendte filer (på f.eks. NAS) eller til direkte backup (der siden er let at og især hurtig at kopiere og verificere i krypteret format til en disk til bankboksen eller anden offline opbevaring).

Det helt store problem er, at operativsystemet kan melde alt klar (sparse files ser for bruger software ud som ethvert andet lagermedie), selv om data slet ikke lander i den virtuelle disk. Selv hvis du laver en egentlig compare eller verify (binary eller checksum), får du en "klarmelding" - alt er OK.

Ved alle filoperationer er upålidelighed og fejl et stort problem. Vi taler datasikkerhed her. Ikke om, hvor mange der benytter en bestemt fremgangsmåde. Blot at denne, specifikke fremgangsmåde - der anvendes af folk, der ved, hvad de gør - kan (og ifølge ol' Murphy derfor også vil) føre til problemer, når uheldet er ude.

At Bombich er en af de få, der opdager problemet, er da ikke unaturligt, og jeg kan ikke se, at det skulle være odiøst, at firmaet oplyser om problemet, så snart det er verificeret. Der findes en workaround (anvende HPFS sparse files i stedet), men hvis du ikke ved det, så...

Vil du hellere have, at fejl, der potentielt kan gøre en backup - eller virtual disk - fejlbehæftet eller direkte ubrugelig ikke offentliggøres?

Hvorfor er det næsten altid problematisk at gøre opmærksom på fejl i Apples kode (og derfor også Apples problem), mens fejl i Windows eller Linux gerne må offentliggøres?

Jeg var faktisk glad for denne heads-up, da jeg bruger sparse files på mit Apple grej (og tilsvarende vhdx-filer for mit Windows 10 grej) til produktion af krypterede "virtuelle diske", der - også -kan være emne/projekt relaterede. Tilfældigvis har jeg kun HPFS udgaver i brug på mit Apple grej - endnu - men jeg var da meget taknemmelig for advarslen (ingen grund til uforvarende at parkere sig på øretævernes holdeplads).

For eksempel benyttede jeg senest fremgangsmåden til at lagre et projekt vedrørende en Singapore rejse (omkring 132GB netto pladsforbrug til ebooks, images, video, audio, tekstfiler, dokumenter, flybilletter, plus alt det løse etc.). Når jeg pakker projektet væk til low-speed storage (ud på NAS) vil jeg nødig opleve, at jeg om tre eller seks måneder oplever manglende data(base) filer, hvis jeg vælger at kigge forbi for at kontrollere en detalje, eller opdatere projektet med et nyt video eller ebook output format/layout).

Jeg ville have akkurat samme problem, hvis mine historiske Windows projekter eller databaser opbevaret på vhdx filer viste sig mangelfulde, beskadigede eller direkte ulæselige grundet en fejl i operativsystemets basissoftware. Endnu værre ville det være, hvis disse skader også omfattede backup udgaverne!

Problemet er, at i tilfældet AFPS sparse files vil den normale fremgangsmåde til at verificere at data er korrekt lagrede OGSÅ svigte. Det er her, uhyggen breder sig, da du nu - helt uforvarende - kan opbygge et lager af beskadigede backup-data.

DERFOR er advarslen på sin plads, selv om den kun vedrører de få, der laver andet, end en lille lokal TimeMachine backup og så anser den hellige grav velforvaret.

Smil.

  • 6
  • 0
Jan Gronemann

Apples softwarekvalitet har—især i det sidste halve år—vist sig at være så dårlig at jeg overvejer at alle mine Apple-ting langsomt* erstattes af ikke-Apple-ting. Librem-laptops, QubesOS, analogt ur, Intel NUC i stedet for AppleTV, osv. Det er bare et helvedes hyr, men jeg synes sgu' ikke længere at jeg får noget "ekstra qualität" for pengene.

  • 0
  • 0
kenneth krabat

Med Carbon Copy Cloner har man fuldt styr på sin backup i OSX. Jeg har brugt det i 10 år og kender f.eks. ikke noget andet back-up-redskab, som ved 1. backup kan skabe den usynlige 700MB genstarts-partition i OSX, så back-up-disken faktisk bliver en 100% bootable kopi af Mac'ens interne disk.

Jeg kan ikke huske, at Bombich tidligere har skabt fokus på sig selv andet end ved at reklamere for nye features i opdateringer af CCC. Når han vælger at gå ud at sige det her, er det givet alene fordi han er seriøs og kender sit område. Og fordi han ikke ærligt kan tilbyde backup til APFS-diskimage, før Apple gør noget ved det. Og lad mig antage, at han har forsøgt at råbe Apple op ad de sædvanlige kanaler uden at høre noget tilbage...

  • 0
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize