SuperDuper! backup doesn't recognize Google Drive

[Felix]

I've noticed that when I boot up on my SuperDuper! back-up (an external drive), my Google Drive folder isn't recognized. Even when I go through the "locate drive" steps, it still isn't recognized.

Is there a workaround other than deleting the folder in the Google "cloud" and then uploading the entire folder again from the folder on my desktop Mac? It's not too much of a problem now when I only have about 4GB of files in the Google cloud but I'm considering purchasing extra cloud storage and wouldn't want to waste the time uploading mega-GBs of Google Drive files if I need to boot and work from the SuperDuper! external drive clone.

[dnanian]

It seems likely that Google Drive is trying to avoid accidental loss of data by carefully tracking the drive that it's copying to/from. You can try making sure the source and destination drives are named the same, but I think it's more likely they're tracking the low-level unique ID.

[Felix]

Dave, it even comes up with a caution note which says something to the effect that the drive name is the same but it can't be synced.

[dnanian]

Yah, they're clearly trying to prevent this, Felix. Perhaps you should ask them what they recommend?

[Felix]

Originally Posted by dnanian

Perhaps you should ask them what they recommend?

Quick response...they said users are reporting Carbon Copy Cloner works OK. That's going to be just ducky if CCC works and SD! doesn't.

[dnanian]

I have no idea why that would be.

[Felix]

I see Mike Bombich of Carbon Copy Cloner posted a detailed explanation for his customers. Unfortunately, I'd already tried his solution with my SD! clone and it didn't work.

QUOTE

Google Drive keeps a database at /Users/yourname/Library/Application Support/Google/Drive/snapshot.db. This database records, among other things, the inode number of your Google Drive folder. File and folder inodes are physical addresses that indicate where within the filesystem a particular file resides. If you read the contents of this database, you can compare the values to the inode numbers on your volumes, e.g.:

Mini:~ apple$ ls -lai /Volumes/Lion/Users/apple/Google\ Drive/
1222230 drwxr-xr-x@ 3 apple staff 102 May 14 14:22 .
391169 drwxr-xr-x+ 23 apple staff 782 May 14 16:02 ..
1222248 -rw-r--r--@ 1 apple staff 0 May 14 14:22 Icon?

Mini:~ apple$ sqlite3 /Users/apple/Library/Application\ Support/Google/Drive/snapshot.db "select inode_number,filename from local_entry"
1222230|/Users/apple/Google Drive

Mini:~ apple$ ls -lai ~/Google\ Drive/
449722 drwxr-xr-x@ 3 apple staff 102 May 14 14:22 .
449381 drwxr-xr-x+ 24 apple staff 816 May 14 16:03 ..
451706 -rw-r--r--@ 1 apple staff 0 May 14 14:22 Icon?

So in this case, I'm booted from the backup volume. You can see that Google Drive has my Google Drive folder's inode number recorded as "1222230" and that's what the inode is for that folder on the original volume, "Lion". When I look at the inode value of the folder on the backup volume, it's different. The inode number can't be preserved in a file-level backup, so Google Drive will always break when you boot from your backup volume.

Unfortunately there's no easy workaround for this. As long as Google Drive records inode numbers, it's only ever going to work with the original source volume. It doesn't matter how accurately CCC preserves the contents of these folders or the databases that store information about them, the inodes will always be different on a new volume.

To summarize:

Problem:
Google Drive reports that the Google Drive folder does not exist

Solution:
Disconnect your account from Google Drive, then sign in again to Google Drive to re-establish the "new" folder on your destination volume as the Google Drive folder.

UNQUOTE

[dnanian]

Right - Google is explicitly preventing this from working. And it doesn't work with CCC either - something I'd expect, given what we're both doing.

I really think you should bring this up with Google - it's their issue...they're trying to tie the "Drive" to a very specific thing, and they may have their own recommended method of handling a restore.

[Felix]

Originally Posted by dnanian

<snip> I really think you should bring this up with Google <snip>

I already reported what they had to say...try CCC.

But per Bombich's explanation, CCC also requires a workaround. But so does Dropbox so I guess that's just the nature of the beast. At this point, I'm still trying to sort out why I can't get SD! to recognize Google Drive when I sign out and back in like Bombich recommends for CCC.

More to come.