Managing Backups #
Viewing backups #
Go to System > Backups to see the latest backup and the recurring schedules at a glance, or click View All Backups for the full list. Each backup shows its source, destination, creation time, and current status:
| Status | Meaning |
|---|---|
| Queued | Waiting for a worker to pick it up. |
| Compressing | The database is being dumped and compressed. |
| Copying | The file is being uploaded to the destination. |
| Finished | Verified, uploaded, and cleaned up locally. |
| Failed | The backup did not complete — click into it for the error details. |
Every backup keeps a log of its lifecycle (created, compressing, copying, finished/failed, deleted), which is the first place to look when something goes wrong.
A backup that stays in Queued, Compressing, or Copying for more than 24 hours is automatically marked Failed. This usually indicates the panel or its queue workers restarted mid-backup; the next scheduled backup will run normally.
Creating a manual backup #
From the All Backups page, select a Source and Destination at the bottom and click Create archive. Manual backups behave exactly like recurring ones — same statuses, same file naming — but are not associated with any schedule.
Manual backups are kept until you delete them, unless the destination itself has a “Backups to keep” limit, which counts them too.
Deleting backups #
Deleting a backup from the list also deletes its file from the destination server. If the destination is unreachable at that moment, the backup record is still removed and the leftover remote file is noted in the panel logs so it can be cleaned up manually.
Backups deleted automatically by retention limits have their remote files removed the same way.
Health monitoring #
The Backups package reports into SynergyCP’s system health indicators:
- OK — the most recent completed backup for every destination finished successfully.
- Warning — no backups have completed yet (for example on a fresh setup).
- Error — the most recent completed backup on at least one destination failed.
Health is tracked per destination, so one destination working correctly cannot hide another that has been failing. If health shows an error, open the All Backups list, find the failed backup, and check its error message against the Troubleshooting guide.
Backups protect you only if they are restorable. Periodically verify that the files exist on your destination server, and make sure you have a configuration backup stored separately — without its secret key, database backups cannot be decrypted during a restore.