Yes, this secures your data from Google, sync.com and from anyone trying to grab your data while it is in transit to Google.
Three things to think about:
Your lastpass password is far shorter and contains (the way it sounds) far less entropy than the one that protects your gpg tar file. Someone attacking this scheme would therefore most likely attack your lastpass account (since now it's public knowledge that your password there is weaker).
It sounds like you're using GPG in symmetric encryption mode (more on an alternative at the end of my answer). So: What's to stop a disgrunted lastpass employee with a bit of technical knowledge to steal your gpg password and sell it to an interested party at Google? Or if you find that problem too theoretical, what about an attack on the lastpass service which steals millions of user passwords and publishes them? Since you've conveniently added a note about where the encrypted files are located, you're basically handing your encrypted files over to anyone who can access your Lastpass account (well, in theory, anyway - he or she still has to get your Google Drive password...)
You're splitting your file into multiple files. Why exactly are you doing this? If you lose just one, you're running the risk of losing all your data. Say you lose file 20 (out of 200): You've lost all the content that was stored in files 20-200 forever. Keeping everything in one big file might make up- and downloading a bit more difficult, but it reduces the risk that you lose one of the files.
A few suggestions
Point 3 is also a problem with a huge file that accidentally gets a single bit flipped in transit. I'd think about redundancy a bit. There are ways to add error correction without having to double the size of the data. (I think some compression programs support it natively, even though you can't expect them to actually compress your .tar.gpg file...). Confidentiality is all well and good, but your scheme is a backup scheme, so you should also think about availability.
I would also suggest not storing your GPG password on an external service (Lastpass). If you're afraid of losing the 100 character password, write it down on a physical piece of paper and put it in a safety deposit box of a bank you trust.
Also, this might seem paranoid, but I wouldn't use the same passphrase over and over to encrypt your gpg files. Instead, I'd genereate a file containing a number of truly random bytes whenever I needed to upload a new backup and use that as a key for my gpg'd tar file. I'd then encrypt this random file with my 100 character passphrase and keep it on my computer, send it along to be stored at google / sync and maybe back it up to an additional location. (Basically, I'd create a session key with which to encrypt my data and use the 100 character string as a master key to decrypt the session keys). You can automate this fairly painlessly, and it gives you forward secrecy in case one of your backup session keys is compromised and the ability to decrypt any specific backup without losing control over your master key.
Finally, if you're really just using Google Drive as a backup and don't really need to decrypt the data except in emergencies, you could think about using gpg in it's public key cryptography mode. Make a backup key pair, and then keep your private key safely offline (in a bank deposit box, on a CD ROM, printed out on a piece of paper somewhere for safekeeping) while using the public key to encrypt your symmetric session keys (using public key cryptography to encrypt with gpg would make the manual session key step seem redundant - I'd still do it for better forward secrecy). So you'd never have to worry about your master key (private key) getting compromised by cyberattacks, even if you stored your public key at LastPass. Even if they stole it, all they could do with it is encrypt more data; they couldn't use it to decrypt your session keys.
