Beiträge von Bonsai

Zitat von "dr_mike"

Du hattest doch am Anfang geschrieben, es wären mehrere Platten im NAS gewesen. Hast du die Möglichkeit alle an den Rechner anzuschliessen?
Eventuell befindet sich eine wichtige Information zum LV auf einer der anderen Platten.

Ich habe jetzt mal einen anderen Test gemacht. Ein kleine Platte (200GB) genommen und allein ins NAS gepackt. Dann System drauf und ein Volume (Thick) in einem Speicherpool angelegt. Also genau so, wie die anderen Platten einzeln eingerichtet wurden.

Ergebnis: Ich komme genauso weit wie mit den anderen Platten und auch die Fehlermeldung am Ende ist die gleiche. Dies deutet darauf hin, dass es also nichts Plattenübergreifendes ist. Wenn ich schon eine einzelne Platte im Ursprungszustand nicht eingebunden bekommen. :cry:

Tja, dann sind wir jetzt also mit dem Latein am Ende. Dann wars das wohl für die Daten. Unterstützung vom Support von QNAP gibt es ja auch keinen. Tolle Wurst ...

Danke nochmal für die bisherige Unterstützung. Wenn ich noch was raus finde, melde ich mich, um die Infos mit den Nachwelt zu teilen.

So, jetzt nochmal mit dem aktuellen Ubuntu 14.

mdadm musste ich nachinstallieren, lvm2 war schon installiert.

Jetzt also die Befehle und Ausgaben.

root@ubuntu:/home/ubuntu# modprobe dm_modroot@ubuntu:/home/ubuntu# lsmod | grep dm_dm_thin_pool           45785  0 dm_persistent_data     54412  1 dm_thin_pooldm_bufio               22204  1 dm_persistent_datadm_bio_prison          14968  1 dm_thin_poollibcrc32c              12543  2 btrfs,dm_persistent_datadm_crypt               22622  0 dm_multipath           22402  0 scsi_dh                14458  1 dm_multipathdm_mirror              21756  0 dm_region_hash         20121  1 dm_mirrordm_log                 18072  2 dm_region_hash,dm_mirror

root@ubuntu:/home/ubuntu# dmsetup targetsthin-pool        v1.9.0thin             v1.9.0crypt            v1.13.0multipath        v1.6.0mirror           v1.13.2striped          v1.5.1linear           v1.2.1error            v1.2.0

root@ubuntu:/home/ubuntu# vgchange -ay  WARNING: Unrecognised segment type thick  /usr/sbin/thin_check: execvp failed: Datei oder Verzeichnis nicht gefunden  Check of thin pool vg2/tp2 failed (status:2). Manual repair required (thin_dump --repair /dev/mapper/vg2-tp2_tmeta)!  Refusing activation of LV lv2 containing an unrecognised segment.  1 logical volume(s) in volume group "vg2" now activeroot@ubuntu:/home/ubuntu# ll /dev/vg2

Jetzt doch mehr an Infos.

Macht es denn einen Unterschied wenn ich das Volume mit Thick statt Thin angelegt habe (Auswahl in der Web GUI von QNAP)?

PS: Danke für die Geduld und Ausdauer ...

---Edit---
Ich bin wieder ein Stück weitergekommen.

Ich musste dann noch die Tools thin-provisioning-tools installieren.

Damit hat dann vgchange -ay dies ergeben

root@ubuntu:/mnt# vgchange -ay  WARNING: Unrecognised segment type thick  Refusing activation of LV lv2 containing an unrecognised segment.  2 logical volume(s) in volume group "vg2" now active

root@ubuntu:/mnt# lvscan   WARNING: Unrecognised segment type thick  ACTIVE            '/dev/vg2/lv545' [13,88 GiB] inherit  ACTIVE            '/dev/vg2/tp2' [1,33 TiB] inherit  inactive          '/dev/vg2/lv2' [1,32 TiB] inherit

root@ubuntu:/mnt# vgscan   Reading all physical volumes.  This may take a while...  WARNING: Unrecognised segment type thick  Found volume group "vg2" using metadata type lvm2

root@ubuntu:/mnt# vgdisplay 
  WARNING: Unrecognised segment type thick
  --- Volume group ---
  VG Name               vg2
  System ID             
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  6
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                3
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               1,36 TiB
  PE Size               4,00 MiB
  Total PE              355269
  Alloc PE / Size       355269 / 1,36 TiB
  Free  PE / Size       0 / 0   
  VG UUID               2ktkBf-OyrR-eZub-NSMN-25gh-Lqyc-Ta0Vvu

