Support

 To me, this doesn't seem to be a successful backup; if the server had died and I tried to restore from the GoogleDrive files, the restored site would have been incomplete.

Yes and no. The backup itself is complete. The resulting backup archive is correct and can be used to restore a site from. However, uploading it failed so yes, if the server died you'd be outta luck.

I can manually transfer the missed file to GoogleDrive to fix this problem.  But if I was running the backup from a cron job would I even have seen the warnings and been alerted that something was wrong, requiring manual intervention?

If you are using the CLI script (akeeba-backup.php) then yes. Its output would have a really big "WARNING" section at the bottom stating that you need to check the output above. If you are redirecting the output to /dev/null you wouldn't receive an email, though.

If you are using the front-end backup URL or the akeeba-altbackup.php script, no, you do not get any feedback for warnings.

In both cases you can enable the PushBullet integration -- it only requires a free of charge account with them -- to receive push notifications on your phone and desktop browser about the backup start, any warnings and backup finish. The push notifications would tell you if there's a warning no matter which backup method you are using.

Just for using the front-end backup, the akeeba-altbackup.php or the JSON API you can also use Akeeba Backup's email on backup completion feature. It's in the component's Options page. It can tell you if the backup completed successfully or with warnings and even list the backup archive names for you. This is meant to be an alternative to the CRON server sending an email with the CLI script's output for the backup methods that use a URL. I believe that you are using the CLI script so this option doesn't apply to you. I just list it for the thoroughness of my reply.

Personally, I use both the CLI output emailed to me and the PushBullet integration. I have mail filters which flag the CLI output email if it contains warnings. I use the push notifications to know that my backups did execute at all. Caveat: I have all of 4 sites with automatic backups. At around 10 sites the push notifications become noise, making the email options better.

Regarding the "yes and no" aspect of your answer: I can find no reference to this particular issue in the (otherwise) excellent documentation.  Have I missed something?

In the past it was merely implied by the wording in the Post-processing Engine documentation and tooltips, as well as the way the backup steps were presented to you. Starting December 2019 I wrote a more detailed documentation page about everything regarding remotely storing backups that I considered self-evident but literally everyone begged to differ :)

And a different question: I'm actually a colleague of David Torr, and we jointly manage the website,  Is it possible for me to get a separate login to the account?

Unfortunately not. Subscriptions are linked to a user account. I tried implementing linked user accounts but it was a bit of a mess and never made it to production. A linked account had its own Download ID (since DLIDs are in fact user identifiers) so when an account got unlinked the updates would stop working. Moreover, support tickets are always personal i.e. only the user submitting them and our support staff can reply to them. Trying to have multiple people reply to them creates a forum situation which makes support harder for us and was the reason we moved to a ticket system. There were other issues about who gets emails about billing, what happens if a linked account tries to renew etc. It was becoming convoluted and user hostile so I decided to scrap it.

cURL error 28: Failed to connect to www.akeeba.com port 443: Connection timed out

When exactly did you receive this error? If it was between Sunday morning and Tuesday morning UTC it had to do with a global issue caused by CenturyLink in the USA dropping the ball with their BGP setup. If you are still getting this problem please make sure that your server resolves our domain to IP 35.214.197.134 and your firewall is set up to allow connections to our site coming through.

Please remember that uploading to Google Drive, Dropbox and a few other remote storage providers using OAuth2 requires your site to connect to our site to mediate the access token provisioning. This is a requirement of the third party storage providers' APIs. If your site cannot connect to ours your backups fail. There is really no alternative unless using a different storage provider which doesn't use OAuth2 (such as Amazon S3, BackBlaze B2 etc) is an option.

As noted in our documentation, backing up to Google Drive requires having a connection to our server (www.akeeba.com). The reason is that Google Drive uses OAuth2 for authentication which necessitates using our server as a "mediator" between Google Drive's API and your site for the purpose of provisioning and refreshing access tokens.

Yesterday we had to do an unplanned server migration of our site because of hardware issues on the physical server hosting it. Our site was intermittently inaccessible between 12:45 and 14:30 UTC. Your backup was taking place during that outage and specifically at a time where I know with 100% certainty our server was unavailable. Between 13:35 UTC and 14:20 UTC our server was completely inaccessible.

Your failure makes sense. You were one of the few unlucky people to try and take a backup while our server was down. There is nothing for either of us to do. We moved our site to a new hosting node which will fix the random outages we were experiencing the past year.