Closed landonpierce closed 1 year ago
At first the relative path it reported was confusing to me, but then I remembered it'll be relative to /data
. The "jfr" part of the filename refers to Java flight recorder, so it's as if a mod, etc left behind a profiler recording session's temp file.
I'd be curious if that file actually exists over on the Minecraft data side and if so, does removing the file manually fix it?
I'm also wondering if tar
might have an option to ignore such file state?
@itzg So I do think you're on the right track about a mod or something moving files around. I noticed over the weekend that the backup started complaining about a file that I know I happened to accidentally move while it was executing a backup. It seems as though if a mod deletes or otherwise moves a file during the backup execution that tar was supposed to be archiving, it will generate an error and the backup will fail.
I guess this is probably an issue that is semi-unique to modded minecraft, since vanilla doesn't change/move/delete files in the same way.
I was just thinking: if it's consistently failing on tmp and/or jfr files, then you could try adding that to the EXCLUDES, like
EXCLUDES: "*.jar,cache,logs,*.tmp"
I was just thinking: if it's consistently failing on tmp and/or jfr files, then you could try adding that to the EXCLUDES, like
EXCLUDES: "*.jar,cache,logs,*.tmp"
I had a similar problem with Purpur and the temporary files of its spark plugin. Excluding *.tmp
fixed the backup. It might be a good idea to have this as default since such files rarely need to be backed up.
It might be a good idea to have this as default since such files rarely need to be backed up.
Great idea 😀
I am currently using the docker-mc-backup image with docker-compose to backup my minecraft server (also using the itzg/minecraft-server docker image). After several successful backups, the backup job will randomly start failing with the error message:
tar: ./config/spark/tmp/spark-2928b2c36397e-profile-data.jfr.tmp: Cannot stat: No such file or directory
In order to get the backups working again, I have to destroy and re-create the backup container. The restart that occurs as part of the failure does not fix the issue. The restart must be manual for it to fix the issue.
I'm utilizing the rclone backup method, and rclone is configured to save the backup to an Azure Blob Storage account. Here are my logs and my docker-compose.yml file (scrubbed of all sensitive data). I've done some basic poking into the issue, but can't find any reference to the file in the error message in the source code. Let me know if I can provide any other info to help with debugging.
Here are the logs. Note the successful backup at 2023-04-24T01:59:13, followed by a failure at 2023-04-24T03:59:13, followed by a manual restart of the container at 2023-04-24T04:02:17 and then a successful series of backups until several hours later at 2023-04-24T16:31:22.
And here is my docker-compose.yml that runs this container alongside my server: