Cryptographic hash lists
From a theoretical standpoint, verifying the integrity of data that will be put on an untrusted medium (such as a remote backup server or an unattended storage device) requires you keep something on a secure medium which is trusted and cannot be tampered with. That something allows you to verify that the rest of the data has not been tampered with. In other words, you are moving trust from the data itself to some auxiliary data (hashes, a cryptographic signature, etc). This is desirable because that auxiliary data is very small and can be stored locally on most mediums. In the case of a drive backup, you could use a cryptographic hash, such as SHA-256, on each file:
find /path/to/backup -type f -exec sha256sum -- {} + > hashlist.txt
The resulting text file contains a list of files and their SHA-256 hashes. The file itself can either be stored locally on a trusted machine, or cryptographically signed (e.g. with GnuPG or signify) and kept in the backup itself. This will prevent anyone with write access to the backup (but not write access to the hash list) from modifying, adding, or deleting files without being detected.
Digital signatures
If you are storing the backup in a large filesystem image or tarball, you can simply hash that instead, which will give you the additional benefit of preserving directories and metadata:
tar cpf - /path/to/backup | tee backup.tar | sha256sum > backup.tar.sha256
If you want to store the hash list in the backup itself, it's necessary to ensure that the hash list cannot be tampered with without detection. The most common way to do this is to use GPG. Once you have created a signing key, you can sign the file, whether the file is a hash list or an entire tarball. The signature can be stored alongside the backups and you can safely verify the backups using the corresponding public key. Just make sure you keep a local copy of the public key and do not allow the private key to fall into the hands of your adversaries. This technique has the advantage of being compatible with a number of security-oriented smart cards.
Secure backup utilities
There are some tools designed specifically for backups which provide integrity and confidentiality. Duplicity, for example, supports sending client-side encrypted incremental backups to a large number of online data hosts, including Google Drive. It encrypts and signs backups using a public and private keypair, though it also supports using a symmetric key (plain passphrase) instead. Because incremental backups are supported, only the initial backup of a large drive will take substantial time. Subsequent backups will only transmit the files that have changed:
duplicity /path/to/backup gdocs://user[:password]@other.host/some_dir
Restoring from backup verifies the data, and data can be manually verified as well. As with GPG, you need to keep the keypair on a trusted medium (a local drive or a smart card). Read access to the private key allows forging valid signatures, as does write access to the public key.
This is what I use myself.
Things to be aware of
In order to ensure that the hash values are faithful representations of the contents of the files being hashed, it is necessary to use a strong hash function. Avoid using MD5 or SHA-1 as they are both broken (in that it is possible to create two files with differing contents but the same hash). The SHA-256 algorithm is the most popular, but SHA-3-256 and BLAKE2b are also acceptable.
If you are generating a keypair (because you are using GnuPG to sign a hash list or archive, or a backup utility that requires a keypair like Duplicity), you should use a strong algorithm. The industry standard is RSA for encryption and signing, with a keysize of 2048 or larger.
In a comment, you mention that you want to be able to use this to prove that incriminating files were not added with your knowledge. This is not likely to fly in court, because it would be trivial for you to upload a new, incriminating file and not sign it in order to claim that it was not added by you. All this will allow you to do is trust the backup as much as you trust the local hash list (or signing key).
