Absolut desaster

[Fireobirdy]

I installed the app on my yunohost. It is a x86 with debian. During installation I gave the credentials of my NAS for sftp access.
I then startet the backup-process with systemctl start restic.service
It run a while and then finished with no message. After that, is started the check process with systemctl start restic_check.service. It also finished with no message. I then logged into my mail account and i got two messages. The first: YunoHost Restic backup log on soandso.xxx (SUCCESS)

The second:
YunoHost Restic check log on soandso.xxx (SUCCESS)
From restic@soandso.xxx on 31.03.2021 20:27
Details

To get more detailed info check the log files /var/log/restic_check_restic.log and /var/log/restic_check_restic.err

So i checked the log-files for errors and they where empty. Everything is running fine. The last thing i did was, to log on to my NAS and have a look at the files and there was NOTHING! No backup has been stored on the NAS.

This is an unexceptable and unexcusable bug from a software that is designed to make backups, even if it is free to use. I have absolut zero trust in this application any more. I don't know where this bug is comming from and i don't want to blame someone. It cannot be that there are several steps integrated to ensure everything works fine and all of them failed. Even worse, the user is getting a positiv feedback about the process. I dont't want to complain only. So if you need additional information to find the cause of this bug, feel free to ask. I will provide as much help as I can, even if I am convinced to not use this app for making backups of my yunohost-server.

[moutonjr]

While the issue is a bit aggressively written uselessly (an open source project is not a paid product, there is no service whatsoever, just a couple of benevolent devs trying their best to improve app...) I confirm the bug since I unplugged my NAS and ran restic service.

I got email that everything was a success.

I'm available to thorough investigation with my instance if not reproductible.

[ashemsay]

Hi, I'm sorry you had those problems. I already noticed the package was missing some tests and was only relying on user inputs since I never really had any problem using it, that's why I started working on integration tests a few days ago.
In the meantime you can show me the content of the log files, /var/log/restic_*.
I suggest you have a look at the borg package as an alternative and the official documentation for more info.

[Fireobirdy]

I have to apologize for my initial posting. I was really upset the moment I wrote it. Next time I wait a few hours to cool down.
Here are the the contents of the logfiles.

tail: error reading '/var/log/restic_backup_restic.err': Is a directory 'and is empty
tail: error reading '/var/log/restic_check_restic.err': Is a directory 'and is empty
tail restic_backup_restic.log 'empty

tail restic_check_restic.log

2021-03-31T20:26:45+02:00

2021-03-31T20:26:49+02:00

2021-03-31T20:26:52+02:00

2021-03-31T20:26:55+02:00

2021-03-31T20:26:58+02:00

ls -lah
drwxr-xr-x   2 root           root      4.0K Mar 31 19:35 restic_backup_restic.err
-rw-r--r--   1 root           root         0 Mar 31 20:10 restic_backup_restic.log
drwxr-xr-x   2 root           root      4.0K Mar 31 19:35 restic_check_restic.err
-rw-r--r--   1 root           root       324 Mar 31 20:26 restic_check_restic.log

[ashemsay]

okay there's an issue with the logs, I fixed it, can you upgrade using this command please

yunohost app upgrade restic -u https://github.com/YunoHost-Apps/restic_ynh/tree/fix/missing-logfiles

Or if you want to use the web interface please upgrade using the URL I gave in that command.

But this is not was is making your backup crash, launch another backup, with the upgraded package we should have more info in /var/log/restic_backup_restic.err and /var/log/restic_backup_restic.log

You can also have realtime logs by running journalctl -f -u restic.service in a separate shell if you want, you could launch it just before running a backup.

[Fireobirdy]

Update:
[admin@soandso ~]$ sudo yunohost app upgrade restic -u https://github.com/YunoHost-Apps/restic_ynh/tree/fix/missing-logfiles Info: Now upgrading restic... Info: [++++++..............] > Installing restic binary Info: [######+.............] > Creating user restic Info: [#######+............] > Configure restic user sudoer rights Info: [########+...........] > Move ssh keys from root to restic user's home Info: [#########+..........] > Generate ssh config Info: [##########..........] > Activating backup methods Info: [##########+.........] > Setting up backup methods Info: [###########+........] > Setting up backup log script Info: [############+.......] > Setting up check log script Info: [#############+++++..] > Configuring cron Info: [##################+.] > Configuring logrotate Warning: mkdir: cannot create directory ‘/var/log/restic_backup_restic.err’: File exists Warning: mkdir: cannot create directory ‘/var/log/restic_check_restic.err’: File exists Success! restic upgraded Success! Upgrade complete

