NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Experiments with exporting and importing a volume in OS6.7.1+
I'm not sure when it got added, but OS6.7.1 and above have an "Export" function for an array. When you select it, it tells you that it's for "cold import" to another ReadyNAS and that it cannot have...
I never tested merging two ReasyNAS into one (taking the disks from one and adding them to another). I don't know how it would behave with md0. Apart from that, I'd assume it would simply show a second volume. If it doesn't, it should. I don't think "exporting" should be necessary. Also for business continuity.
I'll try experiment with a VM.
I'll try experiment with a VM.
Yes, it shows up as a different volume. If you don't export first, the NAS complains that the unused volume needs to be deleted. It must mark the volume as "importable" in some way.
It does make me wonder, though, if something in this process is not also responsible for the unusual number of "remove unused volume" errors reported by users who update their OS, have a failed expension, etc.
I have not tried it on a JBOD volume. Will try to make some time to try it. I have done it on RAID1 and RAID5,
This does have more applicability for a NAS with an EDA500 or a system with lots of bays where you may want more than one volume (like a 12-bay rack mount system).
I look at it this way: Have a backup in case it blows up on you. But if it works, it's a much faster way to transfer data from one NAS to another than over the network or backup and restore. I'm moving backup volumes from two legacy 6-bay units to one 4200 (all upgraded to OS6) and plan to go this route.
BTW, I did find a way to successfully rename a volume via SSH. It worked for me more than once, but I make no guarantees it will for you.
- btrfs filesystem show - this will list the volumes. Assuming default volume data, one will have a random 8-digit hex number (at least I think it's random) followed by :data.
- btrfs filesystem label /data 12345678:data1 - assumes default volume data, random hex value from above is 12345678, and renaming to data1.
- btrfs filesystem show - make sure the relabeling "took". Double-check the hex value.
- vi /etc/fstab - or use nano or your favorite editor you've installed to change the line that includes data to data1 (in two places)
- cat /etc/fstab - check your editing.
- Reboot.
If you get the dreaded "Management system is offline" in RAIDar, then SSH back in and verify btrfs filesystem show and cat /etc/fstab agree on volumes (except root is not listed in fstab). Make sure there isn't still an entry for the old data volume in fstab. Relabel again and/or re-edit fstab it if there are any discrepancies. I did this process a few times, and one time I ended up still having the old volume along with the new one in fstab and it gave me that error. I intentionally made the label and fstab not match and also got the error, but then verified that it's recoverable by fixing the error after the reboot and rebooting again.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
