I’ve used restic for years by now and it has always printed out a warning for two symlink paths created under Windows WSL. During backup restic has been reporting these symlinks similar to this (output has changed during different restic versions):
error: incomplete metadata for <FULL_PATH_OF_SYMLINK1>: unsupported file type "irregular"
error: incomplete metadata for <FULL_PATH_OF_SYMLINK2>: unsupported file type "irregular"
I’ve pretty much ignored these messages since it has seemed that even though they’re reported as error restic process still exits with a success code and I don’t care that there are any problems with backing up these symlinks themselves.
However, now after running restic check after a successful restic forget --prune restic reports like this:
Checking... <REPO>
error for tree 66a53220:
tree 66a53220d226393b59a946063f725ed875ff9169a75e33e9a41d0012acd71dfb: node "<SYMLINK1>" with invalid type "irregular"
error for tree d565f127:
tree d565f12751994132e9f4a4405c73ebbfbce3edef746957ecf37010a2fa69cb86: node "<SYMLINK2>" with invalid type "irregular"
The repository is damaged and must be repaired. Please follow the troubleshooting guide at https://restic.readthedocs.io/en/stable/077_troubleshooting.html .
Fatal: repository contains errors
And restic exits with non-zero exit code. I have a strong suspicion that this change started with version 0.17.1, because I did not see this behavior with version 0.17.0 (I have outputs available from these periods). With 0.17.0 restic check didn’t even complain about these symlinks when running restic check.
My first question is - should I be worried about this message “The repository is damaged and must be repaired” in this situation and if yes then what should I actually do? Another question is - has this change been intentional where restic started to exit with non-zero exit code with this situation?
Output of restic version: restic 0.17.1 compiled with go1.23.1 on windows/amd64.
In my case the error was because I was including the Dropbox cache in the backup. Before I didn’t get an error. I excluded that folder and everything was fine.
I still have this problem with restic 0.17.3 when performing check - it fails with non-successful error code and outputs:
error for tree d565f127:
tree d565f12751994132e9f4a4405c73ebbfbce3edef746957ecf37010a2fa69cb86: node "SYMLINK1" with invalid type "irregular"
error for tree 66a53220:
tree 66a53220d226393b59a946063f725ed875ff9169a75e33e9a41d0012acd71dfb: node "SYMLINK2" with invalid type "irregular"
The repository is damaged and must be repaired. Please follow the troubleshooting guide at https://restic.readthedocs.io/en/stable/077_troubleshooting.html .
backup command itself works and does not even show any warnings about these symlinks, which still exist on the system (but it shows some warnings about other file-types, for example [WARNING] Ignoring an unsupported file "\\?\c:\Ubuntu\rootfs\tmp\redis.sock" of type 0140000.).
I already went over the provided troubleshooting link, but it seems that these might not help me. Since backups are stored in the cloud then running any time-consumine/data-intensive commands also incur extra costs so I would be happy to perform minimum steps if possible.
Is there anything I can do now so that restic check would exit with success code?
Okay, managed to fix my repo with repair snapshots (used --dry-run just in case before running it). It removed one snapshot with these irregular files and that’s it as far as I know.
Thanks again for this wonderful software which has helped me more than once to restore critical data when in need!
Sorry for the late reply. Running restic repair snapshots --forget is the intended solution to fix the irregular file type problem. See Release restic 0.17.2 · restic/restic · GitHub for more context. Unfortunately, it’s not possible to fix the affected snapshots without user interaction.