Basic Backup Basic Backup

[Yippie]

Anderes Thema:
Kann es sein, dass die Übersichtsseite im Basic Backup, mit den definierten Aufgaben, nur immer einen laufenden Job anzeigt, obwohl parallel weitere im Hintergrund laufen?

Ich habe zwei Jobs auf dem lokalen NAS, die jeweils andere Freigaben an jeweils das gleiche Remote-Ziel sichern.

Wenn ich beide Aufgaben im Aufgabenplaner gleichzeitig starte, so zeigt mir die Übersicht, im Basic Backup, jedoch augenscheinlich immer nur einen aktiven Job blinkend an und dies ist vermutlich, die zuletzt gestartet Aufgabe.

Kann das Verhalten geändert werden, dass mehrere laufende Aufgaben visualisiert werden oder hat dies vllt. eine technische Beschränkung?

 

[Tommes]

Man kann rsync auf zwei unterschiedliche Arten ausführen, einmal als rsync-Daemon über den unverschlüsselten Standard Port 873 oder aber als rsync over SSH über den verschlüsselten Standard Port 22! Basic Backup verwendet rsync over SSH, daher ist in den rsync Einstellungen der SSH-Verschlüsselungsport entscheidend und muss daher gleich dem SSH Port sein.



Ich bin mir grad nicht sicher, ob rsync mehrere Aufträge parallel ausführt oder doch nacheinander. Das müsste ich mir selbst noch mal anschauen. Basic Backup greift sich laufende Prozess IDs ab und zeigt diese an. Von daher würde ich vermuten, das die Aufträge nacheinander ausgeführt werden. Aber wie gesagt… ich muss mir das selbst nochmal anschauen und sollte hier irgendwas falsch laufen, versuche ich natürlich, das Verhalten zu korrigieren.

 

[Yippie]

Man kann rsync auf zwei unterschiedliche Arten ausführen, einmal als rsync-Daemon über den unverschlüsselten Standard Port 873 oder aber als rsync over SSH über den verschlüsselten Standard Port 22! Basic Backup verwendet rsync over SSH, daher ist in den rsync Einstellungen der SSH-Verschlüsselungsport entscheidend und muss daher gleich dem SSH Port sein.

Vielleich könnte man dies sehr nützliche Info auch in die bereits sehr gute Installationsbeschreibung mitaufnehmen. Würde vielleicht anderen auch die Problemsuche erleichtern, oder hab ich das selbst überlesen?

Dankeschön!

 

[Yippie]

Ich bin mir grad nicht sicher, ob rsync mehrere Aufträge parallel ausführt oder doch nacheinander. Das müsste ich mir selbst noch mal anschauen. Basic Backup greift sich laufende Prozess IDs ab und zeigt diese an. Von daher würde ich vermuten, das die Aufträge nacheinander ausgeführt werden. Aber wie gesagt… ich muss mir das selbst nochmal anschauen und sollte hier irgendwas falsch laufen, versuche ich natürlich, das Verhalten zu korrigieren.

Meine Test mit zwei Konsolen auf der Quell-Maschine haben ergeben, dass zwei Jobs parallel ausgeführt werden, ohne dass einer davon beendet wird.

ABER, das GUI von BasicBackup zeigt nur immer einen aktiven Job an, nämlich denjenigen, den ich in der Konsole zuletzt gestartet habe.
Die Folge ist dann auch, dass wenn der zweite Job vor dem ersten Job beendet wurde, der erste Job, niemals mehr im GUI als aktiv blinkt.
Es muss jedoch schon Mal funktioniert haben, siehe hier.

Noch ein Problem bei meinen DS
Ich erhalte bei allen Aufgaben, die den Server am Ende herunterfahren sollten, immer den Fehler:

Der Remote Server konnte nicht heruntergefahren werden!

Wake on Lan funktionert hingegen.

Welche Voraussetzungen gelten, dass der Quell-Server den Ziel-Server (Synology DS214+) herunterfahren kann? Bzw. gibt es ein etwas detaillierteres Protokoll, als die Ausgabe oben?

Noch ein kleiner Bug
Wird bei der Eingabe der IP-Adresse, des Remote-Servers, aus Versehen ein Leerzeichen angefügt (was scher zu erkennen ist), so läuft der Backup-Job auf Fehler:

ssh: Could not resolve hostname : Name or service not known
rsync error: unexplained error (code 255) at io.c(254) [sender=3.1.2]

### Rsync meldete den Exit-Code 255:<br />### Vermutlich hat rsync den Exit Code eines Befehls weitergegeben, den es fuer die Verbindung verwendet hat - normalerweise SSH

Mein remote user auf dem Ziel-NAS ist übrigens Mitglieder der Gruppe Administrator, falls es eine Rolle spielt und in Bezug auf hier.

 

[Tommes]

Hi!

Vielen Dank für deine Tests und dein Feedback.

Um das Problem mit den laufenden Prozessen kann ich mich aktuell nicht kümmern und ich weiß noch nicht genau, wann ich dazu komme. Aber ich habe es auf dem Zettel und kümmer mich, sobald es mir möglich ist.

Bezüglich dem herunterfahren eines Remote-Servers verhält es sich so, das der Remote-Server den Befehl nur als root entgegen nimmt und ausführt. Das steht - meine ich zumindest - auch so im entsprechenden Part des Basic Backup Formulares im Info-Text. Du müsstest demnach deinen Remote-Server so modifizieren, das du dich per Public Key Authentifizierung als Root aufschalten kannst, was ich jedoch für ein Sicherheitsrisiko halte. Aus diesem Grund lässt der DSM das Standardmäßig nicht zu, auch wenn es im ersten Moment ein wenig paradox klingt, da man sich von einem
Terminal aus per Public Key durchaus als root aufschalten kann . Ist aber so.

Was den von dir identifizierten Bug betrifft, so kann ich zu meiner Verteidigung nur sagen, das eine clientseitige Formular Validierung der IP durchaus implementiert werden könnte, nur bekomme ich die Validierung einer IP-Adresse UND der gleichzeitigen Validierung einer URL nicht in einen Befehl gepackt. Daher gibt es an dieser Stelle aktuel überhaupt keine Validierung. Mit php und/oder Python ginge das sicherlich einfacher, zumal die Validierung dann serverseitig und damit Browserunabhängig ablaufen würde, aber dafür fehlt mir die nötige Kompetenz. Aber ich Check das nochmal. Kann ja sein, das es dafür mittlerweile eine Lösung gibt.

Tommes

 

[Yippie]

Bezüglich WOL verhält es sich so, das der Remote-Server ein WOL nur als root entgegen nimmt und ausführt. Das steht - meine ich zumindest - auch so im entsprechenden Part des Formulares als Info-Text. Du müsstest demnach deinen Remote-Server so modifizieren, das du dich per Public Key Authentifizierung als Root aufschalten kannst, was ich jedoch für ein Sicherheitsrisiko halte. Aus diesem Grund lässt der DSM das Standardmäßig nicht zu, auch wenn es im ersten Moment ein wenig paradox klingt. Ist aber so.

Hi Tommes!
In meinem Fall ging es nicht um WOL, sondern um den Shutdown. Wake On LAN funktioniert hingegen einwandfrei. Die Public Key Authentifizierung habe ich erfolgreich eingerichtet und diese funktioniert auch.

Die Validierung der IP Adresse ist eine Sache, in meinem Fall würde es auch schon ausreichen, vor dem Speichern in die Config, einen Trim an der IP Adresse durchzuführen. Möglicherweise ist dies auch bei der MAc Adresse notwendig bzw. sinnvoll?

 

[Tommes]

Hab meinen letzten Beitrag nochmal korrigiert. Sorry.

Die MAC-Adresse wird clientdeitig durchaus mittels…

txt_ssh_regex_mac="^([0-9A-Fa-f]{2}[:]){5}([0-9A-Fa-f]{2})$"

… validiert.

 

[Yippie]

Ok, das mit dem root und der potentiellen Sicherheitslücke für den Shutdown kann ich verstehen, aber warum gibts dann die Option bei der Definition einer Aufgabe überhaupt?

 

[Tommes]

Weil es durchaus Leute gibt, die dieses Risiko bewusst eingehen. Auch muss es sich bei dem Remote-Server nicht zwangsläufig um ein Synology NAS handeln.

 

[Yippie]

Das ist korrekt! Guter Einwand

Ich habe mir momentan so beholfen, dass ich in den Energieoptionen des Ziels, um 22.00 Uhr einen Shutdown eingestellt habe. Somit kann Basic-Backup das Ziel-NAS von Seiten der Quelle bei Bedarf aufwecken und spätestens um 22.00 wird das Ziel automatisch heruntergefahren.

Ich werden dennoch die Vorgehensweise beim Backup abändern:
Das bisherige Ziel-NAS soll sich selbst zeitgesteuert aufwecken, die Pull-Sicherung durchführen und dann zeitgesteuert wieder runterfahren.

Das Runterfahren sollte sich dann aber auch im letzten Backup-Job des Tages, der ja mit root-Rechten läuft, direkt bewerkstellig lassen, indem ich noch ein weiteres Kommando /sbin/shutdown -h oder ähnliches an den Aufruf von Basic-Backup anfüge.

Gut, eine gewisse Unsicherheit mit dem Shutdown besteht, denn wenn der letzte Backupjob noch vor einem anderen Backupjob beendet wird, würde das NAS heruntergefahren und alle noch laufenden Sicherungen damit beendet werden.

Aber dieses "Risiko" habe ich auch mit den aktuelle fünf eingeplanten Push-Backups und wenn der letzte beendet wird und dabei versucht das Ziel herunterzufahren (was ja eh nicht funktioniert).

 

[Tommes]

Das bisherige Ziel-NAS soll […] die Pull-Sicherung durchführen…

Ich persönlich halte ein Pull-Backup auch für wesentlich sympathischer als ein Push-Backup.

 

[Yippie]

Hm, mit Basic Backup funktioniert ja ein Pull-Backup gar nicht

Dachte dies geht auch, aber falsch gedacht! Kann somit nicht vom Backup-NAS die Daten von den Produktiven NAS ziehen.
Damit muss ich mir wohl jetzt ganz was anderes überlegen...

 

[Tommes]

Natürlich geht das.

 

[ctrlaltdelete]

Blöde Frage, dazu muss Basic Backup auf der Ziel DS installiert sein, was muss die Quelle können (rsync)?

 

[Tommes]

Nein. Basic Backup muss nur auf dem „lokalen“ Synology NAS installiert sein. Die Verbindung zu einem Remote-Server wird über eine SSH Public Key Authentifizierung hergestellt über die man dann ein Push- oder Pull-Backup ausführen kann. Einzig SSH und rsync muss auf dem Remote-Server installiert sein. Falls es sich bei dem Remote-Server um ein Synology NAS handelt, sollte auch der Benutzer-Home-Dienst aktiviert sein. Auf anderen Linux-Systemen ist der Benutzer-Home Ordner i.d.R. bereits aktiv und wird für die RSA-Keys benötigt.

Edit: Ergänzung hinzugefügt

 

[Yippie]

Natürlich geht das.

Dann habe ich es nur nicht gefunden. Die Drop-Down Liste zeigt ja nur diese beiden Einträge an:

Ich bräuchte auf dem NAS, welches die Files abholen soll, so etwas wie "Pull Backup", denn mit der Auswahl lokal werden ja offenbar nur die lokalen Files an einen anderen Ort im lokalen NAS gespeichert.

Der zweite Eintrag würde dann die (lokalen) Dateien auf ein entferntes NAS sichern.

Hab ich da vllt. einen Denkfehler?

 

[Tommes]

Als erstes wählst du das Datensicherungsziel aus, also die lokale DS. Im zweiten Schritt wählst du die Datensicherungsquelle( n ) aus, also deinen Remote-Server, was dann als Pull-Backup im Auswahlmenü angezeigt werden sollte. Einzig die zu sichernden Ordner musst du als kompletten Pfad manuell angeben, da Basic Backup über die GUI nicht auf einen Remote-Server zugreifen kann/darf.

 

[Yippie]

Ich hänge leider noch immer beim Pull-Backup: lokale Syno <- Remote Syno.

Lt. der Hilfe gibt es drei Punkte zu beachten, bzw. einzurichten:

1. SSH auf dieser Synology NAS einrichten
2. SSH auf einem Remote Server einrichten
3. SSH Handshake und RSA Austausch

Basic Backup ist auf dem Ziel, also dem lokalen NAS eingerichtet, ich kann mich dort per SSH auch anmelden.

Was genau muss ich nun auf dem lokalen NAS einrichten bzw. muss ich alle Punkte 1-3 durchlaufen?

 

[Tommes]

muss ich alle Punkte 1-3 durchlaufen?

Yep

 

[Yippie]

Hm, beim ersten Punkt wird die Einrichtung eines SSH-Keys beschrieben, zuvor aber mit dem Admin-Benutzer auf dem lokalen NAS angemeldet.

Dies bedeutet, dass der SSH-Key ja für diesen Admin-User eingerichtet wird und später dann, auf dem Remote NAS, in die Datei authorized_keys kopiert wird?

Nur, ich habe auf dem Remote NAS einen eigenen Benutzer fürs rsync eingerichtet und diesen soll Basic Backup (vom lokalen NAS) eigentlich verwenden.

Wo und für welchen Benutzer muss jetzt dann der SSH-Key erstellt werden? Doch eigentlich auf dem Remote NAS und von dort auf das lokale NAS kopiert werden?