This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
Migrate dead nv+ v1 sparc 3.01c1-p6 disks to working nv+ v1 sparc 4.1.14
I've read through as many postings related to my particular situation but I'm hoping for a bit more clarity that these articles didn't provide. Notably, regarding step 2 from this page: http://kb.netgear.com/app/answers/detail/a_id/21404
Does the recommended update to the latest RAIDiator release occur after I have powered on the unit, through the FrontView web browser interface (The disks being advanced to the latest version on the device itself during this upgrade)?
Or is the boot menu OS reinstall option necessary to transition the disks successfully to the new device (The disks needing to match the device RAIDiator before they can be used/accessed)?
I'm a little confused about the difference between the OS and the firmware as well as compatibility or matches needed between the disk(s) and the device at different points in the boot-up, upgrade and restart.
My hope is that posts I've read that mention "NAS will attempt to overinstall the firmware in its flash" indicate a desirable outcome with 3.01 disks moved to a 4.1.14 device. Perhaps this happens by default on the first boot and neither of the two things I've mentioned above actually need to occur.
Because of the extreme age difference between the two RAIDiator versions and the lack of a recent backup have made me a little hesitant to try anything without more information. I've also read about upgrades that have gone poorly or something unexpected happening and don't want to make a mistake.
Other details:
I had been having problems formatting a usb backup drive for my ReadyNAS to a usable ext3 volume either via the ReadyNAS itself or another linux system. Before I succeeded, a long term power outage occurred and the device would not power up.
I have since purchased another used ReadyNAS nv+ v1 system online, and have booted it up and formatted it with a spare drive verifying the existing RAIDiator version as 4.1.14 and a healthy system but not upgrading it further.
Hopefully I have a good chance to successfully reinstate the drives from the old device into the new device with a little guidance. Any details on potential complications and how to address them would be appreciated, especially details around migrating disks of 3.01 RAIDiator version to a 4.1.14 RAIDiator device.
If there are additional dangers in upgrading any software before making a backup once the device and drives are in a minimal usable state of some sort, I'd appreciate a heads up.
Which of these three scenarios best explain the migration process that "should work smoothly" if the arrays/volumes are in a good state? (If none, please describe the scenario.)
1. Turn on device, it automatically boots and NAS will attempt to overinstall the firmware in its flash onto the disk, upgrading it, with no additional steps necessary.
2. Turn on device, it boots and a manual upgrade step is activated through some aspect of the Frontview web interface menu in order, and then a reboot happens for the disks to match the device and put the disks in a usable state.
3. Turn on device, activate the boot menu and activate the OS reinstall option which upgrades the disks (either before or following a reboot) and puts the disks into a usable state.
(1).
One nuance - the OS is maintained on all the disks (and therefore is updated on all the disks).
Clone questions:
Should I clone more than one drive? (All or more than one of 3 total 500GB drives?)
If you're going to clone, then clone them all. Label the drives by their original slots also.
Given Macbook and OS X 10.9.5, is a scenario like this a good method for cloning?
Or should I drag out an older desktop and Knoppix distro and attempt the same or something else?
I'm not a Mac user, but I think it looks ok. Any sector-by-sector cloning package will work, especially if the disks have no errors.
Is cloning only possible before a migration attempt?
Is there something about my particular OS/firmware version discrepancy in this case that makes a migration attempt particularly dangerous for the existing data, requiring the clone backup(s)?
The risk I see is that the OS reinstall might fail in a way that compromises the volume. 3.01c1-p6 is 9 year old firmware. Volumes created in 4.1.14 have somewhat different characteristics (a different blocksize and 4K sector alignment). It should be compatible, but it is a bit like upgrading a windows XP system.
Cloning before migrating ensures that if something were to go wrong in the migration you'd have other options to get your data (including engaging a recovery service).
Re: Migrate dead nv+ v1 sparc 3.01c1-p6 disks to working nv+ v1 sparc 4.1.14
I don't have any reason to believe that the array and volume are in a bad state, due to other previous long-term power outages and UPS auto shut-downs that later resulted in succesful power-up that brought the arrays/volume back up just fine.
But clearly, I did not power down the unit before being unable to restart it, so there is some doubt which makes the clone suggestion seem wise and potentially useful.
Migration question:
Which of these three scenarios best explain the migration process that "should work smoothly" if the arrays/volumes are in a good state? (If none, please describe the scenario.)
1. Turn on device, it automatically boots and NAS will attempt to overinstall the firmware in its flash onto the disk, upgrading it, with no additional steps necessary.
2. Turn on device, it boots and a manual upgrade step is activated through some aspect of the Frontview web interface menu in order, and then a reboot happens for the disks to match the device and put the disks in a usable state.
3. Turn on device, activate the boot menu and activate the OS reinstall option which upgrades the disks (either before or following a reboot) and puts the disks into a usable state.
Clone questions:
Should I clone more than one drive? (All or more than one of 3 total 500GB drives?)
Given Macbook and OS X 10.9.5, is a scenario like this a good method for cloning?
Or should I drag out an older desktop and Knoppix distro and attempt the same or something else?
Is cloning only possible before a migration attempt?
Is there something about my particular OS/firmware version discrepancy in this case that makes a migration attempt particularly dangerous for the existing data, requiring the clone backup(s)?
Which of these three scenarios best explain the migration process that "should work smoothly" if the arrays/volumes are in a good state? (If none, please describe the scenario.)
1. Turn on device, it automatically boots and NAS will attempt to overinstall the firmware in its flash onto the disk, upgrading it, with no additional steps necessary.
2. Turn on device, it boots and a manual upgrade step is activated through some aspect of the Frontview web interface menu in order, and then a reboot happens for the disks to match the device and put the disks in a usable state.
3. Turn on device, activate the boot menu and activate the OS reinstall option which upgrades the disks (either before or following a reboot) and puts the disks into a usable state.
(1).
One nuance - the OS is maintained on all the disks (and therefore is updated on all the disks).
Clone questions:
Should I clone more than one drive? (All or more than one of 3 total 500GB drives?)
If you're going to clone, then clone them all. Label the drives by their original slots also.
Given Macbook and OS X 10.9.5, is a scenario like this a good method for cloning?
Or should I drag out an older desktop and Knoppix distro and attempt the same or something else?
I'm not a Mac user, but I think it looks ok. Any sector-by-sector cloning package will work, especially if the disks have no errors.
Is cloning only possible before a migration attempt?
Is there something about my particular OS/firmware version discrepancy in this case that makes a migration attempt particularly dangerous for the existing data, requiring the clone backup(s)?
The risk I see is that the OS reinstall might fail in a way that compromises the volume. 3.01c1-p6 is 9 year old firmware. Volumes created in 4.1.14 have somewhat different characteristics (a different blocksize and 4K sector alignment). It should be compatible, but it is a bit like upgrading a windows XP system.
Cloning before migrating ensures that if something were to go wrong in the migration you'd have other options to get your data (including engaging a recovery service).
Re: Migrate dead nv+ v1 sparc 3.01c1-p6 disks to working nv+ v1 sparc 4.1.14
I'll have to set aside some time in the next few weeks to complete this process, given the need to clone onto the 3 spare Western Digital RE4 WD1003FBYX that came with the replacement unit.
Are there any last concerns because I will be cloning from 500GB drives to 1TB drives?
Both source and destination drives are on the hardware compatibility list for my legacy model and I've tried to confirm that I'll be within the size limits of the device and the ancient RAIDiator 3.x OS/firmware - and the newer 4.1.14 version, but I'm not 100% certain.
Thanks for all the answers up to now. I'll follow up once I make some progress.
Re: Migrate dead nv+ v1 sparc 3.01c1-p6 disks to working nv+ v1 sparc 4.1.14
RAIDiator 3.x was limited to 2TB volumes. I think cloning onto 1TB disks should be fine.
If it all comes up fine I would suggest you backup your data, verify your backup is good, do a factory default (wipes all data, settings, everything) and restore your data from backup.
