Troubleshooting Backup Failures

While it’s not a common occurrence, there may be an instance where backing up your site files and database might fail. SpinupWP will actively notify you of this, both in the app and by email, so you’re made aware of it as soon as it happens.

Large backups

When site backups get up to hundreds of gigabytes in size, they take longer to run and the likelihood of a failure increases. Not to mention it can slow down your server while the backups are running.

When snapshots get large, people typically reach for incremental backups. Only backing up what has changed is quicker, doesn’t bog down the server, and saves storage space, among other benefits. And although SpinupWP doesn’t currently offer its own incremental backup solution, there are several solutions within reach.

If it’s your WordPress Media Library that’s large, you can use WP Offload Media with Amazon S3 and versioning turned on. With versioning turned on, Amazon S3 handles backing up your media files. If an item is accidentally deleted from your Media Library, you can login to Amazon S3 and restore it. And now since you don’t need to backup your media files, you can exclude your /wp-content/uploads/ folder from your site backups.

If you don’t like this solution, you could try setting up Duplicity or Restic on your server, though please be aware that we do not officially support these solutions so you’ll be on your own.

If your database is large, we recommending moving to an external managed database service. These services typically include incremental backups and point-in-time recovery.

If you don’t like managed database services, you could also try SqlBak or rolling your own solution.

Low disk space on the server

You know this is the cause of your failure when the message returned by the backup looks like this:

gzip: stdout: No space left on device

The first thing to check is how much available disk space you have available on the server. You can check this value by clicking on the server on your dashboard page. On the bottom left of the server overview page, there is a “Disk Usage” widget that will show the used disk space of the total available on the server.

Disk Usage

If your site has a large amount of media (video files, images, etc.), you might have been filling up your server disk space without realizing it! The base $5/month DigitalOcean droplets only have 25GB of disk space. That’s not a lot, considering the operating system, WordPress files, and everything else can take up almost 3GB.

Lack of disk space is one of the main reasons backups fail. A compressed file is created on the server and then sent to your storage provider (Amazon S3, Google Cloud, etc.) during the backup process. If you have a large amount of media items or a large database, the zip file created during the backup process can be pretty significant. These large zip files can use up the rest of the remaining disk space on the server and cause a failure.

Checking for disk space usage

To figure out how much space a particular folder is taking up on the server, you can run the disk usage or du command, with a set of switches, to check your server disk usage. To do so, you’ll need to SSH into the server with a sudo user.

Your first step will be to check the root directory of the server:

sudo du -sh /* | sort -hr

This command will return a list of folders in the root directory and a human-readable size for each folder. Below is a simplified example of what this could look like:

19.8G   /sites
1.9G    /var
1.7G    /usr
503M    /snap
145M    /boot
12M /opt
7.8M    /etc
4.0M    /cache
3.0M    /home
1.6M    /root
992K    /run
64K /tmp
16K /lost+found
4.0K    /srv
4.0K    /mnt
4.0K    /media

As you can see, the /sites folder is taking up 19.8GB of space and is probably where the problem lies. You can now modify the du command to only report on folders inside the /sites folder.

sudo du -sh /sites/* | sort -hr

This command might return something like:

16.2G   /sites/site1.com
1.0G    /sites/site2.com
1.8G    /sites/site3.com
164M    /sites/site4.com
4.0K    /sites/refresh

In this instance, site1.com is taking up a whopping 16.2G of space. Next would be to see what’s happening inside /sites/site1.com:

sudo du -sh /sites/site1.com/* | sort -hr

You can continue running du in this way on subsequent folders until you find the culprit.

Sometimes, it might not be your /sites folder that’s taking up a lot of space. It might be some other folder, like /var or /tmp, that needs cleaning up. You can run the du command on these folders in the same way that you did for /sites:

sudo du -sh /var/* | sort -hr

sudo du -sh /tmp/* | sort -hr

Getting more space

If you notice that your server is running low on disk space, there are a few things you can do.

The simplest way to ensure you don’t run out of space is to avoid adding too many sites to one server. If you’re hosting a WordPress multisite installation, for instance, it’s probably best to only have that one install on the server. For single sites, depending on the site, it’s generally a good idea only to house a handful of sites on the default $5/month DigitalOcean server. That way, you don’t have to worry about running out of disk space if one site has an enormous database or media library.

The next thing to do is remove unused media and records in the database. Understandably, for large sites, this isn’t always an option. Alternatively, you can use a tool like WP Offload Media to offload all of your site’s media to the cloud. With the ‘Remove all files from server’ setting enabled, no media will be taking up precious server storage room.

Lastly, you can consider increasing the size of your droplet or server instance. For this, you have two options.

You can resize your droplet or server instance. How easy this is to do will depend on your hosting provider.

However, our recommendation is to create a new server using a larger-sized instance and migrate your site(s) over to the new server, using our move tool. This way, you limit the amount of downtime on your sites, and you won’t have to deal with any unexpected issues if the resizing goes wrong.

If you do decide to resize and you’re using DigitalOcean droplets, it’s pretty straightforward. To start the resize process, you need to login to your DigitalOcean account, click on your Droplet and click “Resize”. This will also resize your memory and CPU for the Droplet, so that is something to keep in mind.

More information on picking the right server size can be found in our doc.

Unable to connect to storage provider

Another major reason for backup failures is an issue with your storage provider.

We were unable to connect to your storage provider. Please check your access credentials, region, and bucket.

The backup process runs mysqldump for the database and then gzips the filesystem and database. Before sending the gzipped data to the storage provider, SpinupWP checks the connection to the provider. This is when a connection error could occur. If a connection error does happen, the backup process will automatically retry the connection. After three failed attempts, the process is stopped, and SpinupWP will email you to notify you that the backup has failed.

Network issues are usually the prime reason that the server cannot connect to the cloud storage provider.

One of the first things to check is that your account with the cloud provider of choice is active and in good standing. The next thing to check is your configuration in SpinupWP. Invalid configuration values can cause backups to fail. There are a couple of values to double-check:

the region you’ve selected for the backup is different from the region where the bucket was created.
the bucket name is entered incorrectly

Bucket Name

Another reason may be that your “Access Key ID” or “Secret Access Key” are incorrectly saved. It’s also a good idea to double-check these values as well.

Access Keys