staging.inyokaproject.org

Ich hoffe, ich bin in diesem Unterforum richtig, ansonsten bitte verschieben...

Ich will von meinem Kubuntu-PC ein Generationen-Backup auf einem NAS (Synology DS420+ mit DSM 7) erstellen. Da die Daten ohne spezielle Software lesbar sein sollen, geht das offenbar nur mit rsnapshot und Back in Time. Da ich die Backups gerne halbwegs übersichtlich mit GUI prüfen/verwalten möchte, habe ich erst einmal Back in Time 1.3.1 auf dem Quell-PC installiert.

Beim Backup soll auf dem NAS der eigens eingerichtete Benutzer Backup genutzt werden.

Nach einigen Versuchen kriege ich keine Fehlermeldungen mehr. Jetzt nutze ich folgende Einstellungen in Back in Time:

Modus: SSH
Rechner: IP_DES_NAS
Port: 21                                          # Vorgabe des NAS
Benutzer: Backup
Pfad: /volume1/Backups
Verschlüsselung: Standard
privater Schlüssel: home/LOCAL_USER/.ssh/id_rsa
Passwort Privater Schlüssel: SSH_PASSPHRASE
Passwort in Schlüsselbund speichern: deaktiviert
Passwort für Cron zwischenspeichern: aktiviert
Rechner: LOCAL_RECHNER
Benutzer: LOCAL_USER
Profil: 3
Zeitplan: deaktiviert

Wenn ich im Einstellungen-Fenster OK klicke kommt nach 5 Minuten die Meldung Möchten Sie den öffentlichen SSH-Schlüssel auf den entfernten Rechner kopieren, um Anmeldung ohne Passwort zu aktivieren? Vorgabe: Nein, ich klicke JA

Nach 10 Minuten ist der Vorgang offenbar abgeschlossen (keine Meldung), jedenfalls kann ich einen anderen Reiter/Tab im Einstellungsfenster wählen.

Wenn ich dann OK klicke um den Dialog zu schliessen kommt nach 5 Minuten wieder die Meldung Möchten Sie den öffentlichen SSH-Schlüssel auf den entfernten Rechner kopieren... spätestens 10 Minuten später ist klar, dass ich in einer Endlosschleife hänge.

/home/LOCAL_USER/.ssh/ wird übrigens nicht verändert.

Was mache ich falsch?

Übrigens: ein cron-gesteuertes Backup mit rsync auf das NAS mit rsync -au --delete --exclude=.Trash-1000/ --exclude=lost+found/ /media/Daten/ IP_DES_NAS::DATEN_BACKUP funktioniert.

Funktioniert der rsync Befehl auch, wenn Du das zu dem Backup-Benutzer syncst und brauchst Du bei dem rsync ein Passwort oder nicht?

Du solltest auf jeden Fall als erstes sicherstellen, dass der Benutzer Backup sich ohne Passwort per SSH am NAS anmelden kann, siehe SSH (Abschnitt „Authentifizierung-ueber-Public-Keys“). Die Schlüsselerzeugung kannst Du Dir natürlich sparen, denn Du solltest schon einen haben.

Danke! ...ich gebe zu, das einrichten von ssh habe ich nie richtig verstanden. 😲 Ich mache es aber auch sehr selten...

Nun habe ich entdeckt, dass ich mich zwar mit LOCAL_USER@IP_DES_NAS anmelden konnte, ~/.ssh/authorized_keys existierte aber nicht auf dem Server. Nachdem ich ssh-copy-id -i ~/.ssh/id_rsa.pub LOCAL_USER@IP_DES_NAS ausgeführt habe, ist der Public-Key jetzt offenbar übertragen.

Wie kann ich nun narrensicher testen, ob ssh mit der Public-Key-Methode funktioniert?

Ich habe jetzt noch einmal Back in Time gestartet: wenn ich das Einstellungen-Fenster mit OK verlasse, reagiert das Programm nicht mehr und nach 5 Minuten kommt die Frage Möchten Sie den öffentlichen SSH-Schlüssel auf den entfernten Rechner kopieren. Nach JA reagiert das Programm wieder nicht mehr und nach weiteren 5 Minuten bin ich wieder im Einstellungen-Fenster. Es ist auch egal, ob ich als Benutzer LOCAL_USER oder Backup wähle. Mir bleibt nichts übrig als abzubrechen.

In der Konsole kann ich mich mit ssh Backup@IP_DES_NAS und ssh LOCAL_USER@IP_DES_NAS anmelden.

Was mache ich falsch? Wie kann ich den Fehler suchen?

KBionic ist außerhalb des Supports seit über 4 Monaten.

Ist zwar alt, aber das Problem hatte ich auch. Vielleicht hilft meine Antwort aber noch anderen.

Backintime ist nicht sehr auskunftsfreudig und Fehlermeldungen gibt es schon gar keine an dieser Stelle aus. Wenn das so lange dauert, hast Du schlicht den falschen Pfad angegeben.

Ich gehe davon aus, das diese Kauf-NAS auch ein recht normales Linux fahren?

Terminal öffnen:

1

ssh-keygen

Und dann den Key auf das NAS kopieren, damit es auch Zugriffe vom PC gestattet.

1

ssh-copy-id user@server

Und nun musst Du den Pfad zu Deinem gewünschten Backp-Ordner herausfinden. Wenn es ganz blöd läuft, dann sieht der zum Beispiel so aus:

1

/srv/dev-disk-by-uuid-yxyxyxyxy-yxyx-yxyx-yxyx-yxyxyxyxyxyxyxyxyxyx/BACKUPS

Das Problem ist leider wieder typisch für viele gute Anwendungen unter Linux. Benutzerfreundlich ist das alles nicht. Ansprechen darf man das Problem aber auch nicht. Ach ... huch.

Gruß Mierscheid