UrBackup Server 2.5.32
UrBackup Client Controller v2.5.25.0
I have a error when start full backup file:
| Errors | 03/04/24 09:47 | Storing file to “/mnt/urbackup-server/FAHASASG-WP/240304-0942/wordpress/wordpress_data/wp-content/uploads/2019/06/Tr�-Vinh-ph�t-qu�-1-6-10.jpg” failed |
|---|---|---|
| Errors | 03/04/24 09:49 | FATAL: Backup failed because of disk problems (see previous messages) |
| Errors | 03/04/24 09:49 | Backup failed |
| How can I debug / resolve this error? Thanks! |
Ah codepages, they are a b*tch. I think if you try to use UTF-8 on all ends, that will help, but be aware that sometimes that might cause issues in other places.
I have several files like that on a client that i backup, the backup shows they are backed up in fact! (i went back into an old backup to check after i found a fix, more on that later)
Both the urbackup server and the client run debian bookworm. Even on the client, when i went to the files i could see the same diamond shaped icon with a questionmark in it, so both server and client dont understand how to represent the character, but are still able to handle it. I think i started using UTF8 some years ago, so i guess it was put there using an old codepage via samba.
My assumption is that if you verify both ends use the same codepage, you backup issue will be gone (would like to hear that). However, the files might still have those characters in their name.
Another route, which i took because another program, Jellyfin in this case, that was running on the client complained about that and about another 100 other files. Then i noticed i could not see/open those same files when browsing to their location via samba. I needed to fix that. Found this post: stackoverflow link Together with this wiki page i was able to figure out those files were probably put there once using cp1252. I was able to rename them using the convmv tool. No more issues in Jellyfin, files accessible via Samba.
Some tips on using convmv: -i for interactive mode if you feel hesitant. Suffix a 2>/dev/null at the end of the command to get rid of the annoying “File is already UTF8”-like messages. --replace will replace the file with the new name, even when there is already a file with the new name, but both are the same (i suspect the tool does a hash comparison). --notest actually does modify the files, without it it’s just a dry-run. In summary:
quick scan for candidates and their suggested updated name: convmv -r -f cp1252 -t utf8 --replace /somepath 2>/dev/null
then add --notest to actually fix them. Run the scan again to see if there are still files that could not be fixed (e.g. because there was already a file with the proposed name present, but was different in contents. I needed to remove a couple manually like that.
You will probably need to try a couple of codepages for the -f parameter to see what works best, it might depend on how they got there. At my end i found a folder that apparently has been written to with another codepage.
Ive bumped in to this twice, once was the balance of a virus that was not fully cleared out, the encrypted files had illegal characters in them, all failed the backup.
Ive also had Abode create major issues with 3 folders that all failed the whole backup, i had to track down each folder (in appdata) and delete all 3 to then complete the backup. All errors were in the log file so wasnt super hard work, just a pain.