ReadyNAS 626 Status Is "Degraded" After Successful Resync

---

nsne wrote:

 

A) Is the cloning strategy that I've proposed a good idea and B) if so, what method would you recommend to carry it out?

---

Cloning would be one way to catch up the RN314, but it's not very sustainable.

One aspect is that you would also be cloning the OS - so the RN314 would be exactly the same as the RN628.  It would have the same NAS name for example.

Another aspect is that updating the RN314 would require copying everything on every RN628 disk to the RN314.  This would take some days, and both NAS would be out of service while you were doing this.  There would be a lot of disk handling involved, so it would be easy to do damage with a mis-step (losing track of what you've already copied, or accidentally dropping a disk).

---

nsne wrote:

 

I have a spare ReadyNAS 314 that I've been using for a long time as a share-based backup. Each of the eight shares on my 626 has its own daily backup job. The 314 initiates those jobs via rsync.

 

---

This should be copying everything in the main share (so the main shares on the two NAS should be identical after the backups are complete).

FWIW, this is what I am doing myself.  I have daily snapshots on the backup NAS, which are updated shortly before the backups are scheduled.  So I do have some backup versioning via the snapshots, though the snapshots themselves are a bit different than the ones on the main NAS.

Just an update to all this.

I RMA'd the Seagate EXOS 18TB X18 drive that the 626 had flagged as faulty. (During a pre-return wipe of the data, the HDD failed completely.) The seller sent a replacement HDD and I added that to the unit.

After re-syncing, the 626 is now showing healthy status and data redundancy. So things have stabilized and I have more peace of mind.

HOWEVER...

When I inserted the new HDD, the NAS immediately began re-syncing. I wasn't prompted to format the disk. This immediate re-sync has never happened before.

The NAS re-synced, then hung on apparent completion of that operation. No shares or data were accessible via FTP, GUI or SMB. This error has happened repeatedly with every new HDD I've inserted since 6.10.8. To restore access, the only solution is to power off the NAS physically.

After the NAS rebooted, it was showing a superfluous "data 4" volume. I had to delete that (using the DESTROY command) that to get the NAS to re-sync once again. During this time, the 626 said it was "reshaping" data (as opposed to re-syncing).

After the reshape, the 626 re-synced yet again. It was only after this that the volume showed as "Healthy."

This whole re-sync/reshape/re-sync process took about 4 or 5 days, if I recall.

So even though the volume is now reporting that it's "healthy," I have very little faith in the integrity of my data.

If you insert an unformatted drive that is a replacement for another missing ot dead one, then the NAS will automatically start the re-sync.  The bad drive must have caused the NAS to at least start the process of adding the drive, so it considered the replacement drive just that -- a replacement.

I suspect that the "new volume" was data-4, not data 4.  That's the name it gives the 4th MDADM RAID in a NAS with multiple groups, like yours.  And when BTRFS can't figure out where it belongs, it shows up as a separate volume.  But, usually, it is supposed to be part of the main volume and may contain data from it.  Destroying it may not have been a good thing, you'll just have to see if any of your data is now corrupt.

If your RAID1 layer is now expanding to RAID5, that's what's reshaping.