Packa systemfiler o annat i ett arkiv

Trädvy Permalänk
Medlem
Plats
Dalarna
Registrerad
Apr 2016

Packa systemfiler o annat i ett arkiv

Hej,
En fråga. Kan filer från ett linuxoperativ (och egna script) packas in i ett arkiv och sen återskapas o samtliga attribut följer med uppackningen? Alltså, inte ändrade ägare o sånt.

Anledning till fråga: Handlar om arkivering av projekt i Windowsmiljö. Arkivet kommer senare att användas i ny linux-dator.

Trädvy Permalänk
Medlem
Plats
$HOME
Registrerad
Jun 2006

Rsync med -a och tar med -p ska fungera.

Gentoo Linux ~ Journal | Socialt | Kreativt

Trädvy Permalänk
Medlem
Registrerad
Aug 2016

Ä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

Trädvy Permalänk
Medlem
Plats
Dalarna
Registrerad
Apr 2016

Tackar för tipsen. Jag kommer att använda tar i detta fall då jag vill ha som slutresultat EN fil som är packad på sådant sätt att alla filer packas upp med attributen rätt.
Jag sitter som sagt vid en Windowsdator med SD-kortsläsare. Bredvid mig programmerar jag en RPi och i min fantasi vill jag stoppa i SD-kortet från RPi:n i windowsdatorns SD-kortläsare och med en Mint installerad i en VirtualBox vill jag göra backup på SD-kortet till en tar-fil. Denna tar-fil kan jag alltså sen packa upp på ett "rent" SD-kort när jag vill duplicera RPi:n.

Trädvy Permalänk
Medlem
Plats
$HOME
Registrerad
Jun 2006

Då kanske det skulle vara smidigare med dd?

Gentoo Linux ~ Journal | Socialt | Kreativt

Trädvy Permalänk
Medlem
Registrerad
Aug 2016

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.

Trädvy Permalänk
Medlem
Plats
Dalarna
Registrerad
Apr 2016

Undra om DD tar backup på hela SD eller bara det som det finns data på.

Trädvy Permalänk
Medlem
Registrerad
Mar 2016

@Sweedland:
Hela partitionen eller disken. Hela raden med nollor och ettor från början till slut. Inklusive allt tomrum och gamla glömda filfragment.

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Apr 2013
Skrivet av Sweedland:

Undra om DD tar backup på hela SD eller bara det som det finns data på.

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.

Server: AMD Ryzen 7 1800X 8/16 | ASUS Crosshair VI hero | 64 GB Corsair RAM @3000 MHz | ASUS radeon RX 460 2GB | Samsung 960 PRO 512 GB M.2 | 2x 2 TB Samsung 850 PRO SSD | 6x Seagate 10 TB | NEC PA301W @ 2560x1600 | Linux Mint 19 Cinnamon

Trädvy Permalänk
Medlem
Plats
Dalarna
Registrerad
Apr 2016
Skrivet av OldComputer:

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.

Jag tänkte också på detta. Komprimering måste ju vara effektiv på en img då en stor del av img:n består av "nollor". Jag har en hel del img i windows-miljö. Har tagit SD-kortet och läst av det med SDReader (eller vad nu windows-programmet heter). Om den IMG-filen komprimeras behålls ju fil-rättigheter etc.
Om jag använder samma windowsprogram för att kopiera över img-filen till ett nytt SD-kort är den känslig för storleken på nya SD-kortet. Gäller det även dd kommandot? Gör den en diskcheck också och konstaterar att mål-SD-storleken inte är (exakt) lika?

En annan fråga. Det kan ju ligga delar av filer i "tomrummet" som helst ska vara nollor. dessa fragment av filer tas ju med vid en dd. Kan man köra ett "wipedisc" på tomrummet först?

Trädvy Permalänk
Medlem
Registrerad
Aug 2016

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...

Trädvy Permalänk
Medlem
Registrerad
Aug 2016
Skrivet av Sweedland:

Gäller det även dd kommandot? Gör den en diskcheck också och konstaterar att mål-SD-storleken inte är (exakt) lika?

'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.

Trädvy Permalänk
Medlem
Plats
Dalarna
Registrerad
Apr 2016

För de intresserade:
Jag packade ihop en 60Gigs img av en linux-sticka (dator-OS på sticka) med 7zip. Den blev 5.8G....

Trädvy Permalänk
Medlem
Plats
Dalarna
Registrerad
Apr 2016
Skrivet av xxargs:

'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.

Testade med Raspibackup och lade över partitionsbackupperna på en Extern hårddisk. Skulle göra en restore till ett mindre SD-kort sen. Det var några meg för litet så det funkade inte. Sen gjorde jag en dd och lade den på samma externa HD. Gjorde en dd tillbaks till ett samma "lilla" SD-kort. dd larmade att det var för litet. Tröttnade ur lite då.
Nästa idé jag fick är att montera source och target i var sitt SD-kortläsare och stoppa de två i var sin kortläsare (som jag har på min stora windowsdator). På den datorn har jag Linux Mint i en virtualbox. Tänkte köra rsync och kopiera över alla filer till target....vad tror du/ni om det?

Trädvy Permalänk
Medlem
Registrerad
Aug 2016

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)

Trädvy Permalänk
Medlem
Plats
Dalarna
Registrerad
Apr 2016
Skrivet av xxargs:

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)

Det som hände när jag använde dd för att "återställa" och det funkade faktiskt o boota target till och börja med MEN booten stannade mitt i . "KERNEL PANIC STOP" eller nåt sånt. Kollade med gparted o den meddelande att partitionen inte kan vara större än vad som var tillgängligt. target är ngt mindre än source.

