Ultimate Backup Ultimate Backup

[Toby-ch]

Da ich das selber aber weder getestet habe noch das ich das in irgendeiner Form empfehlen würde, machst du das alles natürlich auf deine eigene Kappe!

Was kann da schon schiefgehen ? soweit mir dies bekannt ist basiert UB auf Rsync und Rsync ist doch ein Bestandteil von DSM wenn nicht sogar vom kernel ? ?

 

[Tommes]

Dann probier es halt aus. Aber von den ca. 1500 Zeilen BASH Code, die so ein Backup Job hat, nimmt der eigentliche rsync Befehl nur eine Zeile in Anspruch… und jetzt denk mal scharf nach…

Also nochmal. Lass es einfach. Und wenn du es doch nicht lassen kannst, dann teste es halt und mach deine eigene Erfahrung.

Tommes

 

[Jagnix]

Lernen durch Schmerzen sag ich da nur.
Lass gut sein @Tommes . Mehr als warnen geht nicht.

 

[Anthracite]

Benötigt man unbedingt UB muss man sich halt das Update auf DSM 7 verkneifen

Das ist meine Lösung. UB ist mir wichtiger als die neuen Features der Version 7. Aber bei meinem Syno handelt es sich nur noch um das Zweit-NAS für ein Außer-Haus-Backup. (Habe gerade gesehen, dass für mein Modell DSM 7 nicht mehr angeboten wird. Das macht das Verkneifen umso leichter.)

Ein Update von 6.0 auf 6.2 sollte ich vielleicht noch machen. Das selige TimeBackup wird dank UB nicht mehr benötigt. Oder spricht da was dagegen?

Hyper Backup kann beides. Wenn man Versionen seiner Daten vorhalten möchte oder wenn man den Datensatz gerne verschlüsselt abgelegt hätte, dann sollte man datenbankbasiert sichern. Ansonsten kann man auch dateibasiert sichern. Das nennt sich dann "Einzelversion", je nach dem ob du lokal oder Remote sichern möchtest...

Aber Hyper Backup konnte kein dateibasiertes Backup mit Versionierung. Das ist genau die Variante, die ich brauche. UB kann das, das alte TimeBackup konnte das, und die Konkurrenz von Qnap ebenfalls. Hat sich diesbezüglich was geändert, d. h. kann Hyper Backup jetzt dateibasiert mit Versionen? War das nicht auch die ursprüngliche Motivation, UB zu schreiben?

Außerdem kann Hyper Backup kein rsync über ssh-Tunnel. Zumindest habe ich das nicht geschafft. Mit UB geht das.

 

[himitsu]

Hyper-Backup kann (glaube immernoch nicht) bei Dateibasiert keine Versionen.

Alternative (vielleicht), wenn du auf dem Ziel dafürber nochmal sowas wie Snapshots drüberlegts,
nach Ende des Backups, bzw. irgendwann zwischen zwei Backups (spätestens kurz bevor es startet).

 

[Tommes]

UB ist mir wichtiger als die neuen Features der Version 7

Für diese Aussage sollte ich dir eigentlich einen Drink ausgeben ? Nichts desto trotz setzt du dabei auf einen toten Gaul. Igendwann wirst du deine Meinung ändern, da bin ich mir ziemlich sicher. Aber für den Moment lassen wir das einfach mal so stehen.

Aber Hyper Backup konnte kein dateibasiertes Backup mit Versionierung. [ .. ] Hat sich diesbezüglich was geändert, d. h. kann Hyper Backup jetzt dateibasiert mit Versionen?

Hyper Backup konnte und kann bis heute keine dateibasierte-, sondern nur eine datenbankgestützte Versionierung!

War das nicht auch die ursprüngliche Motivation, UB zu schreiben?

Nicht wirklich. Hyper Backup bot in den Anfängen keine Möglichkeit an, eine dateibasierte Datensicherung durchzuführen. Erst im späteren Verlauf - u.a. auf Druck der Benutzer - hat Synology die dateibasierte Datensicherung in Hyper Backup implementiert. Das war meine ursprüngliche Motivation; weiterhin eine dateibasierte Datensicherung anzubieten. Anfänglich war da auch nur ein kleines Bash-Script welches mit der Zeit immer umfangreicher und größer wurde. Erst nachdem der Ruf nach einer GUI immer lauter wurde enstand Ultimate Backup.

