4TB of data corruppoted - thanks drobo!

That’s unfortunate.
Though I suppose we’re both using volumes larger than 2TB, which is outside of the scope of their beta.

I did speak with Data Robotics support and I was rather disappointed with the fact that I offered twice to give them my diagnostic file, and they didn’t want it. I even stated I’d like to file a bug report. Even if it is “beta” I’d expect they would at least welcome the chance to get more real world data to improve the product.

On the plus side, I did manage to recover my data.
It seems from an earlier post that you already did try something similar, but I figured I’d post anyway, in case anyone else needs ideas.
I used TestDisk (http://www.cgsecurity.org/wiki/TestDisk) to locate backup superblocks, and used the first one it found in a “fsck.ext3 -y -b -B 4096 /dev/”. That placed all my files in the lost+found directory.
I’ve rebooted my PC and Drobo a few times now and things seem ok.

rocky, how soon after your recovery did it become corrupt again?

First a day or two, then slowly it started occurring sooner and sooner. Eventually corrupting immediately after fsck’ing.

I have a 1.3.1 firmware if you need it.

Another way to find your backup superblocks is to rerun the drobom format command, which will generate a script /tmp/fmtscript containing a line like “mke2fs -j -i 262144 -L Drobo01 -m 0 -O sparse_super,^resize_inode /dev/sde1”

If you run that command with the -n flag it will tell you where they should be. IE mke2fs -n -j -i 262144 -L Drobo01 -m 0 -O sparse_super,^resize_inode /dev/sde1

I’m jumping in here because I need to figure out a solution to get to my data on the Drobo disk pack outside of the Drobo.

Since the Drobo refuses to boot after updating to the 1.3.5 firmware (I am directly laying blame on this version of firmware).

My approach now seems to be the following:

  1. Pull the drives out of the Drobo and mount them in a standard Linux system
  2. Image them for backup purposes
  3. Destroy the Drobo “disk pack header” information from the drives
  4. Downgrade the physical Drobo to 1.3.1 (a stable, working firmware revision)
  5. Plug in the disk pack and let Drobo “upgrade” that to the current version in the Drobo (1.3.1)

The real question is: Can I downgrade/remove the disk pack version header in the disk pack, without destroying the volume itself?

It would seem that DRI must have tools to do this to test rolling forward and back between their various firmware versions to test them. Heck, if there was a tool that I could use to force a specific firmware version header to the disk pack, that would help.

Has anyone attempted this? I may be in uncharted territory here, but based on the number of posts coming up from people having trouble with 1.3.5, I suspect I’m not going to be the only one.

I recommend responders to hacker’s query do so in his other thread, to avoid confusion.