-
Notifications
You must be signed in to change notification settings - Fork 190
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incompatibility with rsync 3.2.4 #1247
Comments
Bisecting rsync seems to lead to RsyncProject/rsync@6b8db0f:
I tried adding |
This problem sounds serious and should have high priority. I don't fully understand the details about shell interpretation etc but I got an idea about it. Is this new default behaviour of rsync 3.2.4 backward compatible with older rsync versions? |
The |
I can confirm the bug in my system as well. This is actually a show-stopper: all my backups failed since the 19th of April, and as I run the backups mostly in the night, I noticed just today. As a side-note, is it possible to make BiT send an e-mail when a backup fails? |
Same here (BiT 1.3.2 in Fedora 35). |
@Piergi this would be very useful. I'm using a workaround, although it didn't work in this particular situation. On my server, I have a cron job that runs the following script.
It checks the server's log file for an rsync error, and if there had been an error in the last backup, it will remove it, relink the previous one, and mail the user. This was necessary because backintime sometimes fails to backup completely, leaving things in a broken state (despite telling the config not to do this). This would be a problem, because the subsequent backup would start from scratch with new hard links, and take up ~twice the amount of room. However, this script didn't detect this specific bug, because there was no rsync or error file on the server at all. |
At least in my setup the additional option "--old-args" does not work, it seems to do and it had created backups, but the permissions file was empty, so a restore will not have the correct file owner and permissions. This could be fixed by |
Dear @gerum100 , thanks a lot. This seems like a very important information. |
Thanks @gerum100. I can confirm that |
@protist If you would add it to the the crontab, it will not work for manually started backups from cmd or the gui, so I have modified the scripts itself, I add the export command directly to the |
@gerum100 good point. Thanks for the hint. That sounds like a good idea. |
API-breaking changes are an unlucky design decision and IMHO setting the env var by default is the easiest way to solve this in BiT without knowing which version of The question is if this should be done by the distribution, package maintainer or in BiT directly... Since there may not be a common solution for each distribution BiT should set the env var in its local context. Any opinions? |
I suggest to export the env var in
by adding
This should fix the problem by supporting the old and new rsync API (the old version will ignore the env var since it doesn't know it). Any other missing scripts to set the env var? |
I have created a patch file, could someone please test it with the new PS: Apply the patch to the |
I currently doing some research and looking for a solution that works for both versions of rsync without using environment variables, versions checks or other workarounds.
Technically it was API-breaking yes. But I wouldn't see it that dark. In my understanding the behavior of the early rsync version was "unusual". So 3.2.4 just corrects that.
Easy isn't always the best. I'm looking (and testing) for a better solution. But this environment variable is an option.
This is definitely upstream's job; our. That's just my opinion here. I will come up with a possible solution on the bit-dev mailinglist and asking for review. |
Can someone please construct me a case (folder and file structure) to reproduce this? The initial message in that issue here is not clear for me. I am able to "reproduce" the problem using rsync 3.2.5 alone (without backintime). But I am not able to reproduce this using backintime in the same system. I checked the environment variables and the debug output (incl. the rsync call reported there). There is no hint that someone from the distro maintainers where activating one of the known workarounds. I used that source folder in HOME and backed it up with backintime without any problems. I also deleted one of the snapshots. No problem.
It was Debian 12 (testing) with backintime 1.3.2 from that distro repo. And again I was able to reproduce with rsync alone. EDIT: Now I also tried the upstream version of BiT to make sure that there wasn't a patch from any distro maintainer. |
Sorry, I got it and now can reproduce this with BIT, too. I simply forgot to configure a "ssh" job instead of a "local". Sidenote for myself:When implementing the new solution I have to take care of There is also the problem with environment variables Note for myself:The following unittest's do reproduce the problem and reacting on
|
Just for your information and keeping you up to date. I'm still on that problem.
The next hurdle is to create unittests for the relevant code parts. Because most of it is untested or IMHO not very well tested. I'm scared to modify that code without having unittests. This implicates some refactoring to make the code even testable before I can write any unittest. |
Let me give you a small update. I modified all relevant code parts to use my approach and added some unittests. The latter are merged into master. |
Would be glad if some of you could test if the PR #1351 do fix the problem. |
Worked here (Ubuntu 22.10, rsync 3.2.5). |
…#1351) The core problem is that BIT does call rsync in a way that is not compatible with newer versions of rsync. The version 3.2.4 of rsync activated a new method of argument protection. This commit fixes the rsync calls and does all necessary modifications. Important to know is that BIT still works with old rsync versions, too. Fix #1247
After upgrading to rsync 3.2.4, I get the following errors:
Downgrading rsync to 3.2.3 makes everything work just fine again.
I'm running backintime 1.3.2 on Arch Linux.
The text was updated successfully, but these errors were encountered: