Basic Backup Basic Backup

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.669
Punkte für Reaktionen
1.566
Punkte
314
Hey @luddi
Ich hab mir das grade angeschaut und sehe auch kein großes Problem darin, solch eine Option zu implementieren. Ich sehe aber auch kein großes Problem darin, das einfach so zu lassen, zumal man im "worst case" Fall so immer die Möglichkeit hat, auf die "Task Config" zurückzugeifen und diese wieder in Basic Backup einzuspielen. Das ist quasi das Pendant zu Hyper Backups "Mit vorhandener Aufgabe neu verknüpfen".

Was mir aber grade auffällt ist, das ich gar keine Funktion in Basic Backup eingebaut habe, einen einzelnen, verloren gegangenen Auftrag über die GUI (über die Konsole geht das natürlich) wieder einzubinden. Ich habe nur eine Funktion um ALLE Aufträge, oder wie du es nennst "Task Configs" zu sichern und wiederherzustellen. Das treibt mich grad viel mehr um.

Aber gut... ich bin ja ein netter Kerl und werde schauen, was sich da machen lässt. Das wird aber alles ein wenig dauern, da ich nächste Woche noch viel um die Ohren habe und sehr warscheinlich erst ab übernächster Woche dazu kommen werde.

Tommes
 

luddi

Benutzer
Sehr erfahren
Mitglied seit
05. Sep 2012
Beiträge
3.259
Punkte für Reaktionen
601
Punkte
174
Ich sehe aber auch kein großes Problem darin, das einfach so zu lassen
Ich stimme dir zu und möchte dich auch nicht dazu drängen das umzusetzen. Es ist aus meiner Sicht definitiv kein "must have" sondern eher ein "nice to have" feature falls es wirklich jemanden gibt den dieses Verzeichnis an seinem Zielort stören sollte.

[...] ich bin ja ein netter Kerl [...]
Das ist mir bereits bekannt ;)(y)

Also ich würde das jetzt mit Prio "Low" einstufen wenn du überhaupt bereit bist das zu implementieren. Mach dir deshalb bitte keinen unnötigen Stress.
 
  • Like
Reaktionen: Tommes

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.669
Punkte für Reaktionen
1.566
Punkte
314
Mach dir deshalb bitte keinen unnötigen Stress.
Ich versuche in letzter Zeit mir genau dieses Verhalten abzugewöhnen, immer zu meinen, alles sofort erledigen zu müssen.

Eine Funktion fest zu implementieren ist manchmal einfacher und übersichtlicher für den Benutzer, als sich um jede Option Gedanken machen zu müssen. Ich kenne das von mir selbst, das ich hin und wieder garnicht wusste, das ich diese oder jene Option vielleicht irgendwann mal hätte gebrauchen können. Aber gut…

Ich denk mal drüber nach und schaue, ob ich dafür einen Optionsschalter zur Verfügung stellen werde oder nicht. Auf jeden Fall werde ich aber eine Möglichkeit schaffen, das man einzelne Aufträge wiederherstellen, ggfl. auch einzeln manuell sichern kann. Das geht zum Teil zwar schon, jedoch wurde dieser Vorgang von mir nicht dokumentiert und funktioniert auch nur auf Umwegen. Vielleicht kommt dann am Ende eine Kombination aus allem heraus, so das man stets die Wahl hat. Mal schauen…
 
  • Like
Reaktionen: luddi

Dillschnitte

Benutzer
Mitglied seit
03. Apr 2014
Beiträge
10
Punkte für Reaktionen
0
Punkte
1
Hallo liebe Backup-Spezialisten!

Ich nutze aktuell noch das Ultimate Backup auf meiner DS218. Weil ich das Tool so klasse finde, habe ich mich bisher gesträubt die NAS auf das DSM7 zu aktualisieren. Jetzt habe ich mit Freude festgestellt das es einen "Fork" in Form von Basic Backup für das aktuelle DSM gibt.
Zuerst einmal herzlichen Dank @Tommes, für die Mühe und den Entwicklergeist der hier an den Tag gelegt wird!
Auch auf die Gefahr die Antwort eventuell überlesen zu haben, meine Frage: Können Backup-Jobs (mit Versionierung) welche im Ultimate Backup erstellt worden sind im Basic Backup weiterverwendet werden, oder müsste man diese neu erstellen?

