Chavelle Posted April 29, 2017 Share #1 Posted April 29, 2017 Hi Leute ich versuche es auch hier noch mal im deutschen Bereich, vielleicht hat ja jemand hier Hilfe für mich. Ich habe ein Problem mit meinem Xpenology-System, dass der LVM nicht mehr sauber online kommt Kurze Beschreibung des Setups. Mein Xpenology-Systen läuft auf DSM 5.2 Build 5644 als Hyper-V VM mit einem Raid-5 und 5 Daten Disks. Die Disks sind via Passthrough der VM zugewiesen, daher kann ich auch keine Snapshots nutzen. Eine kurze Beschreibung wie es zu dem Problem gekommen ist. Nach einem Stromausfall hat DSM versucht eine Daten Konsistenzprüfung durchzuführen. Während dieser Prüfung kam es zu Disk-Fehlern so dass diese Disks vom LVM als Fehlerhaft markiert wurden. Danach waren also nur noch 3 der 5 Disks aktiv und das Raid damit Fehlerhaft. Ich habe gehofft über einen DSM reboot könnte der LVM wieder neu aufgebaut werden, dem war aber nicht so. Nach ein bisschen google'n um eine entsprechende Lösung zu finden, habe ich mich entschieden das Raid neu aufzubauen, da dabei entsprechend bekannte Raid-Infos wohl entsprechend gelesen werden könnten. Nachdem der LVM neu aufgebaut wurde, war ich aber immer noch nicht in der Lage die Volumes zu sehen. Allerdings entspricht die nun angezeigte "Used size" durchaus der zuletzt bekannten Auslastung. Ich habe mal einige, vielleicht nützliche, Informationen gesammelt und packe diese hier mit rein. Current LVM status: mdadm --detail /dev/md2 /dev/md2: Version : 1.2 Creation Time : Sun Apr 23 11:25:47 2017 Raid Level : raid5 Array Size : 7551430656 (7201.61 GiB 7732.66 GB) Used Dev Size : 1887857664 (1800.40 GiB 1933.17 GB) Raid Devices : 5 Total Devices : 5 Persistence : Superblock is persistent Update Time : Tue Apr 25 19:42:26 2017 State : clean Active Devices : 5 Working Devices : 5 Failed Devices : 0 Spare Devices : 0 Layout : left-symmetric Chunk Size : 64K Name : vmstation:2 (local to host vmstation) UUID : fa906565:71190489:ea521509:a7999784 Events : 2 Number Major Minor RaidDevice State 0 8 67 0 active sync /dev/sde3 1 8 83 1 active sync /dev/sdf3 2 8 115 2 active sync /dev/sdh3 3 8 35 3 active sync /dev/sdc3 4 8 51 4 active sync /dev/sdd3 "vgchange -ay" - no output "pvs" - no output "lvdisplay" - no output "lvscan" - no output "vgscan" - no output "vgs" - no output I have something from /etc/lvm/archive/ vmstation> cat vg1_00004.vg # Generated by LVM2 version 2.02.38 (2008-06-11): Mon Mar 6 07:59:38 2017 contents = "Text Format Volume Group" version = 1 description = "Created *before* executing '/sbin/lvextend --alloc inherit /dev/vg1/volume_1 --size 6289408M'" creation_host = "vmstation" # Linux vmstation 3.10.35 #1 SMP Tue Feb 2 17:44:24 CET 2016 x86_64 creation_time = 1488783578 # Mon Mar 6 07:59:38 2017 vg1 { id = "V7LhPs-YK34-rCUy-TAE9-eNJP-5t9M-exZx3C" seqno = 11 status = ["RESIZEABLE", "READ", "WRITE"] extent_size = 8192 # 4 Megabytes max_lv = 0 max_pv = 0 physical_volumes { pv0 { id = "DKv9e6-mh0q-6SZ5-VNS6-bXHw-hSkL-wFPFSK" device = "/dev/md2" # Hint only status = ["ALLOCATABLE"] dev_size = 15102858624 # 7.03282 Terabytes pe_start = 1152 pe_count = 1843610 # 7.03281 Terabytes } } logical_volumes { syno_vg_reserved_area { id = "Uc1Q6V-f2vY-xKLI-kH0n-OS1f-6P6Q-fWQD5I" status = ["READ", "WRITE", "VISIBLE"] segment_count = 1 segment1 { start_extent = 0 extent_count = 3 # 12 Megabytes type = "striped" stripe_count = 1 # linear stripes = [ "pv0", 0 ] } } volume_1 { id = "6WOtW4-g3mq-796S-sAcm-bqpI-HUzk-OOE3Kc" status = ["READ", "WRITE", "VISIBLE"] segment_count = 2 segment1 { start_extent = 0 extent_count = 1281280 # 4.8877 Terabytes type = "striped" stripe_count = 1 # linear stripes = [ "pv0", 3 ] } segment2 { start_extent = 1281280 extent_count = 118528 # 463 Gigabytes type = "striped" stripe_count = 1 # linear stripes = [ "pv0", 1290243 ] } } iscsi_0 { id = "MoikYK-1lu2-qV2L-VsH8-FreO-W01t-htNHt8" status = ["READ", "WRITE", "VISIBLE"] segment_count = 1 segment1 { start_extent = 0 extent_count = 3840 # 15 Gigabytes type = "striped" stripe_count = 1 # linear stripes = [ "pv0", 1281283 ] } } iscsi_1 { id = "VOl2iq-NFNs-eNXv-uCi5-BmC1-al9s-88f8eg" status = ["READ", "WRITE", "VISIBLE"] segment_count = 1 segment1 { start_extent = 0 extent_count = 5120 # 20 Gigabytes type = "striped" stripe_count = 1 # linear stripes = [ "pv0", 1285123 ] } } } } cat /etc/fstab none /proc proc defaults 0 0 /dev/root / ext4 defaults 1 1 e2fsck /dev/md2 Bad magic number in super-block while trying to open /dev/md2 Das war soweit alles... Ich hoffe jemand von euch kann mir helfen. Danke euch. Gruß Thomas Quote Link to comment Share on other sites More sharing options...
IG-88 Posted May 15, 2017 Share #2 Posted May 15, 2017 Eine kurze Beschreibung wie es zu dem Problem gekommen ist. Nach einem Stromausfall hat DSM versucht eine Daten Konsistenzprüfung durchzuführen. Während dieser Prüfung kam es zu Disk-Fehlern so dass diese Disks vom LVM als Fehlerhaft markiert wurden. Danach waren also nur noch 3 der 5 Disks aktiv und das Raid damit Fehlerhaft. ich vermute du bist hier irgendiwe uaf dem falschen dampfer was LVM angeht ein synology software raid ist im grunde "nur" mdadm (fürs raid) und LVM für das volume (aber nur wenn man auf einem RAID aka Raidgroup mehrere Volumes haben will - so kann man den platz auf dem RAID beleibig zwischen den volumes darauf verteilen) man bekomme durch mdadm ein "großes" devive /dev/md2 das dann als solches von LVM benutzt wird, LVM weis im grunde garnichts von den raid darunter, für den ist das nur eine große disk auf der man was anlegen kann wenn man im diskmanager ein RAID5/6 anlegt beim anlegen des volumes auf der raidgroup angibt das man nur ein Volume haben will dann wird gar kein LVM benutzt dann hat man "reines" mdadm (/dev/md2) das dann mit fdisk partitioniert wird und dann formatiert wird (btrfs oder ext4) wenn also "disks" weg gewesen sind dann ist das nicht LVM sondern hat was mit mdadm zu tun und wenn das /dev/md2 deshlab nicht zur verfügung steht dann gibts auch nichts für lvm zu tun Ich habe gehofft über einen DSM reboot könnte der LVM wieder neu aufgebaut werden, dem war aber nicht so. Nach ein bisschen google'n um eine entsprechende Lösung zu finden, habe ich mich entschieden das Raid neu aufzubauen, da dabei entsprechend bekannte Raid-Infos wohl entsprechend gelesen werden könnten. Nachdem der LVM neu aufgebaut wurde, war ich aber immer noch nicht in der Lage die Volumes zu sehen. Allerdings entspricht die nun angezeigte "Used size" durchaus der zuletzt bekannten Auslastung. wie hast du bei 2 fehlerhaften platten und raid5 (1 platte redudanz) wieder ein laufendes raid5 bekommen, das kann erst mal so ohne weiteres nicht gehen wenn die zwei platten defekt/weg sind hier fehlt mir irgenwie etwas, ohne das wenigstens eine der "fehlende" platten wieder voll funktionsfähig auftaucht kann man das raid nicht wieder in betireb nehmen und nach den sachen weiter unten hast du 5 funktionierende lufwerke im raid, da kommen man nicht von 3 wieder auf 5 ohne das entweder die zwei platten wieder (unbeschädigt) da sind oder man das raid komplett neu anlegt (in letzterem fall kann es natürlich keine LVM mehr geben denn das /dev/md2 ist dann ein komlett neues/leeres device) Ich habe mal einige, vielleicht nützliche, Informationen gesammelt und packe diese hier mit rein. Current LVM status: mdadm --detail /dev/md2 /dev/md2: Version : 1.2 Creation Time : Sun Apr 23 11:25:47 2017 Raid Level : raid5 Array Size : 7551430656 (7201.61 GiB 7732.66 GB) Used Dev Size : 1887857664 (1800.40 GiB 1933.17 GB) Raid Devices : 5 Total Devices : 5 Persistence : Superblock is persistent Update Time : Tue Apr 25 19:42:26 2017 State : clean Active Devices : 5 Working Devices : 5 Failed Devices : 0 Spare Devices : 0 Layout : left-symmetric Chunk Size : 64K Name : vmstation:2 (local to host vmstation) UUID : fa906565:71190489:ea521509:a7999784 Events : 2 Number Major Minor RaidDevice State 0 8 67 0 active sync /dev/sde3 1 8 83 1 active sync /dev/sdf3 2 8 115 2 active sync /dev/sdh3 3 8 35 3 active sync /dev/sdc3 4 8 51 4 active sync /dev/sdd3 das sieht soweit nach einen funktionsfähigen raid5 aus 5 platten aus, einzige auffäligkeit ist das es kein sda und sdb gibt außerdem ist die creation time 23.04.2017 aber zeimlich dicht am "jetzt" - also doch neu angelegt? und wenn ich mir die creation time des lvm aud der archive datei ansehe - 06.03.207 dann passt das auch nicht, das lvm kann nicht vor dem raid angelgt sein, erst erzeugt man das raid und oben drauf kommt lvm ansonten sieht man auch sehr schön am dem archive zeug das das lvm nicht aus "disks" bestand sondern aus /dev/md2 (nur ein physical device pv0) du hattest da drin 4 logigal volumes, eins das von synology zur reserve angelegt wurde, das normale "volume1" (das aber aus 2 segmenten besteht - mal irgendwas um-/aufgerüstet oder SHR mit sda/sdb?) und zwei iSCSI volumes zu je 15GB und 20GB - soviel kann man da zumindest rauslesen aber wenn in dem funktionierenden /dev/md2 keine LVM mehr zu finden ist und es wirklich noch das "alte" (richtige ist - was ich je bezweifle) dann würde nur richtiges datarecovery mit low level tools helfen, man müsste mit einem sektoreditor in /dev/md2 nach spuren der LVM Volumes suchen und sie mit den ihhalten der archive datei vergleichen evtl. kann man auch mit irgendwelchen kommendos die alte lvm archive datei dem /dev/md2 "aufzwingen" aber das würde die daten auf dem volume verändern und weites recovery erschweren/verhindern (da man daten verändert) - aber wenn man sonst das ganze wegwerfen würde kann man das zumindest als letztes mittel vor dem abfalleimer machen und sehen was passiert - allerdings habe ich da nichts parat, das habe ich noch nie gemacht, ist nur rein theoretisch was man machen könnte (bzw. was ich versuchen würde) man kann auch den ihalt von /dev/md2 "sichern" mit dd aber da bräuchte man eine 6TB platte, viel zeit um sich mit data recovery zu beschäftigen, ... das wird man nur machen wenn es kein backup gibt und die daten echt wichtig sind (bzw. kann man so eine mit dd erstellte kopie vermutlich auch datenrettungsprofis geben aber sowas ist in der regel für privat zu teuer) ich bin mir zwar nicht ganz sicher aber - mein beileid zum verlust der daten Quote Link to comment Share on other sites More sharing options...
sze Posted August 4, 2017 Share #3 Posted August 4, 2017 Habe das gleiche wie du. Nur habe ich eine Platte. Nachdem ich mdadm --assemble --force -v /dev/md2 /dev/sda3 war das volume wieder da und mit dem Eintrag in der fstab konnte ich es auch wieder unter /volume1 mounten und alle daten waren da. Jedoch nach jedem Reboot war alles wieder weg, Was kann ich machen? Aufgefallen war es mir, als der DSM nicht mehr erreichbar war. Hatte da die Synology Fehlermeldung von wegen es ist was schief gelaufen. Also ähnlich dem Time Bomb Problem. Quote Link to comment Share on other sites More sharing options...
IG-88 Posted August 5, 2017 Share #4 Posted August 5, 2017 (edited) 16 hours ago, sze said: Habe das gleiche wie du. Nur habe ich eine Platte. Nachdem ich mdadm --assemble --force -v /dev/md2 /dev/sda3 war das volume wieder da und mit dem Eintrag in der fstab konnte ich es auch wieder unter /volume1 mounten und alle daten waren da. Jedoch nach jedem Reboot war alles wieder weg, Was kann ich machen? Aufgefallen war es mir, als der DSM nicht mehr erreichbar war. Hatte da die Synology Fehlermeldung von wegen es ist was schief gelaufen. Also ähnlich dem Time Bomb Problem. ich habe kaum praktische erfahrung mit der reparatur von linux dateisystemen und raids (so viel linux umgang habe ich nicht und da kam das bisher kaum vor, waren wenn eher defekte sektoren auf einfachen platten ohne lvm und mdadm oder trockenübungen) aber mal so aus der theorie wie das funktioniert heraus wenn man aus einem raid platten entfernt und sie mit "force" wieder "reinzwingt" dann muss man mit inkonsistenz rechnen (raid prüfsummen die "vealtet" sind weil daten geschrieben wurden aber ohne die prüfsumme) und sollte wohl die prüfsummen neu erzeugen/überprüfen so das alle sektoren der platten auch eine passende prüfsumme haben und natürlich sollte man das in dem raid liegende dateisystem auf konsistenz prüfen bzw. reparieren - gibt ja einen grund warum ein mdadm raid nicht automatisch beim "zusammengesetzt" wird beim boot bzw. ein dateisystem nicht gemountet wird und diese günde muss man beseitigen, es gibt für sowas in der regel auch dirty flags und die werden bei einer überprüfung, neu berechnung der prüfsummen dann auch zurückgesetzt da sowohl mdadm als auch ext4/btrfs standard linux sachen sind findet man dazu auch jede menge infos und howto's im netz, ist nichts was sysnology erfunden hat und nur für dsm gilt Edited August 5, 2017 by IG-88 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.