Zu blöd für rsync?

[inkasso]

Hallo zusammen!

Mein Chef hat ne DS413j gekauft und ich habe nun das 'Vergnügen' mit den vorhandenen Mitteln verschiedenste Aufgaben zu lösen. Auf den ersten Blick dachte ich: na immerhin ein *nix Unterbau - also werden grundlegende Dinge, die man so aus dem *nix Bereich kennt funktionieren. Nun scheine ich aber zu blöd zu sein, um Daten von einem Debian-Server auf die NAS zu sichern.

Gewünscht ist die Sicherung von Debian aus mittels rsync in ein Unterverzeichnis in einem "Gemeinsamen Ordner". Dabei möchte ich auf der NAS einen RSA Schlüssel hinterlegen, damit ich mir die Passwort-Eingabe sparen kann und das ganze cron-fähig wird. Leider finde ich nirgendwo eine Stelle, wo man entsprechende Berechtigungen auf der DS setzen kann oder gar den Schlüssel hinterlegen kann. Tomaten auf den Augen?

Andersrum - also das die DS sich selbst bedient - möchte ich das äußerst ungern. Kann man das überhaupt so machen, wie ich es mir vorstelle?

Gruß

Manuel

 

[dil88]

Spricht etwas gegen einen Mount des Gemeinsamen DS-Ordners auf dem Debian-System und dann einem lokalen rsync auf das Netzlaufwerk?

 

[inkasso]

Das wäre meine zweite Wahl. Lässt sich das nicht rein über rsync lösen?

Wenn ich es mounte - was läuft stabiler: NFS oder Samba?

 

[inkasso]

Leider gab es ja keine weiteren erleuchtenden Antworten zu meiner ursprünglichen Frage, auch wenn ich die Hoffnung noch nicht ganz aufgegeben habe.

Übers Wochenende habe ich dann mal mit der Variante CIFS mounten und dann 'lokales rsync' probiert. Die zu übertragende Datei war 16 GB. Resultat: rsync hängt sich böse auf. Auch kleinere Dateien (hab das Backup dann gesplittet auf 1GB Schnipsel, danach sogar auf 100MB Schnipsel) haben nicht funktioniert. Das Problem scheint hier eine immer mal wieder abbrechende VPN zu sein und damit kann das rsync über CIFS wohl nicht gut umgehen.

Da CIFS kein intr als mount option unterstützt bin ich nun gezwungen, es über NFS zu machen. Der Test läuft gerade. Erster Eindruck ist aber wenigstens schon mal der, dass es gefühlt etwas schneller mit der Datenübertragung geht.
Trotzdem wäre mir das reine rsync zu rsync-Daemon mit RSA-Schlüssel-Anmeldung lieber.

 

[Thorndike]

Zumindest zwischen zwei DS funktioniert rsync zu Fuß ohne Probleme. Als Übertragunsprotokoll verwende ich SSH und habe auf der Targetsyno einen Schlüssel als authorized_key hinterlegt. Nach Abbrüchen wegen Zwangstrennung mus ich zwar neu starten, aber das mach cron für mich.
Ich denke mit einer Debian Box als Quelle sollte das auch gehen.

 

[AndyHH]

Hi inkasso,

ich habe das gerade am Wochenende für die Sicherung von QNAP auf DS214Play für mich gelöst.
1. Wie in der Hilfe beschrieben habe ich zuerst den rsync Server auf der DS gestartet. Über Hauptmenü / Datensicherung dann Sicherungsdienste und dort den Haken bei Netzwerk-Sicherungsdienste setzen. Danach hatte ich einen Share NetBackup gefunden. Unter dem Verzeichnis habe ich diverse Sicherungsordner (Ziele) angelegt.
2. Dann den Benutzer rsync angelegt und ihm volle Rechte auf NetBackup erteilt.
3. Auf dem Quellsystem habe ich nun die rsync Jobs angelegt. ZielServer mit IP angegeben Port 873 Benutzer rsync und sein Passwort. Als Ziel habe ich dann /NetBackup/<Verzeichnis>/ angegeben. Optionen habe ich gesetzt für incremental und handle sparse files.
Danach wurden die Transfers schnell und Fehlerfrei durchgeführt.

LG Andreas

 

[schmadde]

Wenn ich es mounte - was läuft stabiler: NFS oder Samba?

Eindeutig NFS. Das ist auch wesentlich schneller als rsync über ssh, vor allem wenn man es auf so schwachbrüstiger Hardware wie einer DSxxj laufen lässt. Überlebt auch DS-Updates und erlaubt keine lokalen logins.

Es spricht alles für eine Lösung über NFS und nichts für eine andere, finde ich.

 

[AndyHH]

Hi,

meine Erfahrung sagt mir aber - NFS ist ein share Protokoll welches normalerweise auf die Rückmeldung Datei ist gespeichert (synchron) warten muss. Hingegen ist das rsync Protokoll definitiv auf den Transfer von große Datenmengen optimiert (asynchron).
Bei mir waren vom Durchsatz die rsync Jobs schneller.

LG Andreas

 

[schmadde]

