Support

I do not see any problems in your log file. You have configured Google Drive correctly, it connects correctly, and it appears to be uploading the files just fine. In fact, I see that each 10 MiB chunk takes about 2 seconds to upload which is a reasonable amount of time; I would be worried if I saw it taking under a second as it's physically impossible – and I literally mean "faster than speed of light" kind of impossible.

Please check your Google Drive trash folder. If you deleted a folder that has the same name as the folder you are uploading the backup archives into (or at least the same name as one of its parent directories) you might end up uploading directly to trash. Yes, I know, it is insane. I am doing exactly what the Google Drive API documentation says to avoid it but for some (not all!!!) Google Drive accounts it seems to have no effect. I have seen other people reporting the exact same thing for years, and nobody at Google seems to care – quite unsurprisingly, I might add. The workaround I've found is moving the files to the correct folder by hand, then removing the problematic folder from Google Drive's trash completely. Once it's fully deleted, the Google Drive API no longer resolves the upload path to the trashed directory.

Yeah, this is a symptom of the same issue with Google Drive.

Google Drive was originally meant to be just storage for Google Docs and Google Sheets. It wasn't designed as a regular filesystem. It does not actually have a directory structure based on directory and file names like a regular filesystem does. It has object IDs, with each object also having a user-facing name.

When you tell Akeeba Backup to use, let's say, the path Foo/Bar it means nothing to Google Drive. It can only upload data to an object inside a folder object fed to it by ID. What we have to do is get the ID of the drive root. Then we ask Google Drive to list the entries in that folder ID matching the drive root's ID which have the exact name "Foo". If one does not exist we create it and use its ID. Repeat that for "Bar" with the ID of the "Foo" directory. And so on and so forth.

Sometimes, Google Drive will either return the ID of a folder object that's in the trash (even though we explicitly tell it not to returned trashed items), or fails to find the folder object even though it exists. Since the user-facing name is just a non-unique label, you may end up with two same-named folder objects in the latter case. Which one will be returned first from that point onwards is anyone's guess.

If that sounds stupid, yeah, it is. It is one of the MANY reasons I am telling people NOT to use Google Drive, OneDrive, or Dropbox for storing backups. These services are not made with data resilience or performance in mind. They are cheap for many reasons, none of which gels well with the need for reliable, fast, and durable storage for backup archives. But they are cheap, they are usually part of a bundle deal, people ask for them, and I provide an integration despite my better judgement. And that's how I end up replying to 100 times more tickets about Google Drive, OneDrive, and Dropbox than for all other storage providers combined.

I strongly recommend spending the price of a pizza per month to get much better storage from the likes of Amazon Web Services, Wasabi, etc. I would assume there might be a number of S3-compatible providers in Australia; unfortunately, I am only familiar with the European and USA-based ones due to these being the prevalent demographics of this software.