Ich habe das Gefühl nun doch langsam ans Ziel zu kommen. Komme nur noch leider nicht ans lv2, weil es inactive ist. :x _hurted:

Und dieses thin und thick macht mich total verrückt ...

So, dann habe ich mir jetzt mal einen USB Stick mit Knoppix v7.2 erstellt. CD booten dauert doch leider immer noch länger.

Habe alle Schritte bis vor vgchange -ay durchlaufen.

Jetzt der modprobe dm_thin_pool und danach noch lsmod | grep dm_

root@Microknoppix:/home/knoppix# lsmod | grep dm_dm_thin_pool           30717  0 dm_persistent_data     32240  1 dm_thin_pooldm_bufio                9689  1 dm_persistent_datadm_bio_prison           2917  1 dm_thin_pool

Nicht alle Module, die bei dir in der Auflistung auftauchen ...

Das vgchange -ay danach ergibt folgendes Ergebnis

root@Microknoppix:/home/knoppix# vgchange -ay
  WARNING: Unrecognised segment type thin-pool
  WARNING: Unrecognised segment type thick
  Refusing activation of LV tp2 containing an unrecognised segment.
  Refusing activation of LV lv2 containing an unrecognised segment.
  1 logical volume(s) in volume group "vg2" now active

Die Meldungen scheinen mir immer noch nicht richtig zu sein, oder?

So, nach dem ich die Schritte wieder von Anfang bis Ende durchlaufen habe, hier die Ausgaben für die genannten Befehle.

root@Microknoppix:/home/knoppix# lsmod | grep dm_

Liefert kein Ergebnis.

Ausversehen habe ich auch folgendes mal eingetippt

root@Microknoppix:/home/knoppix# lsmod | grep md_md_mod                 83019  2 raid1

Und dann noch dies hier

root@Microknoppix:/home/knoppix# dmsetup targets
striped          v1.5.1
linear           v1.2.1
error            v1.1.0

Hilft das jetzt irgendwie?

Kann ich vielleicht auf irgendeine Weise den Typ für LVM vorgeben? Ich habe es ja mit der Vorgabe Thick eingerichtet.

Gruß
Bonsai

Zitat von "dr_mike"

Könnte es sein, dass dein Knoppix LVM2 nicht mit --with-thin=internal kompiliert ist oder das entsprechende Modul nicht geladen wurde?
Welche Version hat denn das LVM2 bei dir.

Also Knoppix hat die LVM-Version

root@Microknoppix:/home/knoppix# lvm version  LVM version:     2.02.95(2) (2012-03-06)  Library version: 1.02.74 (2012-03-06)  Driver version:  4.24.0

Und wie finde ich den gesetzten Parameter für LVM2 heraus?

Die LVM-Version auf der QNAP ist

[/mnt] # lvm version
  LVM version:     2.02.96(2) (2012-06-08)
  Library version: 1.02.75 (2012-06-08)
  Driver version:  4.22.1

Außerdem habe ich das Volume auf der Platte nicht als Thin, sondern als Thick angelegt. Sehe keinen Sinn darin den Platz nicht gleich komplett auszunutzen.

Den Vorschlag alle Platten aus dem NAS raus und es leer zu booten habe ich ausprobiert. Ich konnte mich zwar auf die Konsole per SSH verbinden, aber die USB-Platte habe ich nicht gefunden. Das Web-Interface hat ohne Einrichtung nicht funkionert ...

Irgendwie fruchtet das alles noch nicht richtig. In der oben genannten englischen Anleitung wird ein Ubuntu als Live CD genutzt.

Werde dies also mal probieren.

Weitere Ideen?
Der Ansatz mit dem leeren NAS zu booten war ja schon nicht schlecht ...

Gruß
Bonsai

Ok, dann fange ich nochmal ganz von vorne an.

Erstmal Knoppix Live CD v7.2 booten und die Festplatten mit "parted -l" anlisten.

