Troubleshooting

Troubleshooting Backups #

When a backup fails, its status becomes Failed and the error message is stored with the backup. Open System > Backups > View All Backups, click into the failed backup, and match the error against the sections below.

Permission denied (publickey) # 

Error 255 with: ssh ... : Permission denied (publickey).

The destination server rejected SynergyCP’s SSH key. Check that:

  • The public key from System > SSH Keys is present in ~/.ssh/authorized_keys of the user configured on the destination (a common mistake is adding it to root’s file while the destination is configured with another user).
  • Permissions are strict enough for the SSH server to accept the file: ~/.ssh must be 700 and ~/.ssh/authorized_keys must be 600, both owned by that user.
  • The SSH server allows key authentication (PubkeyAuthentication yes in sshd_config).

SynergyCP never authenticates with a password, so anything that breaks key authentication fails the backup immediately.

Connection timed out # 

Error 255 with: ssh ... : Connection timed out

SynergyCP could not reach the destination within 30 seconds. Check that the host and port in the destination are correct, the destination server is online, and no firewall is blocking the SynergyCP server’s IP address on the SSH port.

Host key verification failed # 

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED

or

Host key verification failed

SynergyCP records the destination server’s SSH host key on the first connection and refuses to connect if it changes, because a changed key can indicate the connection is being intercepted.

If the key changed for a legitimate reason — you reinstalled the destination server or changed its SSH host keys — remove the old entry from the known hosts file inside the SynergyCP PHP container and the next backup will record the new key. If you did not change anything on the destination, treat this as a security warning and investigate before forcing the connection. Contact support if you need help with either.

No such file or directory / failed to upload # 

scp: dest open "...": No such file or directory

The upload folder does not exist on the destination and could not be created, or the configured user cannot write to it. Verify the Folder value on the destination, and on the destination server check that the user can create and write to that path:

su - backups
mkdir -p /home/backups/scp-db
touch /home/backups/scp-db/test && rm /home/backups/scp-db/test

Package versions before 2.1.1 could also produce this error against destinations running newer OpenSSH even when the folder was writable. If you see this error with a correct folder, update the Backups package.

Disk full on the destination # 

scp: ... Failure / No space left on device

The destination server’s disk is full. Free up space, and consider setting retention limits so old backups are cleaned up automatically.

Dump verification failed # 

Error 1 with bash -o pipefail -c 'test -s ... openssl enc -d ... | gzip -t'

After every dump, the backup is decrypted and checked before uploading; this error means the result came out empty or corrupt, so the backup was stopped before a bad file could be shipped. This usually means the SynergyCP server ran out of temporary disk space during the dump, or the database was unreachable. Check free disk space on the SynergyCP server and try a manual backup; if it keeps failing, contact support.

The application key is empty; refusing to create an unencrypted backup.

The panel’s APP_KEY is not set, which would normally never happen on a working installation — contact support.

Backblaze B2 errors # 

Backblaze B2 authorization failed (check the key_id and application_key): HTTP 401: ...

The key_id/application_key pair was rejected. Re-check both values — the applicationKey is only shown once when the key is created, so if it was lost, create a new application key in Backblaze and update the destination.

The Backblaze B2 application key is restricted to bucket "X" but the destination is configured for bucket "Y".

The application key was created with access limited to a different bucket than the one configured on the destination. Fix the bucket name on the destination, or create a key for the right bucket.

Backblaze B2 bucket "..." was not found on the account.

The bucket name is misspelled, or the key cannot see it. Bucket names are case-sensitive.

Backup is larger than the 5 GB Backblaze B2 single-file upload limit.

The compressed database backup exceeds what can be uploaded to B2 in a single file. Use a Secure Copy destination for backups this large and contact support.

Cloudflare R2 errors # 

Cloudflare R2 upload failed: HTTP 403: The request signature we calculated does not match...

The access_key_id / secret_access_key pair is wrong, or the API token was rolled or deleted. The secret is only shown once when the token is created — if it was lost, create a new API token in the Cloudflare dashboard and update the destination.

Cloudflare R2 upload failed: HTTP 404: ...

The bucket name is misspelled, or the account_id does not match the account that owns the bucket.

The Cloudflare R2 destination is missing its "..." value.

A required field on the destination was left empty — edit the destination and fill in the named field.

Backup is larger than the 5 GB Cloudflare R2 single-file upload limit.

The compressed database backup exceeds what can be uploaded in a single request. Use a Secure Copy destination for backups this large and contact support.

Backup stuck in Queued, Compressing, or Copying #

A backup normally moves through these states in minutes (large databases can take longer to compress). If it sits for hours, the panel or its queue workers likely restarted mid-backup. Stuck backups are automatically marked Failed after 24 hours, and the next recurring backup runs as scheduled.

If every backup gets stuck in Queued, the queue workers are not running — restart the SynergyCP services or contact support.

A failed backup deleted nothing, right? #

Correct — cleanup of old backups only happens after a successful backup completes, and only ever removes older successful backups beyond your configured limits. Failures never trigger any deletion, so your existing backups on the destination are safe no matter why a new backup failed. See retention for details.