Außerdem kann Hyper Backup kein rsync über ssh-Tunnel. Zumindest habe ich das nicht geschafft. Mit UB geht das.

Das bezahlst du aber auch teuer, da du dafür das Root-Konto verwenden musst. Okay... müssen ist vielleicht übertrieben... aber UB ist halt so ausgelegt, das es am besten mit dem Root-Konto arbeitet. Und SSH als root geht nur noch, wenn das Standard "admin" Konto aktiviert ist. Somit zahlst du gleich doppelt... auch wenn sich über die Verwendung von root und admin sicherlich kontrovers diskutieren lässt. Das wären dann auch die Anforderungen an ein neues Backup Programm, welches eben ohne das Root-Konto auskommen müsste... zumindest was den SSH-Verbindungsaufbau anbelangt.

Alternative (vielleicht)...

Jap... wer weiß das schon.

 

[Anthracite]

Nichts desto trotz setzt du dabei auf einen toten Gaul.

Der Gaul läuft, solange das NAS noch läuft. Für ein neues NAS werde ich irgendwann mal eine neue Lösung brauchen. Das darf aber gerne noch dauern.

Das bezahlst du aber auch teuer, da du dafür das Root-Konto verwenden musst. Okay... müssen ist vielleicht übertrieben... aber UB ist halt so ausgelegt, das es am besten mit dem Root-Konto arbeitet.

Ja, aber das gilt nur für das Syno, auf dem UB läuft. Auf dem fernen NAS - in meinem Falle ein Qnap, aber das gälte für zweites Syno genauso - genügt ein einfacher User (weder root noch Admin). Lediglich das Privileg für den rsync-Befehl braucht jener User, und damit kann man dessen zusätzliche Privilegien in sudoers auf genau den rsync-Befehl begrenzen. Der ssh-Tunnel wird also mit den Anmeldedaten eines einfachen Users aufgebaut.

Dann habe ich die Anmeldung ausschließlich über ssh-Keys eingestellt, für UB allerdings ohne Passphrase, ich meine, das ging nicht. Damit ein Angreifer, der das Syno übernommen hat, nicht auch auf dem fernen NAS Unfug treiben kann, habe ich den Zugriff auf dem fernen NAS in authorized_keys auf ein Kommando eingeschränkt, welches ein Shell-Skript ist, das ausschließlich die von UB gebrauchten Kommandos akzeptiert, und auch nur dann, wenn der Pfad stimmt, d. h. darüber kann man nicht aus dem Backup-Verzeichnis auf dem fernen NAS ausbrechen.

Ich denke mal, das ist sicher.

Ich dachte schon, UB könnte idealerweise auch das Shell-Script in authorized_keys für das ferne NAS erstellen, denn in UB ist exakt bekannt, welche Aufrufe gebraucht werden, aber dafür müsste UB eine Zukunft haben. Wenn du oder irgendwer anderes sich daran macht, UB doch für die Zukunft fit zu machen, dann meldet euch deswegen bei mir.

 

[Tommes]

Das klingt alles ziemlich interessant, jedoch werden die meisten Benutzer damit überfordert sein, in der sudoers oder der sshd_config rumzuwurschteln oder gar Scripte über die authorized_keys zu verknüpfen. Die meisten haben ja schon Probleme damit, über einen Terminal die Befehle für den Aufbau einer SSH-Ordnerstruktur einzugeben, auch wenn die Anleitung dazu noch so gut geschrieben ist. Viele wissen zudem oftmals gar nicht, was ein Terminal ist... was ich ja auch niemanden zum Vorwurf machen will.

Auf der anderen Seite halte ich mittlerweile wenig davon, automatische Prozesse in ein Paket wie Ultimate Backup zu implementieren, die diese Aufgaben automatisch erledigen. Man kann sich damit auch selber schnell ins Knie schießen, wenn ich z.B. automatisch in der ssh_config die Option PasswordAuthentication auf no setzte und der Benutzer nicht weiß, was für Konsequenzen das haben kann, sollte er seinen Schlüssel mal verlieren.

Es bleibt also immer eine Gradwanderung und mittlerweile tendiere ich eher dazu zu sagen, das wenn ein Benutzer Programme wie z.B. Ultimate Backup benutzen will, dieser sich auch mit dem Thema SSH und RSA-Key befassen muss, damit er immer weiß, was auf seinem System passiert. Außerdem macht DSM 7 die Sache nicht einfacher, da viele Dinge nicht mehr so funktionieren wie noch unter DSM 6 und wo man dann nicht mehr einfach so eine automatisierte SSH-Ordnerstruktur für das Root-Konto mit einem Klick über die GUI erstellen kann.