root@Microknoppix:/home/knoppix# parted -lModel: ATA WDC WD800JD-55MU (scsi)Disk /dev/sda: 80,0GBSector size (logical/physical): 512B/512BPartition Table: msdosNumber  Start   End     Size    Type     File system  Flags 1      1049kB  368MB   367MB   primary  ntfs         boot 2      368MB   52,4GB  52,1GB  primary  ntfs 3      52,4GB  80,0GB  27,6GB  primary  ntfsModel: ATA SAMSUNG HD154UI (scsi)Disk /dev/sdb: 1500GBSector size (logical/physical): 512B/512BPartition Table: gptNumber  Start   End     Size    File system     Name     Flags 1      20,5kB  543MB   543MB   ext3            primary 2      543MB   1086MB  543MB   linux-swap(v1)  primary 3      1086MB  1491GB  1490GB                  primary 4      1491GB  1492GB  543MB   ext3            primary 5      1492GB  1500GB  8554MB  linux-swap(v1)  primaryWarning: Unable to open /dev/sr0 read-write (Das Dateisystem ist nur lesbar)./dev/sr0 has been opened read-only.Error: /dev/sr0: unrecognised disk label                                  Error: /dev/zram0: unrecognised disk label                                Warning: Unable to open /dev/cloop0 read-write (Das Dateisystem ist nur lesbar)./dev/cloop0 has been opened read-only.Error: /dev/cloop0: unrecognised disk label

Es geht um die zweite Festplatte (Samsung).

Nun "mdadm --assemble --scan" ausführen.

root@Microknoppix:/home/knoppix# mdadm --assemble --scanmdadm: /dev/md/321 has been started with 1 drive (out of 2).mdadm: /dev/md/13 has been started with 1 drive (out of 24).mdadm: /dev/md/2 has been started with 1 drive.mdadm: /dev/md/256 assembled from 0 drives and 1 spare - not enough to start the array.mdadm: /dev/md/9 has been started with 1 drive (out of 24).mdadm: /dev/md/256 assembled from 0 drives and 1 spare - not enough to start the array.

Jetzt ein "cat /proc/mdstat"

root@Microknoppix:/home/knoppix# cat /proc/mdstat Personalities : [raid1] md9 : active raid1 sdb1[25]      530048 blocks super 1.0 [24/1] [__U_____________________]      bitmap: 1/1 pages [4KB], 65536KB chunkmd2 : active raid1 sdb3[0]      1455183616 blocks super 1.0 [1/1] [U]md13 : active raid1 sdb4[25]      458880 blocks super 1.0 [24/1] [__U_____________________]      bitmap: 1/1 pages [4KB], 65536KB chunkmd321 : active raid1 sdb5[0]      8353728 blocks super 1.0 [2/1] [U_]      bitmap: 1/1 pages [4KB], 65536KB chunkunused devices: <none>

Sieht das soweit ok aus?

Jetzt lvscan

root@Microknoppix:/home/knoppix# lvscan   WARNING: Unrecognised segment type thin-pool  WARNING: Unrecognised segment type thick  inactive          '/dev/vg2/lv545' [13,88 GiB] inherit  inactive          '/dev/vg2/tp2' [1,33 TiB] inherit  inactive          '/dev/vg2/lv2' [1,32 TiB] inherit

Die Meldungen zu thin und thick machen mich schon unruhig ...
Jetzt vgdisplay

root@Microknoppix:/home/knoppix# vgdisplay   WARNING: Unrecognised segment type thin-pool  WARNING: Unrecognised segment type thick  --- Volume group ---  VG Name               vg2  System ID               Format                lvm2  Metadata Areas        1  Metadata Sequence No  6  VG Access             read/write  VG Status             resizable  MAX LV                0  Cur LV                3  Open LV               0  Max PV                0  Cur PV                1  Act PV                1  VG Size               1,36 TiB  PE Size               4,00 MiB  Total PE              355269  Alloc PE / Size       355269 / 1,36 TiB  Free  PE / Size       0 / 0     VG UUID               2ktkBf-OyrR-eZub-NSMN-25gh-Lqyc-Ta0Vvu

Und jetzt noch lvdisplay

root@Microknoppix:/home/knoppix# lvdisplay   WARNING: Unrecognised segment type thin-pool  WARNING: Unrecognised segment type thick  --- Logical volume ---  LV Path                /dev/vg2/lv545  LV Name                lv545  VG Name                vg2  LV UUID                OAoDN1-l61r-PxPb-jSmo-vAZr-tzWY-bWdNOS  LV Write Access        read/write  LV Creation host, time QNAPTS469L, 2014-07-08 23:28:04 +0200  LV Status              NOT available  LV Size                13,88 GiB  Current LE             3552  Segments               1  Allocation             inherit  Read ahead sectors     4096  --- Logical volume ---  LV Path                /dev/vg2/tp2  LV Name                tp2  VG Name                vg2  LV UUID                7yu5BA-oiTW-LPOs-auKR-1FgA-d0FA-gjdDV0  LV Write Access        read/write  LV Creation host, time QNAPTS469L, 2014-07-08 23:28:14 +0200  LV Status              NOT available  LV Size                1,33 TiB  Current LE             347621  Segments               1  Allocation             inherit  Read ahead sectors     auto  --- Logical volume ---  LV Path                /dev/vg2/lv2  LV Name                lv2  VG Name                vg2  LV UUID                lZeI1R-O5M2-Gjtx-Y1Qu-cZYQ-4xNQ-WzJ0wL  LV Write Access        read/write  LV Creation host, time QNAPTS469L, 2014-07-08 23:28:18 +0200  LV Status              NOT available  LV Size                1,32 TiB  Current LE             347108  Segments               1  Allocation             inherit  Read ahead sectors     4096

