Beiträge von erik 0987654

hab ich gelesen. Wer das Passwort nicht ändert, bekommt vom Bug natürlich auch nix mit :mrgreen:
Sollte die Denkweise der Entwickler oder QS'ler die sein, dass der durchschnittliche Anwender nie in die Verlegenheit kommt, dies tun zu müssen, ist das trotzdem noch lange kein Grund, die Funktion des Buttons zu überprüfen und die Richtigkeit der Änderungen festzustellen.

Wie dem auch sei, wir wissen jetzt - oder können jetzt nachlesen, wie die Änderung durchgeführt werden kann, ohne den Job neu erstellen zu müssen, was ja durchaus mühsam sein kann :roll:

ja dann lies doch mal im Internet alle diesbezüglichen Einträge zu 4.0.2, und du wirst sehen, dass das ein Bug ist.
Teste doch mal und stell das Passwort um - und willkommen in der Runder derer, die danach nicht mehr syncen können. Falls doch, will ich einen Beweis !!

Ich habe daher gleich mal eine Anleitung gepostet

Du hast aber schon Recht, die Maschinen sind ja gut, und ein paar wenige Leute machen ja ihren Job. Aber längst nicht mehr alle. Würde ich mir einen Tag lang so viele Fehler erlauben, wie die Hard- und Softwarehersteller herausgeben (welche ich meist 1-2 Tage nach Erscheinen feststelle), wäre ich meinen Job los, ich kann mir keine Fehler erlauben.

Wer in einem bestehenden RTRR Job das Passwort ändert, fällt knallhart auf die Schnauze, denn dank fehlender Funktionskontrolle seitens QNAP ist der Job dahin. Naja, fast.
Die Lösung für die händische Nachbearbeitung:
Die rtrr-Funktion beenden
Mit putty auf die Ziel-Maschine verbinden (per ssh und als "admin").

cd /etc/qsyncvi qhost.conf

da steht das Passwort sicherheitshalber im Klartext. Mit i wechselt man in den Insert = Einfügemodus. Jetzt das Passwort ändern.

ESC-Taste
:wq!

das speichert und schließt die Datei

Auf der Quellmaschine (wo die Jobs liegen) das gleiche (Job beenden, mit putty und vi bearbeiten und speichern), nur diesmal mit der Datei qsync.conf

Dann Job starten et voilà

tja, ich denke an die fehlende Qualitätskontrolle müssen wir armen Verbraucher uns gewöhnen, denn der Großteil der Menschheit ist dazu nicht mehr in der Lage. Es wird überall gespart, überall herrscht Zeitdruck, und die Kunden werden zu Betatestern. Die Krone der Frechheit ist, dass dieses Problem sehr schnell bekannt wurde, denn ich habe es wenige Minuten nach dem Update auf die 4.0.2 festgestellt und der Firma geschickt. Man reagiert mit gekonnter Ignoration - keine Antwort.
Mit dem Bug müssen wir wohl bis zu einer der nächsten 50 Versionen warten, in denen dann wieder andere, jetzt noch funktionierende Module, verschlimmbessert werden.
So ist die Welt heute, dagegen lässt sich nichts mehr machen, denn die Spinner die als Master of Business Arts sich einbilden ein Unternehmen führen zu können, nur weil sie gekonnt unsicher mit Fachbegriffen um sich werfen, bestimmen, dass Qualitätssicherung nicht mehr den Stellenwert zu haben hat, wie das vor einigen Jahren war.

Schade, dass die Welt langfristig wegen diesen fehlplatzierten Entscheidungsträgern nur mehr verschrottet wird. Schade um das Potenzial, denn die QNAPs machen ansonsten einen wirklich guten Eindruck, und meine mittlerweile 3 Geräte machen einen super Job.

Das Passwort lässt sich doch sicher in irgendeiner Datei eintragen, oder?

so, endlich mal gescheite Infos.
Die darin erscheinenden Fehler wollte ich nun beheben, aber der Job lässt sich nicht ändern. Ich brauche nur auf Eigenschaften und OK zu klicken, und schon sind die Werte falsch - sagt das System. Jetzt kann ich auch keinen neuen Job mehr anlegen, bei Schritt 7 funktioniert die "weiter"-Schaltfläche nicht mehr...

vg erik

Guten Morgen Gorilla,

na du bist ja fleißig!!!

