Support

Akeeba Backup for WordPress

#22458 Errors/failure after migrating host

Posted in ‘Akeeba Backup for WordPress’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

WordPress version
n/a
PHP version
n/a
Akeeba Backup version
n/a

Latest post by user86955 on Thursday, 16 April 2015 09:09 CDT

user86955
Hi, I had Akeeba setup and creating successful backups. I changed hosting providers. The new hosting provider was able to migrate without using my Akeeba back-ups.


On the new host, back-ups fail. I tried re-running the configuration wizard which also incurred errors and could not complete. I checked the MySQL version and the database user is allowed to run the SHOW TABLE STATUS. The database user did not change in the migration.

ALICE - suggested to change min & max execution time. Which I did - but did not make a difference.

nicholas
Akeeba Staff
Manager
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.

Nicholas K. Dionysopoulos

Lead Developer and Director

πŸ‡¬πŸ‡·Greek: native πŸ‡¬πŸ‡§English: excellent πŸ‡«πŸ‡·French: basic β€’ πŸ• My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

user86955
Hi Nicholas,
I made the changes and I am still getting errors. The back-up is getting halted and says it fails but I am getting different results in that on the "manage back-ups" page is shows status as "OK", it is chopped into 3 parts and is not storing to Dropbox. Do I need to re-setup dropbox too?

Compared to the previous hosting account where it was successful but took approx 45 minutes to complete; here it is going through the process substantially faster (7 minutes) but is having more difficulty. I've attached a screenshot.

I really hope to get this resolved - as you can see I have not been having back-ups since 3/20
So many issues when migrating!

nicholas
Akeeba Staff
Manager
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.

Nicholas K. Dionysopoulos

Lead Developer and Director

πŸ‡¬πŸ‡·Greek: native πŸ‡¬πŸ‡§English: excellent πŸ‡«πŸ‡·French: basic β€’ πŸ• My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

user86955
Hi Nicholas,
The "Enabled chunked upload" had been checked but the Chunk size had been at 20. I haven't run it yet because I have an additional question based on your last paragraph.

I typically would run a back-up during the hours that I expect the least amount of data input by any user or impact on site performance. Since you said that the back-up itself is only around 5 minutes, is that timeframe the part that is impacting the site? I have hesitated to run a back-up that would impact 45 minutes to an hour.

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?

nicholas
Akeeba Staff
Manager
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.

Nicholas K. Dionysopoulos

Lead Developer and Director

πŸ‡¬πŸ‡·Greek: native πŸ‡¬πŸ‡§English: excellent πŸ‡«πŸ‡·French: basic β€’ πŸ• My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

user86955
Hi Nicholas,
Well it shows we have success with the change of the chunk size to 10. I have a question regarding the drop box file size though. On the previous successful backups prior to migration, the file size shown in the Manage Backups matched the dropbox file size. In this new backup, the back-up manager shows the size at 2.53 Gb but my dropbox only shows 558.7 Mb

Thank you for all of your help. Next step is getting the chron job set up
Kathy

nicholas
Akeeba Staff
Manager
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.

Nicholas K. Dionysopoulos

Lead Developer and Director

πŸ‡¬πŸ‡·Greek: native πŸ‡¬πŸ‡§English: excellent πŸ‡«πŸ‡·French: basic β€’ πŸ• My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

user86955
Hi Nicholas, thank you so much for your help.
I must have checked the dropbox folder too soon because when I originally went there, it was only showing the one file for the backup (the smaller one) but now it is showing the .j01 file.

Again, thank you for the great support. I will close this ticket.

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!