Und wenn ich jetzt "vgchange -ay" mache

root@Microknoppix:/home/knoppix# vgchange -ay
  WARNING: Unrecognised segment type thin-pool
  WARNING: Unrecognised segment type thick
  Refusing activation of LV tp2 containing an unrecognised segment.
  Refusing activation of LV lv2 containing an unrecognised segment.
  1 logical volume(s) in volume group "vg2" now active

Immer diese Meldung das er thin und thick nicht unterscheiden kann ...

Und damit kann ich auch vg2 nicht mounten.

Ach ja, der QNAP Support hat sich auf meine Anfrage vom Wochenende gemeldet ...

Zitat

... auf Grund des LVM Speichermanagers ist es leider nicht mehr möglich auf die Daten der Festplatte zuzugreifen ... dies betrifft die Modelle x69/70/79 ab Firmware 4.0.5 ...

Na dann mal Danke für diese Antwort und Firmwareänderung.

LVM ist doch kein Hexenwerk. Bei Linux-Distributionen ist das doch mittlerweile Standard.

Gruß
Bonsai

Hallo,
habe bisher TS-210 mit 2 Festplatten eingesetzt. Die Festplatten konnte ich auch bei Bedarf mit einer Linux Live CD einfach an einem PC auslesen.

Jetzt habe ich auf eine TS-469L umgestellt. Diese verwaltet die Festplatten bei einer Neueinrichtung mit der Firmware 4.1.0 anders (soweit ich das bisher raus bekommen habe). D.h. es werden keine einzelnen Datenpartitionen, sondern generell RAID's (auch auf single disk) angelegt. Weiterhin wird dann ein LVM für die Verwaltung der Partitionen genutzt. Und das macht mir jetzt einiges an Problemen ...

Da ich bei der Einrichtung wohl einiges falsch gemacht habe, stehe ich nun vor der Aufgabe, die in der TS-469L eingerichteten Festplatten (single disk, ein Speicherpool pro Platte und jeweils ein Volume) und bereits mit Daten befüllt manuell auszulesen. Dies muss ich wohl machen, weil die QNAP diese beim Einsetzen einfach neu einrichten möchte. Womit die Daten weg währen.

Also habe ich die Platte einzeln an einen PC gehängt und diesen per Knoppix CD gestartet.
Dann habe ich das RAID gestartet (mdadm --assemble --scan) was auch geklappt hat.
Prüfung des Raids mit "cat /proc/mkdstat" sieht gut aus (md2 ist vorhanden mit der passenden Größe).
Dann mit lvscan die logical volumes angelistet.
Jetzt kommt das aktivieren mit vgchange -ay. Dies schlägt leider fehl mit der Fehlermeldung

Error starting LVM2 Volume Group: vgchange exited with exit code 5:   
  WARNING: Unrecognised segment type thin-pool
  WARNING: Unrecognised segment type thick
  Refusing activation of LV tp3 containing an unrecognised segment.
  Refusing activation of LV lv3 containing an unrecognised segment.

Wieso kann denn jetzt nicht ermittelt werden, ob der Typ Thin oder Thick ist? Ich habe bei der Einrichtung Thick angegeben.
Damit kann ich nicht auf die Daten-Partitionen (ext4!?) zugreifen.

Wie komme ich dennoch an die Daten? z.B. kann man wohl auch mit Knoppix DVD mit der Speicherverwaltung den Ablauf oben grafisch machen. Ist deutlich einfacher, führt bei mir zum gleichen Ergebnis.
Deshalb habe ich auch eine kleine Platte einzeln in die TS-469L eingebaut und ein nacktes, leeres System als Test aufgespielt (um zu prüfen, ob die anderen Platten ggf. bei den Versuchen einen wegbekommen haben). Auch hier konnte ich das LVM nicht zum laufen bringen.

