schijf uit een Freecom SilverStore NAS onleesbaar op desktop

[VanderWells]

Beste mensen,

Onze Freecom SilverStore 2-bay NAS ging niet meer aan, waardoor we gedwongen waren de NAS terug te sturen. de schijf die er in zat, komt niet van Freecom en is verder een doodgewone 3.5" SATA schijf. Het filesysteem in de schijf is hetgeen waar wij op een probleem stuitten.



Hierboven een afbeelding met de huidige indeling van de schijf. H:\ is de partitie waar alle data op staat. Windows, Mac en Linux kunnen het niet lezen en de schijf moet geformatteerd worden bij ieder besturingssysteem. Dat wil ik niet doen, omdat er heel veel belangrijke data op staat. Is er een manier om de data ervan af te halen?

Met vriendelijke groet,

- Van der Wells

[_Dune_]

EXT3 zou volgens mij via Linux uitgelezen moeten kunnen worden, mogelijk dat je het volume nog moet mounten, maar opzich is er toch niet heel veel aan de hand. Het is heel belangrijke data, daar heb je vast een goede backup van? Welke je zo kunt terug zetten.

Thematopic: Datarecovery
Thematopic: Backups

[ Voor 21% gewijzigd door _Dune_ op 16-08-2013 21:39 ]

[GoldenBatt]

Of gewoon weer in de volgende NAS drukken die je terug krijgt naar reparatie? En Linux zou ze moeten kunnen lezen ja..

Verder, Backups inderdaad, altijd handig, wat als de schijf nu stuk was geweest ipv de nas?

[VanderWells]

Deze schijf is de backup. In Linux herkent hij het grootste filesysteem als unknown file system.

Ik weet niet wat Freecom doet van binnen met die schijf, maar het is vervelend.

[_Dune_]

Als deze hardeschijf de backup is, dan heb je het origineel nog elders staan. Met andere woorden, dan is er nog weinig aan de hand. De vervangende NAS zal hoogst waarschijnlijk de Hardeschijf wel weer inlezen en anders formateren en weer een backup van het origineel maken.

Natuurlijk is het dan wel verstandig voor nu een andere backup mogelijkheid te zoeken, zolang de NAS niet vervangen is. Als er iets mis gaat met de originele data, dan heb je natuurlijk niets meer.

[ Voor 26% gewijzigd door _Dune_ op 16-08-2013 22:01 ]

[GoldenBatt]

Tja. Het is met die kant en klare oplossingen vaak iets wat je niet zomaar weer overneemt, dan had je zelf een oplossing in elkaar moeten draaien

[Mijzelf]

Het lijkt me voor de hand liggend dat de 928GB partitie de data partitie is. Volgens jouw screenshot is hij ongeformatteerd. Maar het is een 2 schijfs nas, dus het zou kunnen dat hij een single partitie raid1 array bevat. Kun je in Linux eens kijken welk device het is

cat /proc/partitions

en vervolgens de raidstatus ervan opvragen

mdadm --examine /dev/sdb6

(er van uit gaand dat de partitie sdb6 is)

[VanderWells]

Beste Mijzelf,

Wanneer ik bij de NAS kan zal ik de commando's uitvoeren. Ik kom hier zo snel mogelijk bij je op terug, mocht je me hiermee nog verder willen helpen.

- Van der Wells

[Mijzelf]

Is goed.

[VanderWells]

Daar ben ik weer, met een aantal screendumps van de resultaten die Terminal geeft.



De eerste commando laat zien dat sdd1 de NAS-schijf is, met z'n vele partities. Dit is wat het volgende commando zegt;

^{ubuntu@ubuntu:~$ sudo mdadm --examine /dev/sdd
/dev/sdd:
MBR Magic : aa55
Partition[0] : 1953525167 sectors at 1 (type ee)
ubuntu@ubuntu:~$}

Geen idee wat terminal hiermee zegt. Ik zou zo langs alle partities kunnen gaan, maar sdd is de partitie waar de data op staat.