meine Erfahrung sagt mir aber - NFS ist ein share Protokoll welches normalerweise auf die Rückmeldung Datei ist gespeichert (synchron) warten muss. Hingegen ist das rsync Protokoll definitiv auf den Transfer von große Datenmengen optimiert (asynchron).
Bei mir waren vom Durchsatz die rsync Jobs schneller.

rsync verbraucht aber signifikante CPU-Ressourcen, selbst wenn man es nicht über SSH tunnelt. Bei meiner 211+ war der Zugriff über NFS deutlich schneller als über rsyncd (und letzteres bekommen die meisten eh nicht zum Laufen). Mit einer j-Station wirds eher noch schlimmer.

Je nach Zugriffsmuster kann NFS auch mal schlechter dastehen, idR wird es aber auf so schwachen Maschinen deutlich im Nachteil sein.

Was wars bei Dir für ne Hardware?

 

[AndyHH]

Hi,

Quelle QNAP TS-419p Ziel bis Sonnabend eine buffalo LinkStation PRO duo (betagt langsam und nun defekt) jetzt eine DS412Play jeweils über GigabitLAN gekoppelt.

Beruflich SLES oder RedHat auf Servern oder Blades (z.T mit SAN Storage über Fibre Channal)

LG Andreas

 

[inkasso]

Zumindest zwischen zwei DS funktioniert rsync zu Fuß ohne Probleme. Als Übertragunsprotokoll verwende ich SSH und habe auf der Targetsyno einen Schlüssel als authorized_key hinterlegt. Nach Abbrüchen wegen Zwangstrennung mus ich zwar neu starten, aber das mach cron für mich.
Ich denke mit einer Debian Box als Quelle sollte das auch gehen.

Das war leider überhaupt nicht hilfreich.
1. hab ich nur eine DS
2. weiß ich jetzt immer noch nicht, wo ich den Schlüssel für SSH hinterlegen kann :-/

 

[schmadde]

Das war leider überhaupt nicht hilfreich.
1. hab ich nur eine DS
2. weiß ich jetzt immer noch nicht, wo ich den Schlüssel für SSH hinterlegen kann :-/

Ist das eine ernstgemeinte Frage? Im Homeverzeichnis des Users als der du connectest natürlich. Anleitungen dazu findest Du zuhauf im Internet oder in der Dokumentation von ssh. Das hat mit Synology überhaupt nix zu tun.

Du wirst aber feststellen, dass das, speziell mit einer j-Syno unerträglich langsam geht.

 

[Thorndike]

Ja, ich dachte authorized_key als Stichwort würde bei Google zu genügend Anleitungen für den Schlüsselaustausch führen, auch wenn die Datei authorized_keys heißt.

Ich persönlich finde die Geschwindigkeit ausreichend, der begrenzende Faktor ist bei mir sowieso der Uplink meiner QuellDS (Adsl2 mit 1MBit Upstream). Vielleicht ändert sich das wenn ich endlich auf 10MBit Uplink umgestellt werde.

 

[inkasso]

Hi inkasso,

ich habe das gerade am Wochenende für die Sicherung von QNAP auf DS214Play für mich gelöst.
1. Wie in der Hilfe beschrieben habe ich zuerst den rsync Server auf der DS gestartet. Über Hauptmenü / Datensicherung dann Sicherungsdienste und dort den Haken bei Netzwerk-Sicherungsdienste setzen. Danach hatte ich einen Share NetBackup gefunden. Unter dem Verzeichnis habe ich diverse Sicherungsordner (Ziele) angelegt.
2. Dann den Benutzer rsync angelegt und ihm volle Rechte auf NetBackup erteilt.
3. Auf dem Quellsystem habe ich nun die rsync Jobs angelegt. ZielServer mit IP angegeben Port 873 Benutzer rsync und sein Passwort. Als Ziel habe ich dann /NetBackup/<Verzeichnis>/ angegeben. Optionen habe ich gesetzt für incremental und handle sparse files.
Danach wurden die Transfers schnell und Fehlerfrei durchgeführt.

LG Andreas

Hallo Andreas,

das ist leider auch an meinem Problem vorbei erklärt.
1. will ich keine Sicherung in den NetBackup Bereich, sondern in einen Shared Folder.
2. ich hab das rsync ja bereits am Laufen - es geht aber momentan nur mit Eingabe der Anmeldedaten - damit ist es nicht Scriptfähig. Ich hätte gern rsync über SSH mit hinterlegten RSA-Schlüssel, damit ich es scripten kann und sich cron drum kümmert.

Gruß

Manuel

 

[inkasso]

rsync verbraucht aber signifikante CPU-Ressourcen, selbst wenn man es nicht über SSH tunnelt. Bei meiner 211+ war der Zugriff über NFS deutlich schneller als über rsyncd (und letzteres bekommen die meisten eh nicht zum Laufen). Mit einer j-Station wirds eher noch schlimmer.

Je nach Zugriffsmuster kann NFS auch mal schlechter dastehen, idR wird es aber auf so schwachen Maschinen deutlich im Nachteil sein.

