Old disk pack & new firmware, same box.

Forum History Drobo
#1

I have an older Drobo II (2nd generation FW 800 & USB) that had a disk pack, about 3/4 full (edit:2011.09.18 actually about 1tb), and I backed up the data and pulled the pack out.

I now need some data from that pack, but just realized that the Drobo has been updated to newer firmware since the original pack was removed. Forgot the original firmware, but it was at least 12 or more months ago.

Is it safe to mount that older pack in the SAME BOX with the newer firmware??? or do I run the risk of turning the pack to ‘raw’. If not compatible with the new firmware, HOW DO I RETRIEVE MY DATA??

TIA,

-= Chris =-[hr]
BTW, anticipating the answer, ‘use your backup’. The back up contains all the raw NEF files (Nikon raw format), but none of the PSD modifications (Photoshop working files), hence I need to retrieve what I did to several RAW Nikon files in the form of PSD files.

So, yes, my digital negatives are safe, but my final ‘digital print’ is on the disk pack.

#2

yes the new firmware will upgrade your disk pack (if you think about it - when you upgrade the firmware in your drobo - on its first boot it has an old diskpack in it).

however the upgrade is one way - once you have used your diskpack with your new firmware - you will no longer to able to use that disk pack with an older firmware.

#3

Hi DocChris… YES, but will my data still be there? What is effectively upgraded?

Are there any changes to the FAT? Or is the firmware only addressing timing issues, sleep mode issues, I/O issues, redundancy, remap …

The question remains, will the data still be there and INTACT.

I would hate to boot up with the old pac in, and find out it is RAW!

TIA

#4

The diskpack will update when you put the old diskpack in.
Your data will still be there.

#5

Thanks Jennifer, I guess even if 2-3 or even 4 firmware updates have taken place, the track layout and the FAT should be the same.

Fingers crossed, I may do a peek at the pack for the needed files.

-= Chris =-

#6

Are you really using FAT on your Drobo or just using this as a generalized term for filesystem metadata? If the former, I would worry about this in the first place and not about the firmware upgrade deleting your data.

#7

equifoto - as i said previously - what you are doing is exactly what would happen if you had your old diskpack in your old drobo and then upgraded the firmware with the diskpack in - it would update drobo, then on reboot drobo would upgrade the diskpack.

#8

Sorry, I used the term FAT generically. It is an NTFS Format. But I have no idea how Drobo translates the data from the computer to its native FAT. Hence I formatted the drive NTFS, or so I told it to, now the Drobo’s proprietary FAT (File Allocation Table) does it’s own think.

I have seen instances with directories that are OK, but on directory (eg [temp]) had persistent double entries displayed. Hence, copy one file to any directory but [temp] and the entry is correct. Copy any one file to [temp] and it shows up as TWO files - same name, same bytes, same dates, etc. Then deleted ONE of the duplicate files, and both disappear.

So the issue here is, when the firmware is upgraded, there could be changes to the Drobo’s internal FAT.

#9

drobo maps blocks - its not quite the same thing

double entries indicate a corruption with the actual filesystem you have formatted it to. (so run chkdsk on it)

yes there are changes to the mapping system (or at least there may be) which is why you cant put a newer diskpack into an old firmware drobo.

obviously new firmwares can recognise old disk packs and upgrade them (otherwise you would have to format your drobo everytime you updates the firmware on it!)
i hope that makes everything a lot clearer.

#10

This weekend I simulated a recovery with:

iCare v3.7.1 which the author claimed it would work… Got 33 files with format recover, out of over 1000+. The estimated time was 211 hours, the drive disconned about 11 hours into the reovery and hung the recovery, so i have no idea what it found. Had to reboot. Only then was the Drobo visible again.

Easeus v5.0.1 - Tried the deep recover, claimed needed 26+ hours. Recovered 44 files, but drive disconnected ALSO about 11 hours into the run, with the recovery locked up… same issue, had to reboot, so I have NO idea what it found.

Set Up -
ASUS P5Q Q9550 (Not overclocked)
4gig Mem
Vista Home 64
FireWire 800 card Dynex DX-PC12PF
Unibrain v5.70 Drivers

Drobo test config -
2 WD Green 1tb drives
Formatted NTFS as 8 gig
Dashboard v1.7.2 as I also have an FS on the Net.

Chassis connected to an APC BackUPS, and Drobo connected to ANOTHER BackUPS. Both UPS are heavy duty 1000+ units with fresh batteries.

Appears to work normally under normal use, which I used to load the initial 1000+ files, then formated the drive.

NOW, interestingly, when doing the format command, on a file populated drive, there is NO SAFETY for the quick fingered, like having to type: FORMAT, or YES, or any such ‘thinking’ action words. Even Quicken, when doing a major delete or repair, forces you to type something special AFTER the warning, as an “Are YOU Sure!!”. Furthermore, tab with the FS and the Firewire connection are not clearly differentiated, yes, there is an FS logo, but a colored tab for Droboshare or FS Drobos would be nice.

So Question: WHy would the Drobo disconnect after ~11 hours?
Any help on this. It’s been quite a while, and I still need to

#11

What Dashboard version are you running? I wonder if you’re running an old one? I’m pretty sure last time I reformatted, Dashboard made me confirm before it proceeded.

Why would Drobo disconnect after ~11 hours? Not sure… But I’m not sure it even disconnected, rather than simply being tied up. Thin Provisioning allows the OS to request blocks that don’t technically exist. Under normal use this isn’t a problem. But when you run a disk repair utility that tries to test/recover bad block, this can be an issue, since a request to a “phantom” block may look like a bad block, and if the software then tries to remap/rewrite that block, it never succeeds because the block always comes back as whatever Drobo returns for non-existent blocks (zero? some other garbage data??).

