Mounting ReadyNAS drives in a virtual NAS for data access and recovery
In a previous post (Mounting-ReadyNAS-drives-in-a-virtual-NAS-for-data-access-and-recovery ), I discussed using a VirtualBox virtual ReadyNAS for recovering data from a failed ReadyNAS. With no new ReadyNAS being sold, the usefulness of this is going to increase. I'm not going to cover everything again here since you can go read the original post, but I essentially go over how to set up a VirtualBox ReadyNAS VM and get it to recognize drives that came from a real ReadyNAS so as to recover data from them. I included both OS4.2.x and OS6 information. That covers all OS6 units with no more than 6 drives (since the Intel based VM can use ARM-based ones, just as a real NAS can) and OS4.2.x on legacy units.
Another user ran into some issues, which I will cover as needed, but I also want to add some things.
For OS4.1.x and 5.x, there is no ReadyNAS virtual machine to use. But that doesn't mean you can't still use a VM. You just have to use a generic Linux VM and recovery methods that @StephenB has posted. You can then either attach the real drives to your PC and make them accessible to a VM, or you can create images of the drives and attach those. The advantage of using images are that you can't do any more harm to the volumes if it has a non-hardware related issue and that you don't need to have a way to attach all the drives at the same time. Of course, if you have 6 10TB drives, finding a space for all those images is going to be tough. But for smaller drives, it's not that hard. For my experiments, I stored them on a NAS (in my case, a ReadyNAS, but any NAS will work). I do want to emphasize again that the maximum number of drives for the VM is six, and one is taken up by the "boot flash". So that means your volume must be recoverable from no more than 5 drives (so 5 from a 6-drive RAID5 will work, the volume will just be non-redundant).
The command for attaching the real drives to a VM has changed since my original post. The new format is as follows:
VBoxManage.exe createmedium disk --filename "C:\Path\To\VM\NASDisk2.vmdk" --format=VMDK --variant RawDisk --property RawDrive=\\.\PHYSICALDRIVE#
The # above is replaced by the drive number shown in Windows Disk Management, and you can choose format=vdi if you so choose and an appropriate location/name. The quotes aren't necessary unless there is a space in the name, but I've included them.
As above, replace # with the drive number and you can use format=vdi and any appropriate file name.
One additional thing I did this go around with my experiments is to include an iSCSI share, and that works great with a ReadyNAS VM. I'm afraid I don't know how to deal with one in a generic Linux environment, but perhaps somebody who does will add that here.
The other issue that the other user found is that the VM source seems to be corrupt. They were also not up to date on the OS version number. So, I have created new .ova files and put them on my Google drive. These are complete VM's, including one NAS drive which you must disconnect before attaching the real NAS drives or images. But it allows you to make sure the VM is working before you try to use it for recovery. The OS 4.2.31 one does have the TLS V1.1 add-on included. The admin/root password for both is password.
Something to be aware of is that you cannot access the 4.2.31 machine via the VBox console. Console output is not enabled in OS4.x. So, you still have to use SSH (or Telnet in Tech Support mode) if you need to do something via the Linux command prompt. The OS6 VM can be accessed via the VBox console in either mode. Tech Support access is still uer root and password infr8ntdebug.
I have not tested how many drives you can have in Tech Support mode. I assume you can have at least as many as in normal mode. Since you, not the OS, is mounting the volume in Tech Support mode, maybe it will support more.
Note that I have done everything on a Windows machine, these VM's should work in VirtualBox for any Intel platform OS. I cannot say how they will work in any other VM. The vboxmanage commands will have different syntax under other OS's, so you'll have to Google them.
If you have general information to add (like maybe pointing to a Linux VM with all the necessary tools installed for ReadyNAS recovery, including how to recover an iSCSI share from it), please do so here. If you have issues specific to you, please start a new thread.
Re: Mounting ReadyNAS drives in a virtual NAS for data access and recovery
FWIW, I have an older version of VMWare Workstation (V 15.5.7). I had no issues importing the OS6 image and creating the VM. I was able to add additional virtual drives too. The "fixes" for the apps work OK too. Overall, looks good and seem to work just fine.
I had issues with the ReadyNAS_RAIDiator_Recovery.OVA. VMWare complained the image did not pass OVF specification conformance (image posted below). When I clicked "retry", it created the VM and booted. Raidar was able to find it. When I went to the admin page and logged in, the ReadyNAS window appeared but was blank (image posted below). I didn't mess around it further.
Not a big deal, it worked just fine in VirtualBox. Just wanted to let everyone know.
Re: Mounting ReadyNAS drives in a virtual NAS for data access and recovery
When you booted with the recovery "flash", did RAIDar show the unit is in recovery mode? You don't use the GUI in recovery mode, you use Telnet to get into the Linux command prompt, just as on a real NAS. I'm surprised you even get a GUI in that mode, but maybe it's just from locally cached data.
Re: Mounting ReadyNAS drives in a virtual NAS for data access and recovery
No, it showed as Healthy just like it did on VirtualBox. The VB machine then logged in fine to the Admin Gui. Once in, I just cruised around, clicked on a few items to ensure the dialogs came up, but didn't really configure anything.
I assumed (risky!) that it would behave the same way under VMWare as it does in VirtualBox. The OS6 image did.
I was able to use Putty to SSH into the VMWare image. I only ran ifconfig to verify the IP Address. So the absence of the Admin GUI may not matter for this purpose.
