Beiträge von postschlumpf

Hmm,

bei mir funktioniert das scheinbar nicht. Die externe Festplatte bleibt weiterhin angezeigt und ich kann auch weiterhin auf die Inhalte der Platte zugreifen.

Aber egal, ich lasse das jetzt so......

OK, ich probiere es in den nächsten Tagen nochmals.

Eine Fehlermeldung gibt es nicht. Nach dem Befehl springt der Cursor in die nächste Zeile und das war es.

Danach ist die externe Festplatte aber immer noch vorhanden.

Ich melde mich wieder....

Moin!

Das hat leider nicht funktioniert. Die Festplatte wird nicht ausgehängt.

Ist aber auch nicht schlimm. Ich melde mich jetzt weiterhin über die Web-Oberfläche an, um die Festplatte auszuhängen. Dabei kann ich auch gleich die Updates durchführen, die mir angezeigt werden. Das würde ich ansonsten nicht mit bekommen. : )

Ahhhh, vielen Dank!

Werde ich am Montag gleich mal ausprobieren.

Guten Tag,

ich greife auf unser QNAP über SSH zu.

Welchen Befehl muss ich ausführen, wenn ich im Terminal eine bereits angeschlossene externe Festplatte aushängen möchte?

Ich habe bisher folgendes probiert:

1. blkid listet mir alle angeschlossenen Geräte auf. Die externe Festplatte ist eingehängt unter /dev/sde1. Und ich vermute, weil die Festplatte verschlüsselt ist, ist sie nochmal zu sehen unter /dev/mapper/sde1.

2. Ich habe versucht: umount /dev/sde1 Das hat nicht funktioniert, die Festplatte wird nach blkid weiterhin angezeigt.

3. Ich habe danach versucht: umount /dev/mapper/sde1 Das hat auch nicht funktioniert, die Festplatte wird nach blkid weiterhin angezeigt.

Was mache ich falsch?

Muss ich sudo davor setzen, obwohl ich mich als admin über ssh angemeldet habe?

Oder muss ich separat die Verschlüsselung schließen und erst danach umount ausführen?

Bitte helft mir!

Vielen Dank!

der postschlumpf

Hallo Xydoc,

sehr interessant. Diese Erfahrung habe ich (unter Anderem) auch gemacht.

Vielleicht liegt es ja wirklich an HBS. DSM habe ich zumindest nicht verändert. Ich weiß gar nicht was das ist : )

Wie auch immer. Mein kleiner Linux-Server läuft jetzt und verrichtet seine Arbeit klaglos...

Ich muss aber noch etwas richtig stellen.

Obwohl ich die schnellste hier verfügbare Internetverbindungen habe (an Quelle und Ziel), schaffe ich nur ca. 4 GB pro Stunde über das Internet. Das sind in 24 Sunden also 96 GB. Wenn eine Datei größer ist, z.B. ein VM-Image, dann schafft rsync oder HBS das scheinbar nicht. Nach 24 Stunden kommt dann das nächste Backup mit neuen Daten und Rsync bzw. HBS fängt wieder von vorne an. Es liegt also zumindest bei mir auch an der Internetverbindung.

Hallo!

Ich danke Euch für die Antworten.

Aber ich habe es leider nicht hin bekommen.

Jetzt übernimmt ein kleiner Linux-Server das Backup über SSH.

Und das funktioniert bisher fehlerfrei und problemlos.

Und das Ganze läuft sehr sehr schnell!

Hallo!

Es war (und ist) das QNAP-NAS.

Ich weiß nicht, was da nicht stimmt und werde es wohl auch nicht heraus finden.

Zur Fehlereingrenzung habe ich jetzt einen zweiten PC ins Netzwerk gehängt. Der holt zunächst im lokalen Netzwerk ein Backup vom QNAP-NAS und anschließend sendet er ein Backup über das Internet zum Backup-Server.

Das Ganze läuft jetzt so schnell, wie ich es erwartet habe.

Das erste Backup im lokalen Netzwerk dauert ca. 7 Minuten.

Das zweite Backup über das Internet dauert ca. 45 Minuten.

So soll es erst einmal bleiben.

Von dem QNAP bin ich weiterhin sehr enttäuscht. Das ganze Multimedia-Tralala in dem Gerät brauche ich gar nicht. Aber die Backups sollten doch bitte genau so schnell laufen, wie über einen Raspi4, oder?

Naja, es ist scheinbar eine falsche Netzwerkeinstellung, die ich leider nicht korrigieren kann. Also kann man auch sagen, ich (als Nutzer) bin zu doof für das Gerät.

Ich schaue mir das jetzt erst noch eine Weile an. Vielleicht ist ja bald ein gebrauchtes QNAP-NAS zu verkaufen.... : )

Vielen Dank für Eure Hilfe!

Oh, danke!