Was wars bei Dir für ne Hardware?

Die CPU Ressourcen sind mir latte. Wichtig ist, dass es möglichst störungsfrei läuft und das auch mit großen Datenmengen und Dateigrößen bei langsamer, abbrechender Internetverbindung.
CIFS ist ausgeschieden - hab ich ja schon geschrieben - weil sich mein ganzes Debian bei Verbindungsabbrüchen aufgehangen hat. Das rsync fährt so schön vor die Wand, dass man es nur noch durch einen reboot (und zwar mit Aus Knopf festhalten, weil das System nimmer runterfährt) wieder hinbekommt

Mit NFS läuft es jetzt - wenn auch immer noch nicht so wie ich es eigentlich gern hätte. Bei NFS stört mich, dass man UIDs und GIDs synchron halten muss und man für den mount nirgendwo nach nem Passwort gefragt wird.

 

[inkasso]

Ist das eine ernstgemeinte Frage? Im Homeverzeichnis des Users als der du connectest natürlich. Anleitungen dazu findest Du zuhauf im Internet oder in der Dokumentation von ssh. Das hat mit Synology überhaupt nix zu tun.

Du wirst aber feststellen, dass das, speziell mit einer j-Syno unerträglich langsam geht.

Klar war das eine ernst gemeinte Frage. Das Spielzeug vom Chef hat eine Klickibunti Oberfläche. Auch wenn ich sowas hasse, erwarte ich doch, dass sämtliche Funktionen darüber nutzbar sind - incl. das Hinterlegen der Schlüsseldateien. Wenn das nur über Kommandozeile geht - hab ich kein Problem mit. Habe ich aber auch nicht erwartet - und darum die Frage. Zumal ja auch jedes System was die Verzeichnisse angeht gern auch mal sein eigenes Süppchen kocht.

 

[schmadde]

Die CPU Ressourcen sind mir latte. Wichtig ist, dass es möglichst störungsfrei läuft und das auch mit großen Datenmengen und Dateigrößen bei langsamer, abbrechender Internetverbindung.

Sollte bei NFS gewährleistet sein, solange es hard mounts sind. Aber von Sicherung übers Internet hast Du bisher nichts gesagt. Dann ergibt ssh evtl. sinn. Wieviel wird denn gesichert? Bei mir sind ca. 2TB über Gigabit. Da ergibt ssh keinen Sinn. Wenns nur ein paar Gigabyte sind geht das schon.

Über Klickibunti geht da nix, mit rsync ohne nutzung der "Backup Station" oder wie das Ding heisst, bewegst Du Dich eh auf nicht mehr supporttetem Terrain. Also ssh-Zugriff über GUI freischalten und dort alles über die Shell-Simulation "busybox" einrichten.

 

[inkasso]

Sollte bei NFS gewährleistet sein, solange es hard mounts sind. Aber von Sicherung übers Internet hast Du bisher nichts gesagt. Dann ergibt ssh evtl. sinn. Wieviel wird denn gesichert? Bei mir sind ca. 2TB über Gigabit. Da ergibt ssh keinen Sinn. Wenns nur ein paar Gigabyte sind geht das schon.

Über Klickibunti geht da nix, mit rsync ohne nutzung der "Backup Station" oder wie das Ding heisst, bewegst Du Dich eh auf nicht mehr supporttetem Terrain. Also ssh-Zugriff über GUI freischalten und dort alles über die Shell-Simulation "busybox" einrichten.

Danke! Nun kommen wir doch voran

Das genaue Szenario:
Synology DS hinter einer Firewall über die eine VPN für externe Mitarbeiter der Firma läuft. Die VPN ist eingerichtet und funktioniert störungsfrei - nach Verbindungsabbrüchen wird automatisch und zügig neu verbunden. Die VPN ist bei mir aufm Debian entsprechend mit OpenVPN konfiguriert - war ne Sache von 1 Minute *g*. Auf der "Ziel" Seite gibts ne fette Internet-Anbindung mit 2x 50MBit Down (VDSL).

Mein Debian Server steht hinter einem Router der ein 2MBit DSL (Telekom Festnetz) und ein 16MBit DSL (skyDSL Satellit) kombiniert. Der Upstream über Festnetz ist erwartungsgemäß bescheiden, also hab ich im Router bereits konfiguriert, dass die VPN vom Debian aus über die Sat-Verbindung gehen soll. Auch das funktioniert. Der Upstream dort erreicht bis zu 10MBit - allerdings je nach Tageszeit fluktuiert die Verbindung stark und über die Antwortzeiten braucht man sich wohl auch nicht zu unterhalten.

Gesichert wird alle 7 Tage ein Vollbackup und dazwischen immer Deltas. Das Vollbackup liegt derzeit bei etwas mehr als 13GB. Die Deltas sind jeweils unter 50MB. Ich habe für die Sicherung inzwischen Volume Splitting bei 100MB eingestellt, weil ich den Eindruck habe, dass er mit kleineren Häppchen bei der Datenübertragung besser läuft.

Hoffe, das beantwortet alle wichtigen Fragen

Gruß

Manuel