Container not restarted after volume backup fails mid-run when "Turn Off Container During Backup" is enabled

[RezzonicoCaritas]

To Reproduce

When a volume backup job fails mid-execution (e.g. due to a network error preventing Docker from pulling the required image), the container that was stopped as part of the "Turn Off Container During Backup" flow is not automatically restarted. The container remains in a stopped state indefinitely until manually reloaded by the user.

1. Create a service with a volume backup schedule
2. Enable the "Turn Off Container During Backup" option on the backup configuration.
3. Trigger a backup run (automatically via cron or manually).
4. Simulate or encounter a network failure during the backup, in my specific case it was a TLS handshake timeout to registry-1.docker.io
5. Observe that the backup job fails and exits.
6. Check the container status; it remains stopped and does not recover automatically.

Current vs. Expected behavior

Current behavior: When the backup fails after the container has been stopped, the container is left in a stopped state. No automatic recovery or restart is attempted, leaving the service offline until a user manually intervenes and clicks "Reload".

Expected behavior: If the backup fails for any reason after the container was stopped as part of the backup process, Dokploy should automatically attempt a container restart anyway to restore service availability; regardless of where in the backup pipeline the failure occurred.

Provide environment information

Ubuntu 24.04
Dokploy v0.28.8

Which area(s) are affected? (Select all that apply)

Application

Are you deploying the applications where Dokploy is installed or on a remote server?

Same server where Dokploy is installed

Additional context

Failed backup log:

Initializing volume backup
Waiting for volume backup lock: /etc/dokploy/volume-backup-lock-[service-id]
Volume backup lock acquired
Stopping compose container
[container-id]
Volume name: [volume-name]
Backup file name: [volume-name]-[timestamp].tar
Turning off volume backup: Yes
Starting volume backup
Dir: /etc/dokploy/volume-backups/[backup-dir]
Unable to find image 'ubuntu:latest' locally
docker: Error response from daemon: failed to resolve reference
"docker.io/library/ubuntu:latest": failed to do request: Head
"https://registry-1.docker.io/v2/library/ubuntu/manifests/latest":
net/http: TLS handshake timeout

Additional context:

• The failure occurred during a scheduled (cron) automatic backup.
• The root cause of the failure was a transient network issue. A TLS handshake timeout when Docker attempted to pull ubuntu:latest from Docker Hub.
• Manually clicking "Reload" on the service successfully restarted the container with no issues, confirming the container itself was healthy.

Will you send a PR to fix it?

No

[dosubot]

Hi @RezzonicoCaritas! I'm Dosu and I’m helping the dokploy team.

This is a confirmed issue in the volume backup implementation. The backupVolume() function generates a shell script that runs commands sequentially — stop → tar → start → upload — but if any command fails mid-execution (like the docker run ubuntu for tar creation failing due to your TLS timeout), the shell script exits and subsequent commands (including the container restart) never run [1].

The relevant code in packages/server/src/utils/volume-backups/backup.ts composes the backup as a linear shell script:

stopCommand       # Scale to 0 / docker stop
backupCommand     # docker run --rm ubuntu bash -c "tar ..."  ← fails here in your case
startCommand      # docker service update --replicas=$N  ← never reached
uploadCommand     # rclone upload

There's no shell-level trap or equivalent to guarantee the startCommand executes on failure [2]. The higher-level JavaScript try/catch only handles logging the error and cleaning up tar files — it doesn't attempt to restart the container.

This has been reported in several other contexts as well:

• Containers remaining stopped after S3 upload failures [3]
• Containers being irrecoverable after Docker cleanup conflicts [4]
• Containers failing to restart due to registry auth issues during backup [5]

A fix would likely involve wrapping the backup command in a shell trap to ensure the start command always runs, or moving the restart logic into the JavaScript-level error handler. Something like:

trap '${startCommand}' EXIT
${stopCommand}
${backupCommand}
trap - EXIT
${startCommand}
${uploadCommand}

This way, even if the backup command fails, the container is always restarted via the trap.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.