Support

Go to Akeeba Backup, Configuration and find the Database backup engine row. Click the Configure button next to it. Check the "No dependency tracking" checkbox and click on Save & Close. Take a new backup.

If this still fails, please try the following time parameter in the Configuration page:
- Minimum execution time: 2 seconds
- Maximum execution time: 10 seconds
- Execution time bias: 75%

If it still fails please ZIP and attach your new backup log file.

OK, that's much better. Right now you do have a backup, but it's stored locally. We've gone past the hardest part of the process (getting a backup done) and now we can focus on getting that backup to Dropbox. This is the easy, but more time consuming during the process, part.

Go to Akeeba Backup, Configuration and find the Post-processing Engine row. Click on the Configure button next to it. Make sure "Enabled chunked upload" is checked. Now set the "Chunk size" to 10. If the upload still fails try setting it to 5.

Do note that the backup itself only takes around 5 minutes. By the looks of it you'll need about an hour or more to get it uploaded to Dropbox. That's where the majority of time is consumed and explains why on your previous host it took around 45' to complete.

Since you said that the back-up itself is only around 5 minutes, is that timeframe the part that is impacting the site?

The critical timeframe for backup consistency is those 5 minutes, give or take a few seconds. That said, do keep in mind that running a backup does use CPU and memory resources while backing up, as well as bandwidth resources when uploading the backup archive. On lower end servers you MAY observe performance degradation during that time. You're hosted on a fairly decent host so I don't expect this to happen. Your (very limited) impact will be mostly concentrated on those 5 minutes the backup generation takes to complete.

I'm also wondering what is causing the current problem. Compared to my last hosting provider, my new VPS has 4 times the RAM (4 GB), 2 CPUs plus 150 GB disk space. Should I have deleted Akeeba and started over?

Good Lord, no! Reinstalling is voodoo. It rarely solves anything except reset any user errors. We have already established that you don't have any. Reinstalling will only set you back since you'll have to start from scratch, therefore making it more possible that you make new mistakes which we will both be none the wiser about. The end result will be one unhappy client who has no working backup and one frustrated developer who's called to fix a different problem than the one he was presented with. Bad idea. Let's not go there.

Please read the documentation page on the basic configuration of cloud backups, namely its last paragraphs after the image. As you can see the thing is how much data you can push through the connection between your server and Dropbox. If it takes a lot of time the process will time out and die. Since you can't change the connection performance or the timeout limit of your server the only thing left to change is the amount of data you have to push.

Less data = less time. You can visualize it very easily. It's like transferring water between two containers using a drinking straw. A glass of water will transfer twice as fast as a pint which transfers twice as fast as a quarter gallon bottle. (I hope I got my units of measurement right; I'm used to metric units!) Water is data. Containers are server. Drinking straw is the connection between the servers.

Please keep in mind that you may have a multipart backup, i.e. your backup consists of many files with the same name and different extensions (.jpa, .j01, .j02 etc). The file with the .jpa extension is the last and the smallest file of the backup set.

Also, the default partitioning occurs at about 2Gb which makes sure that every supported version of PHP on every platform (Windows, Linux, Mac OS X, etc) can read the file. Files over 2Gb may become corrupt during backup or be unreadable while restoring.

Armed with this knowledge I can understand why you think you have a problem: you only checked the last backup part, the .jpa file, which is indeed about 0.53Gb long. Next to it you will see a .j01 file with a reported size of 1.99Gb. Add them together, you've got the correct size.

IMPORTANT! As stressed out in our documentation ALL part files of a backup MUST be present when restoring your site. If any one is missing the extraction cannot proceed.