Jag ska shirinka source med gparted tror jag på ett av de större korten (annat märke) men använda en test-SD först. Sen köra dd till ext. hårddisk. Sen göra en dd tillbaka till target (som är av ngt mindre storlek) och se om de funkar. Att bränna en hel image känns mkt bra för då följer allt med...kan zippa den och ha den i versionshanteringssystemet. Tror det är bra att använda bs=1M när dd används...

Ska också testa rsync från source till target i min windowsdator/linux. Har bra minnes-korts-läsare i den datorn.
Måste kolla längre upp i denna tråd hur rsync skulle konfiggas så systemet med filattribut kan följa med över obehindrat.

Trädvy Permalänk
Medlem
Registrerad
Aug 2016

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.

Trädvy Permalänk
Medlem
Plats
Dalarna
Registrerad
Apr 2016
Skrivet av xxargs:

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.

Target SD-kortet ÄR mindre. Några 100 Meg som jag minns det. Det sade dd till om efter att den dumpat över img. Men jag tog nyaladdade SD-kortet ialla fall och stoppade i o körde. Då bootade den bara till hälften. Sen tvärstopp. Det var då jag läste om att man kan minska ner stora source med nån GIG och sen köra en img av den med dd. Låter det som en plan?

Sen vill jag testa rsync i virtualbox/Linux Mint mellan source o target. Kopiera fil för fil till det tomma (men monteringsbara) SD-kortet.
Det kanske är en annan historia...

Trädvy Permalänk
Medlem
Registrerad
Mar 2016

Ärr det inte bättre att kopiera filerna istället? Går ju snabbare och storleken på diskarna spelar ingen roll.

Trädvy Permalänk
Medlem
Plats
Dalarna
Registrerad
Apr 2016
Skrivet av FattarNiInte:

Ärr det inte bättre att kopiera filerna istället? Går ju snabbare och storleken på diskarna spelar ingen roll.

Ja. Det kan ju vara idealiskt men utan att gå in på detaljerna så tror jag att dd är bäst då den tar boot, sys.inställn. o allt annat.
Jag provade att krympa ner partitionen så när dd skapade sin image så skulle den inte vara så stor. Men dd tycks ta hela SD i alla fall så när jag skulle skicka över img till det nya något mindre SD-kortet så vad ändå denna Img för stor. Där brister jag i knowhow hur göra så att dd (eller nåt annat program) läser bara till sista partition o inte mer när den ska skapa img.

edit: Sen använder jag rsync för att göra backuper av det jag gör....det är en annan story.

Trädvy Permalänk
Medlem
Registrerad
Aug 2016

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

Trädvy Permalänk
Medlem
Plats
Dalarna
Registrerad
Apr 2016
Skrivet av xxargs:

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

*flin* Jag läste som hastigast "man dd" igår innan jag åkte hem från jobbet. Trodde jag skulle hitta nåt men hade inte mycket tid. Men nu så finns det en öppning med count vill jag påstå. Jag har ändå en obekräftad känsla av att det finns information i det som dd läst av Source hur stor SD-kortet ska vara så även om jag krymper ner img så det får ledigt plats på det nya lite mindre Target så kommer boot ändå att läsa in att "SD ska vara så HÄR stort men Target är inte det" och därmed göra halt. Men men...trägen vinner. Varför det vore lyckat är att vi kan ledigt använda 8Gigs SD-kort för hela OS+applikation är bara 5Gig.
Det blir mycket obetalt arbetstid det här. Tur för företaget att jag har det som hobby också. Ingen projekt har råd att betala för min löpande utbildning i Linux.

Angående din story om tar. Jag har alltid sagt att tvång är bästa läromästaren. Det låter som om du var tvungen att rädda vissa filer ur arkivet?
Som jag (tror) jag skrev så i och med mitt labbande med dd och andra program med min externa hårddisk ansluten till Raspberryn så "råkade" jag radera hela Ext.HD med bland annat en folderhiarerki med 17års data från mitt förra jobb. De jag nu är konsult åt. Jag gjorde i ett svep om Ext.HD till ett RPi SD-kort. Ha ha. Resten av datat var borta.
Jag blev totalt kallsvettig för detta data som försvann är kritiskt då jag använder det när de forna arb.kamraterna (numera beställare) ringer mig och frågar mig om diverse jobb jag gjort där. Min sambo undrade varför jag blev så blek. Lite senare drog jag mig till minnes att hade windows-arkiv på en secondary HD på min stora dator och i ett av dessa arkiv fanns en backup på detta viktiga data. Lärdom: Lokalt sparat data är farligt för dit når inte företagets nattliga backup.

Nu ska jag grepa lite tar-arkiv och sen testa count....tack för hjälpen förresten.

edit:
I gparted finns all information om den nerkrympta source-SD:n. Antalet sektorer och storleken på sektorerna. Det är bara å tuta o köra...

Trädvy Permalänk
Medlem
Registrerad
Aug 2016

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...

Trädvy Permalänk
Medlem
Plats
Dalarna
Registrerad
Apr 2016

Jag blir galen om detta är sant:

"A better option is the SD card copier (piclone) included in Raspbian itself , since it works with cards both smaller and bigger than the original. You must be running Raspbian on the Pi and need to use an additional USB cardreader (or USB harddisk/pendrive)."

Trädvy Permalänk
Medlem
Plats
Dalarna
Registrerad
Apr 2016

Epilog.
Efter en hel del bråk med "rpi-clone" kunde jag clona SD-kortet medan det var monterat och dessutom få ner det från 16G till 8G. Det kunde bara göras om jag före justerade 8G kortet med gParted. Det var tvunget att minska ner stora partitionen ganska rejält och låta rpi-clone justera upp den. Det var lite handpåläggning. Vid tid ska jag krympa ner img-filen och dd:a över den till Target. Känns mer seriöst men att få cloningen att funka oavsett metod var viktigast.