Der Top Usser hat zurzeit rund 10 GB auf Lager, das meiste sind Fotos (also jpg).
An Stelle #2 wäre dann ich, bei mir sind es docx, xlsx, mindmaps, jpgs, pdfs

Anscheinend dürfte auch bei mir die USB-Sicherung jetzt einigermaßen funktionieren. Der Job endet jedoch mit "failed", was mir nicht wirklich "gefailed"
Die Nutzdaten scheinen gesichert zu sein. Also muss ich mich quasi blind drauf verlassen...

Ein kurzer Schnelltest mit 6 MB vom Remotestandort aus synct auch fleißig, die Datei ist als admin per winscp m NAS sichtbar, nach manuellem Start der Sicherung ist sie dann auch auf der USB-Platte (ebenfalls per winscp sichtbar)

Was ist Deiner Einschätzung nach das eheste, was da noch fehlschlägt? Gibt es ein detailierteres Log?

Wäre es möglich, dass wir beide mal einen Testordner syncen? Würde gerne mal sehen, obs mit einem anderen qnap funktioniert.

danke und vg
Erik

großes Lob, klasse Arbeit!
ok, so weit so gut.
Auf ein paar Deiner Erkenntnisse möchte ich eingehen.
Die Replikation auf USB-Platte scheint bei Dir funktioniert zu haben, das ist ein Lichtblick
Die Replikation auf ein anderes Netzwerkgerät wird womöglich versuchen die Berechtigungen zu ändern.
Meine aktuellen Beobachtungen ergeben, dass beim ersten initialisieren des FTP-Ziels angezeigt wird, dass das Ziel keine Änderung des Eigentümers zulässt. Das gibt den zweiten Hinweis auf diese Theorie. Evtl. scheitert es da bei FTP, oder am NSS6000, funktioniert jedoch möglicherweise (!) per RTRR. Dazu nehmen wir an, dass das Zielgerät ein qnap NAS ist. Frage die hier zu klären sein wird: Muss das Ziel-NAS auch in Domäne hängen?

Eine Rücksicherung von Dateien wäre grundsätzlich für mein Konzept zweitrangig. Ich will die Frage die nach Datenverlust am Primärgerät aufkommen würde - "hast du eine Sicherung, kann ich die Datei wieder bekommen?" - mit 'Ja' beantworten. Wie das gelöst wird, ist nebensächlich. Allerdings muss ich sagen, dass Deine Untersuchungsergebnisse vielversprechend klingen. Wie reagiert an der Stelle der qsync Client? Wenn ich das richtig verstanden habe, sind die Daten wieder da!?

Nachdem Du keine Domäne hast, wirst Du den Punkt vielleicht nicht nachvollziehen können. Hilfreich wäre für mich nun die Synchronisation von meinem zu einem anderen qnap nas.

vg Erik

Danke dass Du das ausprobierst!! Find ich echt klasse :thumb:
Ich kann nur Deine Frage so nicht beantworten, hab's nicht beobachtet. Meine Strategie war: Benutzer anlegen, qsync installieren, anmelden, Daten rein, syncen lassen, und dann erst am NAS schauen. Klarerweise waren dann auch Daten dort.

Im \homes Folder liegen Unterordner für die Benutzer, darunter jeweils ein .qsync, dort liegen dann die Dateien der Benutzer.

vg erik

Zitat von "GorillaBD"

Danke !
1) Vergleich imho nur möglich, wenn man in Deiner Umgebung eine "Insel" raus"lösen" bzw. raus"betrachten" könnte, die in ihrer Komplexität dann nur noch meiner Umgebung entsprechen würde. Zumindest für den Anwendungsfall NAS intern -> USB extern könnte das vielleicht gelingen, schon bei NAS -> NAS weichen die Umgebungen durch mögliche Dömanenanbindung so voneinander ab, dass hier schon Unterschiede zum Tragen kommen könnten.
...
2) Von daher stellt sich mir die Frage, ob die (einfache) Replikation dieses Ordners von QNAP daher bereits überhaupt "vorgesehen" ist ?
GLG GBD

