Jump to content
  • 1

GDrive - Mounting as RAW this morning.


chrisde1982

Question

Hi there!

I've got a data issue this morning. Been using Cloud Drive for a little while now, and for some reason, after rebooting my instance this morning the google drive I use, through cloud drive is mounting as RAW and is unreadable. It was fine a few hours ago when Plex was running it's usual over night maintenance. 

 

Any ideas? I've tried everything I can think off and cannot access the contents of the drive. Although looking at the stats everything is still there. 

The worrying thing is when looking at the service log it's indicating volume corruption... is there anyway anybody can think of that could allow me to recover my data. It's a 2Tb volume. 

 

Thanks, 

 

Chris. 

 

Link to comment
Share on other sites

Recommended Posts

  • 0

Update: 

It looks like CHKDSK has recovered the directory structure, although there appears to be a lot of data loss at this stage. Cloud Drive is transferring a lot of data when trying to access certain directories that appear to hang, so hopefully it's doing something magical. 

Link to comment
Share on other sites

  • 0

Hello, this happened to me as well. I use Windows 10 and it happened after a Windows 10 update. The computer would reboot and then get an error. The ones that mounted were in RAW.

CHKDSK did not fix my issues, so I would be curious to know what you did specifically. I ended up having to destroy the volumes and recreate. Lost about 90TB of data in the cloud and I am restoring from backups. Was a massive pain.

Link to comment
Share on other sites

  • 0

Hi,

CHKDSK /F corrected the file system issue I was having, it repaired the file allocation tables and I could then access the directory structure on the drive. What I then had to do was enter each directory manually in file explorer and then wait a few minutes (it would appear to hang) depending on the size of the files present for it to "rediscover" everything. 

I use it for Plex media serving but until I manually entered each directory individually and waited for it to bring the files up in file explorer Plex wouldn't respond to any media I tried to play. I'm still going through some of the directories now. I've lost a couple of episodes for one or two shows, but they will be easy enough to replace. 

Touch wood though apart from those one or two lost episodes everything now appears to be working correctly. 

I thought it worth noting that it did appear to hang in file explorer when entering each of the directories for the first time, I gave up on the first occasion and was getting ready to trash the drive, but luckily I tried again, and waited for it to find the files. I'm not really sure what it was doing, but it was almost like Cloud Drive was rediscovering and re-indexing the files as there was a lot of download activity while file explorer appeared to hang. 

I hope this is helpful for somebody, and maybe you (and me) in the future if it happens again :)

Link to comment
Share on other sites

  • 0

I'm not sure why it would need to reindex all of the files on the drive like that, but if it does, indeed, need to search everything once, you could probably use an application like WinDirStat to do it all in one go. It'll touch every file on the drive in a few minutes. 

Link to comment
Share on other sites

  • 0

That's a good suggestion, if I find myself in a situation like this again I'll be sure to give that a go. Either way, I'm just happy I managed to recover pretty much everything except a few gb of data. 

One good thing to come out of this is that it has encouraged to be set up a back up solution before expanding my library any further.

 

Thanks, 

Link to comment
Share on other sites

  • 0

My setup might be different. But when I run chkdsk it just tells me:

 

C:\Users\Administrator>chkdsk /f E:
The type of the file system is NTFS.
Unable to determine volume version and state.  CHKDSK aborted.

 

I also have my cloud drives pooled and if I tried to run CHKDSK on the pooled drive it said the partition is RAW and aborted. Even though the drivepool is reporting as NTFS in disk management. I have submitted a couple questions to support to find out what I am doing wrong.

Link to comment
Share on other sites

  • 0

We've had a rash of these, unfortunately.

 

And actually, the best way to recover from this may be to do this:

  1. Take the drive offline in disk management
  2. Turn off all pinning in the CloudDrive UI
  3. Clear the local cache, and wait until it's down to 0 bytes (literally empty)
  4. Bring the cloud drive back online from disk management

You may need to repeat step #3 a couple of times to get this to work

 

If that doesn't help, then CHKDSK or data recovery may be needed. 

Link to comment
Share on other sites

  • 0
3 hours ago, Christopher (Drashna) said:

We've had a rash of these, unfortunately.

 

And actually, the best way to recover from this may be to do this:

  1. Take the drive offline in disk management
  2. Turn off all pinning in the CloudDrive UI
  3. Clear the local cache, and wait until it's down to 0 bytes (literally empty)
  4. Bring the cloud drive back online from disk management

You may need to repeat step #3 a couple of times to get this to work

 

If that doesn't help, then CHKDSK or data recovery may be needed. 

Glad to see an official response on this. 

