Migration sanity check - 2 bay to 4 bay, SHR where new drives are larger

[abbynormal]

I'm currently in the process of migrating and want a sanity check against my procedure.

Currently running 2x12TB SHR on DS218+. I have purchased DS923+ along with 2x16TB drives to add. I don't use any additional services on the NAS expect for the shared filesystem itself and user/group structure. I found this post which seems to indicate my path forward should be the following:

1. Deploy DS923+ with 2x16TB in SHR
2. Use migration tool to move data from DS218+(2x12TB) to the SHR on the DS923+
3. Reformat the 2x12TB drives and add them to a secondary SHR pool on the DS923+
4. Move traffic from 2x16TB SHR pool to the 2x12TB SHR pool (given SHR expansion requirements of being equal/larger to largest disk in the pool)
5. Reformat 2x16TB drives, and then add them to 2x12TB SHR pool

One thing I want to confirm... the SHR calculator shows that 2x16TB + 2x12TB should provide 40TB usable, with 16TB redundancy. Does this have any correlation to the sequence in which disks are added? IE if I start off with 2x12TB and then add the additional 2x16TB, I will still end with 40TB useable?

Secondly, for step 4 above. What specific process should I use to copy locally from one SHR pool to the other pool? Is there a method I can use to have a one to one mapping with all user/group association to the directories retained?

 

[Telos]

Seems like a lot of effort. Why not...

1. Move 12 TB drives directly to the DS923+. Allow any minor migration steps to complete.
2. Add the 16 TB drives to the existing DS923+ pool/volume. Done.

Pool = 36.37 TiB.

 

[abbynormal]

Seems like a lot of effort. Why not...

1. Move 12 TB drives directly to the DS923+. Allow any minor migration steps to complete.
2. Add the 16 TB drives to the existing DS923+ pool/volume. Done.

Pool = 36.37 TiB.

Thanks for the suggestion! I actually ran across the method you mentioned last night, after I had already started step 1 of the migration process (which is still ongoing). It certainly seems a lot more instant as there's no need for any kind of data file transfer. I thought about cancelling it and going that route, but I wasn't sure how validated the process was. With my current methodology, I'm able to validate health of data at every step with a backup of said data before proceeding. IE:

1. Migrate to new SHR/NAS (data exists and can be validated on both devices before nuking old SHR/disks)
2. Move data to secondary SHR on new NAS (data can be validated on both SHRs on the new NAS before, before nuking 2x16TB SHR)

While the method you purpose seems extremally simple, it also seems a bit scary as I'm more or less just cold swapping drives in the hope that SHR is retained with no issue.

Is this concern warranted or is this process known to be pretty reliable? I'm also going from DSM 6.2.4 on the old NAS, with the new NAS ruining 7.2. I think creating a backup file and restoring it on the new NAS should be okay here, if my research is correct. But again I have seen mentions of mismatching code versions leading to issues. Do I have the option to revert these drives back to the old NAS without issue? IE what does the provisioning look like if I attempt (and fail) to add SHR to the new NAS. Is there anything added to the new SHR attempt that would prevent me from placing the drives back into the old NAS and using it's known config/SHR?

 

[Fortran]

You should make a backup of your data before you proceed no matter which route you take. If you dont already have a backup, buy an external HDD caddy and make a backup to one of the new 16TB drives.

Then, you're always covered at every stage of the migration, and you're free to follow @Telos' method which is much more straightforward and less error-prone.

 

[abbynormal]

Fair enough. I have a cloud backup of the data but placing myself in a situation where I need to restore from such is about the least desirable outcome, only second to completely loosing the data. But you're right, I do have a USB mount for HDD so can just make a backup in that manner on the 16TB. Will go this route then, thanks!

 

[Fortran]

I have a cloud backup of the data but placing myself in a situation where I need to restore from such is about the least desirable outcome, only second to completely loosing the data.

Agreed; you definitely don't want to be restoring <=12TB from the cloud. But copying it over USB3 from an ext HDD to a newly formatted 4 drive SHR volume - ie, should the absolute worst case scenario occur - is not too onerous.