Question about Google Drive stability

[Thronic]

Hi

It's been a while since I stepped away from stablebit software for a bit and have been using 100% cloud via rclone instead. Was wondering how CloudDrive is doing since I'm considering a hierarchy pool with drivepool:clouddrive duplication. It felt very volatile the last time I used it. 

Now I see this sticky:
https://community.covecube.com/index.php?/topic/4530-use-caution-with-google-drive/

Is this a problem similar to write hole behavior on RAID, where blocks of data were being written via CloudDrive and considered uploaded, but interrupted and then corrupted? If so, it should not cause issues with connectivity to the drive and/or the rest of the data. If so, I'll be very tentative to use it.

 

 

[Shane]

@srcrist @Thronic Both of you have made valid points concerning the pros/cons of CloudDrive, rClone and cloud storage.

However, unless specific information is still needed, I suggest this topic has been "sufficiently covered".

[srcrist]

Nobody can really tell you what happened to prompt that cautionary warning about Google Drive other than Google themselves. What we know is that in March of 2019 Google had a major outage that affected multiple services including Drive and Gmail. After the service disruption was resolved, Drive started returning what appeared to be stale, outdated chunks rather than up-to-date data, and that corrupted CloudDrive volumes. I think the widest held presumption is that Google had to do a rollback to a previous backup of some form, and thus replaced some chunks with older versions of themselves--but we'll never really know for sure. Google is not exactly forthcoming with their operative decision making or the technical details of their services.

Regardless, turning on upload verification would prevent the sort of write issue you're describing entirely, but you'll always be at the mercy of the stability of Google's services with respect to the data on their servers. So nobody can guarantee that it won't ever happen again. Hence the warning.

For what it's worth, I've used both rClone and CloudDrive for large-scale data storage for years and I've never found either one to be particularly more volatile than the other--dating even back to CloudDrive's beta. It's always been perfectly stable for me, aside from the Google incident. Just make sure to enable the data integrity features like pinned data duplication and upload verification.

[srcrist]

I am not going to sit here and have some argument with you about this. If you think your data is made safer by rclone, use rclone and let the issue be. I really don't care about your data, and this matters vastly more to you than it does to me.

I'm sorry that you don't understand the actual point. Nobody is forcing you to either use CloudDrive or come here and ask for explanations that you don't actually want. You have a good day.

[srcrist]

2 hours ago, Shane said:

However, unless specific information is still needed, I suggest this topic has been "sufficiently covered".

I thought it was relatively clear that this point had already been reached, frankly.

[Thronic]

Seems upload verification (or any action for that matter on client side) won't help much if the risk is Google doing rollbacks. CloudDrive splitting up files into blocks of data, will make everything fragmented and disastrous if some of those blocks gets mixed with rollback versions. This explains everything. So it will work, as long as Google doesn't mix old/new data blocks. All this makes rclone FAR safer to use, any rollback will not be fragmented, but complete files.

But thanks for the explanation.

[srcrist]

Upload verification will not prevent provider-side data corruption of any form (absolutely nothing will), but that wasn't the concern you mentioned. It WILL prevent the write hole issue that you described, as CloudDrive will not regard the data as "written" until it can verify the integrity of the data on the provider by retrieving it.

Either way, though, I would discourage you from looking at rClone as "safer" in any way. It is not. Any cloud storage is not a safe backup mechanism for data in general, and all cloud storage should be treated as inherently and equally volatile and only used for data that is redundant with more stable mechanisms, or that you can afford to lose. Google Drive has no SLA with respect to the corruption of uploaded data, for example. What you're really noting here is a use case dependent issue. CloudDrive's data (particularly the structural data) was updated more frequently than rClone's more stagnant data. If someone were using rClone to mirror frequently changing data, they also would have been impacted by the rollback--though in different ways. What IS true, is that any corruption on an rClone mirror would be essentially undetected for lengthy periods of time until that specific data is accessed. CloudDrive's corruption was only quickly apparent because the structural drive data is accessed and modified on a regular basis.

This all was, it should be noted, a one-time issue several years ago that has not happened since, and CloudDrive has added pinned data (file system) redundancy in the meantime. So it is less likely to be an issue in the future regardless of all of the above discussion.

[Thronic]

Nonsense. Any rollback would roll back entire files, not fragments. While Rclone uploaded data would just be older versions of complete files, still entirely available, not blocking access to any other data. I'm not saying Rclone is universally better, but in this case it definitely was. Saying Rclone data is stagnant is nonsense too, it entirely depends on the usage. There are absolutely no valid arguments available to make Rclone look worse in the scenario that happened.

I'll look into the pinned data changes. 

[srcrist]

A lot of that is simply repeating what I wrote. But nothing that I wrote is nonsense, and you ignore the inherent volatility issues of cloud storage at your peril.

It is obviously true that in this one particular case and for a specific use case rclone did not have the same issues. But hand-waving away data loss simply because it's in the form of stale but complete files reveals that you are a bit myopic about different use scenarios--which is weird, because it's something that you are also acknowledging when you say "Saying Rclone data is stagnant is nonsense too, it entirely depends on the usage." Which was effectively my point. The point you're actually making in your previous post is only that most users are NOT, in fact, using rclone for that purpose, and that is why they were less impacted by this particular (again, one time, several years ago) issue. If they WERE using it to store frequently updated data, they would also have lost data in the rollback--thus negating your point about volatility. I don't know about you, but if I make a lot of changes to a file and Google just throws them out and replaces it with a version I had last month, I'm not pleased. The ultimate distinction between rclone and clouddrive in this particular instance is that clouddrive was frequently updating data (because of the file system), and rclone was not. The actual file data could, in fact, ALSO be restored an a CloudDrive volume after the incident--it was just a lengthy and tedious process.

In any case, my point to you is not that one solution is better than another at all. Again, I use both for different purposes. I find rclone to be better for longer-term cold storage, and CloudDrive to have superior performance for regular access. My point, rather, is to help you understand that all cloud storage is equally volatile, and to caution you from presuming that ANY of it is "safer," as you previously claimed. It is not. They are just equally volatile and vulnerable to that volatility in different ways.

[Thronic]

If you're going to use a cloud that has rollback of data, then using a solution that splits up your files is straight up a recipy for COMPLETE disaster. This is nonsensical to both argue and defend. In that scenario, uploading entire files is safer. No matter the software. I ignore nothing, I simply stay on topic.

It doesn't matter how volatile you claim cloud storage is in general, this was about Google Drive specifically. And there is no argument available that can claim CloudDrive was safer, or equally safe, as a fully uploaded files in a situation where the cloud rolled back your data. The majority would agree that outdated data, probably just by seconds or minutes, is better than loosing it all. The volatility issue here was CloudDrive's expectation of that not happening, straight up depending on it, not using cloud itself.

You seem to want to defend CloudDrive by saying that cloud is unsafe no matter what. But the fact stands, fully uploaded files vs fragmented blocks of them would have at least offered the somewhat outdated data that Google still had available, while CloudDrive's scrambled blocks of data became a WMD. CloudDrive lost that event, hands down. Claiming my nightly synched files via Rclone would not have been any safer is absolute nonsense.