mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-01-23 23:20:51 +01:00
Offical Backup Process Always Fails, but Saves a Zip File #7461
Labels
No labels
area:database
awaiting-feedback
backend
blocked
breaking change: web api
bug
build
ci
confirmed
discussion needed
dotnet future
downstream
duplicate
EFjellyfin.db
enhancement
feature
future
github-actions
good first issue
hdr
help wanted
invalid
investigation
librarydb
live-tv
lyrics
media playback
music
needs testing
nuget
performance
platform
pull-request
question
regression
release critical
requires-web
roadmap
security
security
stale
support
syncplay
ui & ux
upstream
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: starred/jellyfin#7461
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ethaldeman on GitHub (Oct 20, 2025).
Description of the bug
After updating to 10.11.0, I tried to test the new backup capability. However anytime I try, the backup fails with a pop "An unknown error occurred". However a backup zip is still saved and listed.
Reproduction steps
What is the current bug behavior?
The process is exiting with an error.
What is the expected correct behavior?
No error should be produced and the task should successfully complete.
Jellyfin Server version
10.10.0+
Specify commit id
No response
Specify unstable release number
No response
Specify version number
No response
Specify the build version
10.11.0
Environment
Jellyfin logs
FFmpeg logs
Client / Browser logs
No response
Relevant screenshots or videos
Additional information
No response
@DMtgd220 commented on GitHub (Oct 21, 2025):
Same here!
@YotamKorah commented on GitHub (Oct 21, 2025):
Also experiencing the same behavior running the docker image on k8s
@pertile153 commented on GitHub (Oct 21, 2025):
Same issue happens here, and I’m using Windows 11.
System.IO.IOException: The process cannot access the file 'C:\ProgramData\Jellyfin\Server\data\backups\jellyfin-backup-20251021155824.zip' because it is being used by another process.@crobibero commented on GitHub (Oct 22, 2025):
The logs look like the client is requesting the list of backups while the backup is still being created.
Depending on what you attempt to back up the request could take a very long time.
I don't think this is a bug.
@ethaldeman commented on GitHub (Oct 22, 2025):
At least for me, I just left the webpage open while the back up was being preformed, and then never clicked anything. Thus if the client is making the request, it is doing it it own its own and not because user is trying to load/view the backup.
@Scuzz3y commented on GitHub (Oct 22, 2025):
I'm having this issue except the BackupService tries to allocate too much memory even though the backup should only be around 2GB (see memory graph in upper right). I tried to create backups twice, the cliff on the graph is after the first attempt.
@YotamKorah commented on GitHub (Oct 22, 2025):
Update:
For me, the unknown error in the UI was a simple reverse proxy misconfiguration that caused an HTTP/504 (Gateway Timeout) error.
While testing with a longer timeout, the UI no longer shows an error however i noticed that every time i switch to jellyfin's tab from another a new GET /Backup is sent and i get this error in the logs:
For me it seems that the issue is that the incomplete backup is being built in the same place the server expects completed ones to read metadata from. Perhaps it would be better to build the backups in a different directory and move them when ready?
@theguymadmax commented on GitHub (Oct 25, 2025):
Fixed by #15170
@dlmorgan999 commented on GitHub (Dec 5, 2025):
I'm running 10.11.4 which appears to have this patch, but I'm getting the exact same error.
@crobibero commented on GitHub (Dec 5, 2025):
Please open a new issue.
@dlmorgan999 commented on GitHub (Dec 5, 2025):
I can, but there is already another open issue that appears to be the same thing.