RAID5 startet nicht mehr
Hallo Leute, jetzt ist's passiert, nach dem letzten Schritt bei der Umstellung meines 11.0 Homeserver startet das RAID5 nicht mehr. Leitfaden hierzu waren die beiden Artikel der c't 1 und 2 2009. Kurz zu meiner Systemumgebung. Im System sind nun 3 Platten (2x1TB und 1x750GB) auf dem jetzt 1 256MB RAID1 (/dev/md0) als Boot-Partition und ein 1,5TB RAID5 (dev/md1) mit drüberliegenden LVM liegt, in dem wiederum die Root, /var und /srv als separate Volumes enthalten sind. Das System lief prima und nur eine Sache wollte ich noch machen: Das RAID5 auf die maximale Größe erweitern. Nachdem der Befehl mdadm /dev/md1 --grow --size=max im laufenden System nicht wollte, habe ich KNOPPIX 5.3 gebootet und diese Operation da ausgeführt. Das lief auch ohne Fehlermeldung durch, fdisk zeigte mir das /dev/md1 auch mit der neuen Größe korrekt an. Das LVM lies sich auch in KNOPPIX starten und das testweise mounten der Volumes klappte auch. Nur der anschließende Start des eigentlichen Systems schlug fail, da das RAID5 und somit auch das LVM nicht mehr gestartet werden konnte. Habe dann nochmals KNOPPIX gebootet, da konnte ich das RAID5 auch nicht mehr korrekt starten, das LVM startete mit Fehler aber die Volumes konnte ich noch sehen aber nicht mehr mounten. Habe dann das Rettungssystem der 11.1 gestartet, der kann natürlich auch nicht mehr das RAID5 starten, wohingegen das RAID1 korrekt gestartet wird. Beim Start kommt es hierbei zu folgenden (Fehler-)Meldungen: # mdadm --assemble -v --force /dev/md1 /dev/sda2 /dev/sdb3 /dev/sdc3 mdadm: looking for devices for /dev/md1 mdadm: /dev/sda2 is identified as a member of /dev/md/1, slot 0. mdadm: /dev/sdb3 is identified as a member of /dev/md/1, slot 2. mdadm: /dev/sdc3 is identified as a member of /dev/md/1, slot 1. mdadm: added /dev/sdc3 to /dev/md/1 as 1 mdadm: added /dev/sdb3 to /dev/md/1 as 2 mdadm: added /dev/sda2 to /dev/md/1 as 0 mdadm: failed to RUN_ARRAY /dev/md/1: Input/output error In /var/log/messages steht dann May 31 11:16:35 Rescue kernel: md: bind<sdc3> May 31 11:16:35 Rescue kernel: md: bind<sdb3> May 31 11:16:35 Rescue kernel: md: bind<sda2> May 31 11:16:35 Rescue kernel: raid5: device sda2 operational as raid disk 0 May 31 11:16:35 Rescue kernel: raid5: device sdb3 operational as raid disk 2 May 31 11:16:35 Rescue kernel: raid5: device sdc3 operational as raid disk 1 May 31 11:16:35 Rescue kernel: raid5: allocated 3176kB for md1 May 31 11:16:35 Rescue kernel: raid5: raid level 5 set md1 active with 3 out of 3 devices, algorithm 0 May 31 11:16:35 Rescue kernel: RAID5 conf printout: May 31 11:16:35 Rescue kernel: --- rd:3 wd:3 May 31 11:16:35 Rescue kernel: disk 0, o:1, dev:sda2 May 31 11:16:35 Rescue kernel: disk 1, o:1, dev:sdc3 May 31 11:16:35 Rescue kernel: disk 2, o:1, dev:sdb3 May 31 11:16:35 Rescue kernel: attempt to access beyond end of device May 31 11:16:35 Rescue kernel: sda2: rw=8, want=1464613923, limit=1464613920 May 31 11:16:35 Rescue kernel: attempt to access beyond end of device May 31 11:16:35 Rescue kernel: sdb3: rw=8, want=1464613923, limit=1464613920 May 31 11:16:35 Rescue kernel: attempt to access beyond end of device May 31 11:16:35 Rescue kernel: sdc3: rw=8, want=1464613923, limit=1464613920 May 31 11:16:35 Rescue kernel: md1: bitmap initialisation failed: -5 May 31 11:16:35 Rescue kernel: md1: failed to create bitmap (-5) Ein # mdadm --detail /dev/md1 spuckt aus /dev/md1: Version : 1.00 Creation Time : Wed May 27 18:20:08 2009 Raid Level : raid5 Used Dev Size : 732306816 (698.38 GiB 749.88 GB) Raid Devices : 3 Total Devices : 3 Persistence : Superblock is persistent Update Time : Sat May 30 16:47:05 2009 State : active, Not Started Active Devices : 3 Working Devices : 3 Failed Devices : 0 Spare Devices : 0 Layout : left-asymmetric Chunk Size : 128K Name : 1 UUID : b90c1a32:a7ceb166:2004618a:dc8b44cf Events : 32502 Number Major Minor RaidDevice State 4 8 2 0 active sync /dev/sda2 5 8 35 1 active sync /dev/sdc3 3 8 19 2 active sync /dev/sdb3 Es erscheint mir offensichtlich, dass ewas mit dem Vergrößern nicht geklappt hat, da er über das Ende hinaus zugreifen will. Die Frage stellt sich jetzt, ist da noch etwas zu Reparieren? In Netz konnte ich bei meiner Suche leider kein vergleichbares Fehlerszenario finden. Weis jemand Rat? Ich brauche ja wohl nicht zu erwähnen dass da eine Menge Daten drauf sind die ich eigentlich wieder haben möchte. Zwar habe ich komplette Backups des Systems auf Band aber halt nicht die wirklich großen Sachen wie Virtuelle Maschinen, Videos, iSCSI Laufwerke Vielen Dank für Antworten schon im voraus Gruß Manfred ps Euch allen frohe Pfingsten -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Sunday 31 May 2009 12:45:32 schrieb Manfred Kreisl:
1464613920
Hallo Manfred, Ad1: KMail hat Deinen Text verschluckt, ich wollte aber eh nicht Alles hier drin haben. Jetzt zum eigentlichen Thema: Das ist eine haarige Situation, mit der ich auch keine Erfahrung habe; also vorsichtig sein und weitere Meinungen abwarten. Was mir auffällt, ist, dass Du einen RAID-Superblock in der Version 1.00 hast; bei der OpenSuse 11.0 (kurz OS genannt) ist 00.90 aber der Default. Beide RAID-Superblock-Varianten befinden sich persistent am Ende der Komponenten-Geräte (also der /dev/sd*). Normalerweise werden RAID-Arrays mit persistentem RAID-Superblock mit dem Kommando: mdadm --assemble --scan oder kurz mdadm -A -s zusammengefügt. Hattest Du das vorher im Rettungssystem ausprobiert? Den Parameter --force würde ich erst mal weglassen, um bei der Analyse keine gefährlichen Operationen zu veranlassen. Nach meiner Meinung sind MD-RAID-Arrays zur Zeit noch sehr empfindlich in Bezug auf die Version des Kernel-Treibers (*1), also bitte auch auf die Kernel-Versionen achten. Wenn da verschiedene Treiber-Versionen im Spiel sind, könnte ich mir vorstellen, dass ein 'mdadm --grow --size=max', ausgeführt im Rettungssystem, helfen könnte, wenn der RAID-Superblock erkannt worden ist. Durch die Angaben in der Kommandozeile kann das aber verhindert worden sein. Alternativ kannst Du Deinen Taschenrechner bemühen und die Array-Größe selbst berechnen. Frag mich aber nicht nach einer Formel, die würde ich vor der Überprüfung an einem Test-Array nicht formulieren. Es ist Dein Risiko, siehe oben. Tschö, Emil 1:) Treiber aus den OS-Kernel (2.6.25.x in OS11.0 bzw. 1.6.27.x in OS 11.1) können keine Partitionen auf RAID-Arrays verarbeiten (udev-Events für /dev/md2p1 scheinen zu fehlen) , wohingegen bei 2.6.28 und 2.6.29 diese Geräteknoten erzeugt werden -- Registered Linux User since 19940320 -------------------------------------------------- Emil Stephan, Marktplatz 39, 53773 Hennef, Germany voice: +49-2242-84438 Accelerate Windows: 9.81 m/sec^2 would be adequate -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Emil Stephan schrieb:
Am Sunday 31 May 2009 12:45:32 schrieb Manfred Kreisl:
1464613920
Hallo Manfred,
Ad1: KMail hat Deinen Text verschluckt, ich wollte aber eh nicht Alles hier Macht nix, kann sie dir ja per PM nochmal schicken ;-)
drin haben. Jetzt zum eigentlichen Thema:
Das ist eine haarige Situation, mit der ich auch keine Erfahrung habe; also vorsichtig sein und weitere Meinungen abwarten. ACK Was mir auffällt, ist, dass Du einen RAID-Superblock in der Version 1.00 hast; bei der OpenSuse 11.0 (kurz OS genannt) ist 00.90 aber der Default. Beide Bist du dir da sicher? Ich hab die Raids mit Yast eingerichtet, sowohl das RAID1 (welches ja ok ist) als auch das RAID5 hat Metadata 1.0 Hat mich zugegebenermaßen auch etwas irritiert.
RAID-Superblock-Varianten befinden sich persistent am Ende der Komponenten-Geräte (also der /dev/sd*). Normalerweise werden RAID-Arrays mit persistentem RAID-Superblock mit dem Kommando: mdadm --assemble --scan oder kurz mdadm -A -s zusammengefügt. Hattest Du das vorher im Rettungssystem ausprobiert? Nein, wie geschrieben KNOPPIX 5.3, erst nachdem es passiert ist hab ich das Rettungssystem der 11.1 konsultiert
Den Parameter --force würde ich erst mal weglassen, um bei der Analyse keine gefährlichen Operationen zu veranlassen. Ich hatte es zuerst ohne und dann mit --force probiert, verändert hat das allerdings nichts Nach meiner Meinung sind MD-RAID-Arrays zur Zeit noch sehr empfindlich in Bezug auf die Version des Kernel-Treibers (*1), also bitte auch auf die Kernel-Versionen achten. Na toll, ich hab hier den 2.6.28.7 und KNOPPIX hat den 2.6.24
Wenn da verschiedene Treiber-Versionen im Spiel sind, könnte ich mir vorstellen, dass ein 'mdadm --grow --size=max', ausgeführt im Rettungssystem, helfen könnte, wenn der RAID-Superblock erkannt worden ist. Durch die Angaben Das Problem ist dass der grow nur für aktive Raids anwendbar ist, und gerade aktivieren kann ich es ja nicht.
in der Kommandozeile kann das aber verhindert worden sein. Alternativ kannst Du Deinen Taschenrechner bemühen und die Array-Größe selbst berechnen. Frag mich aber nicht nach einer Formel, die würde ich vor der Überprüfung an einem Test-Array nicht formulieren. Es ist Dein Risiko, siehe oben. Ja, das ist mir klar. Ich hab übrigens zwei Raid Tools gefunden die aber unter Windows laufen und nicht (lt. Beschreibung zumindest) LVM's unterstützen. Also nützen mir die nix.
Mittlerweile habe ich übrigens vom Tape mein System wieder in einen unbenutzten Teil einer 1TB Platte restauriert und es läuft wieder eine Art "Notbetrieb", allerdings ohne die Raids. Ich geb da dir Hoffnung noch nicht auf.
1:) Treiber aus den OS-Kernel (2.6.25.x in OS11.0 bzw. 1.6.27.x in OS 11.1) können keine Partitionen auf RAID-Arrays verarbeiten (udev-Events Dann verstehe ich nicht dass meine Tests in einer VM sowohl mit 11.0 als auch mit 11.1 problemlos geklappt hatten. Allerdings immer ohne den vermaledeiten grow Befehl, der mich ja offensichtlich erst in den Schlamassel gebracht hat für /dev/md2p1 scheinen zu fehlen) , wohingegen bei 2.6.28 und 2.6.29 diese Geräteknoten erzeugt werden
Gruß Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Mon, 01 Jun 2009 18:45:36 +0200 schriebst Du:
Bist du dir da sicher? Ich hab die Raids mit Yast eingerichtet, sowohl das RAID1 (welches ja ok ist) als auch das RAID5 hat Metadata 1.0
YaST2 legt RAID-Superblöcke der Version 1.0 an. Philipp -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Monday 01 June 2009 20:27:26 schrieb Philipp Thomas:
Am Mon, 01 Jun 2009 18:45:36 +0200 schriebst Du:
Bist du dir da sicher? Ich hab die Raids mit Yast eingerichtet, sowohl das RAID1 (welches ja ok ist) als auch das RAID5 hat Metadata 1.0
YaST2 legt RAID-Superblöcke der Version 1.0 an. Philipp
Hallo Phillip, danke für die Information. Aber einen kleiner Beitrag zum Problem wäre nicht schlecht. Tschö, Emil -- Registered Linux User since 19940320 -------------------------------------------------- Emil Stephan, Marktplatz 39, 53773 Hennef, Germany voice: +49-2242-84438 Accelerate Windows: 9.81 m/sec^2 would be adequate -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Mon, 1 Jun 2009 21:13:39 +0200 schriebst Du:
Aber einen kleiner Beitrag zum Problem wäre nicht schlecht.
Wenn ich zum Problem selber etwas hätte sagen können, hätte ich das getan :) Philipp -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Manfred Am Monday 01 June 2009 18:45:36 schrieb Manfred Kreisl:
Emil Stephan schrieb:
Am Sunday 31 May 2009 12:45:32 schrieb Manfred Kreisl:
1464613920
Hallo Manfred,
Ad1: KMail hat Deinen Text verschluckt, ich wollte aber eh nicht Alles hier
Macht nix, kann sie dir ja per PM nochmal schicken ;-) brauchst Du nicht, habe ich noch hier.
drin haben. Jetzt zum eigentlichen Thema:
Das ist eine haarige Situation, mit der ich auch keine Erfahrung habe; also vorsichtig sein und weitere Meinungen abwarten.
ACK
Was mir auffällt, ist, dass Du einen RAID-Superblock in der Version 1.00 hast; bei der OpenSuse 11.0 (kurz OS genannt) ist 00.90 aber der Default. Beide
Bist du dir da sicher? Ich hab die Raids mit Yast eingerichtet, sowohl das RAID1 (welches ja ok ist) als auch das RAID5 hat Metadata 1.0 Hat mich zugegebenermaßen auch etwas irritiert. Also meine RAID-Superblocks sind von der Version 00.90. Diese habe ich allerdings nicht mit yast, sondern mit mdadm eingerichtet.
RAID-Superblock-Varianten befinden sich persistent am Ende der Komponenten-Geräte (also der /dev/sd*). Normalerweise werden RAID-Arrays mit persistentem RAID-Superblock mit dem Kommando: mdadm --assemble --scan oder kurz mdadm -A -s zusammengefügt. Hattest Du das vorher im Rettungssystem ausprobiert?
Nein, wie geschrieben KNOPPIX 5.3, erst nachdem es passiert ist hab ich das Rettungssystem der 11.1 konsultiert
Den Parameter --force würde ich erst mal weglassen, um bei der Analyse keine gefährlichen Operationen zu veranlassen.
Ich hatte es zuerst ohne und dann mit --force probiert, verändert hat das allerdings nichts
Nach meiner Meinung sind MD-RAID-Arrays zur Zeit noch sehr empfindlich in Bezug auf die Version des Kernel-Treibers (*1), also bitte auch auf die Kernel-Versionen achten.
Na toll, ich hab hier den 2.6.28.7 und KNOPPIX hat den 2.6.24 Mit der 2.6.24 habe ich leider keine Erfahrung mit RAID. Die 2,6,28,7 hat in der von mir erwarteten Weise funktioniert, Sprich, der Kernel hat die Arrays automatisch zusammengefügt. Aber das Problem mit /dev/md2p1 sollte nach meinem Verständnis für Dich keine Rolle spielen, weil Du ein LVM darüber gelegt hast. Die Partitionierung wird dann vermutlich mit LVM abgewickelt. Das will und werde ich auch nicht testen, weil ich diese Vermischung von RAID und LVM, gelinde gesagt, nicht gut finde,
Wenn da verschiedene Treiber-Versionen im Spiel sind, könnte ich mir vorstellen, dass ein 'mdadm --grow --size=max', ausgeführt im Rettungssystem, helfen könnte, wenn der RAID-Superblock erkannt worden ist. Durch die Angaben
Das Problem ist dass der grow nur für aktive Raids anwendbar ist, und gerade aktivieren kann ich es ja nicht.+ Nach Deinem 'mdadm --detail ...' wird es aber als active ausgewiesen, aber nicht als Started. Hast Du mal /proc/mdstat per cat bemüht?
in der Kommandozeile kann das aber verhindert worden sein. Alternativ kannst Du Deinen Taschenrechner bemühen und die Array-Größe selbst berechnen. Frag mich aber nicht nach einer Formel, die würde ich vor der Überprüfung an einem Test-Array nicht formulieren. Es ist Dein Risiko, siehe oben.
Ja, das ist mir klar. Ich hab übrigens zwei Raid Tools gefunden die aber unter Windows laufen und nicht (lt. Beschreibung zumindest) LVM's unterstützen. Also nützen mir die nix. Genau, die werden mit ganz anderen Verwaltungstrukturen arbeiten und somit sogar höchst gefährlich sein können.
Mittlerweile habe ich übrigens vom Tape mein System wieder in einen unbenutzten Teil einer 1TB Platte restauriert und es läuft wieder eine Art "Notbetrieb", allerdings ohne die Raids. Ich geb da dir Hoffnung noch nicht auf.
1:) Treiber aus den OS-Kernel (2.6.25.x in OS11.0 bzw. 1.6.27.x in OS 11.1) können keine Partitionen auf RAID-Arrays verarbeiten (udev-Events
Dann verstehe ich nicht dass meine Tests in einer VM sowohl mit 11.0 als auch mit 11.1 problemlos geklappt hatten. Allerdings immer ohne den vermaledeiten grow Befehl, der mich ja offensichtlich erst in den Schlamassel gebracht hat Ich habe das bewusst als Randnotiz an das Ende gestellt, weil es bei Dir im Zusammenhang mit LVM nicht relevant sein dürfte.
für /dev/md2p1 scheinen zu fehlen) , wohingegen bei 2.6.28 und 2.6.29 diese Geräteknoten erzeugt werden
Gruß Manfred
Wenn --grow nicht mehr geht, weil nicht aktiv( oder nicht gestartet, was auch immer), und ein Notsystem aktiv ist, würde ich es riskieren, das Array mit mdadm neu anzulegen, nicht mit yast, und neu zu befüllen. Und nicht vergessen /etc/mdadm.conf zu editieren, denn da sollte die UUID drinstehen. Tschö, Emil -- Registered Linux User since 19940320 -------------------------------------------------- Emil Stephan, Marktplatz 39, 53773 Hennef, Germany voice: +49-2242-84438 Accelerate Windows: 9.81 m/sec^2 would be adequate -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Emil, Emil Stephan schrieb:
Das will und werde ich auch nicht testen, weil ich diese Vermischung von RAID und LVM, gelinde gesagt, nicht gut finde, Würde mich interessieren warum
Wenn da verschiedene Treiber-Versionen im Spiel sind, könnte ich mir vorstellen, dass ein 'mdadm --grow --size=max', ausgeführt im Rettungssystem, helfen könnte, wenn der RAID-Superblock erkannt worden ist. Durch die Angaben Das Problem ist dass der grow nur für aktive Raids anwendbar ist, und gerade aktivieren kann ich es ja nicht.+ Nach Deinem 'mdadm --detail ...' wird es aber als active ausgewiesen, aber nicht als Started. Hast Du mal /proc/mdstat per cat bemüht?
Ja klar, da steht dann: # cat /proc/mdstat Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] [linear] md0 : active raid1 sdc1[0] sdb1[2] sda1[1] 265028 blocks super 1.0 [3/3] [UUU] bitmap: 0/9 pages [0KB], 16KB chunk md1 : inactive sdb2[4] sdc3[3] sda3[5] 2196920448 blocks super 1.0 unused devices: <none> Die blocks Angabe ist natürlich völliger Blödsinn, warum auch immer
Ja, das ist mir klar. Ich hab übrigens zwei Raid Tools gefunden die aber unter Windows laufen und nicht (lt. Beschreibung zumindest) LVM's unterstützen. Also nützen mir die nix. Genau, die werden mit ganz anderen Verwaltungstrukturen arbeiten und somit sogar höchst gefährlich sein können. Glaub ich nicht, die Tools reparieren (leider ??) nix, sondern versuchen nur die Daten auf ein separates Medium kopierbar zu machen.
Wenn --grow nicht mehr geht, weil nicht aktiv( oder nicht gestartet, was auch immer), und ein Notsystem aktiv ist, würde ich es riskieren, das Array mit mdadm neu anzulegen, nicht mit yast, und neu zu befüllen. Und nicht vergessen /etc/mdadm.conf zu editieren, denn da sollte die UUID drinstehen.
Sind dann nicht alle Daten futsch? Ich hab das auch schon als Tip irgendwo gelesen, aber das möchte ich doch wirklich als allerletzten Versuch machen. Ok, das werd' ich auch mal in meiner Test-VM probieren, die hab ich glücklicherweise aufm meinem Win-XP System noch Gruß Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Manfred Kreisl schrieb:
Wenn --grow nicht mehr geht, weil nicht aktiv( oder nicht gestartet, was auch immer), und ein Notsystem aktiv ist, würde ich es riskieren, das Array mit mdadm neu anzulegen, nicht mit yast, und neu zu befüllen. Und nicht vergessen /etc/mdadm.conf zu editieren, denn da sollte die UUID drinstehen. Sind dann nicht alle Daten futsch? Ich hab das auch schon als Tip irgendwo gelesen, aber das möchte ich doch wirklich als allerletzten Versuch machen. Ok, das werd' ich auch mal in meiner Test-VM probieren, die hab ich glücklicherweise aufm meinem Win-XP System noch
Also, das hab ich grad mal in der Test-VM probiert. Hab einfach mal in KNOPPIX 6.1 ein # mdadm --create /dev/md1 --level=5 --raid-devices=3 /dev/hda3 /dev/hdb3 missing gemacht und oh Wunder oh Wunder das LVM lässt sich noch starten. Allerdings das OS bootet nicht mehr, liegt wohl daran dass sich die ID's geändert haben und die in der initrd nicht mehr passen. Seltsam ist auch noch, dass ich wenn ich # mdadm --examine --scan --config=partitions aufrufe ich zweimal das ARRAY /dev/md1 gelistet bekomme mit zwei verschiedenen UUIDs Die ganze Sache verwirrt mich mehr und mehr Gruß Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Tuesday 02 June 2009 13:12:56 schrieb Manfred Kreisl:
Manfred Kreisl schrieb:
Wenn --grow nicht mehr geht, weil nicht aktiv( oder nicht gestartet, was auch immer), und ein Notsystem aktiv ist, würde ich es riskieren, das Array mit mdadm neu anzulegen, nicht mit yast, und neu zu befüllen. Und nicht vergessen /etc/mdadm.conf zu editieren, denn da sollte die UUID drinstehen.
Sind dann nicht alle Daten futsch? Ich hab das auch schon als Tip irgendwo gelesen, aber das möchte ich doch wirklich als allerletzten Versuch machen. Ok, das werd' ich auch mal in meiner Test-VM probieren, die hab ich glücklicherweise aufm meinem Win-XP System noch
Also, das hab ich grad mal in der Test-VM probiert. Hab einfach mal in KNOPPIX 6.1 ein # mdadm --create /dev/md1 --level=5 --raid-devices=3 /dev/hda3 /dev/hdb3 missing gemacht und oh Wunder oh Wunder das LVM lässt sich noch starten. Allerdings das OS bootet nicht mehr, liegt wohl daran dass sich die ID's geändert haben und die in der initrd nicht mehr passen. Seltsam ist auch noch, dass ich wenn ich # mdadm --examine --scan --config=partitions aufrufe ich zweimal das ARRAY /dev/md1 gelistet bekomme mit zwei verschiedenen UUIDs Die ganze Sache verwirrt mich mehr und mehr
Gruß Manfred
Hallo Manfred, Ich denke (hoffe), dass die Daten auf dem Array erst dann weg sind, wenn Du ein neues Dateisystem oder ein neues LVM anlegst. Dann könntest Du nach Erzeugung des Arrays das LVM vielleicht starten, Da Du die Daten auf einem Notsystem verfügbar hast (habe ich doch hoffentlich richtig verstanden), dann kannst Du die Daten ja auch zurückkopieren, wenn es schief geht. Ich habe meinen Kernel so konfiguriert, dass ich keine initrd brauche, ich glaube aber nicht, dass die beim Booten Probleme macht, sondern die /boot/grub/menu.lst oder die Einträge in der /etc/fstab. Ich mounte meine Dateisysteme hier via Label, da habe ich es in der Hand, ob es geht oder nicht (wenn ich das Erstellen des Labels vergesse, kann man aber mit e2label nachholen). Hier meine Zeilen aus der menu.lst: title Emil -- openSUSE 11.0 - 2.6.29.4 root (hd0,1) kernel /boot/vmlinuz-2.6.29.4-emil root=/dev/md0 resume=/dev/sda1 \ splash=none showopts noinitrd vga=0x346 Und hier aus der /etc/fstab: LABEL=root / ext2 acl,user_xattr 1 1 LABEL=usr /usr ext3 acl,user_xattr 1 2 LABEL=var /var ext3 acl,user_xattr 1 2 LABEL=opt /opt ext3 acl,user_xattr 1 2 LABEL=srv /srv ext3 acl,user_xattr 1 2 LABEL=tmp /tmp ext2 acl,user_xattr 0 2 Man könnte fast sagen, um eine Operation am offenen Herzen kommst Du vielleicht nicht mehr herum. Mit --config=partitions ignoriert er die Konfigurationsdatei und schaut in /proc/partitions nach, welche Geräte er scannen soll. Vermutlich findet er da 2 RAID-Superblöcke, einen alten und einen neuen. Ich hatte eine Zeit lang ein RAID-1 auf meinen externen Backup-Platten. Da externe Platten und deren Bedienung aber unsicher sind (mal legen diese sich zur falschen Zeit schlafen, mal vergesse ich, eine einzuschalten), bin ich wieder zur Spiegelung via rsync zurückgekehrt. Ein Scan mit mdadm hat mir das Array aber immer noch angezeigt. Ich habe dann ganz. ganz scharf gerechnet und mit dd die alten RAID-Superblöcke gelöscht. Tschö, Emil -- Registered Linux User since 19940320 -------------------------------------------------- Emil Stephan, Marktplatz 39, 53773 Hennef, Germany voice: +49-2242-84438 Accelerate Windows: 9.81 m/sec^2 would be adequate -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Emil, danke dass du dir so viel Gedanken über mein Problem machst. Emil Stephan schrieb:
Hallo Manfred,
Ich denke (hoffe), dass die Daten auf dem Array erst dann weg sind, wenn Du ein neues Dateisystem oder ein neues LVM anlegst. Dann könntest Du nach Erzeugung des Arrays das LVM vielleicht starten, Da Du die Daten auf einem Notsystem verfügbar hast (habe ich doch hoffentlich richtig verstanden), dann Nicht ganz. Nur die unbedingt notwendigen Sachen halt. VM's, iSCSI Drives, Videos CD/DVD Images sind alle weg kannst Du die Daten ja auch zurückkopieren, wenn es schief geht. Ich habe meinen Kernel so konfiguriert, dass ich keine initrd brauche, ich glaube aber nicht, dass die beim Booten Probleme macht, sondern die /boot/grub/menu.lst oder die Einträge in der /etc/fstab. Ich mounte meine Dateisysteme hier via Label, da habe ich es in der Hand, ob es geht oder nicht (wenn ich das Erstellen des Labels vergesse, kann man aber mit e2label nachholen). So in der Art geht's bei LVM auch. Und für meine /boot Partition hab ich das auch per Label
Hier meine Zeilen aus der menu.lst: title Emil -- openSUSE 11.0 - 2.6.29.4 root (hd0,1) kernel /boot/vmlinuz-2.6.29.4-emil root=/dev/md0 resume=/dev/sda1 \ splash=none showopts noinitrd vga=0x346
Und hier aus der /etc/fstab: LABEL=root / ext2 acl,user_xattr 1 1 LABEL=usr /usr ext3 acl,user_xattr 1 2 LABEL=var /var ext3 acl,user_xattr 1 2 LABEL=opt /opt ext3 acl,user_xattr 1 2 LABEL=srv /srv ext3 acl,user_xattr 1 2 LABEL=tmp /tmp ext2 acl,user_xattr 0 2
Man könnte fast sagen, um eine Operation am offenen Herzen kommst Du vielleicht nicht mehr herum. Jaa, so ist es. Aber leider ist der Patient jetzt tot (s.u.) Mit --config=partitions ignoriert er die Konfigurationsdatei und schaut in /proc/partitions nach, welche Geräte er scannen soll. Vermutlich findet er da 2 RAID-Superblöcke, einen alten und einen neuen. Seh ich auch so Ich hatte eine Zeit lang ein RAID-1 auf meinen externen Backup-Platten. Da externe Platten und deren Bedienung aber unsicher sind (mal legen diese sich zur falschen Zeit schlafen, mal vergesse ich, eine einzuschalten), bin ich wieder zur Spiegelung via rsync zurückgekehrt. Ein Scan mit mdadm hat mir das Array aber immer noch angezeigt. Ich habe dann ganz. ganz scharf gerechnet und mit dd die alten RAID-Superblöcke gelöscht. Das geht aber auch mit mdadm --zero-superblock /dev/<partition> So hab ich das geplättet
Tschö, Emil
Ich habe jetzt das RAID5 erneut angelegt in der Hoffnung (in der Test-VM ging's ja so lala) das das LVM dann wieder da ist. Dem war allerdings leider nicht so. Ich vermute mal dass da halt schon so viel zerklopft war, dass halt nix mehr ging. Habe jetzt das geschrottete RAID5 völlig Platt gemacht (s.o.) und lege es gerade neu an. Ist grad am resyncen. Ich habe mich so entschieden, da lieber ein Ende mit Schrecken als ein Schrecken ohne Ende ;-), denn auf eine tage/wochenlange Baustelle mit ungewissem Ausgang habe ich wirklich auch kein Verlangen. Ist zwar nicht so meine Art nach drei Tagen die Flinte ins Korn zu werfen aber ich habe echt keinen Nerv und keine Lust mehr. Bis dann Gruß Manfred Und danke auch alle anderen die sich Gedanken gemacht haben -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Manfred Kreisl schrieb:
Hallo Emil,
...
Habe jetzt das geschrottete RAID5 völlig Platt gemacht (s.o.) und lege es gerade neu an. Ist grad am resyncen. Ich habe mich so entschieden, da lieber ein Ende mit Schrecken als ein Schrecken ohne Ende ;-), ... Und danke auch alle anderen die sich Gedanken gemacht haben
Schade das die Daten nun einmal weg sind. Aber auch daraus lernt man ja schließlich. Evtl hilft es ja genau Dein Eingangs beschriebenes Vorgehen noch einmal in einer VM nachzustellen....? Ich habe zwar auf RAID 1 auch ein LVM liegen, habe aber bisher noch nicht am RAID dranrum gebastelt. -- Gruß Axel -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Axel, Axel Birndt schrieb:
Manfred Kreisl schrieb:
Hallo Emil,
...
Habe jetzt das geschrottete RAID5 völlig Platt gemacht (s.o.) und lege es gerade neu an. Ist grad am resyncen. Ich habe mich so entschieden, da lieber ein Ende mit Schrecken als ein Schrecken ohne Ende ;-), ... Und danke auch alle anderen die sich Gedanken gemacht haben
Schade das die Daten nun einmal weg sind. Aber auch daraus lernt man ja schließlich.
Ja, das ist wohl wahr. Allerdings weis ich nicht so genau welche Lehren ich daraus ziehen soll. Ein vollständiges Backup von 1/2 TB erscheint mir halt sehr schwer durchführbar. So sichere ich halt nur diese Dinge auf Band, die ich als wirklich wichtig ansehe. Nun ja, vielleicht denke ich dann doch mal auf die Anschaffung einer externen TB Platte für solche Zwecke nach, aber im Worst-Case ist die dann auch gerade kaputt, wenn man sie wirklich braucht. Und ein Freund von diesem externen Gedöns bin ich auch nicht. Leider ist es genau so gekommen wie ich es befürchtet hatte. Durch das RAID ist es im Problemfall wieder um Faktoren schwieriger an seine Daten heranzukommen. So wie ich das momentan sehe ist das ja wohl eher kontraproduktiv.
Evtl hilft es ja genau Dein Eingangs beschriebenes Vorgehen noch einmal in einer VM nachzustellen....?
Hab ich mir auch schon gedacht, aber ich bin mir sicher dass da das Problem nicht auftritt. Ich habe ja wie gesagt das gesamte Szenario in einer VM vorher 2x durchexerziert. Allerdings halt ohne ein grow.
Ich habe zwar auf RAID 1 auch ein LVM liegen, habe aber bisher noch nicht am RAID dranrum gebastelt.
Muss man ja auch nicht wenn alles funktioniert Gruß Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Manfred Kreisl wrote:
Hallo Axel,
Axel Birndt schrieb:
Manfred Kreisl schrieb:
Hallo Emil,
...
Habe jetzt das geschrottete RAID5 völlig Platt gemacht (s.o.) und lege es gerade neu an. Ist grad am resyncen. Ich habe mich so entschieden, da lieber ein Ende mit Schrecken als ein Schrecken ohne Ende ;-), ... Und danke auch alle anderen die sich Gedanken gemacht haben
Schade das die Daten nun einmal weg sind. Aber auch daraus lernt man ja schließlich.
Ja, das ist wohl wahr. Allerdings weis ich nicht so genau welche Lehren ich daraus ziehen soll. Ein vollständiges Backup von 1/2 TB erscheint mir halt sehr schwer durchführbar. So sichere ich halt nur diese Dinge auf Band, die ich als wirklich wichtig ansehe. Nun ja, vielleicht denke ich dann doch mal auf die Anschaffung einer externen TB Platte für solche Zwecke nach, aber im Worst-Case ist die dann auch gerade kaputt, wenn man sie wirklich braucht. Und ein Freund von diesem externen Gedöns bin ich auch nicht.
Aus diesen Gründen habe ich meinen Server etwas anders konfiguriert: - Storage auf einem Hardware Raid5 - /boot und / und /root sind NICHT in einem LVM, sondern auf normalen Partitionen, damit sollte ich die LVM-Tools zur Verfügung haben, wenn es Probleme mit LVM gibt. - das Backup erfolgt per rsnapshot auf eine per SATA2 angeschlossene Wechsel-Platte, so ist auch ein TB an Sicherungsvolumen kein Problem und ich kann im laufenden Betrieb wechseln. Heutzutage ist das Fassungsvermögen von modernen SATA-Platten einfach nicht mehr mit Bändern bezahlbar. rsnapshot arbeitet zuverlässig und schnell, auch ein Restore ist einfach und schnell. Bei unserem Band-Backup in der Firma überlege ich mir immer genau, ob ich die 20-50 Minuten warten will, bis der Autoloader die Datei ausgegraben hat. :-/ -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Sandy, Sandy Drobic schrieb:
Aus diesen Gründen habe ich meinen Server etwas anders konfiguriert:
- Storage auf einem Hardware Raid5
Diese Lösung ist bestimmt sicherer als ein SW-Raid, solange man einen Raid-Controller als Reserve im Schrank liegen hat. Auf diesen "Luxus" wollte ich eigentlich verzichten. Nun, jetzt bin ich da etwas klüger.
- /boot und / und /root sind NICHT in einem LVM, sondern auf normalen Partitionen, damit sollte ich die LVM-Tools zur Verfügung haben, wenn es Probleme mit LVM gibt.
Na ja, /boot hab ich auch nicht im LVM, da meines Wissens Grub damit eh nicht umgehen kann.
- das Backup erfolgt per rsnapshot auf eine per SATA2 angeschlossene Wechsel-Platte, so ist auch ein TB an Sicherungsvolumen kein Problem und ich kann im laufenden Betrieb wechseln. Heutzutage ist das Fassungsvermögen von modernen SATA-Platten einfach nicht mehr mit Bändern bezahlbar.
Da stimme ich dir vollkommen zu
rsnapshot arbeitet zuverlässig und schnell, auch ein Restore ist einfach und schnell. Bei unserem Band-Backup in der Firma überlege ich mir immer genau, ob ich die 20-50 Minuten warten will, bis der Autoloader die Datei ausgegraben hat. :-/
Ja, da braucht man schon Geduld. Bislang hat mir das Tape immer gute Dienste gebracht, da ich noch nie ein völliges Restore machen musste. Und für ein paar einzelne Dateien bzw. Verzeichnisse ist es mir allemal schnell genug. Gruß Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Tue, 02 Jun 2009 17:49:53 +0200 schriebst Du:
Heutzutage ist das Fassungsvermögen von modernen SATA-Platten einfach nicht mehr mit Bändern bezahlbar.
Kommt darauf an, wieviel Wert Dir deine Daten sind :) Wenn du Geschäftsdaten hast, die Du für 10 Jahre vorhalten *musst*, dann sind Dir auch die Kosten für eine LTO4-Library und Bänder nicht zu hoch. Wenn es allerdings um private Daten geht, sind die Preise für dem Fassungvermögen moderner SATA-Platten angemessenen Band-Lösungen eindeutig zu hoch. Zumindest wenn man nicht wie ich das Glück hat, ein AIT2-Laufwerk und einen ordentlichen Schwung Bänder für praktisch umsonst abstauben zu können. Nun warte ich zwar eine erhebliche Zeit, um die Daten zu sichern bzw. die Bänder zu wechseln, aber letztendlich habe ich nur ca. dreissig Euro für den SCSI-Controller ausgeben müssen. Philipp -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Philipp Thomas wrote:
Am Tue, 02 Jun 2009 17:49:53 +0200 schriebst Du:
Heutzutage ist das Fassungsvermögen von modernen SATA-Platten einfach nicht mehr mit Bändern bezahlbar.
Kommt darauf an, wieviel Wert Dir deine Daten sind :) Wenn du Geschäftsdaten hast, die Du für 10 Jahre vorhalten *musst*, dann sind Dir auch die Kosten für eine LTO4-Library und Bänder nicht zu hoch. Wenn es allerdings um private Daten geht, sind die Preise für dem Fassungvermögen moderner SATA-Platten angemessenen Band-Lösungen eindeutig zu hoch.
Selbst bei kleineren Unternehmen sehe ich ein Backup auf Platte (natürlich redundante Sätze) als Alternative zu einer Bandlösung. Die wenigsten kleinen Firmen führen aussagekräftige Restore-Tests durch. Und die Plattenlösung lässt sich ohne jedes Problem auf neue größere Platten umsetzen, währen die Bandlösung nach wenigen Jahren meist schon wieder am Anschlag ist, jedenfalls erheblich schneller als die 10 Jahre. :-(( Vielen Firmen geht es wie mir im Augenblick: wir sind gerade im Umstieg auf Tivoli Storage Manager mit einer LTO4 Library. Vorher ein Backup mit ArcServe und Autoloader. Jetzt läuft beides parallel, wobei ich produktiv nur ArcServe nutze, weil ich für die Handhabung von TSM noch keine Zeit gefunden habe. Das Ding ist eine Blackbox die ich nicht durchschaue und der ich deshalb auch nicht vertraue. :-/ Also habe ich jetzt ein 50000 Euro Monster da stehen, was ich (noch) nicht verwende. Die (nicht geringe) Zeit für die Einarbeitung werde ich mir wohl aus den Rippen schneiden dürfen, anders werde ich es nicht produktiv bekommen. :-/
Zumindest wenn man nicht wie ich das Glück hat, ein AIT2-Laufwerk und einen ordentlichen Schwung Bänder für praktisch umsonst abstauben zu können. Nun warte ich zwar eine erhebliche Zeit, um die Daten zu sichern bzw. die Bänder zu wechseln, aber letztendlich habe ich nur ca. dreissig Euro für den SCSI-Controller ausgeben müssen.
Ich weiss nicht, genau die Sicherungszeit hat mich von der Bandsicherung abgenabelt. Früher habe ich auch bei mir zuhause die Sicherung auf ein Band vorgenommen, ein DLT7000 mit 35 GB Kapazität. Aber die Sicherung brauchte bald einfach zu lange, und ich musste mehrere Bänder einschieben, was die Sicherungszeiten einfach ins Unendliche verlängerte, schließlich war ich nicht immer zur Stelle, wenn ein neues Band eingelegt werden musst. Auch der Punkt Restore ist bei älteren Bandlaufwerken ein kritisches Thema. Wenn es 3 Tage dauert, bis alle Daten wieder zurückgesichert sind, dann ist die Sicherung vermutlich ungeeignet. Das Ergebnis war, dass ich immer seltener ein Backup machte, weil es zu aufwendig und lästig war. Die Lehre, die ich daraus gezogen hatte, war klar: Ein Backup muss einfach, zuverlässig und weitestgehend automatisch ablaufen, sonst wird es nicht durchgeführt. Außerdem muss es eine Gesamtsicherung durchführen können. Wenn man anfängt, "nur wichtige Daten" zu sichern, dann fällt man früher oder später auf die Nase. Unter Linux erfüllt rsnapshot alle Ansprüche an ein Backup: - Redundanz (ich verwende mehrere Sicherungsplatten) - vollständig automatische Sicherung jeden Tag - Transparenz und Anpassungsfähigkeit Wenn ich so eine Lösung auch noch für Windows finde, dann bin ich endlich zufrieden. Ich werde mir mal in der nächsten Zeit Bacula ansehen. (^-^) -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Wenn ich so eine Lösung auch noch für Windows finde, dann bin ich endlich zufrieden. Ich werde mir mal in der nächsten Zeit Bacula ansehen. (^-^)
http://personal-backup.rathlev-home.de/ und http://www.versionbackup.de/download.html könnten helfen. Für größere Umgebungen sicher nicht geeignet aber um ein paar Windowssysteme wegzussichern sollte es reichen. Konkret lasse ich es so laufen das mindestens einmal am Tag versionsweise die Verzeichnisse des Users auf ein NAS gesichert werden der sich gerade anmeldet. Da allle Windowssystem virtuell laufen gibt es noch Sicherungen des kompletten Gastes in größeren zeitlichen Abständen bzw. nach größeren Änderungen. Gruß i.A. Ralf Prengel Manager Customer Care Comline AG Hauert 8 D-44227 Dortmund/Germany Fon +49 231 97575 904 Fax +49 231 97575 257 Mobil +49 151 10831 157 EMail Ralf.Prengel@comline.de www.comline.de Vorstand Stephan Schilling, Erwin Leonhardi Aufsichtsrat Dr. Franz Schoser (Vorsitzender) HR Dortmund B 14570 USt.-ID-Nr. DE 124727422 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Wednesday 03 June 2009 10:01:54 schrieb Sandy Drobic:
Philipp Thomas wrote:
Am Tue, 02 Jun 2009 17:49:53 +0200 schriebst Du:
Heutzutage ist das Fassungsvermögen von modernen SATA-Platten einfach nicht mehr mit Bändern bezahlbar.
...
Unter Linux erfüllt rsnapshot alle Ansprüche an ein Backup: - Redundanz (ich verwende mehrere Sicherungsplatten) - vollständig automatische Sicherung jeden Tag - Transparenz und Anpassungsfähigkeit
Hallo Sandy, Ich benutze zwar noch komprimierte cpio-Archive für den Backup, dem werden vom Script noch Informationen über die RAID-Konfiguration und die Partitionierung hinzugefügt. Ich hoffe damit in der Lage zu sein, mein System von NULL wiederherzustellen. Ich habe mir irgendwann überlegt, was ich dafür brauche, und es zusammengebracht.
Wenn ich so eine Lösung auch noch für Windows finde, dann bin ich endlich zufrieden. Ich werde mir mal in der nächsten Zeit Bacula ansehen. (^-^)
Schau Dir auch mal Acronis True Image an. Es ist keine reine Imaging-Software. Man kann auch einzelne Dateien aus den Archiven zurückholen. Kostet zwar, aber nicht zu viel. Tschö, Emil -- Registered Linux User since 19940320 -------------------------------------------------- Emil Stephan, Marktplatz 39, 53773 Hennef, Germany voice: +49-2242-84438 Accelerate Windows: 9.81 m/sec^2 would be adequate -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Emil Stephan wrote:
> Am Wednesday 03 June 2009 10:01:54 schrieb Sandy Drobic:
>> Philipp Thomas wrote:
>>> Am Tue, 02 Jun 2009 17:49:53 +0200 schriebst Du:
>>>> Heutzutage ist das Fassungsvermögen von modernen SATA-Platten einfach
>>>> nicht mehr mit Bändern bezahlbar.
> ...
>> Unter Linux erfüllt rsnapshot alle Ansprüche an ein Backup:
>> - Redundanz (ich verwende mehrere Sicherungsplatten)
>> - vollständig automatische Sicherung jeden Tag
>> - Transparenz und Anpassungsfähigkeit
>>
> Hallo Sandy,
>
> Ich benutze zwar noch komprimierte cpio-Archive für den Backup, dem werden vom
> Script noch Informationen über die RAID-Konfiguration und die Partitionierung
> hinzugefügt. Ich hoffe damit in der Lage zu sein, mein System von NULL
> wiederherzustellen. Ich habe mir irgendwann überlegt, was ich dafür brauche,
> und es zusammengebracht.
Öh, Backup und komprimierte Archive? Da sind schon häufiger Probleme aufgetaucht.
Ich möchte jetzt nicht auf deine Parade regnen, aber "Backup" und "hoffen"
gehören nicht in einen Satz! Jetzt, wo du keine Probleme hast, ist genau die
Zeit, dein Backupkonzept zu testen! Glaube mir, die Zeit ist gut angelegt. (^-°)
Da ich ein Hardware-RAID habe, brauche ich innerhalb des Betriebssystems keine
Raid-Konfig-Info, das macht meine Arbeit leichter und transparenter.
>> Wenn ich so eine Lösung auch noch für Windows finde, dann bin ich endlich
>> zufrieden. Ich werde mir mal in der nächsten Zeit Bacula ansehen. (^-^)
>
> Schau Dir auch mal Acronis True Image an. Es ist keine reine Imaging-Software.
> Man kann auch einzelne Dateien aus den Archiven zurückholen. Kostet zwar,
> aber nicht zu viel.
Ich verwende es bereits, um die System-Partition von meinem Windows-Rechner zu
sichern. Dank einer angelegten Boot-CD klappt dies sogar als
Bare-Metal-Restore direkt auf mein RAID. Und ja, ich habe es getestet. (^-^)
Acronis hat aber leider einige Probleme mit meiner ebenfalls auf dem Rechner
existierenden Linux-Installation mit LVM. Deshalb stockt das Backup ab und zu.
Vielleicht teste ich es doch noch einmal, um auch incrementelle Sicherungen
der Datenpartition anzulegen.
--
Um die Liste abzubestellen, schicken Sie eine Mail an:
opensuse-de+unsubscribe@opensuse.org
Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken
Sie eine Mail an: opensuse-de+help@opensuse.org
Hi, Sandy Drobic schrieb: [...]
Wenn ich so eine Lösung auch noch für Windows finde, dann bin ich endlich zufrieden. Ich werde mir mal in der nächsten Zeit Bacula ansehen. (^-^)
vllt. 'reicht' da cwrsync - Rsync for Windows (http://www.itefix.no/i2/node/10650) cu -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
T. Ermlich wrote:
Hi,
Sandy Drobic schrieb:
[...]
Wenn ich so eine Lösung auch noch für Windows finde, dann bin ich endlich zufrieden. Ich werde mir mal in der nächsten Zeit Bacula ansehen. (^-^)
vllt. 'reicht' da cwrsync - Rsync for Windows (http://www.itefix.no/i2/node/10650)
Wenn es Hardlinks anlegen kann auf NTFS-Laufwerken, dann wäre das die fertige Lösung. Vielleicht muss ich irgendwann einfach etwas scripten. Meine ideale Lösung wäre ein Tool, welches: - Windows Schattenkopien verwendet, um ein konsistentes Backup zu erstellen - Hardlinks verwenden kann als Option - Automatisierbar ist mit Kommandozeilen-Optionen oder Konfigdateien. - einen Vergleichslauf ermöglicht, welcher die Dateien binär vergleicht - keine Installation benötigt -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
T. Ermlich, Mittwoch 03 Juni 2009:
vllt. 'reicht' da cwrsync - Rsync for Windows (http://www.itefix.no/i2/node/10650)
Damit habe ich mich eine Weile rumgeärgert. Aber so gut rsync unter Linux funktioniert, sowenig tut es das (für mich) unter Windows. Jetzt habe ich unter Windows alle Backups mit robocopy laufen, und seit ich den /FFT-Schalter gefunden hab, läuft es richtig gut. Wäre also evtl. mal einen Blick wert. Ist in den rktools drin. -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Andre Tann wrote:
T. Ermlich, Mittwoch 03 Juni 2009:
vllt. 'reicht' da cwrsync - Rsync for Windows (http://www.itefix.no/i2/node/10650)
Damit habe ich mich eine Weile rumgeärgert. Aber so gut rsync unter Linux funktioniert, sowenig tut es das (für mich) unter Windows.
Windows-Portierungen sind nett und gut, leider haben sie meistens Macken. Ich hatte vor kurzem mit sed unter Windows arbeiten wollen, aber das scheiterte an der in-place-Option, die nicht funktionierte. Als per FTP die Dateien auf eine Linux-Büchse geschoben und dort bearbeitet. Dem NTFS-Zugriff unter Linux traue ich noch nicht ganz, zumindest nicht im Produktivbetrieb.
Jetzt habe ich unter Windows alle Backups mit robocopy laufen, und seit ich den /FFT-Schalter gefunden hab, läuft es richtig gut. Wäre also evtl. mal einen Blick wert. Ist in den rktools drin.
Robocopy ist bei mir bereits im Einsatz. (^-^) Ich suche noch nach einem Script, welches Schattenkopien sauber anlegen, löschen und als Share exportieren kann, damit ich dieses dann mit Robocopy syncen kann. Leider kann es nicht unterschiedliche Versionen von Dateien in Versions-Verzeichnissen ablegen und gegen ein Gesamt-Backup linken wie rsync. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Sandy Drobic, Mittwoch 03 Juni 2009:
Leider kann es nicht unterschiedliche Versionen von Dateien in Versions-Verzeichnissen ablegen und gegen ein Gesamt-Backup linken wie rsync.
Das stimmt, aber ich löse das linux-seitig mit rsync: Windows schiebt immer alles auf die Linux-Büchse, und dann kommt sowas wie rsnapshot. Ist gut für die Versionsverwaltung, und haarsträubend für die Netzwerklast... -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hi, 03.06.2009 12:19, Sandy Drobic wrote: ...
Robocopy ist bei mir bereits im Einsatz. (^-^)
Ich suche noch nach einem Script, welches Schattenkopien sauber anlegen, löschen und als Share exportieren kann, damit ich dieses dann mit Robocopy syncen kann.
Hmm... ich habe sowas im Prinzip als Helper-Script für Bacula im Einsatz. Basiert auf dem VShadow.exe aus dem VSS SDK von Microsoft http://www.microsoft.com/downloads/details.aspx?FamilyID=0B4F56E4-0CCC-4626-826A-ED2C4C95C871&displaylang=en Persistenten Snapshot erzeugen, denselben mounten dann freigeben nach dem Backup den Share entfernen und den Snapshot löschen Bis auf die Freigabe hab' ich ein fertiges Script... kannst Du gerne auf Zuruf, als Basis für deine eigene Lösung, bekommen! Arno -- Arno Lehmann IT-Service Lehmann Sandstr. 6, 49080 Osnabrück www.its-lehmann.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Manfred, Manfred Kreisl schrieb:
Hallo Axel,
...
Evtl hilft es ja genau Dein Eingangs beschriebenes Vorgehen noch einmal in einer VM nachzustellen....? Hab ich mir auch schon gedacht, aber ich bin mir sicher dass da das Problem nicht auftritt. Ich habe ja wie gesagt das gesamte Szenario in einer VM vorher 2x durchexerziert. Allerdings halt ohne ein grow. Jepp, das ist es ja. Ich weiß zwar im Moment nicht wie das mit dem "grow" - dem vergrößern des Raids genau funktioniert...
Aber an der Stelle ist mir auch nicht klar warum Du das genau machen wolltest. Evtl. hast Du ja dabei einen Fehler gemacht. An dieser Stelle verlasse ich mich auch nicht auf Tools wie Yast. So bequem wie das auch sein mag...
Ich habe zwar auf RAID 1 auch ein LVM liegen, habe aber bisher noch nicht am RAID dranrum gebastelt.
Muss man ja auch nicht wenn alles funktioniert
nee, das wohl nicht, aber das kann ich halt auch nicht vergrößern. Wenn ich aber trotz und genau wegen LVM mehr Platz brauche, dann kann ich z.B. einfacher im LVM ein neues Device hinzufügen. Ich erstelle also einfach ein weiteres Raid-Device und füge das der PV hinzu und schon habe ich mehr Platz zur Verfügung. Naja, so gehts halt bei RAID 1 am besten. Weil ich mit Raid 5 bisher mal das Problem hatte, das jedesmal nach dem restart ein sync gemacht wurde, habe ich im Moment und weil ich es nicht ausreichend vorher testen konnte eben ersteinmal auf RAID 1 beschränkt. -- Gruß Axel -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Axel Birndt schrieb:
Hallo Manfred,
Manfred Kreisl schrieb:
Hallo Axel,
...
Evtl hilft es ja genau Dein Eingangs beschriebenes Vorgehen noch einmal in einer VM nachzustellen....? Hab ich mir auch schon gedacht, aber ich bin mir sicher dass da das Problem nicht auftritt. Ich habe ja wie gesagt das gesamte Szenario in einer VM vorher 2x durchexerziert. Allerdings halt ohne ein grow. Jepp, das ist es ja. Ich weiß zwar im Moment nicht wie das mit dem "grow" - dem vergrößern des Raids genau funktioniert...
Aber an der Stelle ist mir auch nicht klar warum Du das genau machen wolltest. Ganz einfach, ich wollte den Platz der brach lag auch noch in das Raid5/LVM integrieren. Ursprünglich wollte ich ein unvollständiges RAID5 mit den beiden neuen 1TB Platten anlegen und dann die 750G mit integrieren, aber irgendwie wollte das System da nicht booten. Mittlerweile weis ich zwar warum das nicht ging (war wirklich nur ne Kleinigkeit, ich hatte mich mit dem LVM Namen vertan und der steht irgendwie in der initrd mit drinnen) aber jetzt ist es halt zu spät.
Evtl. hast Du ja dabei einen Fehler gemacht. An dieser Stelle verlasse ich mich auch nicht auf Tools wie Yast. So bequem wie das auch sein mag...
Yast war da nicht im Spiel. Hab das ja mittels KNOPPIX gemacht und ich schätze dass es wegen eventueller Versionsunterschiede da zum Problem kam. Wie gesagt, als KNOPPIX noch lief sah ja alles perfekt aus und irgendwelche Schweinereien hab ich nicht gemacht und auch immer sauber das System heruntergefahren. Gruß Manfred -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
participants (9)
-
Andre Tann -
Arno Lehmann -
Axel Birndt -
Emil Stephan -
Manfred Kreisl -
Philipp Thomas -
ralf.prengel＠comline.de -
Sandy Drobic -
T. Ermlich