Re: Replacing a REMOVED drive in DEGRADED zpool

From: Robert <robert_at_webtent.org>
Date: Fri, 22 Aug 2025 04:02:30 UTC
On 8/21/2025 3:03 PM, Dag-Erling Smørgrav wrote:
> Robert <robert@webtent.org> writes:
>> Dag-Erling Smørgrav <des@FreeBSD.org> writes:
>>> `gpart backup | gpart restore` does not copy UUIDs or labels.
>> Good to know, this would be the best option then for preparing the
>> drive for zpool-replace?
> Yes.  You should take a look in /var/backups, you may find a backup of
> the partition table from the failed drive.  Assuming you remove the
> failed drive first, you can safely `gpart restore -l` this backup onto
> the replacement drive, which will recreate the labels (but not UUIDs).

Great, had no idea, yes, I see the gpartada0.backup in /var/backups...

root@db1:~ # cat /var/backups/gpart.ada0.bak <<-- REMOVED disk
GPT 128
1   freebsd-boot        40      1024 gptboot0
2   freebsd-swap      2048  16777216 swap0
3    freebsd-zfs  16779264 276267008 zfs0
root@db1:~ # cat /var/backups/gpart.ada1.bak
GPT 128
1   freebsd-boot        40      1024 gptboot1
2   freebsd-swap      2048  16777216 swap1
3    freebsd-zfs  16779264 276267008 zfs1
root@db1:~ # cat /var/backups/gpart.ada2.bak
GPT 128
1   freebsd-boot        40      1024 gptboot2
2   freebsd-swap      2048  16777216 swap2
3    freebsd-zfs  16779264 276267008 zfs2
root@db1:~ # cat /var/backups/gpart.ada3.bak
GPT 128
1   freebsd-boot        40      1024 gptboot3
2   freebsd-swap      2048  16777216 swap3
3    freebsd-zfs  16779264 276267008 zfs3
root@db1:~ # cat /var/backups/gpart.ada4.bak

>> Would recovering the disk be beneficial versus replace? As far as
>> faster recovery, not needing to resilver or as much. These are not big
>> drives as you can see and RAID10 zpool.
> You can try to use recoverdisk to copy undamaged portions of the failed
> drive onto the replacement, but it's likely to take longer than
> resilvering.
Then I'll stick to the original plan but with attach instead of replace 
using `zpool attach ada0p3 ada0p3`.