I wouldn’t do this unless I had a backup of all the data, which you should have anyways because as we all know: Raid is not a backup.
If you do have a backup, maybe it’s worth a shot…
Advantage of this procedure: If it works, it’s probably faster than restoring the data, and you don’t have to recreate your datasets and shares.
Disadvantage, if it doesn’t work or if you make a mistake in one step, all data is gone and you have to restore from backup, which means it would probably have been faster if you had destroyed the pool and created a new RaidZ from the beginning.
If you don’t have a backup, the safest option is to create an additional mirror, but this means less total storage obviously.
So I inserted the 2 new physical disks into my server and created and associated 2 disks of the same capacity to the TrueNas Scale VM.
I then created a RAIDZ2 pool with the 4 disks (the 2 new physical disks and the 2 virtual ones).
Once the pool was created, I removed, from proxmox, the 2 virtual disks.
The pool has been downgraded, but it is functional.
I am replicating the data (via replication tasks).
And it will only remain to destroy the old pool and replace the 2 virtual disks removed from the RAIDZ2 pool by those of the old mirror pool.
The rest tomorrow ! (there is still a 7TB dataset to replicate before we can proceed to the destruction of the old pool and reintegration of the disks)
And that’s it! Operation completed.
Everything went as planned.
After the end of the replication tasks, I removed one disk from the mirror pool and integrated it into the RAIDZ2 pool.
And once the rebuild was finished, I destroyed the mirror pool and integrated the last disk.
So I have a 4x12TB RAIDZ2 pool without having to go through a data restoration phase where I would have lost my snapshots for example.
Performance wise, I don’t see any difference with the mirror, as I’m reaching saturation of the Gb link of my ethernet network.