Backup av read-only hårddisk?

[JimmyAndersson]

Jag funderar... (Jorå, det händer. )

Jag har en 320GB PATA hårddisk (Western Digital) som behöver säkerhetskopieras.
Det är 3 eller 4 st partitioner på den. FAT32 och NTFS. Hårddisken är nog ungefär halvfull. Har kört Windows XP Home.
Eventuellt har den visat ett första försiktigt tecken på att vilja pensioneras.
(Fick ett minnesfel som *kan* vara relaterat till hårddisken. Då låste sig datorn, så jag stängde av och kopplade ur.)



Filerna ska hamna på en NAS (Synology) och helst använder jag Linux till det. (Minst "fuffens under skalet".)

Som hårdvara för hårddisken kan jag välja mellan:
1) Live-CD med Linux i stationär dator och plugga in hårddisken till moderkortet (IDE-kabel). (Det är den datorns hårddisk jag vill kopiera.)
2) Kopiera direkt i NAS'en med USB<->PATA-adapter.
3) Använda USB<->PATA-adaptern till någon dator.

(Det är alltså valen för att komma åt hårddisken. I alternativ 1 och 3 så överför jag i så fall filerna via nätverket.)

Adaptern är förresten en Plexgear. Kjell&Co's egna märke. Pålitlig?





För att testa hur det skulle vara att köra med alternativ 2 så pluggade jag in ett USB-minne i NAS'en.
Det monterades och så verkade NAS'en jobba en stund med USB-minnet.
Jag testade igen, denna gång med ett identiskt minne, men jag ändrade inställningarna så minnet blev Read-Only.
Då monterade den bara USB-minnet, men lät det vara i fred sedan.
När jag ändrade till R/W så började den pyssla med minnet,
så alltså kan den (väl) göra likadant med en hårddisk - och det vill jag undvika.


För att testa alternativ 1 och 3 så funderar jag på det här med att montera hårddisken...
När jag pluggar in den så lär den väl monteras automatiskt? Och dessutom som R/W?
Men Linux (Debian) lär väl låta den vara i fred? Så då kan jag avmontera den och montera som ReadOnly.
(Jag har inte testat med USB-minne i det här fallet.)
Något tips kring detta? <-- Där är frågan


Några tankar annars om detta?


Parentes:
Det finns ju även möjligheten att göra en image-fil av hårddisken.
Det skulle ju slita mindre på hårddisken än om armen behövde åka fram och tillbaka,
men WindowsXP (och även antivirusprogram som t.ex Norton) defragmenterar ju då och då
och hårddisken är inte så risig att den riskerar att fallera vilken sekund som helst.
Dessutom är jag osäker på hur jag kommer åt de individuella filerna från en dator (t.ex med Linux) när image-filen/filerna väl ligger på NAS'en.
Så jag tror att jag vågar strunta i det alternativet. - Förutsatt att det inte är väldigt smidigt att komma åt de individuella filerna sedan.


edit 1: Siffran "3" hade blivit "2" i "För att testa alternativ 1 och 3". edit 2: Skrev edit-raden.

[TomasL]

Du kan monterar imagefilen i ett lämpligt program, och sedan kopiera över det hela fil, för fil.

[xxargs]

körs linuxdist som är specialist på just att hantera datorer som inte fungerar som tänkt som systemrescuecd http://www.system-rescue-cd.org/

så gör den ingenting alls själv utan allt måste instrueras manuellt om man skall montera diskar - medans en liveskiva av ubuntu försöker vara duktig och med udev försöker montera alla synliga partitioner till mappar - och då förstås i read-write mode...

det betyder med systemrescuecd så kan du montera dina partitioner med 'ro' flagga (readonly) manuellt och då innebär att din partition bara läses och ingenting alls på disken rörs eller skrivs om.

[JimmyAndersson]

Tack för tipsen!
Det var bra att veta att System Rescue CD lämnar diskar/partitioner i fred.


Jag tänkte att det är lika bra att jag dokumenterar det här steg för steg i tråden.
Dels för mig själv och även ifall någon ser något knasigt.

Okej, då kör vi:
Min förra skiva var version 1.0.2 så det var dags att bränna en ny.
Valde v 5.3.2 eftersom det är den sista som stödjer 32bit-system.

Sedan bootade jag CD'n och valde första alternativet i menyn.

Dags att montera:
Som test valde jag ett USB-minne istället för hårddisken.
Monterade det som read-only med mount -r /dev/sda1 /mnt/test_usb
Och så mount -l för att se så det gick vägen.


Förresten, "Mount -l" ger ett lite rörigt resultat:
/dev/sda1 on /mnt/test_usb type vfat (ro, realtime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
Det gäller att läsa sakta så att man inte missar "ro" där.
Någon som vet något smidigare sätt att hitta samma info?

Apropå "iocharset=ascii":
När jag listar filerna på USB-minnet så får jag filnamn som "bra id?.psd" och "l?nkar.txt".
Så jag mountade alltså med fel charset. (Har använt USB-minnet enbart på WindowsXP-datorer.)
Så detta är nästa grej att fixa.

(Förväntade mig en flagga nånstans i mount --help, men icke.)
(Det var inte i går som jag gjorde det här senast, så jag får leta lite innan "ah, just det ja!" dyker upp. )


edit:
Hittade en grej:
"iocharset=VALUE: Character set to use for converting between 8 bit characters and 16 bit Unicode characters.
The default is iso8859-1. Long filenames are stored on disk in Unicode format."

Hm... Jag är inte riktigt med än. Måste man alltså *veta* typ av iocharset bara sådär?
Om man har en hårddisk där man inte har en aning om vad den har kört för något då?
Det var länge sedan jag var så pass nördig att jag kunde lukta mig till vilken typ av dator som disken kom ifrån.
Och Google är extra hemskt idag. Får bara sökträffar på Ubuntu och olika forum.
(Innan ni ens hinner tänka Bing.com så kan jag berätta att det blir ungefär samma träffar där.)

edit 2:
Passar på att ta mina andra frågetecken också:
När jag kopierar filerna, kommer dess datum (skapat, ändrat) att ändras?
Hur blir det med långa filnamn? Jag läste om "check"-flaggan i mount-manualen (under "Mount options for fat"), men hänger inte med.
https://linux.die.net/man/8/mount
Jag vill ju kopiera filerna exakt som de är. Annars blir det konvertering snarare än kopiering.

Nä, jag behöver en kopp kaffe.

[xxargs]

Finns väl inget i VFAT som hintar om vilken charset som används - det är ju en gamma utökad DOS-filsystem långt innan olika charset definierades och kan ju lika gärna vara en CP850 eller en CP437 typ...

så, ja det är nog något som du skall bara 'veta' att det är så

är det NTFS så är det nog bättre definierat.

[JimmyAndersson]

Nu har jag läst och fattat mer.
T.ex så förstod jag inte VFAT tillräckligt. Hittade bra info här: https://en.wikipedia.org/wiki/FAT_filesystem_and_Linux
Och så kom jag inte ihåg hur långa filnamn lagras, så jag kikade här: https://en.wikipedia.org/wiki/Design_of ... ile_system

Ditt inlägg fick mig även att komma in i rätt sätt att tänka kring det här.
Så jag tror att jag fixar det nu. Återkommer med resultat ..eller frågor.

[larky]

cp -p sparar ändringsdatum.

-p samma som --preserve=mode,ownership,timestamps --preserve[=ATTR_LISTA] bevara de angivna attributen (standard:mode,ownership,timestamps), om möjligt ytterligare attribut: context, links, xattr, all

[xxargs]

Det där med CP850 eller CP437 i en (amerikansk...) tapestreamerprogram kunde ge ganska allvarliga fel - speciellt från en windows 3.någonting.

någon av ovan nämnda CP-charseten och att olika delar inte använde samma (läs konverterade) kunde ge väldigt jobbiga konsekvenser - som tex. 'stora' Ö som första tecken i filnamn hade samma värde som 'delete' tecknet i FAT med annan CPXXX

Det blev inte bra när man skulle rädda fram filer ur backuppen och det tvärnitade redan efter några få Mbyte - och inte gick det att komma runt heller eftersom olika delar av programbodyn betraktade tecknen på olika sätt - dvs när windows gjorde backup så betraktades stora 'Ö' på ett sätt som just ett tecken - när det skulle packas upp igen så var det med annan charset och istället tolkade 'Ö' som 'delete' tecknet av filen och det kraschade kungligt...

[xxargs]

cp -a ; går också rekursivt ned i filträdet

cp -al ; om man vill kopiera filer mha. hårda länkar istället för nya kopior av filen, går också rekursivt och tillverkar behövliga direktorys (funkar dock endast inom samma filsystem) - hårda länkar ta väldigt lite med extra plats och är vanligt i sammanhang med backupplösning med generationshantering - ofta i kombination med rsync som har den goda smaken att bryta en länk om den finner inkopierade filen är annan än tidigare trots samma namn, istället för att modifiera eller skriva över filen då det skulle slå igenom samtliga exemplar som är refererade med hårda länkar från olika direktorys (alla hårda länkar från olika direktorys pekar på samma Inode).

I filsystem som BTRFS så kan man göra på samma sätt som med hårda länkar men varje fil ändå blir unik med sina rättigheter och inte påverkas om annan fil som det kopierades ifrån - öppnas och modifiera senare - och det är att det kopieras med 'cp --reflink fil1 fil2' vilket innebär att olika inoder pekar på samma dataområde på disken till en början i alla fall - förutsätter att det är COW-system - dvs. alla ändringar skrivs på nya sektorer och aldrig modifierar det som redan är skrivet (tills sista referensen är borta och utrymmet då kan återanvändas)

[JimmyAndersson]

Intressant!

Men jag kan inte låta bli att fundera lite extra på det här med CP850 eller CP437...
Hur kommer det sig att man gjorde så att konverteringen kunde skjuta sig i foten med symbolen av en annan pistol?
Tanken med en konvertering är väl att det ska fungera. Man konverterar ju liksom för att det *inte* ska bli fel. Fel hade man ju redan innan.


--
Jag hittade inte vad Windows XP kör med för codepage och charset i olika filsystem. Sökandet får fortsätta en annan dag.
Men nu är klockan 1 och jag får nog avsluta för dagen/natten. Hjärnan behöver göra något annat.

edit: Halv två hann den visst bli. Jag kunde inte låta bli att leta lite till. Typiskt mig att aldrig ge upp.

$logout
NO CARRIER

[xxargs]

Det var ren bugg jag råkade ut på - men ändå typiskt programtillverkare för just backup (HP i form av colorado backup) som är så väldigt viktigt att de fungerar ändå låter sådant gå igenom i deras kvalitets-kontroll... men jag har aldrig gett så mycket för propertiära program ändå inom området då propertiärt är ofta samma sak som dold slarv då utvecklarna där inte behöver oroa sig att koden skall visas upp publikt och bli synad i sömmarna och gör en massa genvägar och andra fulheter... och efter att man hittade att linux hade QIC80 stöd och kunde hantera det på valfritt sätt ändå och kunde läsa ut bandet rått och den vägen kunde hitta den jättestora (typ 80 MB...) tar-filen som det var mest angeläget att få fatt på vid den tiden - sedan gick det att rädda ut allt.


Amerikanskutvecklade programvaror har alltid haft trassel med andra nationers charset - eller rättare sagt ' inte tänkte på det' och det är egentligen bara de sista 10 åren som det hela börja gå mer friktionsfritt iom. olika codpage och olika sätt att förmedla hintar om vilket som används default. Det är Internet som drivit på med faktum att det är stora delar av världen använder många andra olika alfabeten/teckenuppsättning som i asien - den arabiska välden etc. och måste hanteras på något sätt.

Samma sak med OCR-programvaror då det fans en dominerande (amerikansk) aktör som alla pekade på - sedan dök det upp en rysk eller eller östeuropeiskt utvecklad dito (kommer inte ihåg) som var fasen så mycket bättre på att tolka våra olika europeiska tecken inklusive grekiska och krylliska tecken att den amerikanska produkten närmast kändes oanvändbar i jämförelse.

[JimmyAndersson]

Mycket intressant! Tack.



Jag har fortsatt försöka lösa det, utan framgång.
Mitt sista test för kvällen gick inte heller bra:

mount -r -codepage=850 -iocharset=iso8859-1 /dev/sda1 /mnt/Jimmy_usb

Det gav mig:
"mount: /mnt/Jimmy_usb: wrong fs type, bad option, bad superblock on /dev/sda1, missing codepage or helper program, or other error."

"Helper program" ??
Till vad? Vad för sorts? Vad heter det? Hur laddar man det?
Det är ju bara så sanslöst mycket översittar-fasoner att de inte bemödat sig skriva *NÅGOT* om det.

"or other error" ??
Om inte programmeraren vet vad som triggat de orden att skrivas ut, hur ska då jag veta det?

"Superblock"?? Ingen aning.
Så jag sökte i Google på "linux mount "bad superblock" " och hittade bl.a det här svaret.
Dvs: "You still need to create a file system. mkfs.ext4 /dev/sdb1"
Men som det även står så raderas filerna. Det vill jag ju inte...
Jag hittade även en massa andra forum där folk har frågat om samma saker, men jag vet ju inte vad som är rätt.


-

Nä, det här projektet var game over redan från början.
Om jag inte får någon uppenbarelse i en dröm så är det tyvärr vettigast att inte slösa mer tid på det här.
Så i morgon eftermiddag/kväll får jag ta PATA<->USB-adaptern och koppla in hårddisken i en vanlig Windows-dator och kopiera filerna på det sättet.
Om det då blir några förluster så vet jag att jag åtminstone lade en vecka på att lösa det på det sättet som jag egentligen hade velat.
(För mig så finns det inget som heter "ge upp", men syftet med det hela är att kopiera filerna på hårddisken. Och det gör jag ju isåfall. )


Bara för egen dokumentation:
Jag följer "man --help" och den här manualen: https://linux.die.net/man/8/mount
Under "Mount options for fat" hittar jag "codepage" och "iocharset".
Och under "Mount options for vfat" (som jag vill mounta som) står det: "First of all, the mount options for fat are recognized."

[simply]

Clonezilla och dra en image på hela disken, sen kan du fippla hur mycket du vill med inställningarna när du mount'ar el likn?

//

Tapatalk'd with a OnePlus 6

[Mr Andersson]

-codepage=850 -iocharset=iso8859-1

Options ska anges med -o och separeras med ,
-o codepage=850,iocharset=iso8859-1

-i är att inte använda helpers och kan leda till felet du fick

[JimmyAndersson]

Aha! Tack!

Jag blev genast nyfiken på var detta stod, så nu när jag visste vad jag letade efter så kollade jag manualen igen
och visst, där var det:

Från mount --help:
"-o -- options <list> : comma-separated list of mount options"

och från mount(8)-manualen så ser jag rubriken:
"Mount options for fat"

Ja visst! *options*! Så var det alltså! Så otroligt kul när man förstår!
Och där tillkännagav sig "comma-separated"-detaljen av sig självt.
Men.. det var ju inte helt uppenbart att det skulle stå i *rubriken*.
Det hade säkert inte gjort ont om de skrivit det i texten också. Det är ju ändå en manual menar jag...



Okej, vidare till det här med "-i". Det du skrev förstår jag inte riktigt. Men nu vet jag vad jag ska leta efter. Perfekt.
Ah, i mount --help hittar jag:

"-i --internal-only : don't call the mount. <type> helpers".

Den var klurig... Läser din rad igen. "-i är att inte använda helpers och kan leda till felet du fick"
Och där trillade polletten ner: -i som i "-iocharset"
Jäpp, nu fattar jag sammanhanget och varför det blev sådär med "helper program". - Det var jag som orsakade det.
Jag skrev "Det är ju bara så sanslöst mycket översittar-fasoner att de inte bemödat sig skriva *NÅGOT* om det."
Men det var ju *jag* angett den flaggan och inte specificerat färdigt.


Då var det nog allt. Dags att testa igen.
Men först måste jag svara på Simply:
Det var en bra idé egentligen. Då slipper jag eventuella problem som skulle kunna bero på att jag använder usb-minne istället för hårddisken.
Det får bli plan B om jag stöter på mer problem.


Men nu, dags att testa kvällens nya kunskap:

Så nu kör jag:
mount -r -o codepage=850,iocharset=iso8859-1 /dev/sda1 /mnt/Jimmy_usb

Och jag fick inga felmeddelanden. Den monterades och jag kan se filerna.
Men det är inte riktigt rätt än. T.ex:

'L'$'\344''nkar (2).txt'
och
'Norton 360 f'$'366''r 3 datorer'

(Det ska ju vara "länkar" och "för".)

Så det är inte riktigt rätt codepage och iocharset än.
Men nu vet jag iallafall *hur* man gör, så nu är det vettigt att lägga tid på igen. Gäller bara att hitta rätt för åäö.

Jag har tyckt att det har varit svårt att hitta några konkreta tabeller för olika codepage och charset's.
Har bara hittat diverse forum och wiki-artiklar, men det är så massivt med information om hela historien med
"först användes det, sedan kom en annan och då byttes det namn till något som egentligen heter såhär".
Dvs, inte direkt något datablad eller fakta-referens att gå efter. Mer om man vill läsa bara för att ha något att berätta för barnbarnen.

Så.. någon som sitter och ruvar på vad Windows XP kör med (i FAT32) ?
(Jag ska också fortsätta leta förstås, men jag har som sagt inte haft mycket lycka med att hitta det tidigare.)