Weiterhin gibt es fürs mounten des Dateisystems einer TS-469L im Forum auf qnap.com eine einfache Anleitung. Die ich adaptiert habe. Geht auch nicht.

Was macht QNAP beim LVM anders als andere? Anfrage an QNAP Support ist am Wochenende rausgegangen.

Vielleicht hat einer von euch noch einen Tipp?

PS: Auslesen mit R-Linux (Hinweis hier im Forum) bringen leider auch nur Bruchstücke der Daten auf den Platten zu Tage.

Hallo dr_mike,

danke für die rasche Antwort. Jetzt wird mir einiges klarer. Hätte ich auch selbst drauf kommen können.

Ist das mit der UID im Namen der Festplatten jetzt normal oder würde bei einer komplett neuen Installation die Platte 1 dann auch wieder als HDA_DATA eingehängt werden? Wenn ja, kann ich das irgendwie noch von Hand beeinflussen?
Irgend woher muss die Zuordnung ja kommen.

Dann würde ich mir wenigstens das putzen der Platte inkl. zeitraubendes kopieren der Daten sparen.

Hallo, ich habe mich endlich durch gerungen und mir eine TS-469L gekauft.

Nun wollte ich (wie im Handbuch beschrieben) die NAS Migration durchführen. Also alte Platten aus der TS-210 (single disk) ausgebaut und in der gleichen Reihenfolge in die TS-469L eingebaut. Das neue NAS gestartet und gewartet. Die Konfig wurde auch übernommen und die Daten der freigegebenen Verzeichnisse sehe ich auch. Firmware-Aktualisierung war nicht nötig, die Aufforderung zur Migration (Punkt 7 : Migration starten) kam nicht.
Um ganz sicher zu gehen, habe ich die aktuelle Firmware für die TS-469L über den QFinder aufgespielt.

Allerdings haben einige Apps nicht mehr funktioniert und ich kann z.B. pyload bzw. Optware nicht mehr aufrufen. Es kommen Fehlermeldungsseiten. Ich kann zwar pyload über die Admin-GUI stoppen und starten (ohne Fehler im Systemprotokoll), aber ich kann nicht darauf zugreifen.

Deshalb habe ich mich mal per ssh auf der neuen QNAP umgeschaut und wurde überrascht. Unter /share finde ich die Platten nicht wie gewohnt als HDA_DATA und HDB_DATA. Die Platten sind mit kryptischen Namen eingebunden.

50014EE2B48FB20D_DATA/
50014EE6598C6F76_DATA/

Die Links auf die Verzeichnisfreigaben gehen auch auf diese kryptischen Namen.

Ich denke, dies ist auch der Grund warum nun einige Sachen nicht mehr richtig funktionieren. Wie bekomme ich das gerade gezogen?

Was ist hier passiert? Ist das normal so?

Wie bekomme ich den alten Zustand (HDA/HDB_DATA) wieder hergestellt?

Ich hoffe, dass ich nicht komplett von vorne/null mit der Einrichtung anfangen muss.

Danke & Gruß
Bonsai

Hallo, mich beschäftigt gerade die genannte Aufgabe.

D.h. ich habe eine TS-210 mit zwei Samsung Platten Single Disk (HD154UI, 1,5 TB), aktuelle Firmware 4.0.5.

Da die Platten trotz guter SMART-Werte angefangen haben Probleme zu bereiten, habe ich mir kurzfristig zwei WD30EFRX gekauft und möchte diese einsetzen.

Habe mir überlegt, wie das mit dem geringsten Aufwand (System hat einige Apps und manuelle Erweiterungen und Konfigurationen) hin bekomme.

Habe gelesen, dass man einfach eine der zwei Platten ausbauen und durch eine neue ersetzen kann. Das System (die Systempartitionen) spiegeln sich dann auf die neue Platte.
Dann den Datenbereich formatieren und die Daten (ich nutze rsync, wegen Zeitstempel etc.) auf die neue Platte kopieren.

Was mich stutzig macht ist, dass ich auf der Platte 1 (Samsung) mit fdisk alle 4 Partitionen sehen kann.

Disk /dev/sda: 1500.3 GB, 1500301910016 bytes255 heads, 63 sectors/track, 182401 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytes   Device Boot      Start         End      Blocks   Id  System/dev/sda1               1          66      530125   83  Linux/dev/sda2              67         132      530142   83  Linux/dev/sda3             133      182338  1463569693   83  Linux/dev/sda4          182339      182400      498012   83  Linux

Dies kann ich bei der neuen Platte (WD30EFRX) nicht, dass sieht dann so aus:

Disk /dev/sdb: 0 MB, 0 bytes255 heads, 63 sectors/track, 0 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytes   Device Boot      Start         End      Blocks   Id  System/dev/sdb1               1      267350  2147483647+  ee  EFI GPTPartition 1 has different physical/logical beginnings (non-Linux?):     phys=(0, 0, 1) logical=(0, 0, 2)Partition 1 has different physical/logical endings:     phys=(1023, 254, 63) logical=(267349, 89, 4)

Hierzu habe ich schon mehrere Versuche durchgeführt. D.h. WD ausgebaut, an PC gehängt und alle Partitionen drauf gelöscht. Beim ersten mal mit Windows (8.1), beim zweiten mal mit gparted live cd. Jedesmal das gleiche Ergebnis.

In der WebGUI kann ich die Platte aber ganz normal ansprechen und die Partition sdb3 wurde auch ganz normal ins HDB_DATA gemountet. Da kopieren ich auch gerade zum x-mal die Daten von sda3 per "rsync -avx --progress /share/HDA_DATA/ /share/HDB_DATA" rein.

Was kann ich also mit der Ausgabe von fdisk anfangen? Die irritiert mich doch etwas.
Hängt es vielleicht mit der Größe der Platte zusammen, die fdisk nicht mehr verkraftet?

Ach ja, mit dem zwei Samsung Platten hatte fdisk auch die folgende Ausgabe geliefert:

Disk /dev/sda: 1500.3 GB, 1500301910016 bytes255 heads, 63 sectors/track, 182401 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytes   Device Boot      Start         End      Blocks   Id  System/dev/sda1               1          66      530125   83  Linux/dev/sda2              67         132      530142   83  Linux/dev/sda3             133      182338  1463569693   83  Linux/dev/sda4          182339      182400      498012   83  LinuxDisk /dev/sda4: 469 MB, 469893120 bytes2 heads, 4 sectors/track, 114720 cylindersUnits = cylinders of 8 * 512 = 4096 bytesDisk /dev/sda4 doesn't contain a valid partition tableDisk /dev/sdb: 1500.3 GB, 1500301910016 bytes255 heads, 63 sectors/track, 182401 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytes   Device Boot      Start         End      Blocks   Id  System/dev/sdb1               1          66      530125   83  Linux/dev/sdb2              67         132      530142   83  Linux/dev/sdb3             133      182338  1463569693   83  Linux/dev/sdb4          182339      182400      498012   83  LinuxDisk /dev/md9: 542 MB, 542769152 bytes2 heads, 4 sectors/track, 132512 cylindersUnits = cylinders of 8 * 512 = 4096 bytesDisk /dev/md9 doesn't contain a valid partition tableDisk /dev/md2: 542 MB, 542769152 bytes2 heads, 4 sectors/track, 132512 cylindersUnits = cylinders of 8 * 512 = 4096 bytesDisk /dev/md2 doesn't contain a valid partition table

Mit der WD drin sieht das ganze jetzt so aus:

Disk /dev/sda: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes


   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1          66      530125   83  Linux
/dev/sda2              67         132      530142   83  Linux
/dev/sda3             133      182338  1463569693   83  Linux
/dev/sda4          182339      182400      498012   83  Linux


Disk /dev/sda4: 469 MB, 469893120 bytes
2 heads, 4 sectors/track, 114720 cylinders
Units = cylinders of 8 * 512 = 4096 bytes


Disk /dev/sda4 doesn't contain a valid partition table
You must set cylinders.
You can do this from the extra functions menu.


Disk /dev/sdb: 0 MB, 0 bytes
255 heads, 63 sectors/track, 0 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes


   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1      267350  2147483647+  ee  EFI GPT
Partition 1 has different physical/logical beginnings (non-Linux?):
     phys=(0, 0, 1) logical=(0, 0, 2)
Partition 1 has different physical/logical endings:
     phys=(1023, 254, 63) logical=(267349, 89, 4)


Disk /dev/md9: 542 MB, 542769152 bytes
2 heads, 4 sectors/track, 132512 cylinders
Units = cylinders of 8 * 512 = 4096 bytes


Disk /dev/md9 doesn't contain a valid partition table


Disk /dev/md2: 542 MB, 542769152 bytes
2 heads, 4 sectors/track, 132512 cylinders
Units = cylinders of 8 * 512 = 4096 bytes


Disk /dev/md2 doesn't contain a valid partition table

Auch hier wird die WD-Platte nicht richtig angezeigt.

