scheinbar liegt hier dieses problem vor:
http://ubuntuforums.org/showth…0&p=13334367#post13334367
/share/CACHEDEV2_DATA/.qpkg/.QKVM/.XML/qemu
scheinbar sind da die xml dateien gespeichert, dennoch klappt es bei mir nicht.
jemand eine idee?
scheinbar liegt hier dieses problem vor:
http://ubuntuforums.org/showth…0&p=13334367#post13334367
/share/CACHEDEV2_DATA/.qpkg/.QKVM/.XML/qemu
scheinbar sind da die xml dateien gespeichert, dennoch klappt es bei mir nicht.
jemand eine idee?
Ja! Gibt ja auch noch andere Faktoren außer Speicherkapazität.
Hallo Leute,
ich habe eine QNAP TS-870 Pro.
Ich möchte von 6x2TB RAID6 auf 4x5TB RAID6 wechseln.
Leider scheint dies ja nicht Online möglich zusein.
Ich habe kein Problem damit ein Backup wieder einzuspielen. Allerdings möchte ich meine .qkpg nicht wieder neu einstellen müssen. Ich habe bisher eine SSD als Cache.
Kann ich diese kurzzeitig als Systemfestplatte umstellen?
Also alle Daten löschen die mehr Speicherplatz als die SSD benötigen. Bestehendes RAID entfernen. Neues Einsetzen und Backup wieder einspielen?
Am HDD Slot mangelt es nicht bei mir.
Ich hoffe Ihr könnt mir irgendwie helfen. Danke!
Lösung:
Linux Live OS konnte die Datenrate nicht liefern. NIC 1 macht Probleme. NIC 2 funktioniert. Weitere Fehler war der Einbruch der Übertragungsrate. Ursache war die Synchronisierung des RAID6 Verbund. Dauerte irgendwie gleich mehrere Tage. :oops:
Ich habe noch weitere Fragen.
Soll ich diese gleich hier mit Stellen?
Ich habe mittlerweile wieder zur 4.1 Firmware upgedatet. Finde unter Beta jedoch nicht die Virtualisierungs Anwendung.
Kann mir dazu jemand helfen?
Edit: Danke für eure Hilfe!
Hallo Qnapnutzer,
ich hab ein QNAP 870 mit ein i7-3770s und 16 GB Corsair CMSO16GX3M2C1600C11 RAM.
Ich hatte die 4.1er Firmware und momentan die 4.0.5.
Verbaut ist eine SSD und ein RAID 5. Die Probleme sind ohne aktives RAID 5 auch vorhanden.
Die SSD läuft als Einzellaufwerk.
Mir ist aufgefallen das die Datenübertragung zu mein QNAP langsam sind.
Verbunden waren sie über ein HP ProCurve 1810G Switch ohne Trunking.
Die Probleme waren beim direkten Verbinden mit mein Rechner auch vorhanden.
Windows und Linux getestet. Beide sind gleich langsam.
Ich kann per FTP/SMB nur zwischen 30-40 MByte/s senden. Es geht also noch ums 3fache schneller. CPU Last von proftpd liegt bei Übertragung zwischen 20-35%
Mein Rechner hat selbstverständlich GbE. Getestet über zwei verschiedene NICs.
Ich bin langsam ratlos.
Getestet wurde mit einer Verbindung und mit mehreren. Eine einzelne 4Gbyte Datei auf SSD im Computer.
Wenn ich den internen HDD Test über die GUI mache passt immer alles.
Ich habe bereits alle mögliche Dienste versucht zubeenden. Bringt jedoch keine Änderung auf meine Messwerte.
Hat jemand eine Idee? Kann es am RAM liegen?
Danke dr_mike & GorillaBD.
Ich bin glaub ich jetzt auf den richtigen Weg.
Die mdadm.conf ist jedoch nicht auffindbar. Laut Forum scheinbar normal. Ich werden morgen mal per Skype den englischen Support anrufen. Vielleicht können die mir direkt helfen.
Danke!
Danke. Bin damit ein bisschen weitergekommen.
e2fsck -a /dev/md0
/dev/md0 is mounted.WARNING!!! Running e2fsck on a mounted filesystem may causeSEVERE filesystem damage.Do you really want to continue (y/n)? yes/dev/md0: recovering journal/dev/md0: clean, 467860/365993984 files, 628050355/1463959200 blocks
# more /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath]md0 : active raid5 sda3[0] sdd3[3] sdc3[2] sdb3[1] 5855836800 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU] bitmap: 0/233 pages [0KB], 4096KB chunkmd4 : active raid1 sdd2[2](S) sdc2[3](S) sdb2[1] sda2[0] 530048 blocks [2/2] [UU]md13 : active raid1 sda4[0] sdc4[3] sdd4[2] sdb4[1] 458880 blocks [4/4] [UUUU] bitmap: 0/57 pages [0KB], 4KB chunkmd9 : active raid1 sda1[0] sdc1[3] sdd1[2] sdb1[1] 530048 blocks [4/4] [UUUU] bitmap: 0/65 pages [0KB], 4KB chunk
df -h
Filesystem Size Used Available Use% Mounted on
/dev/ram0 139.5M 110.0M 29.5M 79% /
tmpfs 64.0M 164.0k 63.8M 0% /tmp
/dev/sda4 364.2M 226.5M 137.7M 62% /mnt/ext
/dev/md9 509.5M 98.4M 411.1M 19% /mnt/HDA_ROOT
/dev/md0 5.4T 2.3T 3.1T 42% /share/MD0_DATA
tmpfs 32.0M 0 32.0M 0% /.eaccelerator.tmp
Ich verstehe nicht was er für ein Problem hat.
RAID scheint perfekt zu laufen.
Ich habe die Festplatten wieder zurück ins System 1 gesteckt. Hier ist jedoch der gleiche Fehler.
Mit der SSD war selten dumm von mir. Dachte schon das es sich leider dadurch aufgehangen hat.
Über ssh sehe ich meine Daten unter /share/MD0_DATA/
Wieso jedoch nicht in der Weboberfläche oder per SMB? Hilft da eine Verlinkung von /dev/md0 nach /share/MD0_DATA/ ?
Bei direkten Zugriff auf /dev/md0 bekomme ich permission denied.
Ich komme da leider nicht weiter. Bin da nicht der Pro kann aber immerhin Verzeichnise unter Linux Wechseln.
Hallo Leute,
ich bin dabei ein RAID 5 von ein TS-459 Pro+ zu ein TS-870 zu übertragen.
Zur Hilfe setzte ich das TS-459 Pro+ mit der Nummer 1 gleich und das TS-870 mit der Nummer 2.
1 und 2 haben gleiche Firmwarestände. Die 4.0.2 Build 20130726
Habe System 1 heruntergefahren. System 2 war bereits mit einer SSD in Bay 1 in Betrieb.
System 2 heruntergefahren. Festplatten entsprechend wie in System 1 eingebaut und SSD von Bay 1 nach 5 getauscht.
Beim Start zeigte mir das System keine Daten an. Der Migrationsprozess wurde auch nicht aufgerufen. Eine manuelle Migration erfolgte auch nicht.
Per SSH scheint kein Laufwerk unter /dev/md0 eingebunden zusein.
Laut Datenträgerverwaltung in der Weboberfläche wird mir das RAID 5 unter System1 und System2 angezeigt.
Laut Status soll es auch bereit sein. Gesammtgröße und die Freie Größe passen.
Demzufolge müssen da noch Daten drauf sein.
Kann es sein das ich das RAID noch entsprechend Mounten muss?
Falls Ja. Wie mach ich das?
Oder bin ich vollkommen auf den falschen Pfad?
fdisk -lu
Disk /dev/sdd: 2000.3 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
/dev/sdd1 40 1060289 530125 83 Linux
/dev/sdd2 1060296 2120579 530142 83 Linux
/dev/sdd3 2120584 3906011969 1951945693 83 Linux
/dev/sdd4 3906011976 3907007999 498012 83 Linux
Disk /dev/sdc: 2000.3 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
/dev/sdc1 40 1060289 530125 83 Linux
/dev/sdc2 1060296 2120579 530142 83 Linux
/dev/sdc3 2120584 3906011969 1951945693 83 Linux
/dev/sdc4 3906011976 3907007999 498012 83 Linux
Disk /dev/sdb: 2000.3 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 40 1060289 530125 83 Linux
/dev/sdb2 1060296 2120579 530142 83 Linux
/dev/sdb3 2120584 3906011969 1951945693 83 Linux
/dev/sdb4 3906011976 3907007999 498012 83 Linux
Disk /dev/sda: 2000.3 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
/dev/sda1 40 1060289 530125 83 Linux
/dev/sda2 1060296 2120579 530142 83 Linux
/dev/sda3 2120584 3906011969 1951945693 83 Linux
/dev/sda4 3906011976 3907007999 498012 83 Linux
Disk /dev/sda4: 469 MB, 469893120 bytes
2 heads, 4 sectors/track, 114720 cylinders, total 917760 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk /dev/sda4 doesn't contain a valid partition table
Disk /dev/sdx: 515 MB, 515899392 bytes
8 heads, 32 sectors/track, 3936 cylinders, total 1007616 sectors
Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
/dev/sdx1 32 4351 2160 83 Linux
/dev/sdx2 4352 488959 242304 83 Linux
/dev/sdx3 488960 973567 242304 83 Linux
/dev/sdx4 973568 1007615 17024 5 Extended
/dev/sdx5 973600 990207 8304 83 Linux
/dev/sdx6 990240 1007615 8688 83 Linux
Disk /dev/md9: 542 MB, 542769152 bytes
2 heads, 4 sectors/track, 132512 cylinders, total 1060096 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk /dev/md9 doesn't contain a valid partition table
Disk /dev/md4: 542 MB, 542769152 bytes
2 heads, 4 sectors/track, 132512 cylinders, total 1060096 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk /dev/md4 doesn't contain a valid partition table
Disk /dev/md0: 0 MB, 0 bytes
2 heads, 4 sectors/track, 0 cylinders, total 0 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk /dev/md0 doesn't contain a valid partition table
Alles anzeigen
Danke!
Ist geklärt. Das QNAP mit der IP 192.168.1.20 hatte als Subnet 255.255.0.0. Obwohl das bei einem Class C Netz garnicht geben sollte oder? Der hatte damit nichts aufs Gateway zurück gegriffen. Danke dennoch für eure Bemühungen!
@Eraser-EMC2 Was soll ich diesem Code entnehmen?
Die Verbindung wurde über das offizile Tool erstellt.
Bei beiden NAS ist der Router als Gateway eingetragen an dem sie auch angeschlossen sind. Ich bin ratlos.
Die Sicherheitseinstellungen waren auf niedrig eingestellt. Somit sollte jede Verbindung akzeptiert werden. Zum Probieren habe ich das ganze mal auf Hoch gesetzt und den Range von 192.168.1.1-192.168.2.254 hinzugefügt. Leider ohne Erfolg.
Das seltsame ist das ich mit anderen Clients das entfernte QNAP anpingen kann. Somit sollte die VPN Verbindung in Ordnung sein.
Danke für den Hinweis. Das hätte ich ja fast vergessen zu prüfen.
Leider nein. Ich kann die QNAPs untereinander nicht anpingen. Egal ob hin oder zurück.
Und das obwohl gemäß Securitysetings allow all steht.
Jemand noch eine Idee was man noch Prüfen könnte?
Hallo qnap Mitglieder,
im Einsatz ist ein QNAP TS-459Pro+ und ein TS-119.
TS-459Pro+ hat die IP 192.168.1.20
TS-119 hat die IP 192.168.2.20
Verbunden sind die beiden NAS über eine AVM FritzBox 7570.
VPN funktioniert und ist in Ordnung.
Beide hatte ich bereits Vor Ort im gleichem LAN synchronisiert. Hatte auch gut geklappt.
Jetzt funktioniert es aber nicht mehr.
Das Protokoll gibt folgendes aus:
"Can't reach the specified Sync Server! Begin the 3rd retry."
usw.
Portweiterleitung kommt ja auch nicht in Frage.
Beide QNAPs haben die aktuelle Firmware. Filter sind keine eingerichtet.
Hoffentlich hat von euch noch jemand eine Idee.
Danke!