- Van der Wells

[Ploink]

VanderWells schreef op donderdag 26 september 2013 @ 21:11:
Daar ben ik weer, met een aantal screendumps van de resultaten die Terminal geeft.



De eerste commando laat zien dat sdd1 de NAS-schijf is, met z'n vele partities. Dit is wat het volgende commando zegt;

ubuntu@ubuntu:~$ sudo mdadm --examine /dev/sdd

/dev/sdd is geen partitie, maar de hele schijf.
Wat is /dev/sdb2? Heb je nog een schijf van 1TB of zou dat 'm zijn?

[Mijzelf]

Nee, dit is niet de data partitie, maar de schijf zelf. In Linux heet een schijf (bijna) altijd sdx, waar x een letter [a...z] is. (Weet niet wat er gebeurt als je meer dan 26 schijven aansluit), en de partities heten sdxn, waarbij n het partitienummer is.
De output van mdadm geeft hier informatie over de schijf. De 1e sector bevat een partitie tabel, met 1 partitie type ee. Dat is een gereserveerd type, en geeft aan dat dit een GPT schijf is.

Als je de screendump uit de eerste post naast deze legt, dan zie je dat de sizes van sdd1-4 overeen komen met de eerste 4 partities. Je zoekt dus naar sdd5, maar die wordt niet herkent. (En niet herkent betekent hier dat hij niet in de partitietabel staat, en zegt niets over de eventuele inhoud)

Wat is er met deze schijf gebeurt sinds de startpost?

[ Voor 8% gewijzigd door Mijzelf op 26-09-2013 22:31 ]

[Uncle Mel]

Verwijderd

[ Voor 89% gewijzigd door Uncle Mel op 30-01-2014 21:22 ]

[Mijzelf]

Nee. Als de GPT ergens naar verwijst, staat het in /proc/partitions. Deze bevat gewoon (onder meer) de interpretatie van de partitietabel(len). Of de kernel iets kan met de inhoud van de partitie doet hier niet terzake.

De OP heeft dus een verminkte partitietabel, en een heleboel 'unallocated space' aan het einde van de disk.

[ninjazx9r98]

Mijzelf schreef op donderdag 26 september 2013 @ 22:13:
Nee, dit is niet de data partitie, maar de schijf zelf. In Linux heet een schijf (bijna) altijd sdx, waar x een letter [a...z] is. (Weet niet wat er gebeurt als je meer dan 26 schijven aansluit), en de partities heten sdxn, waarbij n het partitienummer is.

Bij meer dan 26 schijven komt er een extra letter bij.
De eerste 26 schijven zijn dus sda-sdz, vanaf schijf 27 wordt het sdaa-sdaz en daarna sdba-sdbz.
Enz enz.

[VanderWells]

De schijf ligt nu niets te doen en heeft ook een aantal maanden niks gedaan. in die paar maanden zaten een paar ingevingen om uit te proberen, kijken wat EaseUS Partition Master zegt, of er een programma is op Mac die de schijf kan lezen en tenslotte Ubuntu uitgeprobeerd zonder succes. De schijf zat in zulke gevallen intern of in een externe case.

Een verminkte partitietabel klinkt wel ernstig. Is er een manier om die te heropbouwen?

[Mijzelf]

Mogelijk. Een progamma als testdisk kan dat, voorop gesteld dat de partitie als zodanig herkenbaar is op schijf.

Maar voor je zoiets doet is het verstandig een lowlevel kopie te maken van de schijf, en de verdere recovery op de kopie te doen.
Heb je een Linux systeem en een minstens even grote 2e schijf beschikbaar? Alle data op deze 2e schijf zal worden vernietigd.

[VanderWells]

Ja, ik heb nog een 1TB harde schijf die helemaal leeg is. Ik heb ook nog een Ubuntu LiveUSB, maar kan het alleen met een geïnstalleerde Ubuntu?

[Mijzelf]

maar kan het alleen met een geïnstalleerde Ubuntu?