PS: Auch die Meldungen mit "doesn't contain a valid partition table" irritieren mich. Ist da vielleicht noch etwas mehr im Busche?

Danke für eure Unterstützung
Gruß
Bonsai

Hallo, hatte mich jetzt auch mit diesem Problem beschäftigen müssen. Leider.

Nachdem ich alle Dienste gestoppt hatte, konnte auch ich den unmount der Platte/Partition nicht durchführen. Verantwortlich waren auch die genannten Prozesse. Davon gibt es ja so einige.
Deshalb habe ich mir mit dem Befehl "ps" die laufenden Prozesse anzeigen lassen. Zum apache_proxy gibt es dann den obersten Prozess in der Liste zu finden. Diesen konnte ich dann mit kill PID beenden. Dadurch ist die Prozessliste schon deutlich kürzer geworden.
Beim apache_proxys war es genau so. Den obersten Prozess in der Liste mit kill PID gekillt und schon konnte ich den unmount durchführen.

Zwischendurch kann man mit

fuser -m /dev/xxx

(xxx ~ HDD oder Partition) schauen, welche Prozesse noch Zugriff auf das Dateisystem haben und diese dann (kleinste PID zu erst) nacheinander abräumen.
Welche Gefahren mit diesem Verfahren verbunden sind kann ich nicht sagen.
Anwendung ist also auf eigene Gefahr.

Viel Erfolg. Bei mir hat's funktioniert.

Gruß
Bonsai

So, da es ja anscheinend kein RTRR zwischen den beiden Stationen geben kann, weil die TS109PRO dies noch nicht unterstützt, habe ich mich jetzt für folgende Lösung entschieden:

• VPN-Tunnel über zwei Fritzboxen zwischen zwei Standorten
• rsnap in der Version 3.1.2 auf der TS210 und damit Sicherung der Daten mit rsnap auf remote nfs der TS109PRO
• da meine Internetverbindung etwas schwachbrüstig ist, habe ich den Initiallauf von rsnap lokal gemacht und die Differenzläufe laufen jetzt über die Internetverbindung

Gibt es hierbei noch etwas (auch bzgl. Sicherheit) zu beachten?

Obwohl alles über VPN abgewickelt wird, habe ich auf den QNAPs die Sicherheitsstufe auf Hoch gestellt und erlaube nur den Zugriff über definierte IPs aus den einzelnen Netzen. Und hoffe damit, noch einen Sicherheitsgewinn zu haben.

Bonsai

Danke für die Antworten.

@GBD: Per rsync konnte ich bereits Verzeichnisse von der TS210 auf die TS109pro bringen. Das hat also geklappt.

Schade ist nur, dass ich das RTRR für die Replikation nutzen wollte, da es etwas mehr bietet als rsync allein.

Was mir noch aufgefallen ist, dass im PDF Handbuch (für die TS109PRO V3.3.0) folgendes Bild vom Remote-Replication Bildschirm aufgeführt ist.

Warum gibt es auf dem Screen User und Password und bei mir nicht?

Habe mir dann jetzt noch die Firmware 3.3.0 geladen und installiert. Allerdings sehe ich immer noch keine Eingabe für User und Password.

Gibt's hier für ne Erklärung?

Ggf. die TS109 komplett platt machen und neu aufsetzen?

Gruß
Bonsai

Zitat von "GorillaBD"

Auf BEIDEN NASsen sollte der RTRR-Dienst eingerichtet werden. Hierbei erfolgt auch die Kennwortvergabe.

Danke für diesen Hinweis. Auf der TS109PRO habe ich den Dienst bereits aktiviert gehabt. Allerdings finde ich hier keine Möglichkeit ein PW zu vergeben.

In der TS210 habe ich nun den Dienst auch eingerichtet.

Hier konnte ich ein PW vergeben.

Wenn ich nun auf der TS210 einen Auftrag anlegen möchte

dann weiß ich nicht, was ich hier angeben soll

weil auf der nächsten Seite kann ich zwar den lokalen Ordner in der Liste auswählen, aber ich bekomme keine Auswahl für die TS109PRO

.

Woran habe ich noch nicht gedacht?
Irgendwie klemmt's also noch.

Hallo, habe hierzu auch schon Forum gesucht und leider noch nichts gefunden. Vielleicht kann mir ja jemand helfen.

Ich versuche gerade eine RTRR basierte Replikation von Verzeichnissen zwischen der TS210 (Quelle; Firmware 3.7.1) und TS109pro (Ziel; Firmware 3.3.2) aufzusetzen. Leider gelingt mir das noch nicht so ganz.

