NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
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.net...
jmmygoggle wrote:
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.
(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).
If the array and volume are in a good state the migration should work smoothly.
However if it is not, then it would not be advisable.
One option would be to clone the disks so that if the migration fails you have something to fall back onto.
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)?
I really appreciate the assistance.
jmmygoggle wrote:
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.
(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).
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.
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.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
