QSYNC - Backup der QSync-NAS-Ordner per RTRR möglich ?

    --- (abgespaltete Beiträge aus diesem Thema: --> http://forum.qnapclub.de/viewtopic.php?f=166&t=28604 ) ---


    Zitat von "GorillaBD"

    Die QNAP-Bordmittel von NAS<->NAS führen keine inkrementellen oder differentiellen Backups im klassischen Sinne durch.
    Die Backupprogramme nach dieser Methode finden sich in der "Remote-Replikation" --> http://docs.qnap.com/nas/3.8/de/remote_replication.htm
    Diese Sektion gibt es auch in der FW 4.0.2 im "Sicherungsmanager".
    GLG GBD


    hm, funktionieren tut RR nur noch nicht... :?

    Einmal editiert, zuletzt von GorillaBD () aus folgendem Grund: Thema aus anderem Thread abgespaltet, Themenüberschrift verfasst.

    Nein Erik, tut mir leid, so pauschal ist diese Behauptung schlicht unwahr.


    RTRR hat etliche Optionen und Modi und möglicherweise funktioniert die eine oder andere allein oder als Kombination davon in der Tat nicht.


    In den Modi, in denen ich den RTRR fahre, funktioniert der tadellos, schnell und superzuverlässig. Auch via FTP zu "fremden" NAS oder zu einer Speicherkarte in einem Mediaplayer, zum Beispiel. Ich habe hier (fast) nur QNAP stehen, weil es gerade dieses Programm ist, was ich für die Interaktion zwischen meinen NASsen täglich brauche und Syno mir keine vergleichbare Lösung anbieten kann.


    Wenn Du also Probleme mit Deinem RTRR hast und dies zur Kenntnis bringen möchtest, präzisiere bitte genau, bei welchem Replikationsmodus und welchen Replikationsregeln oder -Filtern diese auftauchen.


    Erspare uns allen bitte aber weiter solche Pauschalbehauptungen, die so geschrieben unrichtig sind, nachvollziehbar nicht dazu, weil ohne jede weitere Begründung und dann auch noch "mit der Schrotflinte" in mehreren Threads ausgestreut.


    Das ist völlig unakzeptabel, also STOP IT.


    GLG GBD

    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

    Dann würde Dir mal einen eigenen Thread dazu empfehlen.


    Da stimmt imho irgendwas in Deinem aktuellen Anwendungsfall nicht, weil grundsätzlich funktioniert der RTRR sehr gut, zumindest in den Settings, in denen ich ihn benutze. Und ich bin beileibe nicht der einzige Benutzer hier, der vom RTRR begeistert ist...


    GLG GBD

    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

    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.


    Sehr schade, dass Du Dich scheinbar nicht daran beteiligen möchtest, den Schwierigkeiten in Deinem speziellen Fall auf den Grund zu gehen.


    Mehr, als Dir Hilfe anzubieten und Dir in dem Rahmen dann möglicherweise en Detail zu schildern, unter welchen Anwendungsfällen und Parametern der RTRR sicher, zuverlässig und schnell funktioniert, können wir nicht tun.


    Ich habe hier bei mir "teure" und "billige" Maschinen stehen und in meinen Anwendungsfällen/Parametern gibt es da keinerlei Abhängigkeit der Funktion des RTRR von der Hardware. Insofern fehlt mir aktuell die Phantasie, wie der Austausch von Hardware die Lage bei Dir verbessern oder gar lösen sollte. Einzig, dass die Cisco mit der FTP-Übertragung zur QNAP nicht zurechtkommt, wäre eine mögliche Erklärung, weil der RTRR zwischen zwei QNAPs natürlich mit dem originären Protokoll laufen kann und nicht via FTP gehen muss. Aber da hätten wir meine Syno hier, mit der es via FTP tadellos funktioniert. Am RTRR der QNAP allein liegt das Thema mit Deiner Cisco also scheinbar nicht.


    GLG GBD

    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

    Hallo Erik,


    je mehr Du in Details gehst, desto stärker wird meine Vermutung, dass wir von der Anwendung möglicherweise in völlig verschiedenen "Schuhkartons" sitzen.


    Mein Schuhkarton ist:
    Reine Heimanwendung in einem "einfachem" Windows-Freigabenetzwerk, keine Domain, kaum Online-Multiuserbetrieb für Schreibvorgänge.
    Hauptanwendung Verteilung und Verwaltung von Multimediadaten, regelmässig Online-Multiuserbetrieb für Lesevorgänge.
    Backupsteuerung via RTRR / Zeitplan, automatisch über Nacht, wenn weniger Datenverkehr ist. Zwischendurch manuelle Läufe nach Bedarf.
    Reine Datenreplikation von Anwenderdaten. Alle NASse im Einzeldiskbetrieb, keine RAIDs oder JBODs.
    Replikation inter-NAS (auch USB-extern NAS1 zu USB-extern NAS2) und NAS <-> eSata/USB.
    Keine "Stations" wie Multimediastation, Photostation, Musikstation oder Tralala in Betrieb.
    Nur HD-Station und Plexserver auf der x69 in Betrieb, auf allen anden höchstens Twonkyserver respektive der DLNA-Server der Syno.
    4 Win-PCs, 3 SMB-fähige Multimediaplayer mit Zappiti, einige eher wenig benutzte DLNA-Clients, iPad mit Plex-Client.


    Von oder an Orte, an die ich mit dem Win-Explorer nicht "hinkomme" repliziere ich nicht. Dort würde ich erst gar keine Daten hinlegen.
    Anwendungen auf der NAS oder den PCs, die dies tun oder täten, benutze ich nicht.


    Was ist Dein "Schuhkarton" ?


    GLG GBD

    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

    Danke!


    Also eine wesentlich komplexere Umgebung mit höheren Anforderungen, als meine.


    Kann mir da schon gut vorstellen, dass der RTRR (bzw. RTRR des "MFBSCT" :mrgreen:) da stellenweise oder ganz scheitert, während er in meiner Umgebung tadellos performt.


    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.


    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

    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

    Einmal editiert, zuletzt von GorillaBD () aus folgendem Grund: Doppelte Beiträge vermeiden, siehe Forenregeln!

    Benutzer mit Freigabe für Qsync habe ich einen. Der hat aber in \homes noch keinen Ordner.


    Also muss ich wohl erstmal sehen, dass der irgendwas von irgendwoher synced, damit überhaupt mal Daten dorthinkommen richtig ?


    GLG GBD

    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

    OK.


    Ich muss mich da mal reinwuseln, weil den Qsync habe ich bisher ignoriert, weil ich mir den QNAP-beta-Kram meist schenke. Aber ich schaus mir mal an, weiss aber nicht, wie lange das dauert, weil meine "Forenzeit" für dieses WE bald rum ist. Ich komme zurück, wenn ich soweit bin.


    Vielleicht kann in der Zwischenzeit auch gerne mal jemand anders, der bereits eine "stehende" QSync-Verbindung hat, einen Replikationsversuch unternehmen und berichten.


    --- EDIT ---


    OK


    Benutzer angelegt und aktiv. Qsync auf dem PC des Benutzers installiert.
    Daten (100 Winword Docs im Ordner WINWORD) in den Sync-Ordner des PCs geladen.


    Sehe nun folgendes:
    Wenn ich mich auf der Filestation der NAS als admin anmelde, finde ich die Sync-Daten nirgendwo.
    Wenn ich mich auf der Filestation der NAS als der aktiver Benutzer des Sync-Ordners anmelde, finde ich die Daten in Qsync\WINWORD.


    Soweit, so gut.


    Ich wüsste jetzt nicht, wie ich nun als admin der NAS einen RTRR-Job der Daten auf ein anderes Ziel aufsetzen sollte, weil ich den Ordner Qsync nicht auswählen kann.


    Wie bist Du an dieser Stelle weitergekommen ?


    --- EDIT ---


    Also Versuch: mal den ganzen "homes" - Ordner per RTRR zu USB repliziert.


    Die kann ich als admin via Win-Explorer zwar auf dem Ziel ebensowenig sehen, wie auf der Quelle, mit WinSCP auf dem Ziel sehe ich aber, dass sie da sind.


    Über die Filestation der NAS auf das Ziel zugegriffen, sehe ich die Daten nun weder als admin, noch als der aktive Benutzer.



    Vorläufiges Fazit bis jetzt:
    Die Daten der Qsync-Ordner sind via RTRR (hier: manuelle Sicherung) replizierbar.
    Die Backup-Daten sind auf dem Ziel für den admin der NAS nur via WinSCP sichtbar/kontrollierbar.


    Das Thema scheint ein Sicherheitskonzept/Berechtigungskonzept dieser Daten zu sein: Mit "normalen Mitteln" soll selbst der Admin der NAS diese gesyncten Daten nicht einsehen können. Das erschwert die erfolgreiche Kontrolle von Replikationen dieser gesyncten Daten. Und ist als Sicherheitskonzept in sich "löchrig", solange die Userdaten für den Admin über WinSCP einsehbar sind.


    Die Replikation als solche war aber zunächst mal erfolgreich und sollte dann so auch durch das Netzwerk funktionieren.
    Frage ist jetzt, wie das bei der Rücksicherung ausschaut. Das sehe mir als nächstes mal an.


    --- EDIT ---


    Also: Den Benutzerordner in "homes" gelöscht, vom Admin-Windows-PC aus. Der Benutzerordner wird danach sofort neu angelegt und erscheint wieder im Explorer.
    Gegenkontrolle per Filestation als Benutzer ergibt: Der Subordner Qsync/WINDOWS ist auf der Quelle verschwunden.


    Dann Rücksicherung des ganzen "homes" - Ordners von der USB-Platte zue internen Platte.


    Gegenkontrolle mit WinSCP: alles wieder da.
    Gegenkontrolle mit Filestation des Benutzers: Daten an der Quelle wieder sichtbar
    Gegenkontrolle mit Filestation des admins: Daten an der Quelle nicht sichtbar


    Vorläufiges neues Fazit:


    Datensicherung der Qsync-Daten via RTRR ist möglich, Rücksicherung der Qsync-Daten via RTRR ist möglich. RTRR hier: manuelle Sicherung.


    Problem ist die einfache Kontrolle von Sicherung und Rücksicherung, weil der Zugriff auf die Daten nur via WinSCP möglich ist oder einer mir bis jetzt noch nicht bekannten anderen Methode.


    --- EDIT ---


    OK - nächster Test:


    RTRR (manuelle Sicherung) via FTP auf meine Syno hat ebenfalls funktioniert.


    Nun ist das "Sicherheitskonzept", wenn es eins sein soll, aber einfach "durchbrochen". Die Daten des Benutzers sind nun auf dem Ziel via Windows-Explorer frei zugänglich.


    Rücksicherung von der Syno zur QNAP via RTRR/FTP (manuelle Sicherung) funktioniert ebenfalls einwandfrei. Danach Zugangsbeschränkungen auf der QNAP wieder wie gehabt.



    erik,
    das wäre jetzt mal die Stelle, bis zu der ich heute kommen konnte. Bitte um kurzes Feedback und was ich von hier aus für Dich möglicherweise tun/gegentesten könnte.


    GLG GBD

    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

    Ich kann leider auf die Schnelle keine Dömanen-Umgebung nachstellen und deren mögliche Tücken bei der Sicherung prüfen.


    In meinem "einfachen" Windows-Freigabe-Netzwerk habe ich soeben erfolgreich via RTRR (manuelle Sicherung) den Ordner "homes" von der 269pro / FW 4.0.3 auch auf meine 419p+ / FW 3.7.3 replizieren können. Was nach der erfolgreichen Replikation zu USB oder auf eine fremde FTP-NAS keine Überraschung war.


    Auf der 419P+, also dem Ziel, taucht der .Qsync-Subordner des Benutzers als versteckter Ornder im Windows-Explorer auf und die Dateien darin sind sofort zugänglich.


    RTRR via FTP von der 269pro zur 419p+ funktioniert ebenso, Ergebnis wir zur Syno.



    Somit erscheint Deine Sicherungsaufgabe grundsätzlich lösbar, wenn man dem RTRR ein paar "günstige Randbedingungen" schafft:


    - keine RTRR-Echtzeitsicherung, sondern eine RTRR-regelmässige Sicherung, entweder automatisch nach Zeitplan oder manuell
    - Backup-Ziel: USB, andere QNAP oder andere (geeignete) FremdNAS (via RTRR/FTP dann)
    - Sicherung, wenn möglichst alle Qsync-Clients offline sind, z.B. täglich morgens um 05:00h, wenn auch Nacht-Eulen im Bett sind :D


    Da die Sicherung der Qsync-Ordern der NAS eine Sicherung der Sicherung des Originals ist, sollte imho eine regelmässige Sicherung statt einer Echtzeitsicherung konzeptionell ausreichend sein. Damit entlastet man den Sicherungsvorgang von den Unwägbarkeiten oder Instabilitäten einer Echtzeitsicherung in einer laufenden Online-Umgebung und erhöht somit die Zuverlässigkeit bzw. Stabilität des Sicherungsvorgangs bzw. arbeitet in einem Bereich des RTRR, wo dieser bugarm oder gar bugfrei ist.


    "Klippen" kann es dann immer noch geben, wie Besonderheiten der Dömanenumgebung oder der Dateistruktur der zu sichernden Daten. Dass müsste man dan einzeln anschauen, sollte aber imho nicht das generelle Konzept zum "Kippen" bringen. Sicherung auf USB sollte der "Fallback" sein, der immer funktionieren sollte, weil es ein lokaler Sicherungsvorgang ist, auch in Deiner Umgebung. Hier ist natürlich die "Sichtbarkeit" der Daten etwas umständlich, aber Abdocken der Platte und Anschliessen an einen PC oder eine andere NAS macht ja auch hier nötigenfalls die Backupdaten unmittelbar leicht lesbar und weiterverarbeitbar.


    Mein Versuch so ist natürlich nur ein "Prototypenversuch" mit einem Testordner aus 300 Winword-Docs, ca. 15MB.
    Vielleicht könnte ich mal eine grössere, gemischte Datenmenge erzeugen, die Deiner näher kommt.
    Dazu müsstest Du mir mal eine Angabe machen (Anzahl Dateien, Gesamtmenge in MB oder GB und eine Zusammensetzung (doc, pdf, jpg, avi, mkv, ...))


    GLG GBD

    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

    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

    Jeder RTRR-Job erzeugt einen Log, ist über die WebGUI einsehbar im Jobmonitor. Dort sollte sich ein Hinweis finden, warum nicht fertigrepliziert werden konnte.
    Ist der Reiter "Jobprotokolle". Man kann, glaube ich, auch irgendwo noch einen "Detail Log" einschalten, habe ich aber noch nie benutzt.


    Gründe, die ich kenne:
    - Dateisystemfehler auf Quell- oder Zielplatte
    - Eine oder mehrere Dateien korrupt oder ein Umlautproblem
    - Sehr schwierige Datenstruktur in Verbindung mit gleichzeitig hohem Traffic auf der Quellplatte


    Ich habe ich z.B. eine Zappiti-Datenbank, 28000 Dateien mit Gesamtumfang von ca. 4GB. Eine Mischung aus kleinen Vorschaubildchen und zigtausend sehr kleinen Indexdateien im .txt-Format, kleiner als je 1kb. RTRR via FTP, saugend. Klappt nicht jedesmal sofort, meist dann nicht, wenn von der Quellplatte noch andere Backups parallel laufen oder Mediastreams, so dass der Plattenkopf Schwerstarbeit beim Inhaltsvergleich und der Sicherung leisten muss. Irgendwann ist dann aber eine Wiederholung mal erfolgreich. Tritt bei mir aber auch nur bei diesem einen einzigen Anwendungsfall so auf.


    Ein Übertragungsversuch von Deinem zu meinem Netzwerk wird imho zu aufwendig, weil ich mein Netzwerk nur rein intern betreibe und dessen Anbindung ans Internet mich erstmal vor die Aufgabe stellen würde, das Umfeld für einen solchen Versuch zu schaffen. Der könnte Dir jemand anders als ich sicher schneller helfen.


    Einen 10-20GB Mixdateiordner bauen, qsyncen und replizieren kann ich aber gern mal versuchen.


    GLG GBD