Packa systemfiler o annat i ett arkiv

Även 'tar' (tar-archiver) tar med sådant med rätt flaggor

I Linux/unixvärlden används hårda länkar ofta och med -H i Rsync så behålls även den informationen då annars en generationsbackup med med många hårdlänkade filer (för filer som inte har ändrat sig mellan varje backupgeneration) så kan annars storleken svämma över alla bredder på det nya lagringsmediat. Även 'tar' har sådan flagga.

en applikation som använde hårdlänkar extensivt är tex. Apples time-machine

om du skall ha diskimage av SD (dvs kopiera varenda sektor och är exakt kopia av vad som finns på SD-minnet) så är 'dd' eller om man är osäkrare på hur man accessar diskar och inte vill skriva åt fel håll och förstöra SD-bricka - så kan man prova med ddrescue.

efteråt kan man komprimera filen med tex. gzip eller bzip2

alternativt om du tänker ta regelbunden backup och diskimage av SD, använd borg-backup som både krypterar, komprimerar, deduplicerar även inom filer och det som ökar på repositoriet (efter första backupen) är dom förändringar som skett efter förra backuppen, inte en hel diskimagestorlek till.

Hela disken (sda)/partitionen (sda1) skrivs av. Däremot blir en sådan extremt liten då alla nollor "försvinner" från filen när den komprimeras. Komprimerade själv en diskavbild skapad i programmet diskar (gnome-disks) där filen var drygt 4 TB varav ca 3 TB använt och filen blev knappt 1,7 TB stor.

tar.gz eller tar.7z ger mycket hög komprimering och formatet tar säkrar användare/rättigheter. Om du komprimerar en redan skapad diskavbid, t.ex. en img-fil så behövs ingen tar-fil som container för att bevara rättigheterna.

i linux enklast

ställ dig i rätt filsystem med 'cd'

cat /dev/zero > zerofile

sync

(för att datat verkligen skall skrivas fysiskt till lagringsenheten och inte stanna kvar i datorns RAM-cache)

rm zerofile

(man kan också använda "dd if=/dev/zero of=zerofile bs=1024k status=progress" istället för 'cat /dev/zero > zerofile' då det kan gå fortare samt att du får progress-visare i skrivningen - det kan ju ta ett tag att skriva till långsamma SD-minnen)

Den vägen skriver hela kvarvarande lediga diskutrymmet full med en fil med bara nollor i sig och sedan tar man bort filen igen

Är det med partitioner med msdos (FAT32 mfl) kan man behöva göra det med flera filnamn då det tar stopp vid 2 GB filstorlek - ta inte bort de redan skrivna filerna innan du har skrivit så många zero-filer att disktutrymmet är slut - därefter ta bort filerna.

---

Med tanke på den låga kvaliteten på SD-minne/USB-stickor man kan råka på numera är det inte alltid lämpligt att göra denna överskrivning av ledig utrymme på SD-minnen direkt innan man har tagit diskimagen, då när man skriver till SD-minnet så kan det plötsligt ta tvärstopp och SD-brickan blir oläsbar eller i read-only pga. skräp-flashen man stoppar in i dem.

Man kan nollställa oanvända utrymmen i filsystemen på partitionerna på själva diskimagen i efterhand med

'fdisk -lu /path/to/diskimage'

där får man en lista med ingående partitioner och var start och slut av block de börjar med

startblocket måste multipliceras med 512 för att få en byte-adress offset

för en partition1 med startblock 8192 enligt tabellen ovan så blir det alltså byte-offset adressen med 8192 * 512 = 4194304

med denna kan man sedan göra:

mount -o loop,offset=4194304 /path/to/diskimagen /mnt <enter>

(mount är väldigt bra att gissa fram vilken filsystem som används och gör det för det mesta rätt automagiskt - misslyckas det så kanske man behöver hinta, så används flagga '-t msdos' om det är msdos-filsystem etc. )

