+- AdminsForum (https://adminsforum.com)
+-- Forum: Free & open-source control panels (https://adminsforum.com/Forum-free-open-source-control-panels)
+--- Forum: CloudPanel (https://adminsforum.com/Forum-cloudpanel)
+---- Forum: CloudPanel Guides & Tutorials (https://adminsforum.com/Forum-cloudpanel-guides-tutorials)
+----- Forum: CloudPanel Backups & Migration Guides (https://adminsforum.com/Forum-cloudpanel-backups-migration-guides)
+----- Thread: Guide CloudPanel Backups Not Running: Diagnose and Verify Recovery (/Thread-guide-cloudpanel-backups-not-running-diagnose-and-verify-recovery)
CloudPanel Backups Not Running: Diagnose and Verify Recovery - DEV - 10-16-2026
If CloudPanel backups are not running, first check the newest backup at the remote destination. A saved storage configuration or a successful connection test does not prove that a recent, restorable backup exists.
This CloudPanel v2 diagnostic guide is based on official documentation and a linked user report. It does not claim that a new lab failure or a vendor-code fix has been reproduced. The branded diagram is a workflow illustration.
AdminsForum backup checks: confirm a recent copy, separate scheduling from transfer failures, then prove restoration.
Before changing anything
You need CloudPanel administrator access, access to the backup destination and SSH for optional diagnostics. Record the last known good backup and preserve it. Do not delete remote archives, rotate credentials blindly or overwrite the live site during a restore test. Destination listings, configuration files and logs may contain credentials or private customer information.
1. Is the backup actually missing?
Open the storage provider's console or SFTP destination. Find the affected site's backup location and compare its newest timestamp with your expected schedule. Confirm the correct bucket, directory and account; a similarly named folder on another remote is easy to mistake for the current destination.
Record the backup date, size, site and whether you can download it. An archive with an old timestamp is not evidence of a successful run today. A small archive is not automatically broken, but an unexpectedly small one needs inspection. Provider modification times may use a different timezone from your server.
2. Check the CloudPanel backup settings
In the admin area, open Backups and inspect the selected storage provider, destination and enabled schedule. Verify the instance timezone against your intended execution time. CloudPanel's remote-backup documentation specifically calls out instance timezone as relevant to scheduling.
Review exclusions. A broad excluded directory can omit the site you intended to protect. Also document what else your recovery needs: database dumps, application configuration, uploaded files and any external storage. Do not treat a website archive as a full-server image.
For initial setup, see our CloudPanel remote backups and security guide.
3. Compare one manual run with the scheduled run
At a suitable quiet time, use the Create Backup control documented for your installed version. Run it once and monitor the destination. Backups can consume CPU, disk space and network bandwidth, and storage-provider charges may apply. Avoid launching overlapping retries.
- Manual backup succeeds, scheduled backup is absent: concentrate on timezone, schedule and the scheduling service or task.
- Manual backup fails before any upload: investigate the local error, archive creation, available disk and application compatibility.
- Transfer starts but fails: investigate authentication, provider limits, connection errors and destination permissions.
- New files arrive but restoration fails: investigate completeness and consistency rather than just the schedule.
4. Check local capacity, time and service evidence
Over SSH, these commands read the server state:
Code:
date -Is
timedatectl
df -h
df -i
systemctl list-units --type=service --all | grep -Ei 'clp|cron'
systemctl list-timers --allFor an observed service, inspect its status and journal. Replace example.service below with the exact unit name you found:
Code:
sudo systemctl status example.service --no-pager
sudo journalctl -u example.service --since '24 hours ago' --no-pager5. Check storage access without exposing secrets
Confirm the configured endpoint, region where applicable, bucket/path and remaining storage allowance. Authentication failures, quota exhaustion and connection timeouts are different causes. Use the provider's audit information to distinguish them.
For Custom Rclone Config, CloudPanel documents a remote named remote. With the correct existing configuration and execution user, this read-only command can check directory access:
Code:
rclone lsd remote:your-backup-pathA directory listing tests listing access only. It does not prove upload permission, free quota or successful archive creation. Verify those with a controlled backup run. Avoid rclone sync or delete commands as connectivity tests because they can remove data.
6. Check version-specific failures carefully
A CloudPanel GitHub report from October 2026 describes scheduled backups not running on 2.5.4 and an internal getContainer() error. That is a reporter's diagnosis, not proof that every CloudPanel backup failure has the same cause or that the proposed patch is a supported fix.
If your logs contain that exact failure, record the CloudPanel package version, OS, provider and when the problem began. Check current issue responses and release notes before changing vendor files. Do not apply an old internal console command or a source-code patch just because another server used it. Keep an independently verified backup route while the cause is unresolved, and test any proposed fix on a separate lab first.
7. Download and inspect the backup privately
Download a known backup into a protected directory outside the public web root. For a backup.tar file, this lists archive contents without restoring over your website:
Code:
tar -tf backup.tar | head -n 40Check the database backup separately. A readable file archive does not prove a SQL dump is present, current or restorable. CloudPanel's database documentation covers export and import; plan a separate database restore test with the correct account and engine compatibility.
8. Prove recovery on an isolated test site
Restore into a separate test environment and a separate database. Keep production untouched. Disable outbound email, payments, scheduled jobs and webhooks on the restored copy before testing it, so the recovery exercise does not send real notifications or transactions.
Verify a representative page, a database-backed operation and an expected recent record or upload. Record the backup time and restore duration. A successful homepage alone is not a full application test. Keep recovery credentials and encryption keys available through a secure process.
After fixing the original problem, verify both a manual backup and the next scheduled run at the destination. Record their timestamps and test result. Set an independent freshness check that alerts when the newest backup becomes too old for your recovery requirements.
Questions to include when asking for help
Does a manual backup work? When was the last good scheduled copy? Which CloudPanel version and provider are involved? What is the first redacted error? Is the backup missing, incomplete or unrestorable? These answers help the CloudPanel support community narrow the fault without guessing.
References
CloudPanel Remote Backups documentation
CloudPanel database export and import documentation
Rclone lsd reference
User-reported CloudPanel scheduled-backup issue