Support

Akeeba Backup for Joomla!

#37047 Backup is not transferred/copied to DropBox

Posted in ‘Akeeba Backup for Joomla!’
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

Joomla! version
3.10.6
PHP version
7.4.28
Akeeba Backup version
8.1.2

mj@encretpixel.com

EXTREMELY IMPORTANT: Please attach a ZIP file containing your Akeeba Backup log file in order for us to help you with any backup or restoration issue. If the file is over 10MiB, please upload it on your server and post a link to it.

Hello, 

Since some days the backups seems not to be partially transferred to DropBox, so they are not removed from the website server. I use WebCron.org website to initiate the backups and allowed 3600 seconds to do the job. 

Please find the logs of the last backup enclosed. 

Thank you for letting me know what I should do to resolve the issue. 

Manès

tampe125
Akeeba Staff

Hello,

backup log wasn't uploaded, I suspect it's too large. Please zip it and try again, if it's still too large please upload it somewhere and paste here the link to it.

Davide Tampellini

Developer and Support Staff

🇮🇹Italian: native 🇬🇧English: good • 🕐 My time zone is Europe / Rome (UTC +1)
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

mj@encretpixel.com

Hello, I don't know what happened I added it to my previous message, I try again and in case it's not working again, please find the link to it : https://www.dropbox.com/s/6a0nqkfmugrv0wi/Akeeba%20Backup%20Debug%20Log.zip?dl=1

With best regards. 

 

tampe125
Akeeba Staff

Looking at your log, it seems that the chunk uploads are failing; Dropbox wasn't able to re-assemble all the chunks you uploaded into a singular file.

Your total size backup is more than 6Gb, this means that Akeeba Backup will split the data inside 3 archives of about 2Gb and then another one with the remainder. Then, each file will be uploaded chunk by chunk to DropBox. Since they are very large, there could be some issues in the upload or in the processing on the other end.

First of all I'd suggest to get inside profile configuration, Archiver Engine section and set a part size of 500Mb. This will create more archives but they will be smaller, and it should help with the issue.

If you still have problems, keep lowering it until you reach about 100Mb.

Let me know how it goes.

Davide Tampellini

Developer and Support Staff

🇮🇹Italian: native 🇬🇧English: good • 🕐 My time zone is Europe / Rome (UTC +1)
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

mj@encretpixel.com

This seems to solve the issue :-)  I just tested it now and it seems to work fine now. I'll check again tomorrow when the cron job will be executed automatically.

Thank you for your help !

tampe125
Akeeba Staff

You're welcome!

Davide Tampellini

Developer and Support Staff

🇮🇹Italian: native 🇬🇧English: good • 🕐 My time zone is Europe / Rome (UTC +1)
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

mj@encretpixel.com

Hello, 

Well I spoke too soon. After some more tests, the file transfer to DropBox always fail... I don't know but it seems there might be a problem on DropBox side as I saw there is another ticket open with the same kind of problem. For me the solution would be to transfer those files to a Synology NAS that I have. I just tried to set up an SFTP transfer, but using the same credentials that I am using with my desktop ftp clients (such as ForkLift or Cyberduck) I always have an error message saying : "Cannot connect to SFTP server [host:port] = xxx.synology.me:22". I gave the host name using this format : mysynology.synology.me + username + password. Is there something I am missing ?

I have to add a comment, when connecting with Cyberduck, I had this message before connection (I had to agree before seeing my Synology files) : "Unknown fingerprint - The fingerprint for the EDxxxxx key sent by the server is ....." then I have to choose between "allow" or "deny" buttons. 

Thank you for your help. 

tampe125
Akeeba Staff

mhm... it looks like it's an issue with Dropbox itself. My suggestion would be to disable chunk uploads for a while and then try again after a couple of weeks. We already had something like that with Backblaze, sadly there's nothing we can do about it. Dropbox is meant to be used from the browser or use their app on a desktop PC, so if anything goes wrong the app can simply retry after some time, they're not meant to be used on a server.

If you want a very reliable solution, the best thing would be to switch to Amazon S3.

Regarding SFTP, you have to place the username and password in the appropriate fields, not inside the server name.

Davide Tampellini

Developer and Support Staff

🇮🇹Italian: native 🇬🇧English: good • 🕐 My time zone is Europe / Rome (UTC +1)
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

mj@encretpixel.com

Thank you, I have tried to disable the chunk upload, this doesn't cure the problem. I don't know if this was expected.

Regarding the sftp, I did put the right information in the right fields, so I really don't know what to do to correct this. I tried webdav, it connects alright but the files upload is random, I don't know why... 

I will investigate Amazon S3 but seems more expensive than using dropbox which I am trying to avoid. 

tampe125
Akeeba Staff

Can you please upload the backup log when chunked uploads are disabled?

WebDav uploads are even more fragile, there is a standard protocol, but each provider is adding some changes to it.

Amazon S3 is a little more expensive, but it compensate with reliability. For what is worth, you can setup rules to automatically move your files into less expensive storage and you're really going to pay pennies for it.

Davide Tampellini

Developer and Support Staff

🇮🇹Italian: native 🇬🇧English: good • 🕐 My time zone is Europe / Rome (UTC +1)
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

mj@encretpixel.com

Here is the backup log. 

tampe125
Akeeba Staff

Looking at your log, it seems that the problem is the upload speed. It takes more than 15 minutes to upload 512Mb.

Try to lower the part size again, but you should report the issue to your host since it will take forever to upload anything, regardless of the service provider

Davide Tampellini

Developer and Support Staff

🇮🇹Italian: native 🇬🇧English: good • 🕐 My time zone is Europe / Rome (UTC +1)
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

mj@encretpixel.com

Well I'll check with the hosting company, but I have no real hope that they could change anything on their side. I guess I will have to transfer myself the files from each sites to somewhere else to avoid web servers allowed space to fill up to quickly.

There are several file kind in the "Backup" directory : 

akstorage_frontend.id-20220505-220028-926057.php
akeeba.frontend.id-20220505-220028-926057.log.php
akeeba.frontend.1134.log.php
akstorage_frontend.967.php
confwizvMHZLg
web.config
index.php
index.html
index.htm
.htaccess

Which kind should be kept in the directory to avoid potential problems and which ones could be deleted ?

On the other hand isn't there any other solution to launch a cron job which just starts the backup and end it when all the files are transferred ? I guess here the problem is that the cron job is open for a limited time and ends before the file transfer is finished.

tampe125
Akeeba Staff

You should leave all the files in the backup directory. They are linked to backup records and are automatically deleted when you remove an archive from your site using the web interface.

Using a CLI script won't do the trick. There still are timeouts even in CLI, moreover your upload speed is so slow that you will certainly hit the timeout. You can try to avoid them by using a lower part size, but be prepared for long backup time.

Maybe it's worth a try, but you can try to schedule the backup at another time. Sometimes uploads speeds are better since there's less load on the server.

Davide Tampellini

Developer and Support Staff

🇮🇹Italian: native 🇬🇧English: good • 🕐 My time zone is Europe / Rome (UTC +1)
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Support Information

Working hours: Typically we work Monday to Friday, 9am to 7pm Cyprus timezone (EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets, but we cannot respond to them, outside of our working hours.

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!