därefter har du partitionsinnehållet i partition1 under /mnt/ och kan skriva din jättefil med nollor där och sedan ta bort denna igen.

när du sedan är klar så använd 'umount /mnt' så frigörs diskimage-filen igen och du kan ta nästa partition i diskimagen

på det sättet - i efterhand efter att man kopierat ut SD-minnet, kan radera data på oanvända delen i resp filsystem i diskimagen utan att riskera att man skriver sönder SD så att den är oläsbar innan man hann göra en diskimage på den...

'dd' gör ingen sådan bedömning - får image-filen plats på den nya större SD så är det ingen problem där - även om SD skulle vara mindre än imagefile så kopierar 'dd' tills det tar stopp.

'dd' ser imagefilen som vilken annan fil som helst och bryr sig inte om vad som står i denna alls.

---

när du tar ur och mata in SD:n igen så kommer OS att upptäcka att det finns en partitionstabell och i denna vidare hänvisning till resp partition - ja så länge som det hela betraktas med LBA-adressering vill säga.

kräver BIOS/OS CHS-adressering av disken (vintage-datorer) så är det mycket besvärligare - men det tar vi den dagen när man råkar på en sådan situation.

Det skall gå utmärkt att köra fram och tillbaka disk-imagen till samma SD-kort.

Vad säger det om storlekarna - är är imagen resp SD-korten på sektorn/byten exakt lika stora efter att du tog backuppen??

Det som kan ha hänt är att SD-kortet har tagit bort några av sektorer vid skrivning för att de inte fungerar och SD-kortet blev en smula mindre bara sådär genom att IO-error inträffade en smula tidigare när man närmade sig slutet av disken. Med SD-kort, deras variant av wearlevling och numera i allmänhet lågkvalitetsminne så vet man aldrig längre...

Det andra är om du körde av partioner (sda1, sda2 etc. och inte sda) som image och inte hela disken som image är att du inte använder MBR utan kanske GPT som partitionstabell när du skapade detta på nytt och det slukar mer utrymme och det fattas ett antal sektorer plötsligt.

Om du kan mounta partitionerna och enbart filerna är intressanta så kan du givetvis kopiera ur dessa med rsync eller annan kopieringsmetod (cp -a).

det som kan vara lite plock och mickel är att få med all info som sedan behövs för att SD-minnet skall boota korrekt på en annan SD-bricka - med diskimage så kommer man i regel runt sådana saker även när man flyttar diskimage till en SD-bricka som är exakt lika stor eller något större (räknat i antal sektorer)

Låter som en panik-grej hos själva SD-minnet - när du läste efter skrivningen så var vissa sektorer inte läsbara eller hade korrupt data och det krachade.

Boot och OS brukar inte kolla hela vägen om en filsystem verkligen räcker hela vägen som partitionstabellen anger - problem kommer först när OS försöker anropa en sektor väldigt i slutet av filsystem och först så upptäcker att filsystemet är större än den fysiska mediat och då får ett IO-error - men inte innan dess.

Så fråga 1 är varför din SD-bricka blev mindre - om du både tagit en diskimage av SD-brickan och sedan lagt tillbaka på samma SD-bricka. En förklaring är den bedrövliga kvalitens på SD-minnerna idag och det trollade med knäna när du skrev imagen tillbaka på SD-minnet.

nästa gång när du lägger tillbaka en disk-image på en SD-bricka - läs ut imagen igen (exakt lika många sektorer och samma startpunkt) till en fil under annat namn och kolla med tex sha512sum att imagen verkligen är lika som orginalet och inte har utläsningsfel (läs silent error från dåliga sektorer från SD-minnet)

- ungefär som gamla tiders bränning av DVD att man alltid skall verifiera - SD-minne idag är tom. sämre än DVD-R - för SD-minne säger inte till när det är läsfel på sektorer - ger bara korrupt data lika glatt som korrekt data (silent error)...

