Migrating RAID volumes

[Nazar78]

Such an offer! That's very kind of you.

I'm sure you know what you're doing, but it's my data at risk. So thanks, but no thanks. I'd rather take my time as it's my experience that rash decisions and data integrity go badly together.

I'll wait for Asustor to respond. It's not like I'm lacking any functionality as the existing raids are up and running.

Regards

No problem, one time offer No risk to the data as long as proper steps are taken i.e. not to remove the disks while the array is active or accidentally reinitialize the NAS.

I considered that, but still: The raid already running on the 6004 is created and maintained by the 5304, so it seems likely that it would be included.

Asustor have a weird way of maintaining the arrays. I have a RAID5 running in a 5 bay USB enclosure as volume2 connected my 5304, while this is not even supported by Asustor, a standard Linux distribution with mdadm wouldn't have issues automatically assembling the array.

[helgrimm]

Asustor have a weird way of maintaining the arrays. I have a RAID5 running in a 5 bay USB enclosure as volume2 connected my 5304, while this is not even supported by Asustor, a standard Linux distribution with mdadm wouldn't have issues automatically assembling the array.

It appears my idea of painstakingly copying via single disks won't work either. At one point or other in this process I will switch the system disk 1 in the 5304 and reinitialize the NAS, and that's the end of the line for my project.

Volumes created under a certain system disk will be recognized without a problem, others will have to be reinitialized as a new volume and that will wipe the data.

Of course I can get to run my 4x16TB drives as RAID 10 in the 6004U extension cabinet under my current system, but I'd be powering 6 or 8 disks instead of 4, and quite unnecessarily.

I'll report back what support has to say about this issue.

Regards

[Nazar78]

I share your predicament. I'm not sure about other brands but Asustor seems to bind together data volumes to the system within the single NAS itself. Meaning you, as an ordinary user, can't automatically recover your perfectly healthy data volumes if you were to change the system volume or i.e. in your case, such as putting the data volume/disks into an expansion unit. Take a look at my "rant", ehem, tips here https://forum.asustor.com/viewtopic.php?f=240&t=12860

No idea why they do it in such manner but as I've said earlier, with any standard distro it will allow you to have back your data. Like example, go boot your disks in Ubuntu with mdadm and you can immediately assemble the array then mount it to see your data. You can even boot live USB on the NAS then on-the-fly assemble back your data but not on ADM OS.

Noticed that, unlike previously, support took quite some time to get back to me, maybe they're overwhelmed but I hope all ends well with your ticket, good luck!

[helgrimm]

After reflecting a bit on the matter I still think I must be wrong. If I'm right, then a crashed system drive would render all the rest of the NAS volumes inaccessible - and there may be up to three 6004's in chain from the main NAS, so there might be many volumes. There must be more to the story?

I keep trying to access this search result snippet, but I can't get in there - it's from Asustor knowledge base and requires me to log in, and once I do, I see my own ticket and nothing else.

Here goes: "Knowledgebase - Support Center - ASUSTOR
If Volume 1 is inaccessible or hard disk crashes, user can still put in a new hard drive and then create the new volume 1. After creating the new volume 1, then he can access his folders or data in volume 2 or volume 3 or whatever volume. Step 1: remove t... "

Sounds like there's a way to access volumes even with a new system disk.

regards

[Nazar78]

I may be wrong but the KB vaguely states in its title, "Knowledgebase: NAS", not together with expansion unit. The KB was posted back in 2013 but the expansion units was first released I believe in 2017.

So to my understanding they meant volumes within the NAS itself and different unknown details about expansion units. E.g. for your case, your RAID0 volume got corrupted, you still can access the volume in your RAID1 on the NAS because Asustor mirrors its ADM OS across all its volumes in the 2nd partition of each disks even for a single disk volume.

With that said and what you've experienced, I don't think you can even load volumes from another NAS expansion units. I was about to get the expansion unit when I first got the NAS but with all that being unclear, I decided to go for an external enclosure which cost about 1/3 of the price because at least I'm sure I can load single disk as an external drive and now with some tinkering, any RAID outside Asustor's ecosystem because it's a Linux after all.

[helgrimm]

I may be wrong but the KB vaguely states in its title, "Knowledgebase: NAS", not together with expansion unit. The KB was posted back in 2013 but the expansion units was first released I believe in 2017.

You're right. Support answers:

Did you moved volume 1? if yes, volume1 has been created in the NAS. Volume 1 can't be used outside a NAS because volume1 is linked to md0 (the flash memory of your NAS). Volume 1 can be move in this NAS or in another ASUSTOR NAS but not in the unit of expansion.

