Restore file name with "[" fails

[4fosaefp]

Note: if you have a question or need support please post in the discussions area.

Describe the bug When restoring a file/folder containing the left square bracket [, the backup fails: {"message_type":"exit_error","code":1,"message":"Fatal: --include: invalid pattern(s) provided:\n[.txt"}

Curiously,iIf I restore a file named e.g. [abc].txt, the restore is shown as successful, but the file isn't actually restored. Restoring [].txt will fail just like [.txt though.

To Reproduce Steps to reproduce the behavior:

1. Perform a backup containing files named [.txt, [].txt, and [abc].txt
2. Attempt to restore each of these files
3. Observe errors with [.txt, [].txt
4. Observe that even though the restore is shown as successful with [abc].txt, the file isn't actually restored

Expected behavior Files are restored successfully

Platform Info

• Windows 10 x64
• Backrest Version 1.8.1

[4fosaefp]

Just discovered closed issue https://github.com/garethgeorge/backrest/issues/710 that describes the same problem and its fix https://github.com/garethgeorge/backrest/pull/721 released in 1.8.0. I guess it wasn't fully addressed.

[garethgeorge]

Thanks for the report-- yeah looks like not. These have been fairly tricky since restic itself handles [ ] specially.

I added https://github.com/garethgeorge/backrest/blob/37f0bbe63e7ecf428833f11fa46a204ea9551b9a/internal/resticinstaller/resticinstaller.go#L119-L127 which seemed to have addressed this -- I'm surprised it's still popping up.

Would you mind checking the logs from your backup execution and providing the full command that backrest tried to run? I'm curious if any escape characters are getting included

[4fosaefp]

Here's the log when I attempt to restore D:\My_Files\[.txt to C:\Users\My_PC\Downloads\[.txt-backrest-restore-3c4bca24

[repo-manager] 13:55:04.654Z	debug	restore snapshot	{"repo": "PC_Backups", "snapshot": "3c4bca245fcb86c2cff0364d6d94e3e42b94213b103ec2ec545d22f6edcdccb8", "target": "C:\\Users\\My_PC\\Downloads\\[.txt-backrest-restore-3c4bca24"}

[restic] command: "C:\\Users\\My_PC\\AppData\\Local\\Programs\\Backrest\\restic.exe restore --json 3c4bca245fcb86c2cff0364d6d94e3e42b94213b103ec2ec545d22f6edcdccb8:/D/My_Files -o sftp.args=-oBatchMode=yes --target C:\\Users\\My_PC\\Downloads\\[.txt-backrest-restore-3c4bca24 --include [.txt"

[restic] {"message_type":"exit_error","code":1,"message":"Fatal: --include: invalid pattern(s) provided:\n[.txt"}

[tasklog] 13:55:10.640Z	error	restore snapshot "3c4bca245fcb86c2cff0364d6d94e3e42b94213b103ec2ec545d22f6edcdccb8" in repo "PC_Backups"	task failed	{"error": "restore snapshot \"3c4bca245fcb86c2cff0364d6d94e3e42b94213b103ec2ec545d22f6edcdccb8:/D/My_Files\" for repo PC_Backups: command \"C:\\\\Users\\\\My_PC\\\\AppData\\\\Local\\\\Programs\\\\Backrest\\\\restic.exe restore --json 3c4bca245fcb86c2cff0364d6d...\" failed: exit code 1: restore failed\nprocessing command output: no summary event found\nOutput:\n{\"message_type\":\"exit_error\",\"code\":1,\"message\":\"Fatal: --include: invalid pattern(s) provided:\\n[.txt\"}\n", "duration": 5.986412}

[garethgeorge]

Ah, looks like I attempted this fix at somepoint but couldn't escape globs on windows https://github.com/garethgeorge/backrest/blob/main/internal/orchestrator/repo/repo.go#L442

https://go-review.googlesource.com/c/go/+/87455 provides a bit of context, it's not clear to me if there's a workaround here as this is a golang standard API limitation and filepath.Glob is actually what restic is calling to implement --include iirc.

[michael9dk]

Does this also affect files with characters/numbers before [ ?

Filenames like xyz[abc].txt or 123[abc].txt

[garethgeorge]

I don't believe it should -- this is a limitation of the types of paths that can be provided to --include, so you can specify and restore a directory path (not including [ or ] characters) that contains files that do contain [ or ] characters

e.g. if the path is /my/odd/paths/abc[123].txt you can restore the /my/odd/paths/ directory just fine, but if you try to restore a specific file e.g. /my/odd/paths/abc[123].txt you may run into issues.

I want to mention that I believe this is actually a restic limitation, there isn't a way that backrest can provide such paths safely to the --include flag as far as I understand. We may need to open and track a bug on github.com/restic/restic

[michael9dk]

Thank you for the quick reply. I'll have to research this issue before I switch my backups to restic.