fix(volume-backups): restart container before S3 upload in volume backup

[WalidDevIO]

Description

When using volume backup with "Turn Off Container During Backup" enabled, the container was kept stopped for the entire duration of the backup process — including the S3 upload phase. For large volumes, this caused unnecessary downtime proportional to the upload duration. (Fix issue #4000)

Changes

Split baseCommand into two distinct commands:

• backupCommand — creates the tar archive
• uploadCommand — uploads to S3 and cleans up the local file

In the turnOff flow, the container is now restarted immediately after backupCommand completes, before uploadCommand runs. The container no longer needs to be stopped during the S3 upload since rclone reads only from the local tar file.

Before

stop container → tar → rclone upload → rm → restart container

After

stop container → tar → restart container → rclone upload → rm

Testing

• Tested with a large volume backup (6.6GB) with "Turn Off Container During Backup" enabled
• Container restarts immediately after tar creation
• S3 upload completes successfully after container is back up

Testing

• Reviewed diff — change is a reordering of existing commands with no logic modification

Greptile Summary

This PR reduces container downtime during volume backups when "Turn Off Container During Backup" is enabled. Previously, the container remained stopped for the entire backup process — including the S3 upload phase. Now, by splitting the monolithic baseCommand into backupCommand (tar creation) and uploadCommand (S3 upload + cleanup), the container is restarted immediately after the tar archive is created on the host filesystem, before the potentially slow S3 upload begins. Since rclone reads from the local tar file (not from inside the container), this reordering is safe.

• The change consistently applies to all three turnOff code paths: application (Docker Swarm service), compose stack, and docker-compose
• The non-turnOff path preserves identical behavior by concatenating both commands sequentially
• As a side benefit, if the S3 upload fails in the turnOff path, the container is now already running — an improvement over the previous behavior where it would remain stopped

Confidence Score: 4/5

• This PR is safe to merge — it's a clean reordering of existing shell commands that reduces unnecessary container downtime without changing backup logic.
• Score of 4 reflects that the change is a straightforward and well-reasoned refactor. The tar archive is written to the host filesystem, making the container restart before S3 upload safe. All three turnOff code paths (application, compose stack, docker-compose) are updated consistently. The non-turnOff path preserves identical behavior. No new logic is introduced. The one minor consideration is that both backupCommand and uploadCommand each contain set -e, which is benign but slightly redundant when nested inside lockWrapper which also sets it.
• No files require special attention. The single changed file is a clean refactor with no risky patterns.

_{Last reviewed commit: 2f37235}

_{(2/5) Greptile learns from your feedback when you react with thumbs up/down!}