Christopher, are you able to provide a quick explanation of *why* that process would help? What exactly is going on with these RAW errors, and can they be prevented in case of a Google outage in the future? Would turning on file upload verification help? 

Link to comment
Share on other sites

  • 0

Sorry for taking so long to post the response here.

Specifically, this clears out the cache and forces the software to redownload the data from the cloud, including the file system data.   

Setting the drive as offline ensures that drive data is not updated, and that any open files are forcibly closed (eg, without saving). 

 

As for preventing this, I'm not sure.  This is one of the more tested aspects, so unless google was coming back with old versions of the chunks, I'm not sure why this would happen.  As for mitigating this in the future, I'm not sure how we could do so, but then again, Alex is the expert here. (and he is aware of the issue)

Link to comment
Share on other sites

  • 0
On 4/2/2019 at 5:38 PM, Christopher (Drashna) said:

We've had a rash of these, unfortunately.

 

And actually, the best way to recover from this may be to do this:

  1. Take the drive offline in disk management
  2. Turn off all pinning in the CloudDrive UI
  3. Clear the local cache, and wait until it's down to 0 bytes (literally empty)
  4. Bring the cloud drive back online from disk management

You may need to repeat step #3 a couple of times to get this to work

 

If that doesn't help, then CHKDSK or data recovery may be needed. 

Chris, I'm trying to go through this now and no matter how many times I clear local cache, it doesn't seem to want to get rid of the last 43.8 MB. It also shows 632 KB waiting to upload but doesn't upload anything.

Link to comment
Share on other sites

  • 0
16 minutes ago, Christopher (Drashna) said:

To make sure, you've set the drive as offline in disk management and turned off ALL pinning (file system data, and directory pinning)?

If so, you may be fine just doing step #4

Yep, tried all of that and the drive still doesn't show any folders or files in explorer. Windows now says that there is some space being used, but once I go inside, it says it's empty.

Link to comment
Share on other sites

  • 0
40 minutes ago, fly said:

I'm confused and concerned.  I use CloudDrive to backup important client data for my business, as I assumed it was the perfect backup solution.  Are people actually losing data?

If data is lost by the provider it can fuck up - but most can be recovered then using chkdsk - it just takes a long time when you have a lot stored

Link to comment
Share on other sites

  • 0
7 hours ago, fly said:

I'm confused and concerned.  I use CloudDrive to backup important client data for my business, as I assumed it was the perfect backup solution.  Are people actually losing data?

I mean, this assumption is faulty, and important data should never be trusted exclusively to a single backup solution--cloud or otherwise. There is no such thing as the perfect backup solution. There is a reason that the 3-2-1 backup rule exists. 3 copies, 2 different types of media, at least 1 offsite location. 

If you're relying exclusively on CloudDrive or any other storage solution as your only backup option, you're going to have a bad time. Google rolled back data and corrupted many CloudDrive volumes (we think), and they may do the same in the future. Google Drive is a consumer solution, after all. It is not intended to meet the needs of sensitive business data. CloudDrive is a remarkable product and takes a great number of steps to oversee the integrity of your data, but it can't work miracles. Cloud storage problems exist, and should not be relied upon exclusively. 

Using CloudDrive with an enterprise provider like Google Cloud Storage, Amazon S3, or Microsoft Azure should be the first step, at a minimum, to store sensitive and important business data. Not a consumer provider like Google Drive, which is where we saw corruption last month. Linux ISOs and media files are one thing, but I wouldn't even use CloudDrive with Google Drive to store copies of family photographs that I did not have another backup for. 

Link to comment
Share on other sites

  • 0
On 4/17/2019 at 5:44 PM, srcrist said:

I mean, this assumption is faulty, and important data should never be trusted exclusively to a single backup solution--cloud or otherwise. There is no such thing as the perfect backup solution. There is a reason that the 3-2-1 backup rule exists. 3 copies, 2 different types of media, at least 1 offsite location. 

If you're relying exclusively on CloudDrive or any other storage solution as your only backup option, you're going to have a bad time. Google rolled back data and corrupted many CloudDrive volumes (we think), and they may do the same in the future. Google Drive is a consumer solution, after all. It is not intended to meet the needs of sensitive business data. CloudDrive is a remarkable product and takes a great number of steps to oversee the integrity of your data, but it can't work miracles. Cloud storage problems exist, and should not be relied upon exclusively. 

Using CloudDrive with an enterprise provider like Google Cloud Storage, Amazon S3, or Microsoft Azure should be the first step, at a minimum, to store sensitive and important business data. Not a consumer provider like Google Drive, which is where we saw corruption last month. Linux ISOs and media files are one thing, but I wouldn't even use CloudDrive with Google Drive to store copies of family photographs that I did not have another backup for. 