Wenn du oder irgendwer anderes sich daran macht, UB doch für die Zukunft fit zu machen, dann meldet euch deswegen bei mir.

UB wird in der Form den Sprung auf DSM 7 nicht schaffen, falls du das mit "Fit für die Zukunft" meinst. Dafür weicht die Programmierung zu stark von den Anforderungen und Gegebenheiten von DSM 7 ab. Aber vielleicht kommt ja bald schon eine Alternative auf den Markt...

 

[himitsu]

Aber vielleicht kommt ja bald schon eine Alternative auf den Markt...

DSM8 ... dann wird alles viel besser. ?

 

[Tommes]

Für diejenigen von euch, die es noch nicht mitbekommen haben, aber diesem Thread hier folgen...

Es gibt ab sofort ein Fork zu Ultimate Backup. Es nennt sich Basic Backup und wer mehr darüber erfahren möchte, der klickt einfach *hier*

Tommes

 

[martinski]

Servus!
Ich lerne gerade erste Schritte mit UB und stosse auf diverse Zickereien, die ich bisher aber immer gelöst bekommen habe. Das meiste geht um komische SSH Dinge...

Ich habe es jetzt also geschafft mir eine script basteln zu lassen und beim dry-run kommt der Fehler mit dem "wrong password"



Mir ist jetzt nicht klar wessen passwort (ich nehm an root??) auf welcher Seite wrong ist. Wem muss ich wo welches Passwort noch mitteilen?

Wobei mir "Passwort" in diesem Zusammehang grundsätzlich nicht klar ist. Sollte das nicht alles mit Schlüsseln gehen ohne Passwort?

Das klappt nämlich eigentlich



Und im log sagt er ja auch "Ordner drüben aufm Ziel ist erreichbar". Wie soll er denn zu dieser Erkenntnis kommen, wenn er drüben nicht reinkommen würde? "The SSH connection has been established" steht ganz oben.

Ich habe meinem Admin auf beiden NASen mal das gleiche Passwort gegeben. Daran lag's aber auch nicht.

Und warum sagt er irgendwas von wegen "encrypted folder UNmounted"?



Die Ordner sind GEmounted und ich habe dem script nicht gesagt, dass es irgendwas in Bezug auf Verschlüsselung tun soll.
Bezieht sich der Passwort Fehler vielleicht auf irgendetwas im Bereich Verschlüsselung?

Danke für eure Hilfe!

Gruss
Maddin

 

[Tommes]

Hi!

...kommt der Fehler mit dem "wrong password" [ ... ] Mir ist jetzt nicht klar wessen passwort (ich nehm an root??) auf welcher Seite wrong ist.

Nun. Der rsync-error-code 44 wird immer dann ausgeworfen, wenn das Standard "admin" Konto auf deiner deiner Remote DS deaktivert ist. Du kannst dich zwar auf deiner DS direkt über ein Terminal oder von mir aus über PuTTY per RSA-Authenzifizierung als root aufschalten, oder den Weg über dein Administratorkonto, gefolgt durch Eingabe von sudo -i um zum root Konto zu wechseln. Über die GUI bzw. dem dahinter liegenden rsync-Script von Ultimate Backup bzw. über ein einfaches Bash Script oder gar per Befehl über das Terminal funktioniert das aber nicht. Du kannst das selber gerne mal testen, indem du über das Terminal versuchst, eine SSH-Verbindung zum root deiner Remote DS herzustellen, also z.B. so...

ssh -p [PORT] root@[SERVER-ADDRESS]

... das wird solange scheitern, bis das du das Standard "admin" Konto auf der Remote DS, mit der du dich verbinden willst, aktiviert ist.

Und im log sagt er ja auch "Ordner drüben aufm Ziel ist erreichbar". Wie soll er denn zu dieser Erkenntnis kommen, wenn er drüben nicht reinkommen würde? "The SSH connection has been established" steht ganz oben.