@1: die Inselbetrachtung sollte mit einem lokalen Benutzer ausreichend sein. Hatte ich aber schon getestet. Gleiches Verhalten.
@2: angenommen ich kaufe so ein qnap NUR wegen dieser qsync Funktion, weil mir z.B. dropbox zu klein oder zu teuer ist. Ich will aber eine Sicherung der Daten und habe dazu ein Zweitgerät. Sollte es allen Ernstes QNAP nicht vorsehen, dass ich meine qsync-Daten sichern kann? Was ich zu einer solchen Haltung sagen würde, willst Du ja garnicht wissen . Oder sagen wir so: Ich erwarte dass das funktioniert! Ohne Wenn und Aber. Stellt sich heraus dass das nicht vorgesehen ist, fliegt das Ding raus oder wird zum Briefbeschwerer, denn dann verfehlt es seine qsync-Funktion zu 100% - und das war Kaufargument #1. Wobei ich hier anmerken möchte, dass Löschungen nicht gesynct werden sollen. Ziel ist ja ein Backup mit Vorhaltezeit gelöschter Dateien. Immerhin ist qsync so buggy, dass man momentan ohne Backup mehr als fahrlässig unterwegs ist.

Oder mal andersrum gefragt: gibt es statt qsync eine ebenso einfache Methode, die die Daten in einer Form ablegt, dass die auch ge-rtrr-t werden können?

vg erik

--- EDIT ---

Zitat von "GorillaBD"

Danke !
Ich kann leider zur Replikationsfähigkeit des Qsync-Ordners nichts sagen, weil ich diesen noch nie benutzt habe.
Ein einfacher Testversuch scheitert bei mir (x69pro/4.0.3), weil ich ihn als Quellordner bei der Ordnerpaarbindung eines einfachen RTRR-Jobs von intern nach USB erst gar nicht zur Auswahl auffinden kann. Den Pfad müsste ich manuell eingeben, richtig ? Von daher stellt sich mir die Frage, ob die (einfache) Replikation dieses Ordners von QNAP daher bereits überhaupt "vorgesehen" ist ?
GLG GBD

als Quellordner dient "\homes" - den wirst doch sicher finden...
allerdings musst du einen Benutzer anlegen dem du qsync als Funktion freischaltest.

vg erik

ein lokaler Händler hätte ein TS-212 Turbo vorrätig. Das sollte zum Testen reichen oder?
Wie hoch ist die Chance, dass sich die qsync-Subordner damit syncen lassen?

vg Erik

darin liegt in meinem Fall die Schwäche des nss6000. Das dumme Ding kann nämlich fast garnix, außer kalte Luft in warme zu verwandeln, 0 db in 30, und Umlaute in irgendwelche anderen Zeichen, die im Nachhein nicht mehr lesbar sind.
Nunja, seit heute Vormittag dient es als B2D-Ziel. Nicht schnell, dafür langsam und gemütlich. Hat ja 24h Zeit pro Sicherung

vg erik

Zitat von "GorillaBD"

Zur Zuverlässigkeit der Echtzeitreplikation via RTRR muss ich leider passen.
Die benutze ich in meinen Anwendungsfällen konzeptionell nicht, weil ich keine Instant-Replikation von Benutzerfehlern wie versehentliches Löschen oder Überschreiben unwiederbringlich mit auf die Replikationsdaten (Backup) übertragen möchte.
GLG GBD

RTRR = realtime remote replication. Für meine Zwecke beispielsweise will ich "sofort" eine Kopie neuer oder geänderter Dateien auf einem Zweitgerät, da das primäre jederzeit ausfallen kann. Nicht nur morgens, wenn die Sicherung gerade erfolgreich war. Diesen Mechanismus impliziert ja gerade RTRR.

aber ok, es ist ja wie Du schreibst, rtrr kann ja mehr. Somit kann's jeder benutzen wie er mag

vg Erik

wohlgemerkt Privat, keine Firma - reines "Hobby"
- alle Netzwerkkomponten (aktuelle 800er Router, ASA 5505 Firewalls, verschiedene Switches, VoiP-Telefone, 541er WLAN Accesspoint im Cluster) von Cisco.

Eine Zentrale (bei mir) und 6 per Site2Site angebundene Standorte
1 Forest mit 1 Domäne, 2012er Domainfunctionlevel
2 DCs in Zentrale, 2008 R2, 1 davon mit lokaler SSD und iscsi LUN am 469L als Datenserver mit DFS-Replikation zu 1 Außenstelle
1 Backupserver, 2008 R2 in Zentrale, 2 Ultrium-2
1 DC in 1 Außenstelle, 2012 R2, lokale Disks, als Datenserver mit DFS-Replikation zur Zentrale
TM Worryfree 7 als Virenschutz

zahlreiche User und PCs/Notebooks mit Windows 7, ein paar iPhones verteilt auf alle Standorte