Bedoel je of Ubuntu geïnstalleerd moet zijn? Nee, dat hoeft niet. Linux is tamelijk relaxed met dat soort zaken.

Boot je PC van de LiveUSB en sluit de beide schijven aan. (Of andersom, als je dat beter uikomt).
Nu moet je de device namen van de beide schijven vinden:

code:

cat /proc/partitions

Je kunt de schijven herkennen aan de grootte, en de oude aan zijn 4 partities. De nieuwe schijf heeft geen partities, neem ik aan, dus die heeft alleen een device in de vorm sdx, en geen in de vorm sdxn.

Er vanuit gaand dat de oude, belangrijke, schijf sdd is, en de nieuwe, lege, schijf sde, kun je de schijf rauw kopiëren met het commando

code:

sudo dd if=/dev/sdd of=/dev/sde bs=16M

Hierbij staat if voor InputFile, of voor OutputFile, en bs voor BlockSize. Die laatste is niet zo boeiend, maar als je hem niet opgeeft gaat het kopiëren nodeloos lang duren.
Doublecheck dat if en of kloppen voor je het commando uitvoert. dd zal zonder verder vragen alles overschrijven wat je hem aanbied. Als je oude schijf als output wordt gegeven heb je een serieus probleem.

Het kopiëren gaat even duren. Wanneer een of beide schijven via USB zijn aangesloten is de doorvoer maximaal 25MB/sec, dus 1TB kost dan 40000 seconden, dat is ruim 11 uur.

[VanderWells]

Momenteel zit ik in Linux en heb ik de kapotte schijf en de lege schijf in de computer gedaan. Zo gaat het wat sneller.

De lege schijf heeft ook in de Silverstore NAS gezeten en daardoor dacht ik dat het misschien interessant is om beide schijven met hun partities naast elkaar te zien. In gparted kan ik overeenkomsten zien, maar ook duidelijke verschillen.


Dit is de schijf die niet gelezen wil worden


Dit is de lege schijf die ook in de SilverStore heeft gezeten en waarop ik de backup wilde gaan maken.

Is er hier iets bijzonders aan te zien? Anders ga ik door met het sudo dd-commando.

- van der wells

[Mijzelf]

KIJK UIT! volgens mij heb je de schijven verwisseld. 'De schijf die niet gelezen wil worden' heeft bij jou 5 partities, en de 'nieuwe schijf' heeft er 4, plus een hoop ongealloceerde ruimte.

Er vanuit gaand dat ze verwisseld zijn:
Jazeker. Er is iets bijzonders. De nieuwe schijf heeft een intakte partitietabel, die wel eens zou kunnen passen op de oude schijf.

Verder is het boeiend dat de 'Flags' van de partities van de defecte schijf zijn veranderd. Ik weet overigens niet wat we daarmee moeten/kunnen.

Het is dus aan te raden eerst de partitie tabel van de 'nieuwe disk' op te slaan:

sudo dd if=/dev/sda of=kopie_van_partitietabel bs=512 count=64

Zet deze file (kopie_van_partitietabel) ergens op een 'echte schijf', een USB stick ofzo. De gebruiksomgeving is waarschijnlijk weg na een reboot. Dan kunnen we die terugplaatsen als de lowlevel kopie is gemaakt.

Verder kun je even kijken naar de md status van de nieuwe schijf:

mdadm --examine /dev/sda5

[VanderWells]

Ik denk dat ze inderdaad verwisseld van elkaar zijn. Excuses! sdd heeft inderdaad 4 partities net als sdc. sdc is dus de schijf met de data en sda is de lege schijf.

Ik heb het sudo dd commando uitgevoerd en nu staat de partitietabel van sda veilig opgeslagen. het mdadm-commando zei het volgende;

[Mijzelf]

OK, dat verklaard waarom je de schijf oorspronkelijk niet kon lezen op een Linux systeem. De data partitie is inderdaad een member van een raid array, en die had dus eerst geassembleerd moeten worden.
Sommige distro's doen dat automatisch, maar die van jou blijkbaar niet. (Of de raid header was beschadigd, natuurlijk.)