Just as an aside here, unless both BackUPS units are on the same outlet, you should consider putting the computer and Drobo on the same unit. That way you avoid any voltages induced on the signal cables due to ground differential. I’ve seen issues where pieces of equipment (and computers) got damaged when connected because ground on one side did not equal ground on the other side and caused a voltage spike. An older generation run of Macs connected to Firewire devices were notorious for this…

#12

Hi bhiga… It’s stated that its version 1.7.2 [1.7.29352], I did not mention this, but the firmware on the Drobo 2 is 1.3.6.

I can appreciate the issue the recovery may have when faced with a non existent block… I’ll contact the software vendors… (FWIW, they all claim yes, but a couple when questioned further, admitted that their answer was, what I would call generic, with no first hand experience, yet the developer freely gave out information leading to believe it was tested on a Drobo (shades of our fine media).

Yes, both UPS are on the same outlet and circuit… but you are absolutely right. I’ll just place both units - Computer & Drobo, on the same UPS… Thanks for the reminder.

Next step is to contact the vendor. I forgot to mention that I also tried Data Rescue PC3 v3.1 Demo, and it too hung up - no idea when however. I’ll call John at Prosoft.

Thank you for your help and support.

-= Chris =-

#13

I’m Back!!! Now with two Drobo II, one S and one FS.

RECAP of original issue:

1] Drobo v2 on a Droboshare network, Drobo v2 on USB2. Accidentally formated the network Drobo, instead of the USB unit!
2] Both were fully populated with 1tb drives (D’shared had Deskstars, the D’USB’ed had WD Greens)
3] Droboshare unit was NTFS, and got reformated (took about 15-30 seconds!), also using NTFS. About 850mb-1tb max of photo files on the D’shared unit.
4] Immediately AFTER the accidental format, the unit was shut down in an orderly manner, the drives were taken out, and cocooned ever since.
5] All simulation done with new drive and new data… recovery to no avail so far. But never got around to testing the read only feature…

I since cleaned up my data from backups, got ~90% back from external USB drive back-ups, but STILL MISSIN the ~10% -AND- that 10% represents nearly 100% PSD work files. This is ‘art’ stuff, so there was no commercial rush… but but a lot of time and effort went into the PS editing/layering.

Now… I got some spare time, and would like to work with the original data off ‘cloned’ disks on a ‘read only’ Drobo v2 (which have since been upgraded to the latest firmware).

Question:
1] Now that more services are doing recovery, several mention making a ‘Clone’ of the problem drives, and using the cloned drive to do the recovery so as not to damage the original drive’s data. OK, so questions:

  • My original drives are 4 Deskstars 1tb drives from the D’shared v2.

Can I use any other 1tb drive to clone the drive, or must they be identical Deskstars?
Does the Drobo check the harware s/n of the drive? If that is the case, I do not see how the services claim they use a cloned drive for the recovery… if the Drobo uses a code on the platter, then I can imagine ANY 1tb drive could be used to clone the original. I would venture to guess this is the case, as I read you can move a pack to another Drobo, and not necessarily put them back in the same order.

So… Any hint from ACTUAL experience? I use Acronis True Image as my backup software, and they have a clone feature. Any suggestion on a better cloning program??

TIA…

-= Chris =-
Skype: christian.baude

#14

I’m Back!!! Now with two Drobo v2, one S and one FS.

RECAP of original issue:

1] Drobo v2 on a Droboshare network, Drobo v2 on USB2. Accidentally formated the network Drobo, instead of the USB unit!
2] Both were fully populated with 1tb drives (D’shared had Deskstars, the D’USB’ed had WD Greens)
3] Droboshare unit was NTFS, and got reformated (took about 15-30 seconds!), also using NTFS. About 850mb-1tb max of photo files on the D’shared unit.
4] Immediately AFTER the accidental format, the unit was shut down in an orderly manner, the drives were taken out, and cocooned ever since.
5] All simulation done with new drive and new data… recovery to no avail so far. But never got around to testing the read only feature…

I since cleaned up my data from backups, got ~90% back from external USB drive back-ups, but STILL MISSIN the ~10% -AND- that 10% represents nearly 100% PSD work files. This is ‘art’ stuff, so there was no commercial rush… but but a lot of time and effort went into the PS editing/layering.

Now… I got some spare time, and would like to work with the original data off ‘cloned’ disks on a ‘read only’ Drobo v2 (which have since been upgraded to the latest firmware).

Question:
1] Now that more services are doing recovery, several mention making a ‘Clone’ of the problem drives, and using the cloned drive to do the recovery so as not to damage the original drive’s data. OK, so questions:

  • My original drives are 4 Deskstars 1tb drives from the D’shared v2.

Can I use any other 1tb drive to clone the drive, or must they be identical Deskstars?
Does the Drobo check the harware s/n of the drive? If that is the case, I do not see how the services claim they use a cloned drive for the recovery… if the Drobo uses a code on the platter, then I can imagine ANY 1tb drive could be used to clone the original. I would venture to guess this is the case, as I read you can move a pack to another Drobo, and not necessarily put them back in the same order.

So… Any hint from ACTUAL experience? I use Acronis True Image as my backup software, and they have a clone feature. Any suggestion on a better cloning program??

TIA…

-= Chris =-
Skype: christian.baude