This is all a good point.  Not sure why I didn't think of it before.  Thank you.

 

edit: Can I 'backup' the same data from the same CloudDrive to multiple storage providers?

Link to comment
Share on other sites

  • 0
4 hours ago, fly said:

edit: Can I 'backup' the same data from the same CloudDrive to multiple storage providers?

Sorta. But I think you might have it backwards. You wouldn't back up the data that sits on the provider to other providers, because the drive structure changes somewhat by provider. You would, instead, mount multiple providers with CloudDrive and use a tool like DrivePool to mirror the volumes to one another. 

Link to comment
Share on other sites

  • 0

Just to add my experience to the list -- I had this issue pop up yesterday (though I was out of town for a week, and friends were complaining my Plex server wasn't working...) and came across this thread while looking for solutions.  Running CHKDSK /F on the drive worked for me, then scanning with WinDirStat solved the issue of it taking a long time to open each folder for the first time (sounded like the same issue chrisde1982 was having).  In case it's relevant, I also performed the 4 steps suggested by Drashna a few times before running CHKDSK.

To add: I have both DrivePool and CloudDrive running, with DrivePool combining 2x 8 TB physical disks as a single 16 TB "LocalDrive" (X:\), which is then "pooled" with a 16 TB CloudDrive (Z:\) to create my main storage drive (D:\).  Then I have folder duplication turned on, so (I think...) anything on D:\ gets written to one physical disk (X:\) and to the CloudDrive (Z:\).  I noticed that the torrent files I had auto-downloaded with Sonarr were all stalling (hence my friends noticing my Plex server hadn't added new shows), and when I manually added one, it downloaded for about 10 seconds, then the speed fizzled to 0 b/s, and qbittorrent said it stalled.  Then I noticed I couldn't write files or folders to my D:\ drive, and then realized that my Z:\ drive wasn't actually working correctly.  A smart man probably would have figured it out more quickly, but I figured I'd post my process in case someone else googles a similar problem down the road. 

Thanks all!  It's always nice when you're troubleshooting and you don't have this "relevant xkcd" experience:

 Wisdom of the Ancients

Link to comment
Share on other sites

  • 0
On 5/16/2019 at 9:16 PM, Christopher (Drashna) said:

CHKDSK may do this, if the damage isn't too severe. 

Otherwise, it's disk recovery tools like Recuva or TestDisk. 

Nope. Chkdsk totally scrambled all my files into video142.mkv, so recovering 12TB is as good as useless. CHKDSK did more harm than good

Link to comment
Share on other sites

  • 0
On 5/18/2019 at 10:56 PM, Bowsa said:

Nope. Chkdsk totally scrambled all my files into video142.mkv, so recovering 12TB is as good as useless. CHKDSK did more harm than good

Chkdsk can never do more harm than good. If it recovered your files to a Lost.dir or the data is corrupted than the data was unrecoverable. Chkdsk restores your file system to stability, even at the cost of discarding corrupt data. Nothing can magically restore corrupt data to an uncorrupt state. The alternative, not using chkdsk, just means you would continue to corrupt additional data by working with an unhealthy volume.

Chkdsk may restore files depending on what is wrong with the volume, but it's never guaranteed. No tool can work miracles. If the volume is damaged enough, nothing can repair it from RAW to NTFS. You'll have to use file recovery or start over. 

Link to comment
Share on other sites

  • 0
22 hours ago, srcrist said:

Chkdsk can never do more harm than good. If it recovered your files to a Lost.dir or the data is corrupted than the data was unrecoverable. Chkdsk restores your file system to stability, even at the cost of discarding corrupt data. Nothing can magically restore corrupt data to an uncorrupt state. The alternative, not using chkdsk, just means you would continue to corrupt additional data by working with an unhealthy volume.

Chkdsk may restore files depending on what is wrong with the volume, but it's never guaranteed. No tool can work miracles. If the volume is damaged enough, nothing can repair it from RAW to NTFS. You'll have to use file recovery or start over. 

How does a Virtual Volume even get damaged? It makes no sense to me. I had the drive running normally, no power outages, and upload verification was on.

So why does StableBit connecting 200 times (user-rate limit exceeded) cause a drive to even become RAW in the first place, what's the point of Upload Verification? In some software it can still detect the drive as NTFS, but it still makes no sense. It's a virtual drive reliant on Chunks (that should be safe due to upload verification). I detached the drive, and mounted it again, and the Drive was still RAW.

How do chunks even become RAW in the first place, it's like mounting the drive on another computer and it being raw too.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...