× NETGEAR will be terminating ReadyCLOUD service by July 1st, 2023. For more details click here.
Orbi WiFi 7 RBE973
Reply

Experiments with exporting and importing a volume in OS6.7.1+

Sandshark
Sensei

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 the same volume name as any already on the target NAS.  This seems to be designed for systems with multiple volumes, and I had one instance crash and burn when I did not disable XRAID before trying to import, so I do not recommend you try this without disabling XRAID before doing an export or import.  On a multi-volume system, XRAID would already be disabled.  And being an undocumented feature, you should have a backup of both systems and be prepared for the worst if needed -- factory default and rebuild everything. 

 

The problem I had when I forgot to disable XRAID (I'm pretty sure that's what caused it) was that the primary volume would no longer boot properly.  It gave the dreaded "management system is offline" problem.  The volume was still accesible via SMB, but I would not trust that it always would be.  I had to do a factory default on the primary array, but I could still add the exported one after that.  Again, I would not trust that will always be the case.  Note that I did an export and import several times with XRAID disabled and did not have an issue, so I think it is pretty reliable when used with XRAID disabled or else I would not be posting this.

 

A major issue if you have only one volume is that by default it is named data and you cannot import it to another device that already has a data volume.  So, if you plan on using this function, you need to work around that if you expect to move the primary array.  I know of no way to rename a volume before export.

 

The export works pretty much like you would expect.  You select the volume, select Export, confirm by typing EXPORT, and it does some stuff and the volume turns red.  You then remove the drives.

 

Import is also straight forward.  Keeping the same drive order, install the drives in empty bays of another unpowered NAS (this is what it means by "cold import") that has had XRAID disabled, and power up.  It takes a little longer to boot, and you now have your two volumes.  Or, you can install them as the first drives in a new system and they will become the primary volume.

 

If you had shares with the same names on the two volumes, only the one from the added volume will be visible.  But, you can rename the visible share and the other will become visible (I think I had to reboot).  I'm not sure what happens with home folders, I don't use them.  Though you can export the primary volume where the home folders reside, it's probably not intended for that.

 

The shares on the imported volume will have no sharing privilages at all.  The export appears to wipe them out (they are gone even if you import into the same system).  That makes sense because the new NAS may not have the same access protocols, users, and groups.  So, you have to set all that up again.

 

Now, if you are just moving the only volume from one NAS to another, this is not necessary.  You can move from a 2-bay to a 6-bay system by just moving the drives and everything will be retained.  Just make sure the new chassis is at the same OS revision as the old for the cleanest transfer.

 

And speaking of OS versions, it did not seem to make a difference that I moved the volume from a 6.7.1 to a 6.7.4 system.  But if the revision was more extensive, i don't know what would have happened.  It is unclear to me if the OS partitions on the moved drives were updated or not.

 

Now, this begs the question as to whether this could be used as an offsite backup system.  One primary array and two secondary ones that are swapped in and out.  Until we find out what happens with a major OS update, I would not trust it.  Same thing with using this to offload data from a completed project.  And it's probably undocumented for a reason -- it's not fully tested.  I'd stick with USB drives for now, even if slower.

Message 1 of 10
StephenB
Guru

Re: Experiments with exporting and importing a volume in OS6.7.1+


@Sandshark wrote:

... And it's probably undocumented for a reason -- it's not fully tested. 

 

Export's been there for years, though I think the statement about "cold import" is new.

 

I had trouble with it a long time ago when I tried to migrate a jbod volume from an RN102 to an RN202, and avoided it ever since.

 

I wish they'd either make it work, or remove it from the web ui.

Message 2 of 10
jak0lantash
Mentor

Re: Experiments with exporting and importing a volume in OS6.7.1+

I personally don't see the point of that feature. It's either completely useless or so niche its place in the GUI is questionable.

Message 3 of 10
StephenB
Guru

Re: Experiments with exporting and importing a volume in OS6.7.1+


@jak0lantash wrote:

I personally don't see the point of that feature. It's either completely useless or so niche its place in the GUI is questionable.


I do see some value - for instance if you have an EDA500 you might want to move it to a different NAS without data loss.  My use case was similar (wanting to shift a jbod volume to an RN202 without losing the data).

 

I agree that they either need to make it work or get rid of it.  Some people who've tried to use it have gotten stuck on the import step (losing access to their data).

Message 4 of 10
jak0lantash
Mentor

Re: Experiments with exporting and importing a volume in OS6.7.1+

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.
Message 5 of 10
Sandshark
Sensei

Re: Experiments with exporting and importing a volume in OS6.7.1+

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.

Message 6 of 10
Sandshark
Sensei

Re: Experiments with exporting and importing a volume in OS6.7.1+

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. 

Message 7 of 10
jak0lantash
Mentor

Re: Experiments with exporting and importing a volume in OS6.7.1+

I'm pretty sure there are also entries in various config files (like Samba.conf.admin) that would contain the old volume name, and maybe in the management database. That's why it's not supported, and usually create issues, to restore a config file with another volume name.
Message 8 of 10
Sandshark
Sensei

Re: Experiments with exporting and importing a volume in OS6.7.1+

Yeah, it turns out that at some point the NAS lost track of what was where.  Those commands work for a pure Linux system, but not necessarilly a NAS with it's UI.  I didn't go deep enough in most of the time to see it happened.  If you want to move drives to another NAS temporarilly to copy files via SSH commands, it'll work just fine.  But if you plan to keep the volume intact, it looks like there are too many things that can go wrong.

Message 9 of 10
Sandshark
Sensei

Re: Experiments with exporting and importing a volume in OS6.7.1+

OK, so I checked out exporting and importing a JBOD volume of twi drives in a system with one other JBOD, one RAID0, and one RAID5.  It exported fine and I removed the drives.  I rebooted and all was fine (without the removed volume, of course) and powered down.  Then I re-installed the removed drives in a different set of slots and powered on.  It re-imported the volume just fine.  Maybe not the best of tests since it was all on the one NAS, but I'm preping the other for real data.

Message 10 of 10
Top Contributors
Discussion stats
  • 9 replies
  • 3314 views
  • 0 kudos
  • 3 in conversation
Announcements