Restored a Time Machine backup from Google Drive, but MacBook won't recognise it. What does MacOS look for to identify a Time Machine?

Time Machine (pre-APFS) uses hard links to folders. Those are not possible on ExFAT (and just about every other file system).

However, if it was a network backup, it would have been a disk image that contains the embedded File System. Is the backup a single sparse bundle disk image, or a Backups.backupd folder structure. The former should work, but the latter would not.

Depends on what happened to the Time Machine disk when it was sync'd to Google Drive. Like Barney-15E states, if the NAS backup was a sparse disk image and it wasn't altered when sync'd to Google then it might work. However, my guess is that the data was sync'd but not the disk layout format. Depends on how the Google Sync worked. HFS+ Time Machine uses hard links while APFS Time Machine uses snapshots.

A sparse disk image is more like an App Bundle in that it looks like this outside of macOS when I list the contents on my Linux with ZFS NAS.

/capsule
└── timemachine
    ├── jbrickley
        ├── M1.sparsebundle
        │   ├── bands
        │   ├── com.apple.TimeMachine.MachineID.bckup
        │   ├── com.apple.TimeMachine.MachineID.plist
        │   ├── com.apple.TimeMachine.Results.plist
        │   ├── com.apple.TimeMachine.SnapshotHistory.plist
        │   ├── Info.bckup
        │   ├── Info.plist
        │   ├── mapped
        │   └── token
        └── MacPro.sparsebundle
            ├── bands
            ├── com.apple.TimeMachine.MachineID.bckup
            ├── com.apple.TimeMachine.MachineID.plist
            ├── com.apple.TimeMachine.Results.plist
            ├── com.apple.TimeMachine.SnapshotHistory.plist
            ├── Info.bckup
            ├── Info.plist
            └── token

The "bands" folder contains equally sized file chunks with unique file names so when the disk image grows it adds more bands. If you delete data from a sparse image bundle you need to compress it to free up the space. Doing so will remove unused band files. When you mount the disk image on macOS you see the actual contents.

/Volumes/Backups of M1
├── 2021-08-16-075300.previous
│   ├── ContentCache
│   │   ├── Icon\r
│   │   └── Library
│   └── Data
│       ├── Applications
│       ├── Icon\r
│       ├── Library
│       ├── System
│       ├── Users
│       ├── Volumes
│       ├── cores
│       ├── mnt
│       ├── opt
│       ├── private
│       ├── sw
│       ├── usr
│       └── ~
└── backup_manifest.plist

If you can see folders such as /Applications, /Users, etc. on your USB drive copy from Google Drive. Then you will need to manually copy the data to restore it. However, if you see the sparse image bands, well that's a problem. You might be able to create a new sparse image and manually copy the contents to it then cross your fingers that it will work.

Okay, try creating a new Time Machine sparse bundle and then manually copy contents from the USB drive to the sparse bundle before you mount the sparse bundle. Then say a little prayer to whatever god you worship and try mounting the sparse bundle in macOS.

I am guessing that some file attributes, permission, etc. was lost in translation when the sparse bundle contents were sync'd to Google Drive.

Here is an old script showing how to create a Time Machine sparse bundle using the hdiutil command line tool. It creates an JHFS+ sparse image not an APFS one. I wouldn't run script but you can examine what it is doing. Notice how it generates the UUID and the PLIST, etc.

https://gist.github.com/chrisfcarroll/e05f1133de0aaf94d7d4

Here is an article detailing how you might repair the sparse bundle. Make a backup copy of the original backup before you attempt anything.

http://thefunkstop.com/fix-corrupted-time-machine-backups/

Again, if it's APFS which it might be if you created it new with Big Sur but it could still be JHFS+ format if you maintained an older Time Machine backup or your NAS didn't support APFS, etc. You will have better luck with JHFS+ as APFS isn't nearly as well documented.

Some notes on the above link from James Brickley

The first command you can copy/paste this and then drag the sparsbundle into the Terminal window to complete the path to it.

hdiutil attach -nomount -noverify -noautofsck -readwrite  

If it shows Apple_APFS instead of Apple_HFS, use this to check the disk where disked is whatever the previous command spit out:

fsck_apfs -y <diskid>

fsck for APFS doesn't have all of the options he is using for HFS, so maybe this works or maybe not.