sdd heeft inderdaad 4 partities net als sdc

Heb je TWEE verminkte schijven, of bedoel je dat sdc vroeger ook wel eens sdd is geweest?

[VanderWells]

Inderdaad, voordat sdc intern was, zat ie in een externe case. Toen werd hij sdd genoemd, zoals je kan zien in mijn screenshot van 26-9 21:11.

Dus een andere linux distro zou deze schijf wel kunnen lezen?

[Mijzelf]

VanderWells schreef op dinsdag 01 oktober 2013 @ 16:17:
Dus een andere linux distro zou deze schijf wel kunnen lezen?

Er vanuit gaand dat de raidheader en filesysteem intact zijn, kan elke distro hem lezen, alleen bij sommige distro's moet je met de hand de array assembleren.
Overigens, als deze schijf uit een 2 schijfs raid1 array komt, zal voor zover ik weet geen enkele distro hem automatisch assembleren. Een degraded array assembleren en mounten kan namelijk heftige impact hebben als de 2e schijf alleen tijdelijk afwezig is.

Maar op het moment is de partitietabel beschadigd, dus kan geen enkele distro er wat mee.

[VanderWells]

De schijf zat als enige schijf in de NAS. Dus dat kan het probleem niet zijn right?

De volgende stap is nu sudo dd if=/dev/sdc of=/dev/sda bs=16M en hem laten overschrijven?

[Mijzelf]

Ja, lijkt me wel.Dat gaat trouwens alsnog even duren. 100MB/sec? => 10000 seconden ~ 3 uur.

[VanderWells]

Hmm, het commando geeft me een foutmelding;




Misschien toch via usb proberen?

[Mijzelf]

Het is /dev/sdc, niet /dev/sdc/

[VanderWells]

Aha! de schijf is gekopieerd volgens Terminal. De volgende stap is met Testdisk de partition table fixen?

[Mijzelf]

Koppel nu de originele schijf los, om te voorkomen dat daar iets mee gebeurd.

Vervolgens kun je inderdaad testdisk laten lopen, maar we kunnen natuurlijk ook proberen om die partitie tabel terug te zetten.
Als het goed is is jouw kopie 32kB groot. Klopt?

In dat geval eerst weer de huidige tabel veiligstellen (kost niets, en je weet maar nooit)

sudo dd if=/dev/sda of=2e_kopie_van_partitietabel bs=512 count=64

waarbij je natuurlijk even moet checken of het nog steed sda is.
Vervolgens de oude kopie terugzetten:

sudo dd if=kopie_van_partitietabel of=/dev/sda bs=512 count=64

Als dat gebeurt is, reboot je, om de nieuwe tabel in te laten lezen.
Als het goed is zal

cat /proc/partitions

nu 5 partities laten zien, en kun je de raid status van sda5 opvragen:

mdadm --examine /dev/sda5

Lijkt dat op de raid header die je hier boven ergens hebt gepost, dan kun je de array assembleren:

mdadm --assemble /dev/md1 /dev/sda5 --run

Geeft dit geen foutmelding, dan kun je proberen te mounten

mkdir -p /tmp/mountpoint
mount /dev/md1 /tmp/mountpoint

Geeft dit ook geen foutmelding, dan zou je je data moeten kunnen terugvinden in /tmp/mountpoint

[VanderWells]

Wacht even, de partitietabel is inderdaad 32kb groot, maar de eerste commando laat me de corrupte partitietabel overschrijven op de correcte partitietabel juist? Nu ben ik mijn goede partitietabel kwijt

Edit: inderdaad, mijn usb stick, die eerst de goede partitietabel had gekopieerd, heeft nu nog maar 4 partities . Gelijk doorgaan naar testdisk dan?

[ Voor 27% gewijzigd door VanderWells op 02-10-2013 12:36 ]

[Ploink]