1 QNAP NAS, 4x2TB im Raid5 (Zentrale)
- als iscsi Target für Datenserver
- als qsync-Host für eine Handvoll Anwender, die bestimmte Daten am Handy brauchen (z.B. ich)
- wordpress für interne Doku

1 CISCO NSS6000, 4x1TB im Raid5 (Zentrale)
ursprünglich gedacht als Backup-Gerät für qsync-Inhalte, zurzeit als B2D-Gerät für Backupserver

Sharepoint 2010 und Exchange 2013 in Zentrale
---
ständiger Multi-User-Online Betrieb, Anspruch auf 24/7 Verfügbarkeit, sofortige Replikation neuer und geänderter Daten. Synchronisation des qsync-Ordners auf ein paar wenige Notebooks, Erreichbarkeit des Ordners per iphone notwendig.

im nächsten strategischen Ziel sollten die qsync-Ordner der Domänenbenutzer in Echtzeit auf irgendeine zweite Maschine repliziert werden. Mehr will ich garnicht :roll:

ungeachtet des ganzen "Wahnsinns", der mich natürlich auch unter einen gewissen "Druck" stellt, bleibt eine zentrale Frage die mit dem Aufbau meiner Ansicht nach so garnichts zu tun hat: wieso repliziert das NAS die qsync-Ordner nicht korrekt?

vg Erik

Zitat von "GorillaBD"

Das Prüfungsinstrumentarium, mit dem ich den Erfolg meiner Replikationen überprüfe, ist schlicht der Windows-Explorer, der mir einfach die Anzahl der Dateien auf Quelle und Ziel und die Gesamtzahl der jeweiligen Bytes addiert, so dass ich damit eine schnelle und einfache Erfolgskontrolle habe.

mit dem Datei-Explorer komme ich nicht auf \homes\DOMAIN\benutzer\.qsync
Oder doch? wie? lt. Info von qnap ist das nicht einmal technisch vorgesehen.
Natürlich kann ich schauen, was in meinem lokalen qsync Ordner liegt. Aber dessen "aktuell"-Status ist ja schon falsch. Da ist alles grün, und am NAS fehlt jede Menge.
Somit weiß ich nicht, was am NAS liegt. Daher schau ich ja mit winscp.

Ich habe beim Kauf nicht erwartet, Probleme lösen zu müssen, die die allgemeine QNAP-Kundschaft betrifft. Ich werde nicht als Beta-Tester von qnap bezahlt. Natürlich können Fragen auftauchen, aber die allgemein ersichtlichen Schwächen der RTRR-Funktionen zu debuggen sehe ich nicht als Teil meiner Endanwender-Rolle.
Jedoch habe ich bereits angemerkt, dass ich zur Validierung der anderslautenden Erfahrungen ("RTRR funktioniert bei mir super", sind ja einige dabei, nicht nur du) ein zweites, identisches NAS kaufen werde. Dass das NSS6000 eine komplette Fehlentwicklung war, hat sich auch rumgesprochen, daher ist das mit heutigem Tage aus der Testumgebung raus. Allerdings schockiert mich schon, dass RTRR auf eine lokale Festplatte nicht funktioniert.

Was ich ja vermute: diese .qsync-Ordner lassen sich nicht gescheit replizieren. Die Suche geht hier Richtung offener Dateien (wobei sicher keine 100.000 Dateien bei 3 Usern gleichzeitig offen sind) oder irgendwelchen Sperren. Zu dem Zweck habe ich qsync vorübergehend deaktiviert und RTRR angeschuppst - identisches Verhalten. Also liegts daran offenbar auch nicht.

So ganz ohne etwas zu probieren und riskieren ist es also bei mir auch wieder nicht...

vg erik

ich bin aber auch nicht der einzige, der massive Probleme hat. Ok, beiseite damit.

Ich brauche unter anderem ein Prüfungsinstrumentarium um einfach mal manuell zu schauen, ob zumindest eine Teilreplikation auf USB-Disk funktioniert hat.
Beim Berechnen der Größe (über winscp) können zum Einen teilweise Nutzdaten nicht gelesen werden, zum anderen sind die Vorschaubilder anscheinend in der Berechnung dabei. Das macht den manuellen Abgleich der Anzahl und Größe der Dateien unmöglich.