Da bin ich grade überfragt, nutzte ich Ultimate Backup schon länger nicht mehr. Theoretisch läuft das aber so...
Es wird zuerst ein Ping Befehl abgesetzt, um zu prüfen, ob der Remote Server "online" ist, ansonsten kann dieser ggf. per WOL geweckt werden. Nachdem die Überprüfung abgeschlossen ist und das System erkennt, das der Remote Server online ist, wird eine SSH-Testverbindung aufgebaut, einige Server Daten abgefragt und bei Erfolg ein - "The SSH connection has been established" - ausgeworfen. Eigentlich wiederspricht das aber dann dem rsync-error-code 44, da ja scheinbar eine SSH Verbindung erfolgreich hergestellt werden konnte. Es kann auch sein, das diese Meldung bereits nach einem erfolgreichen Ping ausgelöst wird. Um das zu überprüfen, müsste ich mich nochmal in das Script reinfuchsen und da steht mir grade nicht der Kopf nach.

Und warum sagt er irgendwas von wegen "encrypted folder UNmounted"? [ ... ] Die Ordner sind GEmounted und ich habe dem script nicht gesagt, dass es irgendwas in Bezug auf Verschlüsselung tun soll.

Ich meine, das kontrolliert Ultimate Backup automatisch, aber auch hier müsste ich mir das im Detail anschauen um eine fundierte Aussage zu treffen.

Wie gesagt, ich nutzt Ultimate Backup nicht mehr, jedoch liegt das nicht daran, das das Programm schlecht ist. Es funktioniert leider nicht mehr unter DSM 7 und da ich hier bis auf eine VM nur noch DSM 7 Boliden rumstehen habe, kann ich es nicht mehr einsetzen. Daher habe ich für DSM 7 Basic Backup entwickelt.

Tommes

 

[martinski]

Und kaum macht man's richtig, schon geht's!
Admin Konto wieder angeschaltet und es ging. Es war aus, weil Synology ja mal davor gewarnt hatte, dass es angreifbar sei.

Danke!

 

[Tommes]

Und eigentlich sollte man dem Rat von Synology auch folgen, aber das muss ja jeder für sich entscheiden. Sei's drum... freut mich, das es läuft!

 

[martinski]

Haste ja recht. Ist aber alles nur im lokalen Netz. Das Risiko gehe ich ein und hoffe mal, dass sich niemand die Mühe macht sich hier reinzuhacken und dann den Admin account aufhacken zu wollen.

 

[himitsu]

"angreifbarer" ist es, weil jeder diesen Namen kennt und somit nur noch das Passwort braucht. (oder eine Lücke, womit man das Passwort umgehen kann)

außerdem ist es unpraktisch, wenn die DS öffentlich ist, und jemand ständig sich als Admin anmelden will, wobei andauernd dieses Konto gesperrt würde und man selbst nicht rein kommt. (ein Konto mit unbekanntem Namen hat das Problemchen nicht seltener)


ansonsten haben halt fast Alle dieses Konto deaktiviert
und nutzen es nur noch für Notfälle, wenn sie sich mit ihrem anderen Adminkonto selbst ausgesperrt haben (hinten Reset gedrück und das "admin"-Konto ist wieder aktiv)

 

[martinski]

Absolut richtig. Mit einem ausreichend komplexen Passwort im lokalen Netz sollte die Gefahr überschaubar sein.

 

[Anthracite]

Das klingt alles ziemlich interessant, jedoch werden die meisten Benutzer damit überfordert sein, in der sudoers oder der sshd_config rumzuwurschteln oder gar Scripte über die authorized_keys zu verknüpfen.

Das glaube ich gerne.

Man könnte eine Anleitung automatisch generieren lassen, die genau beschreibt, was auf dem fernen System zu tun ist für eine sichere Nutzung, in der Hoffnung, dass nur Anwender, die die Anleitung auch verstehen, sie nutzen.

Man könnte ein Skript generieren, das auf dem fernen System ausgeführt werden kann und alle Einstellungen, sofern noch nötig, automatisch macht.

In beiden Fällen ist ein Problem aber, dass keineswegs bekannt ist, worum es sich bei dem fernen System handelt. Es kann ein Synology NAS sein, aber ebensogut ein Qnap oder ein normaler Linux-Rechner mit Ubuntu o. Ä., und in allen Fällen können die Schritte unterschiedlich sein. Gerade Qnap ist auf Grund des blöden Bootmechanismus aufwendig. Man könnte das also nur für ausgewählte Systeme freigeben.

Man könnte so viel machen. Aber die Programmierung muss einem auch Spaß machen. Es bezahlt dich niemand dafür. Du hast mein volles Verständnis, wenn du dazu keine Lust hast.

