Backup your raid1 data if you haven’t and open a ticket with support.
On Qnaps, the only raid1’s I use are all on M.2’s for ‘system’ pool and on hero systems for ZILwriteLog, but numerous times on raid6’s and a couple times on raid5’s I’ve done the ‘occasionally drop in larger disks as budget allows until last member disk has been replaced with the larger size and and when that last rebuild completes the raid capacity enlarges’. Based on that experience, I would have expected when you dropped that brand new 6TB into HDD1 slot it should immediately begin to rebuild, and after the hours that takes when the rebuild completes the capacity expansion should automatically begin and eventually let you know your raid1 capacity has gone 1.8TB–>5.4TB.
Since the raid1 was perfectly happy with exact same model-size working in HDD2 slot, a brand new one of those in HDD1 slot should be perfectly ‘suitable for rebuilding RAID group 1.’ …unless new disk came doa… It says ‘Ready’ in the snippet you provide, but maybe look at disk details and SMART info to verify no HDD hardware issues rendering it ‘unsuitable’…
That same snippet shows HDD1 as ‘Data’ (vs. ‘Free’) and the Stor Pool 1 Mgmt display shows HDD1 as ‘Not Member’. Those seem to imply your new HDD1 disk is recognized by QTS as a 'Data" disk, but just not part of this storage pool… I believe that’s why one respondent suggested moving new HDD to different machine to format and then trying again.
With your firmware level I believe QTS altered behavior when disks are inserted or first used where you used to get a pop-up warning ‘all data will be destroyed. OK?’ it now skips that pop-up and gives just ‘info bubble’ “not suitable…” if QTS thinks that drive might already be part of a different QTS pool, leaving you to have to take further action on your own to be able to use it. If you have a brand new drive never inserted in a qnap slot before, that shouldn’t be an issue, hence my suggestion to open a support ticket.
If you have data backed up and can’t wait on support, don’t have a different machine to format hdd1 drive, something to consider - You have a TS-853A…
If you have an empty bay in #3-8, move disk from HDD1 slot to empty bay, then StorMan->Disks selecting that bay disk should show as ‘Free’ and on ‘Action’ pull-down do ‘securely erase’. Once erase completes, move disk back to HDD1 slot, and hopefully you see ‘start rebuilding raid 1’ in event log.
If you don’t have an empty bay, possibly one of the pool(s) in bays#3-8 could be safely detached and removed to free a bay to work with. While I safely detach and scan to recover pools pretty routinely with no issues, I did just have previously unseen difficulty one of the eight times I did it upgrading nas’s to 5.2.1. In fact first I ever saw ‘inelligible disk’ message. Described in old forum post:
QTS/hero 5.2.1 upgrades on a handful of models, no issue during/after upgrade. On a EC-1280U-RP, upgrade done as on the others: (1) Reboot (2) Safely detach all data volume pools and remove HDD’s (3) Manual firmware download and installation via gui.
As with the other NAS’s, upgrade and subsequent reboot went fine. When things looked ‘OK’, replugged data pool HDDs, but when I tried “Attach and recover” apparently it did not recognize my safely detached pool and recovered nothing. Rebooted and tried again; same result. Re-installed firmware, this time thru Qfinder, again successful, but still can’t find my ‘safely detached pool’ with ‘scan and recover’. Put in some new HDD’s and tried to create a new pool and get ‘pool creation failed’. Since my ‘(System)’ volume has only apps to re-install and logs to be lost upon system re-initialization, I re-initialized from scratch at same 5.2.1 level. Afterwards I could create a new pool with the new HDD’s, but I still couldn’t successfully ‘scan and recover’ my ‘safely detached’ data volume pool.
I suspect at that point while 5.2.1 could not successfully ‘scan and recover’ my old data volume pool, I think it recognized that there was possibly valid data on the data pool hdd’s because when I tried to use these HDD’s to create a new pool (understanding I would be destroying content on the ‘safely detached’ data vol pool hdd’s) 5.2.1 said these disks were ineligible for pool creation (even though disks showed as 'Free"). This all leads me to believe that QNAP support could probably assist in making 'Scan and Recover" work or otherwise successfully recover access to that pool safely detached prior to initial 5.2.1 upgrade.
Weighing prior support response times when they need to login remote to fix (>2 weeks to months) vs. restore times (7-10 days ~75TB’s) decided data restore would have additional advantage of exercising disaster recovery plan not tested for past few years (though ‘free’ in gui, had to securely erase data volume pool hdd’s to allow recreation of data vol pool).
I forced the shutdown with the physical button, but then it hung booting. Forced shutdown again, removed disk 1, finally it booted. I left the disk 1 removed for now.
