Sorry. I spoke too soon and closed ticket #32151 prematurely.

Version 7.0.0.b3 will fetch back small or medium-sized backups (34.31 MB) but fails on a larger backup (1.26 GB).

It consistently fetches 10 of the 262 files that make up the backup. The files are 5MB in size.

I am still getting error log entries like this: [error] AH01630: client denied by server configuration: /services/users/1/xxxx/www/xxxx.com/Solo/assets/private/config.php

Thank you,

Bill Ervin

Can you please confirm that all backup parts exist on the S3 bucket and there are no discontinuities? For example, if you have files .j01 through .j10 but the next one is .j12 (not .j11) the download will stop on the assumption that there are no more parts to be found.

Regarding the error: it is expected and completely unrelated to your issue. Every time you access Solo it checks whether your configuration file is inaccessible over the web. That's what causing the access error and it is a good thing; it means that your configuration cannot be read by a random user by accessing its well-known URL. In case Solo detects that the file is accessible over the web it shows a big, scary notice to let you know that you must fix this issue for security reasons. In any case, that error should be in your logs and is unrelated to your issue. Just forget about it.

Yes, all the backup parts are on S3. I copied them manually and restored them without any trouble.

I have attached three screenshots. S3 storage is on the left and web server is on the right.

You can see that when I try to fetch a backup with 5MB parts I get 11 files. J10 is incomplete.

When I try to fetch a backup with 10MB parts I get 7 files and J06 is incomplete.

The third screenshot is of the modal window after the fetch has failed.

Thank you for your help,

Bill Ervin

Sorry for the delay. Debugging file transfers, especially those involving files at volume, are notoriously slow since they're affected by the network speed.

Apparently the whole problem was a single mistyped letter. I had put "remorefiles" instead of "remotefiles". This meant that the download started, it hit a breakpoint to prevent it from timing out, but the next run was never taking place because of the typo.

I have fixed that in this developer's build. You will need to update manually to it per the documentation instructions under "Manual update method".

I am happy to confirm that the problem has been resolved.

I updated with the developer's build and then successfully fetched a 700MB backup and restored it.

Thank you very much for fixing the issue so quickly.

Best regards,
Bill Ervin