|
| HP hardware RAID1... Fra : Jacob Tranholm |
Dato : 17-09-11 09:01 |
|
Vi har en ældre HP Proliant ML350 G4 server stående, hvor dataene i
serveren er blevet gemt på 2 SCSI-diske (Ultra 320 SCSI - 147GB) i en
hardware RAID1-opsætning.
Til dagligt har jeg intet med denne server at gøre, og jeg kan derfor
heller ikke forsvare, at der ikke er blevet taget løbende backup af
dataene. Men bundlinjen er, at backup'et af dataene er flere måneder
gammelt.
Nu er serveren brudt totalt sammen, og vi skal have dataene ud af
harddiskene og serveren skal skrottes. Men... Jeg har prøvet at flytte
harddiskene til en anden server, der kan læse SCSI-diskene, men ikke har
en HP hardware RAID controller. Og her kan systemet overhovedet ikke
identificere en partitionstabel på harddiskene. Jeg lavede så en bit for
bit kopi af harddiskene (vha. dd) og nu har jeg leget lidt med denne
kopi og kan stadig ikke få data ud af den. Harddisken lå i en Win 2003
server, hvor hele systemet var partitioneret i én NTFS-partition. Jeg
lod mig inspirere af følgende guide:
http://www.freesoftwaremagazine.com/articles/recovery_raid?page=0%2C0
og håbede på, at tingene var simplere, da vi bare snakker om et
RAID1-system. Men alle mine forsøg på at lægge en ny partitionstabel ned
over har ikke givet nogle positive resultater, da systemet stadig ikke
kan identificeres som et NTFS-filsystem.
Jeg håber lidt, at nogle af jer har erfaringer med at genskabe data fra
hardware RAID1, hvor RAID-controlleren ikke længere kan bruges, men hvor
diskene fungerer ganske udmærket.
Mvh. Jacob Tranholm
| |
Michael Rasmussen (17-09-2011)
| Kommentar Fra : Michael Rasmussen |
Dato : 17-09-11 09:40 |
|
On Sat, 17 Sep 2011 10:00:43 +0200
Jacob Tranholm <jt@drlund-gym.dk> wrote:
> Jeg håber lidt, at nogle af jer har erfaringer med at genskabe data fra hardware RAID1, hvor RAID-controlleren ikke længere kan bruges, men hvor diskene fungerer ganske udmærket.
Uden en identisk hardware raid controller ingen data!
--
Hilsen/Regards
Michael Rasmussen
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
A computer is like air conditioning: it becomes useless when you open
windows.
| |
Jacob Tranholm (17-09-2011)
| Kommentar Fra : Jacob Tranholm |
Dato : 17-09-11 09:59 |
|
Den 17-09-2011 10:39, Michael Rasmussen skrev:
> Uden en identisk hardware raid controller ingen data!
Det var jo svaret som jeg frygtede... Jeg har dog lidt svært ved at
forstå, at HP eller andre ikke har lavet et eller andet software, der
kan genskabe dataene uden controlleren.
Beklageligvis kommer dette ikke som en overraskelse for mig, og dette er
netop også hovedårsagen til, at jeg bruger software RAID på vores Linux
servere. Men i Windows-systemer er deres variant af software RAID
væsentligt ringere, og derfor bruger jeg sædvanligvis hardware RAID med
Windows serverne. Her er det lidt som at skulle vælge mellem pest og
kolera, enten kan du vælge hardware RAID med risiko for datatab hvis
RAID-controlleren bryder sammen eller også kan du benytte et væsentligt
ringere software RAID-system.
Mvh. Jacob Tranholm
| |
Jacob Tranholm (17-09-2011)
| Kommentar Fra : Jacob Tranholm |
Dato : 17-09-11 22:55 |
|
Den 17-09-2011 10:39, Michael Rasmussen skrev:
> Uden en identisk hardware raid controller ingen data!
Det er nu lykkedes uden en hardware raid controller...
Mvh. Jacob Tranholm
| |
Kent Friis (17-09-2011)
| Kommentar Fra : Kent Friis |
Dato : 17-09-11 09:46 |
|
Den Sat, 17 Sep 2011 10:00:43 +0200 skrev Jacob Tranholm:
> og håbede på, at tingene var simplere, da vi bare snakker om et
> RAID1-system. Men alle mine forsøg på at lægge en ny partitionstabel ned
> over har ikke givet nogle positive resultater, da systemet stadig ikke
> kan identificeres som et NTFS-filsystem.
Det har du forhåbentlig kun forsøgt på en kopi?
> Jeg håber lidt, at nogle af jer har erfaringer med at genskabe data fra
> hardware RAID1, hvor RAID-controlleren ikke længere kan bruges, men hvor
> diskene fungerer ganske udmærket.
Ingen erfaring, men de raid controllere jeg har arbejdet med har kunnet
genkende et raid-sæt selvom man flytter dem til en anden controller. Der
må altså ligge en eller anden header foran partitions-tabellen.
Har du prøvet at springe over en eller flere blokke, når du kopierer
disken? Jeg vil forvente at der dukker en normal partitionstabel op nogle
blokke inde på disken.
Altså "dd bs=512 skip=1" (og 2,3,4,5...)
Mvh
Kent
--
"The Brothers are History"
http://www.gianas-return.de/
| |
Jacob Tranholm (17-09-2011)
| Kommentar Fra : Jacob Tranholm |
Dato : 17-09-11 10:13 |
|
Den 17-09-2011 10:45, Kent Friis skrev:
> Den Sat, 17 Sep 2011 10:00:43 +0200 skrev Jacob Tranholm:
>> og håbede på, at tingene var simplere, da vi bare snakker om et
>> RAID1-system. Men alle mine forsøg på at lægge en ny partitionstabel ned
>> over har ikke givet nogle positive resultater, da systemet stadig ikke
>> kan identificeres som et NTFS-filsystem.
>
> Det har du forhåbentlig kun forsøgt på en kopi?
>
Naturligvis...
Under kopieringen pipede jeg dataene fra dd igennem gzip og split, og
min hovedkopi af harddisken ligger derfor i en lettere komprimeret
udgave, der er fordelt på flere filer. Så når jeg leger med harddisken
går jeg den modsatte vej og leger med et billede af harddisken, der ret
hurtigt kan genskabes (det tager dog lidt minutter at genskabe et
billede på 147GB).
>> Jeg håber lidt, at nogle af jer har erfaringer med at genskabe data fra
>> hardware RAID1, hvor RAID-controlleren ikke længere kan bruges, men hvor
>> diskene fungerer ganske udmærket.
>
> Ingen erfaring, men de raid controllere jeg har arbejdet med har kunnet
> genkende et raid-sæt selvom man flytter dem til en anden controller. Der
> må altså ligge en eller anden header foran partitions-tabellen.
>
> Har du prøvet at springe over en eller flere blokke, når du kopierer
> disken? Jeg vil forvente at der dukker en normal partitionstabel op nogle
> blokke inde på disken.
>
> Altså "dd bs=512 skip=1" (og 2,3,4,5...)
>
Det giver mening, og det vil jeg prøve.
Mvh. Jacob Tranholm
| |
Mogens Kjaer (17-09-2011)
| Kommentar Fra : Mogens Kjaer |
Dato : 17-09-11 14:46 |
|
On 09/17/2011 10:45 AM, Kent Friis wrote:
> Har du prøvet at springe over en eller flere blokke, når du kopierer
> disken? Jeg vil forvente at der dukker en normal partitionstabel op nogle
> blokke inde på disken.
>
> Altså "dd bs=512 skip=1" (og 2,3,4,5...)
Jeg ville kopiere hele disken og så prøve med at loop-mounte den
kopierede fil med offset=512, offset=1024, indtil der er bid.
Eller tage små bidder ud af den store fil og prøve med "file"
kommandoen hvad det er.
Mogens
--
Mogens Kjaer, mk@lemo.dk
http://www.lemo.dk
| |
Jacob Tranholm (17-09-2011)
| Kommentar Fra : Jacob Tranholm |
Dato : 17-09-11 19:16 |
|
Den 17-09-2011 15:46, Mogens Kjaer skrev:
> On 09/17/2011 10:45 AM, Kent Friis wrote:
>> Har du prøvet at springe over en eller flere blokke, når du kopierer
>> disken? Jeg vil forvente at der dukker en normal partitionstabel op nogle
>> blokke inde på disken.
>>
>> Altså "dd bs=512 skip=1" (og 2,3,4,5...)
>
> Jeg ville kopiere hele disken og så prøve med at loop-mounte den
> kopierede fil med offset=512, offset=1024, indtil der er bid.
>
> Eller tage små bidder ud af den store fil og prøve med "file"
> kommandoen hvad det er.
>
> Mogens
>
Angående tjekket med offsets lavede jeg følgende script:
-----
#!/bin/bash
COUNTER=0
while [ $COUNTER -lt 512000 ]; do
echo Taelleren er $COUNTER
losetup -o $COUNTER /dev/loop0 kontorservhd.img
mount -t ntfs /dev/loop0 /mnt/tmp
if [ "$?" = "0" ]; then
echo Mount lykkedes ved offset $COUNTER
exit 0
fi
sleep 1
losetup -d /dev/loop0
let COUNTER=COUNTER+512
done
exit 1
-----
Og dette gav ikke et positivt resultat... Sleep-kommandoen blev
hovedsageligt smidt med, da jeg skulle nå at se fejl-beskederne fra
mount. Og alle beskederne var identiske. Så dette løste ikke problemet.
Angående file kommandoen giver den følgende identifikation:
kontorservhd.img: DOS-executable
Dette giver ikke ret meget mening, men på den anden side var der
overhovedet ingen partitionstabel på disken. Og det kunne jo tænkes, at
controlleren gemmer det hele i et format, der overhovedet ikke ligner
normale partitioner.
Jeg har ikke prøvet med file på forskellige segmenter af filen endnu...
I øjeblikket tror jeg mest på Michael Rasmussens kommentar: "Uden en
identisk hardware raid controller ingen data!".
Mvh. Jacob Tranholm
| |
Kent Friis (17-09-2011)
| Kommentar Fra : Kent Friis |
Dato : 17-09-11 19:28 |
|
Den Sat, 17 Sep 2011 20:15:32 +0200 skrev Jacob Tranholm:
>
> Dette giver ikke ret meget mening, men på den anden side var der
> overhovedet ingen partitionstabel på disken. Og det kunne jo tænkes, at
> controlleren gemmer det hele i et format, der overhovedet ikke ligner
> normale partitioner.
Partitioner er en software-ting. Hvad hardwaren gør bør ligge udenom.
Prøv file kommandoen med offsets, den version af file jeg har plejer
at kalde en partitionstabel "x86 boot sector".
Mvh
Kent
--
"The Brothers are History"
http://www.gianas-return.de/
| |
Jacob Tranholm (17-09-2011)
| Kommentar Fra : Jacob Tranholm |
Dato : 17-09-11 20:20 |
|
Den 17-09-2011 20:27, Kent Friis skrev:
> Den Sat, 17 Sep 2011 20:15:32 +0200 skrev Jacob Tranholm:
>>
>> Dette giver ikke ret meget mening, men på den anden side var der
>> overhovedet ingen partitionstabel på disken. Og det kunne jo tænkes, at
>> controlleren gemmer det hele i et format, der overhovedet ikke ligner
>> normale partitioner.
>
> Partitioner er en software-ting. Hvad hardwaren gør bør ligge udenom.
>
> Prøv file kommandoen med offsets, den version af file jeg har plejer
> at kalde en partitionstabel "x86 boot sector".
>
> Mvh
> Kent
Så vidt jeg husker læser file kun de første bits af filen, og jeg valgte
derfor kun at trække et relativt lille stykke ud af gangen. Denne test
er lavet på en Gentoo server med følgende script:
-----
#!/bin/bash
COUNTER=0
while [ $COUNTER -lt 100 ]; do
echo "dd if=kontorservhd.img bs=512 skip=$COUNTER count=100"
dd if=kontorservhd.img bs=512 skip=$COUNTER count=100 >tempfile.dat
file tempfile.dat
sleep 1
let COUNTER=COUNTER+1
done
rm -f tempfile.dat
-----
Ved skip 64 og 74-79 blev der angivet "data" som filtype, og ved skip 65
blev der angivet "MS Windows icon resource". For alle de andre blev
typen angivet som "DOS-executable".
Jeg har også lavet tjekket for de første 1000 filsegmenter. Og her viser
sig det samme billede...
Mvh. Jacob Tranholm
| |
Kent Friis (17-09-2011)
| Kommentar Fra : Kent Friis |
Dato : 17-09-11 21:06 |
|
Den Sat, 17 Sep 2011 21:19:52 +0200 skrev Jacob Tranholm:
> Den 17-09-2011 20:27, Kent Friis skrev:
>> Den Sat, 17 Sep 2011 20:15:32 +0200 skrev Jacob Tranholm:
>>>
>>> Dette giver ikke ret meget mening, men på den anden side var der
>>> overhovedet ingen partitionstabel på disken. Og det kunne jo tænkes, at
>>> controlleren gemmer det hele i et format, der overhovedet ikke ligner
>>> normale partitioner.
>>
>> Partitioner er en software-ting. Hvad hardwaren gør bør ligge udenom.
>>
>> Prøv file kommandoen med offsets, den version af file jeg har plejer
>> at kalde en partitionstabel "x86 boot sector".
>>
>> Mvh
>> Kent
>
> Så vidt jeg husker læser file kun de første bits af filen, og jeg valgte
> derfor kun at trække et relativt lille stykke ud af gangen. Denne test
> er lavet på en Gentoo server med følgende script:
> -----
> #!/bin/bash
>
> COUNTER=0
> while [ $COUNTER -lt 100 ]; do
> echo "dd if=kontorservhd.img bs=512 skip=$COUNTER count=100"
> dd if=kontorservhd.img bs=512 skip=$COUNTER count=100 >tempfile.dat
> file tempfile.dat
> sleep 1
> let COUNTER=COUNTER+1
> done
>
> rm -f tempfile.dat
> -----
>
> Ved skip 64 og 74-79 blev der angivet "data" som filtype, og ved skip 65
> blev der angivet "MS Windows icon resource". For alle de andre blev
> typen angivet som "DOS-executable".
>
> Jeg har også lavet tjekket for de første 1000 filsegmenter. Og her viser
> sig det samme billede...
Det lyder underligt. "DOS-executable" skulle gerne betyde at
filen starter med "MZ", og det burde alle blokkene ikke gøre.
Har du prøvet at se på filen med hexdump?
Enten er disk-formatet meget underligt (hvis controlleren skal proppe
ekstra bytes ind i hver blok, bliver der plads til mindre data, som den
skal finde et andet sted til - både HDD og OS forventer at en blok er
512 bytes), eller også er din "file" underlig.
På min (ikke RAID) harddisk, får jeg flg. resultat:
# for i in $(seq 0 15); do dd if=/dev/sda bs=512 skip=$i count=4 2>/dev/null
| file -; done
/dev/stdin: x86 boot sector; partition 1: ID=0xee, starthead 0, startsector
1, 1953525167 sectors, extended partition table (last)\011, code offset 0x63
/dev/stdin: data
/dev/stdin: data
/dev/stdin: data
/dev/stdin: data
/dev/stdin: data
/dev/stdin: data
/dev/stdin: data
/dev/stdin: data
/dev/stdin: data
/dev/stdin: data
/dev/stdin: data
/dev/stdin: data
/dev/stdin: data
/dev/stdin: data
/dev/stdin: data
Jeg skal helt op til skip=2048 (1MB), før jeg får:
/dev/stdin: Linux rev 1.0 ext3 filesystem data (needs journal recovery)
Mvh
Kent
--
"The Brothers are History"
http://www.gianas-return.de/
| |
Jacob Tranholm (17-09-2011)
| Kommentar Fra : Jacob Tranholm |
Dato : 17-09-11 22:00 |
|
Den 17-09-2011 22:06, Kent Friis skrev:
>
> Det lyder underligt. "DOS-executable" skulle gerne betyde at
> filen starter med "MZ", og det burde alle blokkene ikke gøre.
>
> Har du prøvet at se på filen med hexdump?
>
> Enten er disk-formatet meget underligt (hvis controlleren skal proppe
> ekstra bytes ind i hver blok, bliver der plads til mindre data, som den
> skal finde et andet sted til - både HDD og OS forventer at en blok er
> 512 bytes), eller også er din "file" underlig.
>
> På min (ikke RAID) harddisk, får jeg flg. resultat:
>
> # for i in $(seq 0 15); do dd if=/dev/sda bs=512 skip=$i count=4 2>/dev/null
> | file -; done
> /dev/stdin: x86 boot sector; partition 1: ID=0xee, starthead 0, startsector
> 1, 1953525167 sectors, extended partition table (last)\011, code offset 0x63
> /dev/stdin: data
> /dev/stdin: data
> /dev/stdin: data
> /dev/stdin: data
> /dev/stdin: data
> /dev/stdin: data
> /dev/stdin: data
> /dev/stdin: data
> /dev/stdin: data
> /dev/stdin: data
> /dev/stdin: data
> /dev/stdin: data
> /dev/stdin: data
> /dev/stdin: data
> /dev/stdin: data
>
> Jeg skal helt op til skip=2048 (1MB), før jeg får:
>
> /dev/stdin: Linux rev 1.0 ext3 filesystem data (needs journal recovery)
>
> Mvh
> Kent
For at teste Gentoos "file" kommando, har jeg også kørt følgende:
for i in $(seq 0 2048); do dd if=/dev/sda bs=512 skip=$i count=10
2>/dev/null | file -; done > hd_fileinfo_gentoo_sda.txt
Filen kan findes her:
http://jtranholm.dk/hd_fileinfo_gentoo_sda.txt
Og jeg har også kørt den tilvarende kommando på backupdisken:
for i in $(seq 0 2048); do dd if=kontorservhd.img bs=512 skip=$i
count=10 2>/dev/null | file -; done > hd_fileinfo_gentoo_kontorservhd.txt
Filen kan findes her:
http://jtranholm.dk/hd_fileinfo_gentoo_kontorservhd.txt
Mvh. Jacob Tranholm
| |
Jacob Tranholm (17-09-2011)
| Kommentar Fra : Jacob Tranholm |
Dato : 17-09-11 22:18 |
|
Den 17-09-2011 23:00, Jacob Tranholm skrev:
> Og jeg har også kørt den tilvarende kommando på backupdisken:
> for i in $(seq 0 2048); do dd if=kontorservhd.img bs=512 skip=$i
> count=10 2>/dev/null | file -; done > hd_fileinfo_gentoo_kontorservhd.txt
>
> Filen kan findes her:
> http://jtranholm.dk/hd_fileinfo_gentoo_kontorservhd.txt
Jeg læste lige selv dataene... Og for skip=1088 fås:
/dev/stdin: x86 boot sector, Microsoft Windows XP MBR, Serial
0xbfb77568; partition 1: ID=0x7, active, starthead 1, startsector 63,
286728057 sectors, code offset 0xc0
Og for skip=1151 fås:
/dev/stdin: x86 boot sector, code offset 0x52, OEM-ID "NTFS ",
sectors/cluster 8, reserved sectors 0, Media descriptor 0xf8, heads 255,
hidden sectors 63, dos < 4.0 BootSector (0x80)
I min mount-test prøvede jeg kun for de første 1000 segmenter og nåede
derfor ikke hertil.
Jeg fortsætter mine tests...
Mvh. Jacob Tranholm
| |
Jacob Tranholm (17-09-2011)
| Kommentar Fra : Jacob Tranholm |
Dato : 17-09-11 22:27 |
|
Den 17-09-2011 23:18, Jacob Tranholm skrev:
> Den 17-09-2011 23:00, Jacob Tranholm skrev:
>> Og jeg har også kørt den tilvarende kommando på backupdisken:
>> for i in $(seq 0 2048); do dd if=kontorservhd.img bs=512 skip=$i
>> count=10 2>/dev/null | file -; done > hd_fileinfo_gentoo_kontorservhd.txt
>>
>> Filen kan findes her:
>> http://jtranholm.dk/hd_fileinfo_gentoo_kontorservhd.txt
>
> Jeg læste lige selv dataene... Og for skip=1088 fås:
> /dev/stdin: x86 boot sector, Microsoft Windows XP MBR, Serial
> 0xbfb77568; partition 1: ID=0x7, active, starthead 1, startsector 63,
> 286728057 sectors, code offset 0xc0
>
> Og for skip=1151 fås:
> /dev/stdin: x86 boot sector, code offset 0x52, OEM-ID "NTFS ",
> sectors/cluster 8, reserved sectors 0, Media descriptor 0xf8, heads 255,
> hidden sectors 63, dos < 4.0 BootSector (0x80)
>
> I min mount-test prøvede jeg kun for de første 1000 segmenter og nåede
> derfor ikke hertil.
>
> Jeg fortsætter mine tests...
>
> Mvh. Jacob Tranholm
Opgaven er løst...
Det hele fungerede med:
losetup -o 589312 /dev/loop0 kontorservhd.img
mount -t ntfs /dev/loop0 /mnt/tmp
Tak for alles hjælp...
Mvh. Jacob Tranholm
| |
(Thorbjørn Ravn (17-09-2011)
| Kommentar Fra : (Thorbjørn Ravn |
Dato : 17-09-11 10:04 |
|
Jacob Tranholm <jt@drlund-gym.dk> writes:
> harddiskene og serveren skal skrottes. Men... Jeg har prøvet at flytte
> harddiskene til en anden server, der kan læse SCSI-diskene, men ikke
> har en HP hardware RAID controller. Og her kan systemet overhovedet
Hvis data er vigtige var det måske en ide at anskaffe sig en ny af sådan
en HP hardware RAID controller, bare til dette projekt?
--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"
| |
Jacob Tranholm (17-09-2011)
| Kommentar Fra : Jacob Tranholm |
Dato : 17-09-11 11:18 |
|
Den 17-09-2011 11:03, Thorbjørn Ravn Andersen, 20110917 skrev:
> Jacob Tranholm<jt@drlund-gym.dk> writes:
>
>> harddiskene og serveren skal skrottes. Men... Jeg har prøvet at flytte
>> harddiskene til en anden server, der kan læse SCSI-diskene, men ikke
>> har en HP hardware RAID controller. Og her kan systemet overhovedet
>
> Hvis data er vigtige var det måske en ide at anskaffe sig en ny af sådan
> en HP hardware RAID controller, bare til dette projekt?
Det er ikke RAID-controlleren, der er brudt ned. Der sidder en HP
PS-3701-1 strømforsyning i maskinen, og denne strømforsyning brød ned i
starten af august måned. Efterfølgende købte vi en ny HP PS-3701-1
strømforsyning og satte denne ind i maskinen. Den kørte med denne
strømforsyning i ca. 14 dage uden problemer, men herefter begyndte det
hele at køre ustabilt igen. Og nu kan vi overhovedet ikke få liv i
maskinen...
Vi har en anden server stående, der nemt kan overtage opgaverne. Så
vores eneste problem er at få dataene ud af harddiskene, og herefter
skrottes serveren.
Mvh. Jacob Tranholm
| |
(Thorbjørn Ravn (17-09-2011)
| Kommentar Fra : (Thorbjørn Ravn |
Dato : 17-09-11 10:05 |
|
Jacob Tranholm <jt@drlund-gym.dk> writes:
> pest og kolera, enten kan du vælge hardware RAID med risiko for
> datatab hvis RAID-controlleren bryder sammen eller også kan du benytte
Tillader budgettet reservedele?
--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"
| |
Mogens Kjaer (17-09-2011)
| Kommentar Fra : Mogens Kjaer |
Dato : 17-09-11 10:09 |
|
On 09/17/2011 10:00 AM, Jacob Tranholm wrote:
> Vi har en ældre HP Proliant ML350 G4 server stående, hvor dataene i
> serveren er blevet gemt på 2 SCSI-diske (Ultra 320 SCSI - 147GB) i en
> hardware RAID1-opsætning.
Præcis hvilken controller sad der i denne?
Mogens
--
Mogens Kjaer, mk@lemo.dk
http://www.lemo.dk
| |
Jacob Tranholm (17-09-2011)
| Kommentar Fra : Jacob Tranholm |
Dato : 17-09-11 10:30 |
|
Den 17-09-2011 11:08, Mogens Kjaer skrev:
> On 09/17/2011 10:00 AM, Jacob Tranholm wrote:
>> Vi har en ældre HP Proliant ML350 G4 server stående, hvor dataene i
>> serveren er blevet gemt på 2 SCSI-diske (Ultra 320 SCSI - 147GB) i en
>> hardware RAID1-opsætning.
>
> Præcis hvilken controller sad der i denne?
>
Jeg kan ikke få maskinen online og kan derfor ikke give dig et sikkert
svar. Men så vidt jeg husker hedder den noget i stil med: HP Smart Array
E200 Controller... Denne controller bruges i en lang række HP-servere.
Mvh. Jacob Tranholm
| |
Mogens Kjaer (17-09-2011)
| Kommentar Fra : Mogens Kjaer |
Dato : 17-09-11 10:47 |
|
On 09/17/2011 11:29 AM, Jacob Tranholm wrote:
> Jeg kan ikke få maskinen online og kan derfor ikke give dig et sikkert
> svar. Men så vidt jeg husker hedder den noget i stil med: HP Smart Array
> E200 Controller... Denne controller bruges i en lang række HP-servere.
Kan du ikke flytte den over i en anden maskine?
Det behøver jo ikke være en server.
Boot maskinen i Linux og se om den vil genkende controller og diske.
Mogens
--
Mogens Kjaer, mk@lemo.dk
http://www.lemo.dk
| |
Jacob Tranholm (17-09-2011)
| Kommentar Fra : Jacob Tranholm |
Dato : 17-09-11 10:52 |
|
Den 17-09-2011 11:46, Mogens Kjaer skrev:
> On 09/17/2011 11:29 AM, Jacob Tranholm wrote:
>> Jeg kan ikke få maskinen online og kan derfor ikke give dig et sikkert
>> svar. Men så vidt jeg husker hedder den noget i stil med: HP Smart Array
>> E200 Controller... Denne controller bruges i en lang række HP-servere.
>
> Kan du ikke flytte den over i en anden maskine?
>
> Det behøver jo ikke være en server.
>
> Boot maskinen i Linux og se om den vil genkende controller og diske.
>
> Mogens
>
Jeg har ikke maskinen her... Men så vidt jeg husker må controlleren være
bygget ind i bundkortet (der er kun et ekstra netkort som indstikskort -
så vidt jeg husker).
Mvh. Jacob Tranholm
| |
(Thorbjørn Ravn (21-09-2011)
| Kommentar Fra : (Thorbjørn Ravn |
Dato : 21-09-11 23:19 |
|
Jacob Tranholm <jt@drlund-gym.dk> writes:
> Opgaven er løst...
>
> Det hele fungerede med:
> losetup -o 589312 /dev/loop0 kontorservhd.img
> mount -t ntfs /dev/loop0 /mnt/tmp
Tillykke. Hvis jeg skal være ærlig havde jeg ikke troet det ville
lykkedes.
Lyder som om du har en god sag når du skal argumentere for passende
indkøb til næste sikkerhedskopieringsløsning.
--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"
| |
|
|