If filename is too long, it is truncated, but the last character of new filename is corrupted (before hash)

The bug appears in this configuration:
Client 2.4.11 on Windows 10 x64 (last updates installed)
Server 2.4.14 on Debian 9 (last updates installed)

Looks like some changes were made to the code earlier, but they still don’t work (I reported the bug a year ago).

Files with incorrect names are not visible by network access (if the backup folder shared using Samba).
In Midnight Commander, the filename displayed will contain a diamond with a question mark inside. The program hints that one UTF-8 character is corrupted.

Criticality of the bug: I think “high”. This makes it impossible to completely copy the archive over the network to another computer. Files with corrupted names will not be copied.
It will definitely be a very bad surprise.

Have you considered testing using Debian stable for the server?
I suspect there have been changes and improvements to SAMBA between oldoldstable (9) and stable (11).

Might be nothing to do with your problem, but worth testing.

Haven’t tried the new stable version of Debian. In any case, the incorrect unicode character in the names of the backed up files comes from Urbackup. It is necessary to fight with the root cause, not the consequence.

One more note. When trying to copy a file with invalid unicode characters, the system reports that the file was not found.

(invalid or incomplete multibyte or wide character)

What’s the output of locale on that server?
If the output doesn’t have a list of stuff ending .utf8 that could be the issue.

Since you’re on Stretch you could try the Debian UTF-8 migration wizard

Debian UTF-8 migration wizard

This wizard upgrades legacy system locales to their UTF-8 equivalent. It also informs users whenever files in their home directory still utilize legacy encodings.

Available in Stretch.

It’s solved the problem for people in the cases where I searched that specific error.