How to resolve cPanel backup failure error ‘Couldn’t write to remote file: Failure’

How to resolve cPanel backup failure error ‘Couldn’t write to remote file: Failure’

Backups are inevitable for business uptime. Disasters such as a hard disk crash, may strike any moment, and having latest server backups handy helps in getting your business back and rolling without much downtime.

But many often, web hosts configure backups, but never check them for completion or adequacy. This can end up spoiling the effectiveness of having backups, if they are useless or incomplete.

See how we add value to your business!

In our role as Outsourced hosting support specialists for web hosts, monitoring backup process for successful completion and validating the backups for adequacy, is a vital part of our support services.

How to debug backup failures in your cPanel server

Recently we were contacted by a web host whose backups were not working. The first step in debugging backup issues is to check the backup log file.

In cPanel, the file ‘cpbackup_transporter.log’ stores all cPanel backup related logs. Upon examining the log files, we could see the following error messages logged in it:

[2017-06-17 07:04:45 +0100] warn [cpbackup_transporter] Upload attempt failed: Couldn’t write to remote file: Failure at /usr/local/cpanel/Cpanel/LoggerAdapter.pm line 27.
……….
eval {…} called at /usr/local/cpanel/bin/cpbackup_transporter line 149
[2017-06-17 07:04:45 +0100] info [cpbackup_transporter] Error encountered
[2017-06-17 07:04:45 +0100] info [cpbackup_transporter] Error is not a reference Couldn’t write to remote file: Failure

We could see that the backup process is unable to write into the file. This can happen due to many reasons such as permission issues or lack of disk space.

You don’t have to lose your sleep to keep your customers happy. Our friendly Hosting Support Specialists are online 24/7/365 to help your customers. ]

How to resolve backup error ‘Couldn’t write to remote file: Failure’

For backup process to complete fully, adequate disk space is indispensable. While we usually recommend storing backups in an external server for redundancy, some web hosts prefer storing backups in the same server.

When the backup server does not have enough free disk space available, or the disk space got used up due to any processes, backup process will not complete and would fail with the error ‘Couldn’t write to remote file: Failure’.

The solution here is to check the disk space usage in the backup server. In this customer’s case, the backup destination path partition was almost full (98%), which caused this error.

Our server technicians checked for any unwanted files in the server and cleared them, but still there wasn’t enough disk space. So we moved the older backups to another server and freed up some disk.

After that, we executed the backup process once again and it was completed successfully. To prevent the issue from recurring, we added a script to rotate older files whenever the disk space got above 80%.

[ Use your time to build your business. We’ll take care of your servers. Hire Our Hosting Support Specialists and boost your server performance. ]

At Bobcares, our 24/7 server specialists constantly monitor all the services in the server and proactively audit the server for any errors or corruption in them.

This enables us to prevent a service downtime for our customers who are web hosts. By following a systematic debugging approach for service or backup failures, we have been able to minimize the downtime involved.

If you would like to know how to avoid downtime for your customers due to service failures, we would be happy to talk to you.

 


GET 24 HOURS PHONE SUPPORT SERVICES

Use Bobcares for your phone support services. Ensure 24/7 coverage for your customers!

CONTACT US FOR 24/7 PHONE SUPPORT PLANS

Submit a Comment

Your email address will not be published. Required fields are marked *

Bobcares
BUSY WITH TECH SUPPORT ALL DAY? We help web hosts and other web solution providers save time and focus on growth.
Here's how we helped a web host reduce support engagement time from 3 hours to 30 mins per day:
SEE CASE STUDY