Gruß
Florian
 

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.669
Punkte für Reaktionen
1.566
Punkte
314
Können Backup-Jobs (mit Versionierung) welche im Ultimate Backup erstellt worden sind im Basic Backup weiterverwendet werden, oder müsste man diese neu erstellen?
Ausprobiert habe ich das selber nicht und würde auch davon abraten es zu versuchen, in der Theorie könnte das aber klappen, da die Ordnerstrukturen soweit identisch sein sollten. Theoretisch!
 

williwkl

Benutzer
Mitglied seit
11. Nov 2020
Beiträge
13
Punkte für Reaktionen
1
Punkte
3
Hallo alle.

Ich habe mir BasicBackup vor 10 Tagen installiert und bis heute nicht zum Laufen bekommen. Die Prozedur zur ssh-Verbindung habe ich mehrmals durchlaufen und bin der Meinung, alles wie benötigt installiert zu haben. Die Fehlermeldung lautet:

[...] Die Verbindung zum Remote Server ist fehlgeschlagen.

Ich habe auch versucht mehr zu erfahren und habe -v/-vv und -vvv im script ergänzt, aber leider kam immer nur der gleiche kurze Text. Was kann ich tun, damit ich es ausführlicher sehen kann?

Ein Punkt ist mir beim Handschake aufgefallen. Nach dem kopieren des public-key mit cat... melde ich mich an der remote-Station ab und dann wieder an. Hier muss ich nun trotzdem wieder mein PW eingeben. Das sollte so nicht sein. In der authorized_keys-Datei ist der Schlüssel jetzt schon vier Mal vorhanden, weil ich die Prozedur ja schon mehrfach durchgemacht habe.

Auf der remote-Station habe ich einen extra Benutzer eingerichtet, der in der Admin-Gruppe ist und rsync ausführen darf. Sein Unterverzeichnis sieht so aus:

williRsync-ext@DS_williwkl-ext:~/.ssh$ ls -la
total 16
drwx------ 2 williRsync-ext users 4096 Jul 15 13:12 .
drwxrwxrwx+ 3 williRsync-ext users 4096 Jul 15 13:07 ..
-rw------- 1 williRsync-ext users 2968 Jul 20 23:48 authorized_keys
-rw-r--r-- 1 williRsync-ext users 387 Jul 15 13:19 known_hosts

Was könnte ich noch probieren?
 

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.669
Punkte für Reaktionen
1.566
Punkte
314
Hi!

Bau über das Terminal deiner lokalen Diskstation eine Verbindung zu deinem Remote-Server nach dem nachfolgenden Schema auf und verwende dabei den Optionsschalter -v

Bash:
ssh -p [PORT] -v [USERNAME]@[SERVER-ADDRESS]

Poste bitte, was dir im Terminal ausgegeben wird.
 

williwkl