A volume in the AS6004U is created by a NAS. So my advice is re-put volume1 in AS5304T, create another RAID in AS6004U and move your data from NAS to unit of expansion

My problem is I can't move a newly created raid volume from the expansion unit back in the 5304T, so it seems you were wise to avoid the expansion unit.

I never imagined it'd be so hard to move data as in my current situation. And I never had so much storage space with the promise of good data security and no way to utilize it.

Currently I have only one plausible idea left how to solve this problem:

1. Leave the 5304T running with the current "old" volumes (it already does) and take one of the four new 16TB disks and install it in my Windows PC as NTFS.
2. Copy all the data to this NTFS disk over the network from the current 5304 volumes (a total of about 10TB)
3. Install the resting 3 new disks in the 5304, initialize a new system and create a 3 disk RAID 5.
4. Copy all the data back onto this new volume from the Windows PC
5. Pull the NTFS volume and add it to the 5304 RAID 5 volume, change RAID to 10

Does that sound plausible? I'm especially pleased that if anything fails, I still have all data intact on the old volumes.

regards

[Nazar78]

Volume 1 can't be used outside a NAS because volume1 is linked to md0 (the flash memory of your NAS). Volume 1 can be move in this NAS or in another ASUSTOR NAS but not in the unit of expansion.

This only exists in the Asustor's realm lol, you're free to move your data anywhere if you break out of Asustor's ecosystem. This is one of the reason why some folks chose break the warranty and run alternative OS such as TrueNAS (previously known as FreeNAS) on their Asustor NAS. While I can do that, i.e. run Ubuntu Desktop permanently on my 5304, I'm still staying with Asustor's ADM because I like to challenge myself messing around with the original stuffs to fit my needs.

Does that sound plausible?

That will do but I'm afraid you'll not be able to migrate the RAID5 to RAID10. In this case to achieve RAID10 is to start fresh then copy over the data.

I'm especially pleased that if anything fails, I still have all data intact on the old volumes.

Asustor didn't offer to help you move your data remotely? My offer still stands, if you were to take a look at my profile (not specifically only on this forum), I do this remote thingy every now and then, selectively to those whom I think deserve my time. Assure you your data is perfectly safe as I'll verify every steps before commiting and you'll be able to see what's going on, which would only take few minutes need not rush. If you're still concern about the data integrity, we can do a dry run prior, now shutdown and remove the RAID0 and RAID1 from your 5304. Put in the 4x16TBs then create a RAID10, place some dummy data in the volume1/share, shutdown then swap back the disks to the RAID0 and RAID1, place the 4x16TBs into the 6004 then connect it to the 5304. We start the remote session and I'll present to you the dummy data in the 6004 accessed from the 5304. Then we can do the actual thing some other fine day.

Edited: Oh yeah your warranty, if any left, will still be intact because no permanent modification was made.

[Nazar78]

Here's my setup since 2019 when I got the 5304, 5 Bay USB3 enclosure with 1xSSD (running the ADM OS [volume0] and all my LXC Ubuntu Desktop, docker containers, chroot for Jellyfin/websites/webapps) and 4XHDD in RAID5 as volume2 secondary backup connected to USB port #1, USB port #2 is connected with a USB3 hub that holds my bluetooth dongle (gamepads and wireless keyboard for LXC Ubuntu Desktop on the TV), air remote, UPS and spare ports. All the disks are sleeping unless required except for the SSD.

Untitled.png (284.32 KiB) Viewed 3373 times

[helgrimm]

That will do but I'm afraid you'll not be able to migrate the RAID5 to RAID10. In this case to achieve RAID10 is to start fresh then copy over the data.

Your assistance is priceless. I went back and looked at it, and from my current understanding RAID5 would be able to migrate to RAID6. And RAID1 + RAID1 to RAID 10. Either of those should be viable with 4 disks at hand. Oh, plus a single disk should be able to migrate to 5,6,10.

Thanks again for your offer, I might take you up on it later. As I am already copying data according to the plan I described, I guess I'll have a go at doing it that way.

[helgrimm]

All the disks are sleeping unless required except for the SSD.

I actually turn it off at night as I'm not running a server - and because despite setting the shortest sleep interval on all disks and the shortest interval at entering S3, S3 doesn't happen. I haven't had time to investigate why, but I have/had an active webserver for educational purposes, Emby and Roon running. Anyway it draws a constant ~30 watts instead of entering S3 and that's just bad.

Nice setup!