I’ve used restic for years and a few weeks ago something new occurred. When listing the snapshots, the “Paths” column shows the normal paths but also shows “/dev/fd/63” or another /dev/fd/## depending on which host I’m using.
Just before this started showing up, I had made a number of changes including updating to a new restic version and also some changes to the include and exclude files I use. I’m not sure which of my changes started this. Wondering if anyone else has seen this.
• Version: 0.17.1
• Command: “restic snapshots”
If you do not want to backup these paths just exclude them maybe?
1 Like
Excluding has no effect. Even when excluding the path, it still shows up in a new snapshot.
It helps if you can copy and paste the actual output, rather than just describing what you are seeing.
When you say listing snapshots, are you meaning the restic snapshots Command output, and the path column from that output? If so, then that means that those additional paths are somehow being provided to the restic command line for the backup command as the source path along with those you provided previously (I presume). Having it show in the column means it will explicitly specified when the backup was run. Do you use scripts to perform your backups? Is it possible, something you have changed in your automation may have added those paths to your backup commands?
But again, without pasting the actual commands executed and their output, I can only speculate.
Using ‘restic snapshots’ command, I get results like the following:
In my backup script, I’m using “–files-from” and a file that contains the following, only:
/home
/opt
/root
/etc
/var
I think the answer will be in your backup script. Clearly it is more than just restic backup…
/dev/fd/63 suggests you have some named piping which does not work as you intended.
Figured it out. In my script, at the end of my restic backup command, I’m using:
2>&1 >(tee -a $loglastrun >/dev/null)
Something about this is adding the /proc path to the command. I don’t know how or why.
But, if I use pipe instead " | tee -a $loglastrun", the issue goes away.
parse your script through shellcheck. It is quite good in detecting obvious issues.
2 Likes
Never saw shellcheck before. Thank you! It’s got a lot of recommendations for my script.
1 Like
It is not panaceum for all shell scripting problems and pitfalls:) But helps me all the time to avoid most obvious issues. And its online wiki is very clear and informative. It is must to have in shell scripting warrior arsenal:)