VanderWells schreef op woensdag 02 oktober 2013 @ 12:30:
Wacht even, de partitietabel is inderdaad 32kb groot, maar de eerste commando laat me de corrupte partitietabel overschrijven op de correcte partitietabel juist?

Heb je if (input file) en of (output file) omgewisseld?

sudo dd if=/dev/sda of=2e_kopie_van_partitietabel bs=512 count=64

Dit is van disk naar file dus. Als het goed is heb je nu backups van beide partitietabellen, tenzij je ergens de verkeerde disk hebt aangegeven...

[VanderWells]

Nee ik heb een nieuwe partitietabel overschreven op mijn bestaande partitietabel die ik had bewaard op een usb stick.

Ik had niet meer usb sticks.

[Mijzelf]

Gelijk doorgaan naar testdisk dan?

Ja, dat blijft dan over.

[Ploink]

VanderWells schreef op woensdag 02 oktober 2013 @ 12:47:
Ik had niet meer usb sticks.

Het is mogelijk om meer dan 1 file op een usb stik te bewaren.
Ik denk dat je het naar je usb device hebt geschreven dus /dev/sdX, maar je kan bij if/of ook gewoon een file naam opgeven.

Bovendien laat "cat /proc/partitions" nog de oude situatie zien nadat je de partitie tabel hebt overschreven, omdat de kernel zijn interne data niet automatisch ververst.

Gebruik daarom partprobe nadat je de partitie tabel overschrijft!

[ Voor 55% gewijzigd door Ploink op 02-10-2013 13:57 ]

[VanderWells]

Klopt, maar sudo dd overwrite compleet wat je hem geeft las ik even snel in een Wikipedia entry.



Testdisk is nu aan het lopen, is dit de goede instelling? Ik was aan het lezen en ik wilde terug, maar volgens mij betekent escape ook enter in het programma.

Hij was sneller klaar als ik dacht, hier zijn wat resultaten;



Wat is er nu precies gebeurt?

[Mijzelf]

Hij heeft gezocht naar alles wat een paritie zou kunnen zijn. Zo te zien komt alleen die MS Data aan het eind in aanmerking, gezien de size. Eigenlijk zou ik liever die Linux Raid daarboven hebben, gezien de metadata, maar die is veel te klein.
Dus 'Add' eerst die MS Data maar. Als dat geen mountbare partitie oplevert zetten we de partitietabel terug, en voegen handmatig die Linux Raid toe, met de eindsector van de MS Data.

[Ploink]

VanderWells schreef op woensdag 02 oktober 2013 @ 14:55:
Klopt, maar sudo dd overwrite compleet wat je hem geeft las ik even snel in een Wikipedia entry.

Je begrijpt mijn post niet helemaal want het is niet duidelijk waar je op reageert.

Dat dd de bestemming overschrijft is logisch als je zegt dat ie dat moet doen en je hebt de rechten. Hij gehoorzaamt prima

In linux is /dev/sda een disk, maar je kan er naar schrijven alsof het een file is.
Als je "dd if=/dev/sda of=/pad/naar/mijn/files/diskimage.img" doet dan krijg je de hele disk inhoud in een file die diskimage.img heet en andersom kan ook, snap je?

Na overschrijven moet de kernel de partitie opnieuw inlezen, anders weet linux niet dat er iets veranderd is aan je disk layout. "cat /proc/partitions" geeft data uit de cache van de kernel, niet direct van de disk!

[afbeelding]

Wat is er nu precies gebeurt?

Ik zie een 8 sector RAID header en een grote data partitie.
Lijkt erop dat je partititabel nu weer compleet is. Doe enter en Write. Als je dan reboot staat de disk met een beetje geluk op je desktop

[Thralas]

