Prerequisite question:
From what I understand in the borg_ynh app readme page, and from this issue, I can backup to a custom path in my destination server, by setting the server where I want put my backups to ssh://user@user.myRemoteServer.tld/var/backup-dir/ (if I want my backup to be located in /var/backup-dir/ in the destination server). Did I understand this right?
Now the real question:
What if the destination server doesn’t run yunohost, what should I do/setup/install on the destination server?
Note:
I know there is development in making borg_ynh part of yunohost core, I think this would be an important aspect for it as well.
After configuring both servers, I realized that borg version in remote is 1.0.9 which is not recent enough if I understand well this (yes I know I should have checked it before).
I don’t have the necessary permissions to install a more recent version in the remote server so I have to wait it’s admin does it.
The thing is that I had setup the backup to start during the night, and I don’t know what will happen if it tries to start the backup with the current situation.
I changed the backup scheduling running yunohost app setting borg on_calendar -v Mon. I assume this will postpone the first backup to next Monday.
Is it enough to just use yunohost app setting set to change backup scheduling? Or is there anything more to do to make sure that the change has bee taken into consideration and that it won’t try to create a backup at the previously set time?
I also realized that actually the destination repo in the remote is also set in the origin borg config here. So I think having it customly set in the remote will probably only make the ssh request refused. (If I understand well the logic.)
I think I’d better uninstall the borg_ynh app for now because it’s likely to create more issues than good things, since I don’t really know where I’d have to look for cron job and systemd borg timer.
And then when I reinstall it I guess I’ll also have to patch backup_method.j2 file to change the path to the destination, or maybe it could be enough to symlink in remote server ~/backup to the real location I want for the backups, I don’t know.
Ok finally I wanted to try without uninstalling.
So indeed yunohost app setting borg on_calendar -v weekly wasn’t enough to cancel the execution of the backup.
I edited /etc/systemd/system/borg.timer, changed the OnCalendar value to weekly. And then ran systemctl daemon-reload so that the changes are recorded.
Thanks @Aleks for pointing it out to me
@ljf do you think creating a symlink from ~/backup to /var/myCustomBackupPath/ in the remote server would work to setup a custom backup directory (with borg serve --restrict-to-repository /home/user/backup setup on remote)?
Or do I have to use borg serve --restrict-to-repository /var/myCustomBackupPath on remote and modify origin’s /etc/yunohost/apps/borg/conf/backup_method.j2 file line 11 like this: repo=ssh://{{ ssh_user }}@{{ server }}/var/myCustomBackupPath?
Not sure I understand what you mean by that. --restrict-to-repository is the standard borgserver_ynh setup so in this case the only difference is that I symlink the repo location from ~/backup to a custom location.
I’ll try it with symlinking and update on how it went.
Thanks : )
So it seems everything worked fine, there’s ~10Go on the remote server which could be the compressed ~20Go from the origin one I imagine.
But when I try checking the backup in destination server, running borg list /home/user/backup I get:
Failed to create/acquire the lock /home/user/backup/lock.exclusive (timeout).
I also tried running borg list /var/myCustomBackupPath (the target of the symlink /home/user/backup) and got similar output.
I checked logs int the origin and /var/log/backup_borg.log is empty, /var/log/backup_borg.err contains the following (don’t know if the end of it is normal):
Remote: Warning: Permanently added 'destinationserver.tld,xxx.xxx.xxx.xxx (ED25519) to the list of known hosts.
By default repositories initialized with this version will produce security
errors if written to with an older version (up to and including Borg 1.0.8).
If you want to use these older versions, you can disable the check by running:
borg upgrade --disable-tam 'ssh://user@destinationserver.tld/~/backup'
See https://borgbackup.readthedocs.io/en/stable/changes.html#pre-1-0-9-manifest-spoofing-vulnerability for details about the security implications.
IMPORTANT: you will need both KEY AND PASSPHRASE to access this repo!
Use "borg key export" to export the key, optionally in printable format.
Write down the passphrase. Store both at safe place(s).
A repository already exists at ssh://user@destinationserver.tld/~/backup.
A repository already exists at ssh://user@destinationserver.tld/~/backup.
A repository already exists at ssh://user@destinationserver.tld/~/backup.
A repository already exists at ssh://user@destinationserver.tld/~/backup.
A repository already exists at ssh://user@destinationserver.tld/~/backup.
A repository already exists at ssh://user@destinationserver.tld/~/backup.
Maybe there is something to do with this borg key export thing that is logged, but nothing mentions that in borg_ynh doc.
Update on last post, one day after, now it works, I can list or check the repo and it’s archives. Not sure what happened overnight I didn’t touch the servers in the meantime. Now the global repo size is 5Go bigger than yesterday, but I don’t think the origin content changed so much.
Maybe something hadn’t been completed properly during the first backup. Not sure.
Thanks @Aleks and @ljf for the advices
I think your data was still uploading when you tied to list. Don’t forget you need about 10 hours to upload 3GB with ADSL… Or the first borg operation has failed or be interrupted.
