Replaced disk, does the data get destroyed

TrueNAS General
21

Hmmm.

It’s a mirrored pool trick.

22

Ok, way to many to respond to but the general consensus is to Mirror then Offline.

I’ll try it in the next couple of days again, hopefully it won’t keep complaining as being degraded and such or forever keep looking to be fixed with a mirror disk.

*Though I’m begining to think the best bet would be:
1- Rename the current disk to be replaced.
2- Install the new disk and create pool with same name and passphrase.
3- rsync disk to disk then export the old disk thereby keeping the old data structure.

Though I don’t know if datasets and will work correctly.

Stuffit I have backups, I may as well just Replace and start again with the old disk in a different system.

Thanks everyone, I’ll see what I decide.

For the curios, I generally create a moc up pc to break things before I apply to my actual machine.

23

No, Mirror then Split the pool.

I don’t know if the TrueNAS GUI exposes the Mirror Split function. But that is part of ZFS. (Their is no way to “clone” a pool made up of RAID-Zx or dRAID-x vDevs using a split like function.)

Simply off-lining a Mirror disk(s) does not make them suitable for import as a working pool. It gets worse if you have 2 or more Striped disks. This is because ZFS may update the pool after the off-line of one disk causing the next disk offlined to have a different transaction level, (a ZFS write transaction is like a database write).

A ZFS pool consists of one or more vDevs, which can be individual disks, (like in a Stripe configuration). However, a single disk from a multi-disk Striped pool does not contain enough data to recover the pool.

Sorry a bunch of side issues got mentioned.

2 Likes
24

Exactly.

A mirrored ZFS storage pool can be quickly cloned as a backup pool by using the zpool split command.

https://docs.oracle.com/cd/E19253-01/819-5461/gjooc/index.html

2 Likes
25

Ah! There’s the underlying goal, finally!

Having a play-test machine is a good idea, though I’m not convinced this is the best method of duplicating your setup to be put into “production mode”.

Honestly if you would have started with “Hey, I’m testing this on a machine, and I want to create a copy of the environment onto its final resting place on the “real” server” I would have recommended replication; that way you would have to deal with “data loss” from the weird convoluted cloning attempt you’ve been trying to do.

The steps for this would be so much simpler, supported and hopefully obvious:

  1. Create a new pool on the “new” disk
  2. Set up a local one-time replication to copy the old pool into the new pool
  3. export the new pool and remove the disk
  4. import the new pool into the new production system

If you want to keep the old name on the new system, @Stux has also created a quick guide on that too over here. You only need to do the second half, starting with “Once that is finished”.