Ik snap uberhaupt niet waarom er losse partities worden weergegeven voor de RAID-partitie en MS-DATA (waarom herkent 'ie dat niet als ext?).

Dat is ook al zo in het eerste screenshot van testdisk, maar daar valt MS-DATA binnen de RAID-partitie, dat is nog enigzins verklaarbaar. Voor de werkelijke datapartitie is er ook een RAID-partitie, maar hier staat 'ie er enkel voor. Huh?

That said, op basis van je eerdere gparted-screenshots leek die MS-DATA te worden herkend als RAID-partitie door mdadm --examine, die recoveren zou dan inderdaad moeten werken (zoals de heren boven mij al aangeven).

[Ploink]

Het is een 1-disk raid, dus geen stripe of parity. Zonder raid header is het dus een gewone partitie. Testdisk veegt ze blijkbaar niet bij elkaar in 1 partitie.

Wel vreemd dat het type "ms data" is. Helaas bestaat er vrijwel geen documentatie van testdisk (niet gevonden tenminste), maar hiero hebben ze hetzelfde en blijkt gewoon dat ms data = ext3 om een of andere vage reden.

Doe anders eerst de "list files" voor die laatste partitie, dan kun je zien of het klopt.

[ Voor 5% gewijzigd door Ploink op 02-10-2013 16:27 ]

[Thralas]

Ploink schreef op woensdag 02 oktober 2013 @ 16:25:
Het is een 1-disk raid, dus geen stripe of parity. Zonder raid header is het dus een gewone partitie.

Dat is inderdaad logisch, maar dat verklaart niet helemaal waarom de RAID-metadata maar 8 sectors is ipv. de rest van de disk spant.

Bij de gparted screenshots was dit ook het geval (sda4 meta, sda5 filesystem), maar toch werkte een mdadm examine op enkel sda5? Raar.

[Mijzelf]

Ploink schreef op woensdag 02 oktober 2013 @ 16:25:
Wel vreemd dat het type "ms data" is.

Het is een GPT tabel, en testdisk moet dus een passende GUID kiezen als partitietype. En zowel Linux als Windows gebruiken voor 'platte filesystemen' MS Data. Er is geen aparte GUID voor elk filesysteem.

[VanderWells]

Ploink schreef op woensdag 02 oktober 2013 @ 16:11:
[...]

Je begrijpt mijn post niet helemaal want het is niet duidelijk waar je op reageert.

Dat dd de bestemming overschrijft is logisch als je zegt dat ie dat moet doen en je hebt de rechten. Hij gehoorzaamt prima

In linux is /dev/sda een disk, maar je kan er naar schrijven alsof het een file is.
Als je "dd if=/dev/sda of=/pad/naar/mijn/files/diskimage.img" doet dan krijg je de hele disk inhoud in een file die diskimage.img heet en andersom kan ook, snap je?

Ah okay, ik had er alleen geen diskimage van gemaakt. Die partitietabel werd letterlijk de partitietabel van de usb stick.

Mijzelf schreef op woensdag 02 oktober 2013 @ 16:05:
Hij heeft gezocht naar alles wat een paritie zou kunnen zijn. Zo te zien komt alleen die MS Data aan het eind in aanmerking, gezien de size. Eigenlijk zou ik liever die Linux Raid daarboven hebben, gezien de metadata, maar die is veel te klein.
Dus 'Add' eerst die MS Data maar. Als dat geen mountbare partitie oplevert zetten we de partitietabel terug, en voegen handmatig die Linux Raid toe, met de eindsector van de MS Data.

Okay als ik Add doe kan ik de starting sector, ending sector of partition type veranderen. Ik wil hier geen fouten in maken, maar het lijkt me dat ik de partition type moet veranderen?

[Mijzelf]

Nee, je hoeft het type niet te veranderen. Dat is alleen metadata in de partitietabel. Bij het mounten wordt het genegeerd.

[Thralas]

Partities zijn overigens al marked als primary, dus volgens mij kun je gewoon save & exit doen.

sudo file -s /dev/sd??

Is overigens ook wel handig als je eenmaal een werkende partitietabel hebt. Als het goed is, is de 'MS-DATA'-partitie dan ext3 en kun je 'm zo mounten.

[VanderWells]

Goed, ik ben nu weer in Linux. De schijf is nog steeds niet leesbaar, ook niet na Thralas zijn commando. Is er een stap die ik gemist heb?

[Mijzelf]

Wat was de output daarvan? En wat geeft

cat /proc/partitions

[VanderWells]

[Thralas]

Zo te zien heb je de partities die TestDisk had gevonden niet teruggeschreven naar de partitietabel. Opnieuw TestDisk runnen dus (kan overigens ook vanuit Linux, even sudo apt-get install testdisk runnen oid).



Vanaf dit scherm, dus met de SilverStore en DATAVOLUME-partitie listed op enter drukken, dan zie je als het goed is nogmaals een overzicht van hoe de partition table eruit zal zien. Klopt dat? Kies dan voor write en je bent klaar.

Het file-commando was overigens letterlijk bedoeld, dus inclusief de vraagtekens. Al kan '/dev/sdc?' ook als sdc de probleemschijf is.

[ Voor 6% gewijzigd door Thralas op 03-10-2013 18:19 ]

[VanderWells]

Holy shit ik kan hem lezen en alles zien! Wat een geweldige uitkomst.

Nu is er nog een stap en dat is de data kopieren naar een veilige schijf. De schijf waar ik naartoe wil kopieren is klaar, maar volgens Ubuntu heb ik niet de permissies om de data te verplaatsen? Is hier misschien een handige sudo commando voor?

edit: ik heb nu sudo dd if=/dev/sdc3 (DATA VOLUME) of=/dev/sda1 (LEGE SCHIJF) gedaan en dat gaat nu z'n gang. Ongelofelijk bedankt voor jullie hulp met deze schijf. Zonder jullie was het nooit gelukt, en daarom heb ik een gifje gevonden om ons succes te vieren.

[ Voor 33% gewijzigd door VanderWells op 03-10-2013 20:53 ]

[u_nix_we_all]

Waarschijnlijk heb je geen schrijfrechten op de doelmap. Die kun je aanpassen met

code:

sudo chmod 777 </pad/naar/doelmap>

Edit: Dit is een quick-and-dirty oplossing, je geeft iedereen lees en schrijfrechten op die map.

[ Voor 28% gewijzigd door u_nix_we_all op 03-10-2013 20:48 ]

[Mijzelf]

VanderWells schreef op donderdag 03 oktober 2013 @ 20:34:
Holy shit ik kan hem lezen en alles zien! Wat een geweldige uitkomst.

Gefeliciteerd!

ik heb nu sudo dd if=/dev/sdc3 (DATA VOLUME) of=/dev/sda1 (LEGE SCHIJF) gedaan en dat gaat nu z'n gang.

Hiermee kopieer je het hele filesysteem. De doelschijf zal hierna dus een ext3 of xfs filesysteem hebben. Of zo.

[Ploink]

Yep je kopieert het hele filesystem bit voor bit. Zorg wel dat (LEGE SCHIJF) minimaal even groot is als (DATA VOLUME), dan zou het in misschien goed gaan. Maar als LEGESCHIJF gemount is dan kan het ook erg mis gaan.

Beter had je de schijven allebij gemount en het cp commando gebruikt, dan kun je gewoon van ext3 naar ntfs kopiëren. Eventueel kun je ctrl-c doen en LEGESCHIJF opnieuw formatteren en dan cp doen.

sudo cp -ax "/pad/naar/data volume/"*  "/pad/naar/lege schijf/"

(dus niet /dev/sd.. gebruiken. Aanhalingstekens zijn alleen nodig als er spaties of speciale tekens in de naam staan)

[VanderWells]

Het hele filesysteem was inderdaad gekopieerd. Nu staat alle data veilig op een tweede schijf geformatteerd in HFS+.

Dit was een hele operatie en ik ben blij dat het met succes afgerond is. Daarbij weet ik ook weer een paar handige commando's in Linux, mocht ik die ooit weer nodig hebben!