In-Place Replacing Multiple Drives: A Good Approach?

[DerPeit]

Dear FreeNAS veterans,

I am running FreeNAS for a couple of years now, since 9.3 I guess. However, recently I rebuilt my box and I am considering to replace my hard drives. They are all running properly and did not suffer of any errors or such. It's four 3 TB SATA drives with a RAIDZ2 pool in a server with eight bays. All four drives have a total uptime of 4+ years now. Thus, I want to replace all four with larger ones. The pool is encrypted.

I read on the internet that it would be possible to in-place replace multiple disks at a time. So, would it be a good idea to plug in four larger new drives in the remaining bays and in-place replace them all at once keeping the current ones online? Or should I instead resilver one by one? Or might I even regularly replace the drives one by one by taking each offline?

At the time of writing I don't really consider option three because I don't think it's a good idea to lose redundancy when there is no good reason like a failing disk, but I also read that some people argued for this approach because it would be faster. I already search the forum, but I did not yet find a similar post, so any opinions are appreciated.

TL;DR

1 Encrypted Pool on
4 Disks to be In-Place Replaced with
4 New Larger Disks and
4 Empty Bays.

Best,
Manuel

 

[JohnDigital]

Ive done 2 of 4 just fine but never all 4, I dont see why it wouldnt work if all drives are online and functioning. So what if anything is stopping you from just adding the new disks in a new pool and keeping the existing pool online? I mean if there arent errors or impending failure, id just roll with it. Power overhead for 4 additional drives isnt an issue. Ive had drives go on fine for more than 4 years. Move mission critical data to new drives and use the 3's as slack space or temp download directory or something. Just a thought.

Good day.

 

[JaimieV]

Replicating Pool1 over to a new-build Pool2 is the right plan if (as you do) you have enough disk slots. One streamed copy is a lot kinder on the old mechanisms than four complete resilvers, and leaves you with a point-in-time backup Just In Case on the old disks after you pull them out.

Add the disks in and go read the hard drive burn-in testing thread and do those tasks. Allow three or four days, it takes a while.
Build the encrypted Pool2.
Make a snapshot job, recursive, from the root of Pool1.
Make a replication job that takes from that Pool1 root, puts it to Pool2 root.
Wait perhaps three days until completion.

Once you're done replicating, first make sure Pool2 has your stuff on it - there have been reports of doing a complete replica where the replica doesn't show up but is taking all the space up.

Several ways to do the next step, depending on how your setup is.

1) Redo all your shares, replica jobs, snapshots, SMART tasks etc to point at /mnt/Pool2/whatever

or

2) Export Pool2 and then re-import it as Pool1. You can export from the GUI, but I'm not sure if you can import and rename in the GUI. If you can't do it through the Pool Add button, on the command line it's just 'zpool import Pool2 Pool1'

Even in case 2, which I did recently, I found that while most things were happily inherited, my SMB shares needed deleting and re-creating exactly the same. Mild annoyance, but I only have two so...