Backup Not Running

You filled in the form, clicked Test Connection, and got an error. The four most common causes, in order:

• Wrong region. AWS strictly requires the region to match the bucket. Look up the bucket in the S3 console and copy the region exactly (e.g. us-east-1).
• Typo in bucket name. Bucket names are case-sensitive on most providers. Re-paste from the provider's console.
• Access key without permission to write. The IAM policy on the access key needs at least s3:PutObject, s3:GetObject, s3:ListBucket, and s3:DeleteObject for the bucket.
• Custom endpoint missing or wrong. For Cloudflare R2, MinIO, Wasabi, and other S3-compatible providers, the Custom Endpoint field is required. Leave it empty for AWS.

Fix the field, click Test Connection again before saving.

The job didn't fail, it just had nothing to copy. This almost always means the Source Path is wrong or empty.

Open the View Log modal (expand the job → click View Log). Look for the line:

Transferred:   0 B / 0 B, -, 0 B/s, ETA -

If you see Transferred: 0, the source path is the culprit.

Common causes:

• A typo, like /var/wwww instead of /var/www.
• The path exists but the user CtrlOps logs in as can't read it (try ls -la <path> from the AI Terminal).
• The folder is empty.

Fix: click Edit on the job, correct the Source Path, save, and run again.

You set a schedule (Interval or Custom), but nothing has run automatically.

Check, in order:

• Is cron running? Open the Backup tab and look for the "Cron service is not running" alert. Click Start Cron Service. To confirm the entry actually exists on the server, open the Cron Jobs tab, which lists every crontab entry including the ones CtrlOps wrote.

• Did you save the schedule? Click Edit on the job and confirm the Schedule Type is Interval or Custom, not Manual.

• Is the time correct in the server's timezone? The job runs on the server's clock, not yours. From the AI Terminal:

  date
  timedatectl

  If the timezone is wrong, fix it: sudo timedatectl set-timezone Asia/Kolkata (or whichever zone is correct).

• Is the cron expression valid? For Custom schedules, a typo in any field breaks the whole job. Stick to digits, ranges, or * per field.

Two cases are easy to miss:

'Permission denied' on the source: the user doesn't have read access to part of the source. Pick a subdirectory the user owns, or in the AI Terminal:

sudo chown -R <user>:<user> /path/to/source

Disk full on the source: rclone needs a tiny amount of working space, and a 100% full disk breaks it. Open the Infrastructure Details tab and check the Storage card. If it's red, click Clean Disk Space and retry the backup.

Two settings to tune in the Advanced Options card of the job form:

• Bandwidth Limit, if it's set, raise it or remove it. Empty means full speed.
• Transfers, how many files upload in parallel. Default is 4. Bump to 8 or 16 for many small files; lower if your provider is throttling.

Other common causes:

• The provider is rate-limiting your account. S3 throughput is generous but capped. Check the provider's docs.
• Your server's outbound bandwidth is small. Run speedtest-cli from the AI Terminal to measure. A 10 Mbps server can't push backups at 100 MB/s no matter the settings.
• Many tiny files. Backing up node_modules is slow because rclone has to handshake on every file. If you don't need them, exclude them from the source path.

A run that's been RUNNING for far longer than it should can be killed.

Expand the job row → Click Kill This Process → Confirm

The current run stops, the job stays in the table, and you can re-run it. If kill doesn't work because the shell session is gone, look for the "Backup Shell Disconnected" banner and click Reconnect.

If the same job hangs every time, the issue is usually network: a dead route to the bucket, a misbehaving proxy, or DNS resolving to the wrong endpoint. Test from the AI Terminal:

curl -v https://your-bucket.s3.your-region.amazonaws.com/

You should see a quick HTTP response (any status code is fine, even 403 means the network works).

The View Log shows exactly what was transferred. Expand the job → click View Log → look for the summary lines at the bottom:

Transferred:   	2.345 GiB / 2.345 GiB, 100%, 12.345 MiB/s, ETA 0s
Errors:                 0
Checks:               423 / 423, 100%
Transferred:           87 / 87, 100%
Elapsed time:        3m12.4s

A clean run shows zero errors and matching counts. If Errors: is non-zero, the same number of files failed and the log lists each one earlier.

For peace of mind on critical data, run a small test restore once a month: download a few files from the bucket using your provider's console and confirm they open.

The job definition is gone, but the backup files at the destination are not touched when you delete a job. Your data in S3 is safe.

To re-create the job, click Create Job again with the same source path, destination, and credentials. The next run will sync against the existing backup files (with Sync) or add to them (with Copy).

The job is currently running. You can't edit a running job; stop it first:

Expand the row → Click Kill This Process → Confirm

After the run stops, Edit and Delete become available again.

The shell session may have dropped. Look for the "Backup Shell Disconnected" alert at the top of the tab and click Reconnect. Then click Refresh again.

If the alert isn't showing but Refresh still shows stale data, switch to another tab and back; the stat cards reload on tab focus.