Re: Replacing a REMOVED drive in DEGRADED zpool

On 8/22/25 09:53, Robert wrote:
> On 8/22/2025 2:04 AM, David Christensen wrote:
>>> root@db1:~ # cat /etc/rc.conf
>>> hostname="db1.REDACTED"
>>> ifconfig_em0="inet REDACTED netmask 255.255.255.192"
>>> defaultrouter="REDACTED.1"
>>>
>>> # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
>>> dumpdev="AUTO"
>>> nrpe3_enable="YES"
>>> sshd_enable="YES"
>>> ntpdate_enable="YES"
>>> ntpd_enable="YES"
>>> named_enable="YES"
>>> postgresql_enable="YES"
>>> nfs_client_enable="YES"
>>> nfs_server_enable="YES"
>>> nfs_server_flags="-u -t -n 4"
>>> rpcbind_enable="YES"
>>> mountd_flags="-r"
>>> mountd_enable="YES"
>>> apache24_enable="YES"
>>> postfix_enable="YES"
>>> sendmail_enable="NONE"
>>> sendmail_submit_enable="NO"
>>> sendmail_outbound_enable="NO"
>>> sendmail_msp_queue_enable="NO"
>>> slapd_enable="YES"
>>> slapd_flags='-h "ldapi://%2fvar%2frun%2fopenldap%2fldapi/ 
>>> ldap://0.0.0.0:389/ ldaps://0.0.0.0:636/"'
>>> slapd_sockets="/var/run/openldap/ldapi"
>>> mrtg_daemon_enable="YES"
>>> saslauthd_enable="YES"
>>> saslauthd_flags="-a ldap"
>>
>>
>> That server has some complexity.
> 
> Perhaps. As the host name nomenclature would suggest, it is our db 
> server that serves lightweight bind9 DNS and LDAP to serve mail routing 
> to our MX servers. The PostgreSQL houses the spam filtering data for 
> same MX servers that run Amavisd with SpamAssassin and some other small 
> utility databases. That's it in a nutshell.
> 
> I have two of these for redundancy primary/secondary DNS, openldap and 
> PostgreSQL replication. As we know, these servers are setup with root on 
> ZFS and gmirror swap. I've done zfs send/recv with data snapshots, but 
> never for this root on ZFS setup. I'd like to also put a plan together 
> for cloning to a new server. Could I get some pointers to good posts or 
> docs on doing this and possibly start another thread to discuss 
> questions? Perhaps this involves dump and beadm.
> 
> -- 
> Robert


Some thoughts:

1.  Put your OS on a disk-on-module, single SSD, or gmirror/ ZFS mirror 
of two such devices.  Keep the OS instance small and self-contained.  In 
addition to backups, take images regularly.

2.  Put your data on a ZFS pool with suitable redundancy and performance.

3.  ZFS mirrors and stripes-of-mirrors perform better and resilver 
faster than ZFS RAID-Z or stripes-of-RAID-Z's, but they are not as space 
efficient.  Mirrors should not be a problem for a 300 GB pool.

4.  AIUI some databases can manage disks directly.  I suggest 
researching databases on raw disks vs. databases on ZFS volumes vs. 
databases on ZFS file systems.  If the first is compelling, include 
dedicated SSD's for the database.

5.  Root-on-ZFS offers many features (including replication), most 
notably boot environments.  I started with this, but now use UFS.

6.  It is easier to manage multiple computers with similar hardware than 
to manage multiple computers with differing hardware.  Your organization 
might benefit from standardizing on one or a few server platforms.  You 
would then pick a suitable platform, and add disks and options as needed 
for the next pair of database servers.

7.  Virtualization and containers are possibilities, especially if you 
want isolation for security and/or damage control.


David