Unter Anderem habe ich auch RTRR mit Portforwarding probiert. Das war auch zu langsam und ich habe es wieder gelöscht.

Zuletzt habe ich rsync über ssh probiert. War auch zu langsam aber zuminest sicherer.

Wie die 2 x 1 GBit LAN angeschlossen sind, weiß ich nicht. Ich sehe nur, dass da beide Ports mit LAN-Kabeln verbunden sind.

Ich versuche das mal zu klären.

Da das Ziel-Netzwerk volle Geschwindigkeit bringt und da auch der Router im Quell-Netzwerk volle Leistung anzeigt, vermute ich den Fehler irgendwo im NAS oder in der Firewall. Mehr ist nicht dazwischen.

Die CPU des NAS ist es auch nicht. Während rsync und ssh laufen hat die CPU eine Auslastung von maximal 33 %.

Es wird wahrscheinlich eine Netzwerkeinstellung sein oder vielleicht ein defektes Kabel. Obwohl die Kabel neu sind.

Moin!

Ich versuche jetzt seit Wochen, eine Datensicherung über das Internet durchzuführen. Bisher sind alle Bemühungen gescheitert, weil die Datenübermittlung zu langsam war. Ich habe mit HBS3 ein Backup versucht und auch eine Syncronisation. Ich habe als Protokoll sowohl RTRR als auch Rsync probiert. Alles war und ist zu langsam. Zuletzt habe ich im Terminal ein rsync gestartet und das im Terminal beobachtet. Die Datenraten sind unterirdisch. Rsync schafft maximal 1.72 MB/s. Das geht dann runter bis auf 16.3 KB/s (kein Tippfehler).

Die Situation:

Das QNAP-NAS ist über 2 x 1 GBit am Switch angeschlossen, es gibt eine Hardware-Firewall und einen Router. Die Internetverbindung ist eine DSL 100MBit Leitung. Download 116 MB/s, Upload 36,2 MB/s.

Der Server im Zielnetzwerk ist über 1 x 1GBit am Switch angeschlossen. Internetanbindung ebenfalls über DSL 100MBit mit fast gleichen Up- und Downloadraten (laut Router).

Wenn ich den exakt gleichen rsync-Auftrag im Zielnetzwerk ausführe und über das Internet leite, erhalte ich Datenraten von 72 MB/s bis 192 MB/s (laut rsync).

Ich vermute daher, dass das Problem im Quellnetzwerk liegt.

Entweder die Einstellung im QNAP ist nicht richtig oder die Firewall bremst das Ganze aus.

Meine Frage an Euch: Wie kann ich prüfen, ob die Netzeinstellungen im NAS korrekt sind?

Bitte gebt mir genaue Anweisungen. Ich habe dieses NAS leider nicht selbst eingerichtet.

Ich habe es gerade nach Deiner Anleitung versucht. Ich habe sogar alle angebotenen Servervarianten durch probiert. Bei mir klappt das nicht.

Ist aber auch nicht schlimm. Im Terminal funktioniert es ja und dort kann ich rsync auch viel feiner einstellen.

Ich mache jetzt also einfach wieder wie früher

Aha, ja dazu habe ich noch Fragen...

Ich habe im QNAP-NAS im Terminal ein SSH-Schlüsselpaar erstellt, ohne Passwort.

Der SSH-Login vom QNAP-NAS zum Backup-Server funktioniert im Terminal auch, ohne Passworteingabe, nur mit SSH-Key.

Wie muss ich jetzt in der GUI weiter vorgehen? Das ist mir nicht klar.

Ja, ich habe auch versucht HBS mit rsync zu benutzen.

Das ist aber schon daran gescheitert, dass ich im QNAP leider nur ein Passwort für den SSH Zugang eingeben konnte. Der Backup-Server erlaubt aber nur ein SSH-Login über Pub_Key. Und das möchte ich auch nicht ändern!
Tja, und so bin ich die ganze Zeit in Sackgassen rein gelaufen.

Ich versuche es jetzt nochmal im Terminal mit rsync, ssh und Pub_Key.

Moin!

Mit 3,8 Tagen wäre ich hoch zufrieden gewesen. Selbst mit 14 Tagen wäre ich zufrieden gewesen : )

Ich bin einfach enttäuscht, dass die QNAP-Backup-Software (HBS 3), nach einem Verbindungsabbruch nicht genau an dem Punkt weiler macht wo die Verbindung unterbrochen wurde, sondern tatsächlich jedes Mal wieder am Anfang beginnt. Das kann ja sogar rsync besser. Und da ich sowieso vermute, dass hinter dieser schicken GUI irgendwo ein rsync rein gefummelt wurde, kann ich noch weniger verstehen, warum der Schalter "-P" oder" --partial" nicht mit dazu genommen wirde.

Wie auch immer. Ich werde mir jetzt leider eine andere Lösung suchen müssen.

So,

ich habe es nochmals versucht aber es funktioniert nicht.

Auch der Sync-Auftrag läuft krötenlangsam und nach 24 Stunden fängt er wieder von vorne an.

Ich versuche es jetzt nochmal über rsync. Das ist zumindest schneller.

Vielen Dank für Eure Hilfe aber diese QNAP-NAS sind offensichtlich nicht geeignet für meinen Einsatzzweck.

So Leute,

nachdem es mit RTRR nicht vorwärts geht und auch keine Lösung in Sicht ist, habe ich als letzten Versuch eine "One-way-Syncronisation" gestartet.

Das soll wieder von einem lokalen QNAP-NAS auf ein entferntes QNAP-NAS erfolgen.

Wenn das auch nicht funktioniert, gebe ich auf. Die Software-Lösungen von QNAP sind scheinbar auf einen stark reduzierten Einsatzzweck ausgelegt. Das gefällt mir bisher gar nicht.

So ganz nebenbei habe ich auch heraus gefunden, dass man in der GUI rsync über SSH nur mit Passwort einrichten kann. Key-Files werden gar nicht angeboten.

Das ist fast so kurios wie die "Einschränkung" von SSH auf root.

Was denken sich diese Entwickler???

Guten Tag,

nachdem ich mit rsync ebenfalls gescheitert bin, habe ich nochmal versucht ein Backup über RTRR von einem QNAP-NAS zu einem anderen QNAP-NAS durch zu führen. Beide QNAP haben die aktuelle Firmware und beide haben das jeweils aktuelle HBS installiert.

Beide Internetverbindungen haben Download100Mbit und Upload ca. 50 Mbit.

Das Backup ist recht groß, ca 1,5 TB. Es ist genug Speicherplatz auf beiden NAS frei (noch ca. 2 TB frei).

Wenn ich RTRR starte, beginnt es ganz normal. Nach einigen Stunden bekomme ich jedoch die Fehlermeldung

"-53"

RTRR wird dann scheinbar erneut gestartet und versucht erneut, das Backup zu machen.

Wenn ich zu Testzwecken einen Testordner nehme (mit ca. 5 MB), dann läuft das Backup mit RTRR problemlos durch.

Wo ist der Fehler? Kann RTRR ein so großes Backup nicht verarbeiten? Oder muss ich in den Einstellungen etwas verändern?

Oh wow,

das wäre z.B. schon eine Herausforderung für mich : )

Vielen Dank für diese Lösung!

Weil ich ja noch nicht all zu fit bin habe ich eine für mich simplere Lösung gefunden:

1.

Ich habe auf dem Backup-Server (dem Ziel-Gerät) einen neuen Nutzer angelegt.

2.

In diesem Nutzerkonto habe ich ein SSH-Schlüsselpaar erstellt. Dadurch wurden auch gleichzeitig alle notwendigen Verzeichnisse mit den richtigen Rechten angelegt.

3.

Auf dem QNAP-NAS (der Quelle) habe ich dann ebenfalls ein SSH-Schlüsselpaar erstellt und mit dem oben genannten Befehl auf den Backup-Server kopiert.

cat ~/.ssh/id_rsa.pub | ssh user@ip.address "cat >> ~/.ssh/authorized_keys"

4.

Danach habe ich den SSH-Login mit Key getestet

5.

Danach habe ich den SSH-Passwort-Login auf dem Backup-Server deaktiviert und ich habe ssh neu gestartet.

6.

Sobald mein Backup über rsync läuft, werde ich den SSH-Key auf dem Server auf rsync beschränken. Folgendes habe ich mir aus dem Internet zusammen gebaut. Das wird dann einfach vor den Pub-Key kopiert:

command=rsync,no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding

Ich bin jetzt echt gespannt, ob ich da auf weitere Probleme treffen werde. Vielleicht ist rsync in diesem QNAP-NAS ja auch nur reduziert vorhanden, wer weiß...

Bei weiteren Problemen melde ich mich wieder!

Moin Leute!

Ich bin eher so eine mittelhelle Linux-Leuchte : )

Fortgeschrittener Anfänger könnte man auch sagen.

Ich habe aber auch weiter herum probiert und ich habe eine Lösung gefunden!

Da es "ssh-copy-id" leider nicht gibt, habe ich folgenden Befehl versucht und das hat bei meinem QNAP-NAS funktioniert:

cat ~/.ssh/id_rsa.pub | ssh user@ip.address "cat >> ~/.ssh/authorized_keys"

"user@ip.address" habe ich natürlich durch meine Server-Adresse ersetzt.

Vielleicht braucht das ja auch mal jemand von Euch.

Hallo tiermutter,

ich verstehe Deine Antwort leider nicht.

Soll ich mich an Anthracite wenden?

Oder ist es eine Frage an Anthracite?

Ich bin unsicher...