- obs gör ingen 'mount' av imagen innan det är gjort - så fort det mountas så ändras det saker i filsystemet och checksumman stämmer inte längre - i ubuntu kan det finnas automount som kan stöka till med mount av enheten så fort den känner igen en giltig partitionstabell och man kanske får kika i https://help.ubuntu.com/community/Mount/USB för att stänga av det.

du får läsa manualen för dd

dd tar hela volymen om du inte har instruerat något annan.

med flagga 'skip' (skip=2048) så hoppar du över ett stycke i antal block räknat från början av volymen

med 'count' (count=123000) så säger det hur stort stycke i antal block som skall kopieras ut från punkten där 'skip' stannade

dvs med 'dd if=/dev/sda of=/path_to_masstorage/partial_image skip=1024 count=30000 bs=1024'

Så säger man att hoppa över de första 0-1023 blocken, från blockpositionen vid 1024 blockposition så kopierar man ut 30000 block till /path_to_masstorage/partial_image och sedan avslutas det. Med 'bs' så bestämmer man hur stort en block är, ovan exempel då satt som 1024 Byte och då motsvarar en block 1 kB i storlek.

Man kan alltså (tillsammans med 'cat') klippa och klistra med 'dd' och därför är verktyget väldigt användbart för lågnivå-meck på hårddiskar.

---

Det finns tillfällen där jag har kört med bs=1 (blockstorlek räknat på 1 byte-nivå) för att kunna plocka ut starten på en tar-arkiv i en tapevolym som var totalt havererad (hatar kommersiella programvaror som inte kan hantera ÅÄÖ i filnamn... - stora Ö i dos som första bokstav i filnamn har samma kod som för raderad fil i FAT-filsystem - och då krachade tape-streamer programmet fullständigt...) - var väldigt glad att jag inte hade slagit på kompressionen (i propertiär format) den gången...

Och det roliga med tar är att varenda fil ur tar-arkivet kan man hitta genom att dess början markeras med just 'ustar' som magic-word och med 'grep' och andra hjälpmedel hitta exakt positionen och med titt i tar.h i källkoden vet man hur många byte framför 'ustar' man skall klippa ut med 'dd' för att sedan kunna packa upp filen med 'tar' - tar-arkiv har egenskapen att även om filen ifråga är sönderklippt i bitar så går det extrahera filerna med rättigheter, path etc. så länge filhuvudet med datakropp precis efter är komplett och går att identifiera.

tar-archive är en av de ytterst få arkivformaten som har distrubierad direktory/tabell över filerna och är räddningsbart till stora delar även om en bit av början är borta eller en bit i mitten är utklippt - 'tar' står står ju för 'Tape Archiver' och man kanske inser en viss pragmatisk inställning till det hela med början som råkade bli överskriven en bit innan det hejdades och man kan få bandsallat på mitten... - och det som är kvar efteråt är ändå räddningsbart!!

prova att klippa av början på en zip-fil, rar-arkiv etc. och sedan försöka rädda det som är efter i filkroppen - så förstår man snart varför 'tar' är rätt unik i tänket vad man kan göra med arkivet den dagen när det redan har skitit sig... som bit-rot på ett media

Jo tvång är en bra läromästare, likaså svidande dataförluster förbättrar backupstrategierna avsevärt - och slutligen, man vet aldrig i förväg vilken typ av data som man anser som livsviktig några år senare - det som man tror är viktigt och det som verkligen är viktigt är inte alltid samma sak - och i många fall filerna som är mest kostsamma att återskapa är ofta väldigt små filer och ligger på ställen som vanliga backuprutiner aldrig någonsin kikar i.

att göra en diskimage-backup då och då är inte så dumt - just för att få med allt sådant 'smått' på konstiga ställen som ingen hittar och med borgbackup som arkivformat så är det inte fullt lika dyrt utrymmesmässigt att ha flertal sådana i loopen över en tid...