After that, I started a backup and check-process.

tail restic_backup_restic.err [...] subprocess ssh: ssh_exchange_identification: read: Connection reset by peer Fatal: unable to open repo at sftp://yunobackup@192.168.178.13:22/./yunobackups//auto_gitea: unable to start the sftp session, error: EOF
restic_backup_restic.log empty

tail restic_check_restic.log [...] 2021-04-03T23:27:11+02:00 BEGIN REPO CHECK: auto_gitea using temporary cache in /tmp/restic-check-cache-817094813

tail restic_check_restic.err [...] 2021-04-03T23:27:11+02:00 BEGIN REPO CHECK: auto_gitea subprocess ssh: ssh_exchange_identification: read: Connection reset by peer Fatal: unable to open repo at sftp://yunobackup@192.168.178.13:22/./yunobackups//auto_gitea: unable to start the sftp session, error: EOF

Both email still say "SUCCESS".

[ashemsay]

Ok, so the ssh connection never gets opened.

1. Do you get a prompt for password or ssh key when you do ssh yunobackup@192.168.178.13 from your yunohost server?
2. Have you authorized the ssh key for the user yunobackup on the server at 192.168.178.13? You can do so by typing sudo ssh-copy-id -i /root/.ssh/id_restic_ed25519 yunobackup@192.168.178.13 from your YNH.
   For this to work you have to be able to ssh to that session with a password from your YNH, otherwise use the suggestion I gave in the Readme at the end of the Setup Restic app on Server A section to authorize the key from the target server instead (while being logged-in as yunobackup).
3. To make sure passwordless ssh works and restic can correctly open ssh session on your server, you should be able to log into your target server (where you want to put your backups) using sudo ssh -i /root/.ssh/id_restic_ed25519 yunobackup@192.168.178.13 from your YNH.

I know the SUCCESS title of the e-mails are wrong, I'll work on that, I think I see where I f***ed up.

[Fireobirdy]

The user yunobackup is not allowed to access via ssh for security reasons. It is only allowed to access via sftp and this is working fine after promting the PW.

root@soandos:/home/admin# sftp yunobackup@192.168.178.13 Warning: Permanently added '192.168.178.13' (ECDSA) to the list of known hosts. yunobackup@192.168.178.13's password: Connected to yunobackup@192.168.178.13. sftp>

[ashemsay]

Ok, that's not a problem, can you open an sftp session with the command sudo sftp -i /root/.ssh/id_restic_ed25519 yunobackup@192.168.178.13? This should not prompt for password

[Fireobirdy]

Did that. Still promting for password.

root@soandso:/home/admin# sftp -i /root/.ssh/id_restic_ed25519 yunobackup@192.168.178.13 Warning: Permanently added '192.168.178.13' (ECDSA) to the list of known hosts. yunobackup@192.168.178.13's password: Connected to yunobackup@192.168.178.13. sftp> exit root@soandso:/home/admin# sftp yunobackup@192.168.178.13 Warning: Permanently added '192.168.178.13' (ECDSA) to the list of known hosts. **yunobackup@192.168.178.13's password:** Connected to yunobackup@192.168.178.13. sftp> exit

restic seems to have problem with password login.

[ashemsay]

Yes, restic won't work with password login.
Did you willfully ignore the ssh key authorization steps because you do not want it or did it not work?
If it's the former there's no point in trying, it won't work, I read about some workaround but I do not intend to integrate that to the YNH package.
If it's the latter, can you tell me what OS you are running on the target server and what steps have you taken on it yet?

[tomdereub]

I think this issue can be closed ? There is some work to do in this package as suggested here : #22, I don't think the present issue is still relevant ?