YunoHost-Apps / borg_ynh

An experimental Borg implementation for YunoHost
https://www.borgbackup.org/
GNU Affero General Public License v3.0
19 stars 22 forks source link

Seems to fail to backup wireguard app #143

Open Napator opened 1 year ago

Napator commented 1 year ago

Describe the bug

Error during the backup scheduled daily : "Backup state: failed" Seems to fail to backup wireguard app.

After backup i get "_auto_conf-2023-05-31_00:00 _auto_data-2023-05-31_00:01 _auto_borg-2023-05-31_00:01 _auto_freshrss-2023-05-31_00:02 _auto_nextcloud-2023-05-31_00:03 _auto_wallabag2-2023-05-31_00:05"

And also data in borgbase repo.

Context

Steps to reproduce

Configure distant backup to borgbase with no error at save : "Checking what changed in the new configuration... Validating the new configuration... Applying the new configuration... '/home/yunohost.multimedia/.nobackup' wasn't deleted because it doesn't exist. Configuration of borg completed Config updated as expected"

Expected behavior

Manage to finish backup

Logs

https://paste.yunohost.org/tasixupexu

Napator commented 1 year ago

Tested manual local backup of wireguard successfully.

Tested also backup to borgbase with "exclude:wireguard" successfully.

It seems only the backup with of wireguard with borg is not working.

Thank you for your help.

jorge-vitrubio commented 1 year ago

this issue is related to this one https://github.com/YunoHost-Apps/wireguard_ynh/issues/70

cat /var/log/yunohost/categories/operation/20230627-000322-backup_create.yml
args:
  apps:
  - wireguard
  description: null
  dry_run: false
  methods:
  - borg_app
  name: auto_wireguard
  output_directory: null
  system: null
ended_at: 2023-06-27 00:03:25.577427
error: '''/etc/wireguard/wg0.conf'' and ''/home/yunohost.backup/tmp/auto_wireguard/apps/wireguard/backup/etc/wireguard/wg0.conf''
  are the same file'
interface: cli
operation: backup_create
parent: null
related_to:
- - app
  - wireguard
started_at: 2023-06-27 00:03:22.479313
success: false
yunohost_version: 11.1.21.4

but some of us didn't manage to use the "exclude:wireguard" so the yunohost borg keep trhowing errors every day

for me the solution is to use the exact value of the apps to backup, for example:

yunohost app setting borg apps -v "etherpad_mypads,nextcloud,onlyoffice"
CodeShakingSheep commented 7 months ago

I can see that https://github.com/YunoHost-Apps/wireguard_ynh/issues/70 in Wireguard repository is closed. However, the issue still persists for me. Anyone else?

jorge-vitrubio commented 7 months ago

I can see that YunoHost-Apps/wireguard_ynh#70 in Wireguard repository is closed. However, the issue still persists for me. Anyone else?

have you tried this? -> https://github.com/YunoHost-Apps/wireguard_ynh/issues/70#issuecomment-1758668254

CodeShakingSheep commented 7 months ago

I can see that YunoHost-Apps/wireguard_ynh#70 in Wireguard repository is closed. However, the issue still persists for me. Anyone else?

have you tried this? -> YunoHost-Apps/wireguard_ynh#70 (comment)

Yes, I commented this line in Wireguard's backup script yesterday but the backup still failed last night.

jorge-vitrubio commented 7 months ago

I can see that YunoHost-Apps/wireguard_ynh#70 in Wireguard repository is closed. However, the issue still persists for me. Anyone else?

have you tried this? -> YunoHost-Apps/wireguard_ynh#70 (comment)

Yes, I commented this line in Wireguard's backup script yesterday but the backup still failed last night.

you have to apply changes to cron by restartin ther service or even restarting the server will do

CodeShakingSheep commented 6 months ago

Yesterday I restarted my whole server, but the backup is still not successful. I commented this line in the backup script as suggested in the solution:

# Backing up specific config file, in case of it is not in /etc/wireguard
#ynh_backup --src_path="$(jq -r 'select(.config_file_path | startswith("/etc/wireguard/") | not) | .config_file_path' $install_dir/db/server/global_settings.json)" --not_mandatory

Any other ideas?

Also, if I understand correctly, instead of restarting the whole server I would need to restart wg-quick@wg0 service, right?