Ich habe also auf der TS109pro unter Backup->Remote-Replikation die Häckchen gesetzt und den Port 873 eingestellt.

Dann ging es bei der TS210 weiter. Hier will ich nun den Replikationsjob einrichten. Ich gebe im Assistenten also die TS109pro als Host an und den Port 873. Als Servertyp ist RTRR-Dienst ausgewählt.
Dann fehlt noch ein Kennwort. Welches muss hier eingegeben werden? Das admin-Kennwort von der TS210?
Ein User wird ja nicht verlangt. Ich habe auf der TS109pro aber auch kein Kennwort beim Einrichten des RTRR gesetzt/setzen können.

Wenn ich jetzt auf "Test" klicke, arbeitet die TS210 etwas und dann kommt ne Meldung "Aktivieren Sie diese Optionen, um mehr Informationen in die Protokolldatei aufzunehmen. ..." am oberen Rand des Browserfensters.

Dann geht's also mit "weiter" weiter. Hier kann ich links das Quellverzeichnis auf der TS210 aus einer Liste auswählen (Doppelklick) befördert es in die Auswahl. Nur leider kann ich auf der rechten Seite keine Auswahl aus der Liste für "Externer Zielordner" per Doppelklick treffen. Eine direkte Eingabe ist auch nicht möglich.
D.h. wohl, dass der Zugriff auf die TS109pro so nicht funktioniert.

Was habe ich falsch gemacht? Wie bekomme ich per RTRR einen Abgleich zwischen den QNAPs hin?

Danke für die Hilfe.

Gruß
Bonsai

Hallo,
die Frage wäre ja, in welchem Format liegen die Daten vor? Wenn es einzelne Verzeichnisse sind und der Webhoster z.B. den rsync-Dienst anbietet, würde es bestimmt funktionieren.

Das initiale Backup würde dann die genannte Zeit dauern. An den folgenden Tagen würden nur die geänderten Daten übertragen, was dann viel schneller/kürzer ablaufen würde.

Weiterhin muss man sich die Frage stellen: Werden die Daten dort unverschlüsselt oder verschlüsselt abgelegt? Hierbei spielen ggf. auch rechtliche Aspekte eine Rolle.

Ich z.B. nutze duply/duplicity dazu die Daten lokal zu verschlüsseln und zu packen. Dann werden die Archive auf ein Web-Storage per rsync hochgeladen bzw. mit den dort bereits liegenden Daten abgeglichen. Gelesen werden können die Daten nur lokal mit dem richtigen pgp-Schlüssel und dem Passwort für den Schlüssen.

Zitat von "AlxH77"

es gibt ja die IPKG-Pakete
- apache
- mysql5
- php
- php-apache

Alles anzeigen

Die ganzen Programme sind doch bereits auf der QNAP installiert und müssen ggf. nur noch aktiviert/gestartet werden.

Warum also nochmal zusätzlich über IPKG installieren?

Gruß
Bonsai

Zitat von "juergus"

Nein ich will nicht von NAS auf einen Server spielen, sondern vom Server auf das NAS!!

Habs vorerst anders gelöst das ich per SCP auf der Kommandozeile von Server auf das NAS kopiere!

Wenn du mit deinem NAS Dateien von einem Server per FTP ziehen willst, ist das richtige Werkzeug nicht der WebFileManager, sondern die Download-Station auf dem QNAP NAS.

Wenn dieser in den Einstellungen aktiviert ist (Anwendungen -> Download Station) taucht es auf dem Login-Bildschirm auf (scrollen nach rechts) oder kann im Standard unter http://qnapts210:8080/cgi-bin/index.cgi erreicht werden (in der URL muss die Adresse/IP des NAS angepasst werden).

Zitat von "woistwalter"

Wie schlimm wäre es, wenn ich nun pyload über qpkg installiere und dann update?

Was heißt hierbei denn schlimm?

Je nach dem wie deine Verzeichnisstruktur beim manuellen Installieren aussicht. Du kannst diese Verzeichnisse entweder umbenennen (als Backup) oder einfach löschen.

Ich habe bei mir auch von der manuellen Installation auf das QPKG-Paket umgestellt (leider veraltet) und dann per hier im Forum benannten update-Skript auf die neuste Version upgedatet. So funktioniert es aktuell sauber und stabil.

Gruß
Bonsai

Hi, hast du dein Problem gelöst?

Ich habe mich jetzt etwas intensiver mit duplicity/duply auf meinem QNAP beschäftigt und bisher sieht es so aus, als ob es gut läuft.