Open Miq1 opened 3 months ago
Hello Michael, Thanks for your report.
I don't understand your problem description. Can you be a bit more specific about it please.
"Synology" is a good indicator. Please check this two FAQ entries:
Best, Christian
Sorry for being unclear - I am German and my English may not be as good as I would hope for... Second I have not used Linux for many years and only recently converted from Windows to Ubuntu, so I am lacking knowledge about the nooks and crannies of course.
I sort of followed the FAQ, hence I was able to set up the Synology NAS to accept rsync requests over ssh for my user without requiring a password any more.
I proved it was working by rsync -vvv -e ssh micha@192.168.178.21:/volume1/NimbusBackup/
, which gave me
opening connection using: ssh -l micha 192.168.178.21 rsync --server --sender -vvvde.LsfxCIvu . /volume1/NimbusBackup/ (10 args)
receiving file list ...
server_sender starting pid=21203
[sender] make_file(.,*,0)
[sender] pushing local filters for /volume1/NimbusBackup/
[sender] make_file(#recycle,*,2)
[sender] make_file(backintime,*,2)
[sender] make_file(@eaDir,*,2)
[sender] popping local filters
send_file_list done
send_files starting
recv_file_name(.)
recv_file_name(#recycle)
recv_file_name(backintime)
recv_file_name(@eaDir)
received 4 names
done
recv_file_list done
get_local_name count=4 /volume1/NimbusBackup/
generator starting pid=5929
delta-transmission enabled
recv_generator(.,0)
recv_files(4) starting
drwxrwxrwx 4.096 2024/03/31 11:11:56 .
recv_generator(#recycle,1)
drwxrwxrwx 4.096 2024/01/19 20:14:22 #recycle
recv_generator(@eaDir,2)
drwxrwxrwx 4.096 2024/03/18 07:46:50 @eaDir
recv_generator(backintime,3)
drwxrwxrwx 4.096 2023/12/17 17:44:51 backintime
generate_files phase=1
send_files phase=1
recv_files phase=1
generate_files phase=2
send_files phase=2
send files finished
total: matches=0 hash_hits=0 false_alarms=0 data=0
recv_files phase=2
recv_files finished
generate_files phase=3
generate_files finished
sent 20 bytes received 552 bytes 381,33 bytes/sec
total size is 0 speedup is 0,00
client_run2 waiting on 5930
[generator] _exit_cleanup(code=0, file=main.c, line=1865): about to call exit(0)
That looks good to me and returned the folder names I was expecting.
The main difference to the FAQ seems to be that my backup folder is not in the home directory of my user, but in the root of the volume. As my Synology user is member of the administrators group, that was working before just fine (and still is, at least for rsync, as you saw before).
So I started to set up a config profile for backintime to use rsync via ssh in the same way, but that ended in the error message I posted in my initial post.
And so ended my understanding what is happening...
Thanks for your reply. Please feel free to suggest improvements of the FAQ entries.
The error message indicates a problem with mounting. Currently I have no new idea or info I can add here. Let's wait maybe my team mates have something to add.
@buhtz Thanks a lot so far! Keeping my fingers crossed... :wink
There is a thread in Synology forum that seems to deal with a similar issue. The solution there is to mount the root instead of the qualified path, but I would not know how to tell backintime to not use the root directory then.
And another oddity: Backintime is able to create the folder from the profile on the Synology, but in turn cannot find it obviously:
See the blank space in the path?
Can you give me your rsync version please?
And I need the rsync call from the debug output, or the whole debug output.
I am afraid that is the separating space between remote path and mount point only.
My PC is shut down for today, so I will have a look tomorrow only.
Thanks a lot for now!
I am not familiar with using sshfs
command on shell. Regarding to the error dialog and the message in it I have a further question. It complains that micha@192.168.178.21:Micha/backintime
could not be found. Is that a valid name/identifier for a "directory" when using sshfs
? Maybe there is somehow a slash missing in front of Micha
before the :
?
Sorry, I was not able to power up my PC yesterday and will not be today either, so I can not answer the version question yet.
As for your last question: I am pretty sure the path ist not correct. The complete path would be /volume1/home/Micha/backintime
. BackInTime itself manages to create that folder on the Synology when given Micha/backintime
as path. All attempts to use the complete or any other path ended up in authority errors.
I owe you the version: 1.4.1-1.
You asked for my version number of backintime :wink:
buhtz @.***> schrieb am Do., 18. Apr. 2024, 11:14:
I owe you the version: 1.4.1-1.
What does this mean? I don't understand.
— Reply to this email directly, view it on GitHub https://github.com/bit-team/backintime/issues/1674#issuecomment-2063404976, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGFPLXD7235JLCPGDU7FG33Y56FIPAVCNFSM6AAAAABFQIT4WKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRTGQYDIOJXGY . You are receiving this because you authored the thread.Message ID: @.***>
Hi @Miq1, please let me take over this issue from @buhtz since I have a Synology at hand and can try to diagnose this with BiT.
I suggest to switch to German here to make our communication easier and will write a summary in English finally so that other non-German users can understand the relevant parts...
Ich würde als Erstes gerne ein paar Punkte abklären, könntest du diese bitte prüfen und beantworten? Vielen Dank!
ssh micha@192.168.178.21
und wenn das klappt dann
id micha
und hier zeigencd /volume1/NimbusBackup/
funktioniert (pwd
muss den gleichen Pfad zeigen)Vielen Dank erst mal!
Gerne auf deutsch 😄
backintime
(und wird derzeit über einen CIFS-Mount benutzt)
Micha@SynMahal:~$ id Micha
uid=1026(Micha) gid=100(users) groups=100(users),101(administrators),65536(sc-syncthing)
Micha@SynMahal:~$ ls
backintime
Micha@SynMahal:~$ cd backintime
Micha@SynMahal:~/backintime$
Micha@SynMahal:~/backintime$ pwd
/var/services/homes/Micha/backintime
Micha@SynMahal:~/backintime$
Das Verzeichnis ist also ein anderes?!?
3. Einen Teil siehst du im Eröffnungspost - reicht das? Ich kann das Profil nämlich wegen des Fehlers nicht speichern und muss jedesmal von vorne anfangen...
Im Eröffnungspost sieht der SSH-Pfad /volume1/NimbusBackup
plausibel aus (= mit /
als erstem Zeichen),
im Screen Shot in diesem Post dagegen nicht. Daher meine Rückfrage.
BTW: Lt. FAQ soll man hier gar keinen Pfad eingeben (siehe Punkt 12) - der Grund ist mir unklar.
Aber bevor du die Config erneut anlegen musst, würde ich erst gerne noch andere Punkte abklären:
4. Das Verzeichnis heißt jetzt `backintime` (und wird derzeit über einen CIFS-Mount benutzt)
Wo heißt das Verzeichnis (jetzt) backintime
?
a) Die Freigabe auf der NAS (unter "Systemsteuerung > Freigegebener Ordner")
b) Der Mountpunkt auf deinem Rechner?
Micha@SynMahal:\~/backintime$ pwd /var/services/homes/Micha/backintime Micha@SynMahal:\~/backintime$
Das Verzeichnis ist also ein anderes?!?
Was meinst du mit "ein anderes"? ssh
loggt dich ins Home-Verzeichnis des NAS-Users ein und pwd
zeigt dir den absoluten Pfad zum akt. (NAS-internen) Verzeichnis an (/var/services/homes/Micha/backintime
statt verkürzt ~/backintime
).
Ich muss unbedingt wissen, wo du auf der NAS die Backups ablegen willst (ich gehe mal von dieser Backup-Richtung aus, also nicht davon, dass du Dateien von der NAS auf dem lokalen Rechner als Backup ablegen möchtest):
Wie heißt der freigebene Ordner für die Backups auf der NAS (Systemsteuerung > Freigegebener Ordner).
Wenn du mir bitte meine Fragen beantwortest, dann habe ich alle Infos, um das Szenario auf meiner NAS nachzustellen und eine Doku als Musterlösung zu schreiben...
Wo heißt das Verzeichnis (jetzt)
backintime
? a) Die Freigabe auf der NAS (unter "Systemsteuerung > Freigegebener Ordner") b) Der Mountpunkt auf deinem Rechner?
a)! Ich benutze backintime derzeit im lokalen Modus, gesichert wird auf auf das NetBackup/
-Verzeichnis auf dem Synology. Der Unterordner backintime
wurde schon von backintime angelegt. DerMount in der fstab sieht so aus:
//192.168.178.21/NetBackup /mnt/backup-mit-nas cifs vers=2.0,uid=1000,gid=1000,auto,rw,credentials=/home/micha/.smbcredentials 0 0
Dieses lokale Backup funktioniert, nachdem ich im Python-Code von backintime die rsync-Option --executability
entfernt habe und als Extraoptionen --no-owner --no-group --no-perms
angegeben habe. (erstere verwirft letztere und ist standardmäßig gesetzt).
Für die ssh
-Tests lege ich gerne ein neues an, bzw. macht backintime das ja selbst.
Was meinst du mit "ein anderes"?
ssh
loggt dich ins Home-Verzeichnis des NAS-Users ein undpwd
zeigt dir den absoluten Pfad zum akt. (NAS-internen) Verzeichnis an (/var/services/homes/Micha/backintime
statt verkürzt~/backintime
).
Ich hatte die Tilde übersehen, sorry.
Ich muss unbedingt wissen, wo du auf der NAS die Backups ablegen willst (ich gehe mal von dieser Backup-Richtung aus, also nicht davon, dass du Dateien von der NAS auf dem lokalen Rechner als Backup ablegen möchtest):
Wie heißt der freigebene Ordner für die Backups auf der NAS (Systemsteuerung > Freigegebener Ordner).
Du gehst richtig - Backup vom PC auf das NAS ist gewünscht. Der Ort ist mir relativ egal, unter /homes/Micha
fände ich es am logischsten.
Der Dateibaum in der File Station auf dem NAS sieht so aus (die backintime
-Ordner in home
und homes/Micha
sind Relikte meiner Versuche):
Die Freigegebenen Ordner sind diese:
Ich scheitere ebenfalls beim Speicher-Versuch des Profils in BiT mit der Fehlermeldung (nur relevanter Auszug):
Permission denied, please try again.
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(231) [sender=3.2.7]
Manuelle rsync
-Versuche ohne Bit funktionieren nur, wenn ich keinen Zielpfad angebe (also nur micha@192.168.178.21
verwende, ohne den Pfad mit Doppelpunkt danach.
# ist nur ein "dry-run" - kopiert also nicht wirklich Dateien!
rsync -v -rtDHh --relative --checksum --links --no-p --no-g --no-o --info=progress2 --rsync-path /bin/rsync --no-i-r --rsh="ssh -p 22 -o IdentityFile=/home/<user>/.ssh/synology_sshuser_id_rsa" --dry-run --chmod=Du+wx /home/<user>/Documents "sshuser@192.168.178.21:./test"
Wenn ich dagegen --rsync-path /bin/rsync
mit angebe (expliziter Pfad zu rsync
auf der NAS), geht es in der Kommandozeile.
In der BiT-Config kann ich das auch angeben, bekomme beim Speicherversuch dann aber eine andere Fehlermeldung:
Can't write to: /home/<user>/.local/share/backintime/mnt/tmp_9_52672
Funktioniert es bei dir mit dieser Option in BiT?
Ich versuche es weiter am WE...
Die rsync-Option brauche ich nicht, rsync gibt's genau einmal (/usr/bin/rsync
) und das wird auch benutzt.
Allerdings:
Sieht also analog zu deinem Versuch aus. Das ist doch ein Link auf den ssh-Mount, und der Mountpoint sieht so aus:
dr-xr-xr-x 1 micha micha 0 Jan 1 1970 mountpoint
Also keine Schreibrechte. Gemountet wird
micha@192.168.178.21:./ on /home/micha/.local/share/backintime/mnt/41B896E4/mountpoint type fuse.sshfs (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
@aryoda Konntest Du schon etwas herausfinden?
Hallo @Miq1 es hat leider etwas länger gedauert als gedacht bei mir, sorry!
Ich habe den Grund gefunden, aber noch keine Lösung:
sshfs
(nicht ssh
!!!), um den Folder lokal zu mounten für das Backup mit rsync.
Hier wird aber das sftp
-Subsystem von ssh
verwendet und der sftp
-Home-Folder auf der Synology ist aus unerklärlichen Gründen ein anderer (nämlich "fast" der Root-Folder der Synology, genauer: Der Root-Folder eines volumens).Durch die unterschiedlichen "home"-Folder von 1. und 2. legt BiT zwar (wie du gut beobachtet und beschrieben hast) den Pfad per ssh
an, scheitert dann aber am sshfs
, da dort der Folder nicht mehr existiert.
So kannst du also das BiT-Profil nicht speichern...
Ich suche jetzt nach einer Lösung (Synology umkonfigurieren wäre am Besten, da BiT nicht erraten kann, wo der sftp
-Home-Folder relativ zum ssh
-Homefolder steht...).
Meine TODOS:
openssh
kein Problem ist (Synology verwendet eine angepasste openssh
-Version)PS: Siehe man sshfs
:
SSHFS allows you to mount a remote filesystem using SSH (more pre‐ cisely, the SFTP subsystem). Most SSH servers support and enable this SFTP access by default
OK, die ssh/sftp-Installation von Synology DSM 7 wurde customized und ich habe bei diversen Konfig-Versuchen in /etc/ssh/sshd_config
keine Lösung gefunden, sftp und ssh ins gleiche Home-Verzeichnis zu bringen.
Ein genialer SO'ler hat aber eine tief versteckte Einstellung in der DSM-GUI gefunden, mit der das geht und ich habe damit BiT mit DSM 7 zum Laufen gebracht:
@Miq1 Könntest du bitte mal testen, ob du bei deinem Synology-User, den du für ssh
verwendest (in meinem Beispiel sshuser
, bei dir vermutlich micha
), den Home-Folder wie in meinem Screenshot umkonfigurieren kannst? Dann sollte BiT funktionieren...
Control Panel > File Services > Advanced Settings > Change user root directories > Select User > Add > User or group > dein ssh-User auf der Synology > [x] User home
@aryoda Klasse ! Das funktioniert tatsächlich. Ganz herzlichen Dank für Deine Hartnäckigkeit und Hilfe! 👍🏻
Nebenschauplatz: beim Aufräumen auf dem NAS fiel mir auf, dass Synology die Größe des Backupordners berechnet, ohne die Links zu beachten. Dadurch entsteht eine "Größe", die ein Vielfaches der Kapazität des NAS darstellt. Bei mir werden z.B. statt ca. 108GB realer Größe (sagt rsync) dann mehr als 16TB angezeigt. Das NAS hat aber nur 1,9TB.
@aryoda Klasse ! Das funktioniert tatsächlich. Ganz herzlichen Dank für Deine Hartnäckigkeit und Hilfe! 👍🏻
Sehr schön, vielen Dank für die Rückmeldung. Ich mache mich dann an demnächst daran, die TODOs abzuarbeiten (v. a. unsere FAQ zur Synology zu aktualisieren), hier eine engl. Zusammenfassung zu schreiben und dann das Ticket zu schließen (wenn du einverstanden bist).
Bei mir werden z.B. statt ca. 108GB realer Größe (sagt rsync) dann mehr als 16TB angezeigt. Das NAS hat aber nur 1,9TB.
Danke für den Hinweis, ich werde das auch noch in den FAQs erwähnen...
Please be aware of #1745 where BIT show a similliar behavior in context of a Hetzner Storage Box. Might it be the same?
I am using Ubuntu 22.04 LTS with backintime 1.2.1, so there is no
--diagnostics
yet. There seems to be no backport of a more recent backintime for Jammy.I am trying to use backintime to back up to a remote folder on my NAS (Synology DS216j with version 7.1.1). While that is working with the folder mounted locally, but with issues like excess copying of files that are not changed, I cannot get the rsync/ssh variety to work.
I can manually rsync with ssh to the folder
/volume1/NimbusBackup/
from the console, but setting up a backintime profile ends with this error:Since I am using the exact same path when manually using rsync, I have no clue what may be wrong.