Auf der anderen Seite halte ich mittlerweile wenig davon, automatische Prozesse in ein Paket wie Ultimate Backup zu implementieren, die diese Aufgaben automatisch erledigen. Man kann sich damit auch selber schnell ins Knie schießen

Das verstehe ich voll und ganz. Macht man es nicht wirklich gründlich und gut, hat man nur Ärger damit.

Admin Konto wieder angeschaltet und es ging. Es war aus, weil Synology ja mal davor gewarnt hatte, dass es angreifbar sei.

Es geht auch ohne Admin, sondern mit einem normalen Benutzerkonto. Dieses braucht "nur" die Berechtigung in sudoers, rsync aufrufen zu dürfen. Dann muss noch ein "sudo" in den rsync-Aufruf eingeschmuggelt werden, entweder durch nachträgliche Änderung des von UB erzeugten Skriptes oder durch ein Skript als Kommando in Authorized_keys, welches dies erledigt. Wenn du verstehst, wovon ich rede, können wir das hier besprechen, ansonsten bleib einfach beim Admin. In einem LAN, wo beide NAS nicht direkt aus dem Internet erreichbar sind (d. h. keine Portfreigaben), spricht nichts dagegen. Bei zwei verschiedenen Standorten, wo man womöglich noch für die Sicherheit eines Standortes nicht garantieren kann, sicht das anders aus und es lohnt sich mehr Aufwand.

 

[martinski]

Ja, ich kenne mich damit aus. Aber wie du sagst, das ist im eigenen LAN nicht zwingend nötig.

 

[Tommes]

Man könnte eine Anleitung automatisch generieren lassen, die genau beschreibt, was auf dem fernen System zu tun ist für eine sichere Nutzung, in der Hoffnung, dass nur Anwender, die die Anleitung auch verstehen, sie nutzen.

Den Zahn kann ich dir ziehen. Das wird niemals so sein, da man sich doch all zu oft selbst in seinen Fähigkeiten überschätzt - und ich schließe mich da auch garnicht aus... hatte ich doch dank meines gefährlichen Halbwissens mal die sudoers geschreddert und wusste nicht mehr wie ich das rückgängig machen konnte. Da half dann nur die Berühmte Büroklammer... und ab dafür mit dem Reset-Knopf!

Ich habe in Basic Backup 3 Artikel zum Thema SSH Verbindung einrichten geschrieben, einmal für die lokale DiskStation, dann für Remote Server allgemein und eine für die Bekanntmachung der beiden Geräte (Handshake, Austausch des puplic Key etc.) Ich befürchte jetzt schon, das einige meckern werden, warum man das nicht automatisieren könnte oder was das für eine GUI wäre, wo man noch selber etwas für tun muss. Ultimate Backup war damals auch nur ein einfaches rsync-Script ganz ohne GUI. Erst auf Wunsch vieler entstand daraus das, was Ultimate Backup heute darstellt und die Wunschliste an noch zu implementierenden Dingen könnte noch lange weiter geschrieben werden.

Man könnte so viel machen. Aber die Programmierung muss einem auch Spaß machen.

Das ist vollkommen richtig. Man könnte noch so viel machen. Ich mache das auch alles nur, weil ich Bock darauf habe. Nicht um mich zu profilieren oder um Ruhm und Ehre zu kassieren, sonder einfach, weil es mir total viel Spaß macht. Nichts desto trotz lernt man für sich auch, eben nicht jedem Wunsch nachzukommen, sondern das zu tun, was man selber für richtig und sinnvoll erachtet. Daher heißt mein Fork zu Ultimate Backup ja auch Basic Backup, eben weil ich mich lieber auf das Wesentliche konzentrieren will, auch wenn das beutet, das ich nicht jeden damit erreichen werde.

Macht man es nicht wirklich gründlich und gut, hat man nur Ärger damit.

Wie ich seit Beginn von Ultimate Backup sage... ich spiele hier mit euren Daten, selbst wenn es am Ende nur ein einfacher rsync ist, den das Script ausführt. Und trotz das ich durch die GPL3, einer Beta-Deklarierung und was weiß ich nicht noch, erstmal aus allem raus bin, so möchte ich am Ende nicht derjenige sein, der Deinen Datenverlusst zu verantworten hat, egal ob es durch das rumfuchteln in der sudoers geht, seltsame rsync Optionen verwende oder ich einfach einen blöden rm -r Fehler im Script habe.

Aber ich rede schon wieder zu viel...

Tommes