Ein neuer Thread ist nicht notwendig, denke ich. Nachdem ich alles mögliche versucht habe, sämtliche Einstellungen durchprobiert habe die die Geräte hergeben... Es sind Basisfunktionen die ich lt. Anleitung eingerichtet habe. Ich bin ziemlich sicher, dass das Bugs sind. RTRR ist seit Jahren buggy, wie man genau in diesem Forum lesen kann.

Einen letzten Versuch kann ich nur noch mit einem zweiten neuen NAS wagen. Kostet zwar wieder 1000 Euro (469L + 4x 2TB Constellations), aber was soll's. Schade wird's erst, wenn's damit genauso wenig funktioniert.

vg erik

Zitat von "GorillaBD"

...präzisiere bitte genau, bei welchem Replikationsmodus und welchen Replikationsregeln oder -Filtern diese auftauchen.
GLG GBD

RTRR per FTP auf NSS6000, lokales Netzwerk
RTRR auf USB-Disk, mit EXT4 formatiert

keine Regeln, keine Filter. Einfach nur einen einzigen Ordner. Es fängt an, synct ein paar Subordner, meldet dann 2 Fehler, dass die Synchronisation fehlgeschlagen ist:
1. not all files/folders and their attributes are copied
2. bad prot number to an unknown service

vg erik

Version 3.x - damit sind alle Unklarheiten beseitigt :thumb: !

vg Erik

qsync hat in Eigenregie den Inhalt eines Foto-Ordners verdoppelt (alle Dateien gibt es ein zweites Mal mit der Endung (!!!) .JPG[1]) und zwischenzeitlich den kompletten Ordner gelöscht. Die Dateien sind jetzt im entsprechenden qsync-recycler. Doppelt, aber gelöscht.
Mit winscp (aktuelle Version), verbunden als admin, sehe ich die Daten, kann sie aber nicht auf die lokale Festplatte kopieren. In der Fortschrittsanzeige steht nur "warte". Seit 12 Stunden... (1 Datei mit 3 MB zum Testen).

Wie komme ich jetzt wieder an die Daten?
Welche Möglichkeiten zur Zuverlässigkeitssteigerung von qsync gibt es zurzeit? (außer darauf zu verzichten, weil's ja noch 'beta' ist)

Nachtrag 1: habe zum Testen FTP aktiviert, komme bis zum Überordner über .qsync. Beim Wechsel auf .qsync heißt es "no such file or directory" - also scheidet das wohl schon aus.

danke für Hilfe
vg erik

RTRR funktioniert nicht, vergiss es. In einigen Beiträgen ist die Rede von rsync. Werde ich mir jetzt auch mal genauer anschauen.
Ich versuche mit einem 469L auf ein FTP-fähiges NAS von Cisco zu sichern. Vergeblich, Jobabbrüche, keine Daten vom qsync-Ordner,...

erstaunlich dass man es sich leisten kann, jahrelang einen bekannten Bug einfach nicht in den Griff zu bekommen. Was ist an einem simplen FTP-Kommando zum Wegschicken von Dateien so kompliziert? Totalcommander bringts hin, ja sogar robocopy aus dem Hause Microsoft schafft sowas.

Wenn wenigstens die qsync Ordner über SMB sichtbar wären, könnte ich mit robocopy vom Windows-Server aus sichern. Aber nee... :roll:

vg erik

Zitat von "bladekiller"

Mein Reden bin 100% bei dir

Die großen MÜSSEN mitlesen, zumindest maschinell. Lädtst Du "bösartiges" Zeug rauf, wird das erkannt. Da gab es vor langer Zeit einen Artikel, wonach bei Microsoft der Upload von Ki...po...fie festgestellt wurde. Der Uploader wurde gefasst (gut so). Zeigt aber, dass sie entgegen Ihrer Bestimmungen handeln.

Dass QNAP unverschlüsselt überträgt, hätte ich wetten können. Meine Erwartungen an die Firma sind mittlerweile ziemlich zerstört. Würde mich wundern, wenn die keine Backdoor drin haben um von außen mitlesen zu können. Meine ASA ist zwar entsprechend dicht, lässt das NAS in keinster Weise "nach außen", aber selbst diese hochgelobten Geräte haben ja eine Backdoor für die NSA drin. Also wird sicher auch da auf den NASses rumgeschnüffelt.
Ganz ehrlich, wer glaubt denn heute noch, dass die NSA nicht auf Deine Dateien schaut??? Da ist es dann auch schon wurscht, ob auf NAS oder in der Cloud, oder?

vg erik