|  | 		    
					
        
         
          
         
	
          | |  | 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!"
 
 
 |  |  | 
 |  |