Benutzer
Mitglied seit
11. Nov 2020
Beiträge
13
Punkte für Reaktionen
1
Punkte
3
Das ist der output:
Code:
PS Microsoft.PowerShell.Core\FileSystem::\\DS_williwkl\homes\admin> ssh -p 22 -v williRsync-ext@DS_williwkl-ext
OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2
debug1: Connecting to DS_williwkl-ext [192.168.178.45] port 22.
debug1: Connection established.
debug1: identity file C:\\Users\\willi/.ssh/id_rsa type 0
debug1: identity file C:\\Users\\willi/.ssh/id_rsa-cert type -1
debug1: identity file C:\\Users\\willi/.ssh/id_dsa type -1
debug1: identity file C:\\Users\\willi/.ssh/id_dsa-cert type -1
debug1: identity file C:\\Users\\willi/.ssh/id_ecdsa type -1
debug1: identity file C:\\Users\\willi/.ssh/id_ecdsa-cert type -1
debug1: identity file C:\\Users\\willi/.ssh/id_ed25519 type -1
debug1: identity file C:\\Users\\willi/.ssh/id_ed25519-cert type -1
debug1: identity file C:\\Users\\willi/.ssh/id_xmss type -1
debug1: identity file C:\\Users\\willi/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_for_Windows_8.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.2
debug1: match: OpenSSH_8.2 pat OpenSSH* compat 0x04000000
debug1: Authenticating to ds_williwkl-ext:22 as 'williRsync-ext'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:QzS7a2p4PP01cG7jagJ7dVUU5wPA0ZKkUZQcxOsg9ZM
debug1: Host 'ds_williwkl-ext' is known and matches the ECDSA host key.
debug1: Found key in C:\\Users\\willi/.ssh/known_hosts:14
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: pubkey_prepare: ssh_get_authentication_socket: No such file or directory
debug1: Will attempt key: C:\\Users\\willi/.ssh/id_rsa RSA SHA256:YlyNQQUTA38DSpq+Yn48IlsEOln7Vkn/TftUbCWZZ/M
debug1: Will attempt key: C:\\Users\\willi/.ssh/id_dsa
debug1: Will attempt key: C:\\Users\\willi/.ssh/id_ecdsa
debug1: Will attempt key: C:\\Users\\willi/.ssh/id_ed25519
debug1: Will attempt key: C:\\Users\\willi/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: C:\\Users\\willi/.ssh/id_rsa RSA SHA256:YlyNQQUTA38DSpq+Yn48IlsEOln7Vkn/TftUbCWZZ/M
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: C:\\Users\\willi/.ssh/id_dsa
debug1: Trying private key: C:\\Users\\willi/.ssh/id_ecdsa
debug1: Trying private key: C:\\Users\\willi/.ssh/id_ed25519
debug1: Trying private key: C:\\Users\\willi/.ssh/id_xmss
debug1: Next authentication method: password
debug1: read_passphrase: can't open /dev/tty: No such file or directory
williRsync-ext@ds_williwkl-ext's password:
debug1: Authentication succeeded (password).
Authenticated to ds_williwkl-ext ([192.168.178.45]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: ENABLE_VIRTUAL_TERMINAL_INPUT is supported. Reading the VTSequence from console
debug1: ENABLE_VIRTUAL_TERMINAL_PROCESSING is supported. Console supports the ansi parsing
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Remote: Ignored authorized keys: bad ACL permission for file /volume1/homes/williRsync-ext

Synology strongly advises you not to run commands as the root user, who has
the highest privileges on the system. Doing so may cause major damages
to the system. Please note that if you choose to proceed, all consequences are
at your own risk.

williRsync-ext@DS_williwkl-ext:~$

"No such file or directory" könnte auf einen Fehler hinweisen, aber ich kann das bisher nicht beurteilen.

Wilhelm
 

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.669
Punkte für Reaktionen
1.566
Punkte
314
Hi!

Da ich grad kein Windows zu Hand habe und ich mit der Windows PowerShell noch nie groß gearbeitet habe eine Frage:
PS Microsoft.PowerShell.Core\FileSystem::\\DS_williwkl\homes\admin> ssh -p 22 -v williRsync-ext@DS_williwkl-ext

Du hast dich über die PowerShell eines Windows Rechners per ssh auf deine Diskstation DS_williwkl als admin eingeloggt und versuchst von dort aus, eine SSH-Verbindung zu deiner Diskstation DS_williwkl-ext aufzubauen?

Da laut deinem Protokol aber versucht wird auf die RSA-Keys deines Windows Rechners zuzugreifen...
debug1: identity file C:\\Users\\willi/.ssh/id_rsa type 0
... vermute ich eher, das du dich von dort aus versucht hast, auf deine Diskstation DS_williwkl-ext aufzuschalten. Falls dem nicht so ist, dann beschreib bitte mal genau, von wo aus du dich wie auf deine DS_williwkl-ext verbindest.

Laut meiner Basic Backup Beschreibung sollst du dich aber auf deiner Diskstation DS_williwkl als root einloggen und darüber dann eine SSH-Verbindung zu deiner Diskstation DS_williwkl-ext aufzubauen!
 
Zuletzt bearbeitet:

williwkl

Benutzer
Mitglied seit
11. Nov 2020
Beiträge
13
Punkte für Reaktionen
1
Punkte
3
Das war wirklich nicht gut gemacht von mir. Natürlich muss ich mich ja erst als admin/root einloggen. Habe ich nun nachgeholt:
Code:
PS Microsoft.PowerShell.Core\FileSystem::\\DS_williwkl\homes\admin> ssh -p 22 admin@DS_williwkl
admin@ds_williwkl's password:

Synology strongly advises you not to run commands as the root user, who has
the highest privileges on the system. Doing so may cause major damages
to the system. Please note that if you choose to proceed, all consequences are
at your own risk.

admin@DS_williwkl:~$ sudo -i
Password:


root@DS_williwkl:~# ssh -p 22 -v williRsync-ext@DS_williwkl-ext
OpenSSH_8.2p1, OpenSSL 1.1.1n  15 Mar 2022
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
ssh: Could not resolve hostname ds_williwkl-ext: Name or service not known


root@DS_williwkl:~# ssh -p 22 -v williRsync-ext@192.168.178.45
OpenSSH_8.2p1, OpenSSL 1.1.1n  15 Mar 2022
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to 192.168.178.45 [192.168.178.45] port 22.
debug1: Connection established.
debug1: identity file /root/.ssh/id_rsa type 0
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa_sk type -1
debug1: identity file /root/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: identity file /root/.ssh/id_ed25519_sk type -1
debug1: identity file /root/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /root/.ssh/id_xmss type -1
debug1: identity file /root/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.2
debug1: match: OpenSSH_8.2 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.178.45:22 as 'williRsync-ext'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:QzS7a2p4PP01cG7jagJ7dVUU5wPA0ZKkUZQcxOsg9ZM
debug1: Host '192.168.178.45' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:3
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /root/.ssh/id_rsa RSA SHA256:D4j3HyZqpxgknuNe610eephZF2OiOjvMgTeMrYk9iqY
debug1: Will attempt key: /root/.ssh/id_dsa
debug1: Will attempt key: /root/.ssh/id_ecdsa
debug1: Will attempt key: /root/.ssh/id_ecdsa_sk
debug1: Will attempt key: /root/.ssh/id_ed25519
debug1: Will attempt key: /root/.ssh/id_ed25519_sk
debug1: Will attempt key: /root/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /root/.ssh/id_rsa RSA SHA256:D4j3HyZqpxgknuNe610eephZF2OiOjvMgTeMrYk9iqY
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ecdsa_sk
debug1: Trying private key: /root/.ssh/id_ed25519
debug1: Trying private key: /root/.ssh/id_ed25519_sk
debug1: Trying private key: /root/.ssh/id_xmss
debug1: Next authentication method: password
williRsync-ext@192.168.178.45's password:
debug1: Authentication succeeded (password).
Authenticated to 192.168.178.45 ([192.168.178.45]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Remote: Ignored authorized keys: bad ACL permission for file /volume1/homes/williRsync-ext

Synology strongly advises you not to run commands as the root user, who has
the highest privileges on the system. Doing so may cause major damages
to the system. Please note that if you choose to proceed, all consequences are
at your own risk.

williRsync-ext@DS_williwkl-ext:~$

Zwei Dinge sind mir aufgefallen:
1. Am Anfang klappt es nicht mit dem Servernamen, sondern nur mit der direkten Eingabe der Server IP 192.168.178.45
2. Letzte Zeile der Hinweis auf die bad ACL

Habe mir dazu einen Permission Report erstellen lassen, den ich als csv und Excel Datei anhänge.
 

Anhänge

  • Synology_PermissionReport_20220725-234648.zip
    10,5 KB · Aufrufe: 4

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.669
Punkte für Reaktionen
1.566
Punkte
314
Dann hast du das gleiche Problem wie schon @stere ab Post #213 zu lesen ist. Leider hat der Benutzer nicht mehr geantworte, weshalb es zu keinem abschließenden Ergebnis gekommen ist. Wenn ich wüsste, was ihr anders macht als ich und wie genau ich den Fehler bei mir reproduzieren könnte, würde mir das sehr helfen. So ist es aber schwierig für mich, eine Lösung zu erarbeiten.

Ich werd hier noch das Ein oder Andere probieren und würde mich melden, wenn mir noch was einfällt. Für den Moment bin ich aber überfragt.

Ach ja… dein .zip File schaue ich mir später mal an. Bin noch nicht dazu gekommen.
 

williwkl

Benutzer
Mitglied seit
11. Nov 2020
Beiträge
13
Punkte für Reaktionen
1
Punkte
3
Für die Drive-Station habe ich offensichtlich zu viele Dateien zu kopieren. Also muss ich BB oder was anderes zum Laufen bringen. Ich mache also weiter mit meiner Suche.
 

williwkl

Benutzer
Mitglied seit
11. Nov 2020
Beiträge
13
Punkte für Reaktionen
1
Punkte
3
Danke für den Vorschlag, werde ich im Auge behalten. Allerdings sagt mir das bisher nichts und ich bräuchte dazu weitere Hinweise, wie das realisierbar ist.

Hauptziel ist aber nach wie vor ssh zum Laufen zu bringen. Habe alles nochmal gelöscht und neu eingerichtet. Kein Erfolg. Ebenso in der sshd_config den Eintrag "RSAAuthentication yes" ergänzt und den sshd neu gestartet. Das hat aber auch nichts bewirkt. Da gehen mir langsam auch die Ideen aus. Werde mich mal nach einem Experten umsehen müssen, der das mit Links kann :).
 

tokon

Benutzer
Mitglied seit
12. Dez 2015
Beiträge
192
Punkte für Reaktionen
41
Punkte
28
Allerdings sagt mir das bisher nichts und ich bräuchte dazu weitere Hinweise, wie das realisierbar ist.
Auf dem Backup-NAS in der File Station > Extras > Remote-Ordner bereitstellen > Freigegebener CIFS-Ordner
Hier dann die Ordner des Haupt-NAS einhängen und BB entsprechend für die Ordner konfigurieren.
 

williwkl

Benutzer
Mitglied seit
11. Nov 2020
Beiträge
13
Punkte für Reaktionen
1
Punkte
3
Dieser Link hat mir geholfen.
https://blog.aaronlenoir.com/2018/05/06/ssh-into-synology-nas-with-ssh-key/

Code:
Rechte auf externer DS geändert:
willi@DS_williwkl-ext:~$ chmod 755 /volume1/homes/willi

Anmeldung (mit dem Servernamen hat es nicht geklappt, aber mit der IP-Adresse):
root@DS_williwkl:/# ssh -p22 -v willi@DS_williwkl-ext
OpenSSH_8.2p1, OpenSSL 1.1.1n  15 Mar 2022
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
ssh: Could not resolve hostname ds_williwkl-ext: Name or service not known

root@DS_williwkl:/# ssh -p22 -v willi@192.168.178.45
OpenSSH_8.2p1, OpenSSL 1.1.1n  15 Mar 2022
...

Ergebnis:
debug1: Offering public key: /root/.ssh/id_rsa RSA SHA256:PHrChthDMn7Lr5WlLEXfv1fJxBXXmUphcBwk8oRXY14
debug1: Server accepts key: /root/.ssh/id_rsa RSA SHA256:PHrChthDMn7Lr5WlLEXfv1fJxBXXmUphcBwk8oRXY14
debug1: Authentication succeeded (publickey). --> Anmeldung ohne PW jetzt erfolgreich!!!

Vielleicht sollte das mit chmod 0755 /volume1/home/username für das Benutzerverzeichnis in die Beschreibung aufgenommen werden.
Jetzt kann ich mich um die weitere Sicherung kümmern.
 
  • Like
Reaktionen: Tommes

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.669
Punkte für Reaktionen
1.566
Punkte
314
Toll das du es hinbekommen hast, auch wenn das für mich mit dem chmod 755 nicht ganz nachvollziehbar ist, hat mein Admin Benutzer ebenfalls 777'er Rechte auf seinen Benutzer-Home-Ordner. Aber okay... scheinbar haben dieses Problem noch mehr Benutzer gehabt, wobei ich den Verweis in deinen verlinken Artikel nicht öffnen kann. Es mag auch sein, das wir dieses Phänomen bereits irgendwo schonmal besprochen hatten und ich es schlicht vergessen habe. Wie dem aus sei... schön das es jetzt funktioniert.

Tommes
 

williwkl

Benutzer
Mitglied seit
11. Nov 2020
Beiträge
13
Punkte für Reaktionen
1
Punkte
3
Gut oder schlecht, wer weiß?
Ich habe einen Testlauf gemacht, die Anmeldung hat geklappt, aber:
Code:
Der Remote Server ist einsatzbereit. Der Datensicherungsauftrag wird vorbereitet.
Datensicherungsauftrag abgebrochen! Der Zielordner konnte nicht erstellt werden.
Jetzt hat BB offensichtlich keine Schreibrechte mehr, oder verstehe ich das falsch?
 

Tommes

Benutzer
Sehr erfahren
Maintainer
Mitglied seit
26. Okt 2009
Beiträge
9.669
Punkte für Reaktionen
1.566
Punkte
314
Ich gehe davon aus, das du ein Push Backup ausführen möchtest - sprich, du möchtest Daten von deiner lokalen Diskstation auf einem Remoteserver sichern. Fall dem so ist, wäre meine erste Frage, ob der SSH Benutzer auf dem Remoteserver die nötigen Rechte hat, in dem gewählten Ordner einen neuen Ordner zu erstellen bzw. das Backup dort abzulegen. Als zweites würde ich gerne wissen, ob du den Optionsschalter --chmod=ugo=rwX an den Backupauftrag angehangen hast, so wie in Basic Backup angegeben? Als letztes wäre interessant zu erfahren was passiert, wenn die den Ordner im Vorfeld anlegst. Kannst du dann eine Datensicherung ausführen?
 


 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat