OpenBSD Handbook

    Theme
    • Part I. Install & Configure
      • Introduction to OpenBSD
      • Installing OpenBSD
      • The X Window System
      • Networking on OpenBSD
      • System Configuration
      • OpenBSD Basics
      • Managing Software: Packages and Ports
    • Part II. Daily Operations
      • OpenBSD Desktop Environments
      • Multimedia
      • Printing
      • Linux Compatibility
      • Windows Compatibility
      • Games
    • Part III. System Administration
      • Virtualization
      • Storage and File Systems
      • Updating and Upgrading
      • Localization
      • The OpenBSD Boot Process
      • Security
    • Part IV. Networking & Daemons
      • Services
        • Database
          • MariaDB
          • PostgreSQL
          • Redis
          • memcached
        • Directory
          • YP (NIS)
          • LDAP
        • File
          • NFS
          • Samba
        • FTP Services
          • ftpd
          • ProFTPD
          • vsftpd
          • Pure-FTPd
          • TFTP
        • Mail
          • OpenSMTPD Mail Server
          • Dovecot IMAP and POP3 Server
          • Postfix
          • Exim
          • Rspamd
        • Name
          • Unbound DNS Resolver
          • NSD Authoritative DNS Server
          • BIND DNS Server
        • Networking
          • OpenBGPD
          • rad
          • DHCP on OpenBSD
          • slaacd
        • Web
          • Apache HTTP Server
          • nginx Web Server
          • OpenBSD httpd Web Server
          • relayd Reverse Proxy
        • Logging
          • syslogd
        • Monitoring
          • SNMP
        • Remote Access
          • Audit OpenSSH
          • OpenSSH Server
        • File Synchronization
          • rsync
        • Messaging
          • RabbitMQ Message Broker
        • Time
          • NTP Time Synchronization
        • Load Balancing
          • Build Redundant Load-Balanced Gateways
          • Load Balance Services with NAT or DSR
          • Build an HA HTTPS Load Balancer
      • PF
        • pfctl cheat sheet
        • PF Anchors
        • PF Filter Rules
        • PF Forwarding
        • PF Lists and Macros
        • PF Load Balancing
        • PF Logging
        • PF NAT
        • PF Options
        • PF Policies
        • PF Shortcuts
        • PF Tables
      • Advanced Networking
        • High Availability and State Replication
        • Multi-WAN and Policy-Based Routing
        • VPN and Cryptographic Tunneling
        • Classic and Lightweight Tunnels
        • IPv6 at Scale
        • QoS and Traffic Shaping
        • MPLS and Label Distribution
        • Network Services at Scale
        • Virtualization and Host Networking
        • Large-Scale L2 and L3 Design
        • Telemetry, Logging, and Flow Export
        • Hardening and Operational Safety
        • Reference Architectures
        • Troubleshooting Playbooks
      • Serial Communication
    • Part V. Miscellaneous
      • Virtualization Cheat Sheet
      • OpenBSD Cheatsheet
      • How-to Guides
        • Installation and First Boot
          • Complete the First 30 Minutes After Installation
          • Check Hardware Compatibility Before Installing
          • Bootstrap Wi-Fi Firmware Without Ethernet
          • Run OpenBSD as a Virtual Machine Guest
          • Install OpenBSD on a VPS or Cloud Server
          • Install OpenBSD with Full-Disk Encryption
          • Dual-Boot OpenBSD on a UEFI System
          • Automate OpenBSD Installation with Autoinstall and PXE
        • Desktops and Laptops
          • Set Up OpenBSD as a Laptop or Workstation
          • Configure Laptop Power Management
          • Troubleshoot Web Browsers on OpenBSD
          • Use Plan 9 Tools on OpenBSD
          • Build a Minimal Desktop with suckless Tools
          • Install Z shell (zsh)
        • Networking and Remote Access
          • Create an Administrator Account with doas and SSH Keys
          • Configure Secure Remote Access with OpenSSH
          • Use FIDO Security Keys with OpenSSH
          • Configure Wi-Fi Roaming and Wired Failover
          • Troubleshoot PF, NAT, and Routing
          • Route Multiple VLANs with PF
          • Configure a Road-Warrior WireGuard VPN
          • Route IPv6 Networks without NAT
          • Test OpenBGPD with Two Providers
          • Unlock an Internal Service with an SSH Key
          • Build a Simple Router and Firewall
        • Servers and Services
          • Set Up WordPress on OpenBSD
          • Build a Mail Server with OpenSMTPD, Dovecot, and Rspamd
        • Security, Maintenance and Recovery
          • Establish a Conservative Security Baseline
          • Recover Access and Reset the Root Password
          • Collect OpenBSD Diagnostic Evidence
          • Troubleshoot Package Installation and Update Failures
          • Schedule Recurring Maintenance
          • Monitor an OpenBSD System
          • Back Up and Restore an OpenBSD System
          • Configure softraid RAID1
          • Recover an OpenBSD System That Does Not Boot
        • Building, Automation and Virtual Machines
          • Manage OpenBSD with Ansible
          • Build Third-Party Software from Ports
          • Build OpenBSD from Source
          • Plan a Docker Workload Migration to OpenBSD
      • OpenBSD for Linux Users
      • OpenBSD for FreeBSD Users
      • OpenBSD for macOS Users
    • OpenBSD FAQ
    • OpenBSD Architectures
      • OpenBSD Package Search
        • Synopsis
        • Plan the Mirror
        • Identify and Label the Component Disks
        • Create the Mirror
        • Monitor Mirror Health
        • Replace a Failed Component
        • Bootable Mirrors

        Configure softraid RAID1

        Synopsis #

        The RAID 1 discipline of softraid(4) mirrors data across two or more chunks. The assembled volume appears as a normal sd(4) disk and is partitioned and formatted at that virtual layer.

        RAID1 improves availability after a component failure. It does not protect against deletion, corruption, compromise, fire, theft, or an error applied to the mirror. Maintain and test independent backups.

        This procedure destroys all data on the selected component partitions. Disk names can change whenever hardware or installation media changes. Identify devices by model, size, attachment, and disklabel UID before every destructive command.

        Plan the Mirror #

        The example uses:

        RoleDevice
        First physical disksd1
        Second physical disksd2
        RAID chunkssd1a and sd2a
        Assembled volumereported by bioctl, assumed sd3
        Data filesystemsd3a mounted at /srv

        The component partitions must have type RAID and compatible sizes. The mirror’s usable size is limited by its smallest chunk.

        Identify and Label the Component Disks #

        Inspect all candidates:

        doas sysctl hw.disknames
          # Record disk names and disklabel UIDs
        dmesg | grep '^sd'
          # Match disks to size and attachment
        doas disklabel sd1
          # Inspect the first proposed component
        doas disklabel sd2
          # Inspect the second proposed component
        

        Stop unless both devices are unambiguously identified and all required data has been backed up.

        Prepare the required outer partitioning for each data disk, then create one equal-size disklabel partition of type RAID on each. Use disklabel(8) interactively and inspect the proposed offset and size rather than copying sector values from another disk:

        # disklabel -E sd1
        Label editor (enter '?' for help at any prompt)
        sd1> a a
        offset: [default]
        size: [default] *
        FS type: [4.2BSD] RAID
        sd1*> w
        sd1> q
        

        This transcript assumes partition a is unused. If an old layout exists, inspect and remove only the intended old partitions after confirming both disks are disposable; initializing an outer table need not clear an old disklabel. Repeat for sd2, then inspect both completed labels. Check both labels before creating the mirror.

        Create the Mirror #

        Create the RAID1 volume with bioctl(8) :

        doas bioctl -c 1 -l /dev/sd1a,/dev/sd2a softraid0
        

        Record the virtual disk name reported by the command. This example assumes sd3. Confirm its discipline and state:

        doas bioctl sd3
          # Confirm RAID 1 and an online state
        doas disklabel sd3
          # Confirm the expected virtual size
        

        Clear stale signatures only on the assembled virtual disk, never on either physical chunk:

        doas dd if=/dev/zero of=/dev/rsd3c bs=1m count=1
        

        Initialize the virtual disk’s outer partition table as appropriate for the platform and intended use. For a data-only amd64 disk using an MBR OpenBSD area, one example is:

        doas fdisk -iy sd3
        

        Create a normal 4.2BSD partition on the virtual disk:

        # disklabel -E sd3
        Label editor (enter '?' for help at any prompt)
        sd3> a a
        offset: [default]
        size: [default] *
        FS type: [4.2BSD]
        sd3*> w
        sd3> q
        

        Create and mount the filesystem:

        doas newfs /dev/rsd3a
          # Create FFS on the virtual partition
        doas install -d -o root -g wheel -m 755 /srv
          # Create the mount point
        doas mount /dev/sd3a /srv
          # Mount the mirrored filesystem
        

        Use the virtual partition’s DUID in /etc/fstab rather than relying on sd3, which can change across boots.

        Monitor Mirror Health #

        Inspect the assembled volume regularly:

        doas bioctl sd3
        sysctl hw.sensors.softraid0
        

        Softraid exports volume status through hardware sensors, so sensorsd(8) can report state changes. Test the notification path.

        A degraded mirror remains a data-loss risk until it has rebuilt and returned to an online state. Reduce writes and replace the failed component promptly, but do not rush device identification.

        Replace a Failed Component #

        Before removing hardware, record bioctl output, disk identity, chunk state, and the assembled volume name. Shut down when the controller or enclosure does not support safe hot replacement.

        After installing the replacement disk:

        1. identify it from current sysctl, dmesg, and disklabel output;
        2. create outer partitioning compatible with the surviving component;
        3. create an equal-size partition of type RAID;
        4. inspect the completed label and confirm that the surviving disk is not the target;
        5. start the rebuild by naming the full replacement chunk and the assembled volume.

        If the replacement chunk is /dev/sd2a and the assembled volume is currently sd3:

        doas bioctl -R /dev/sd2a sd3
        

        Monitor progress and state:

        doas bioctl sd3
        sysctl hw.sensors.softraid0
        

        Do not reboot, detach the volume, or treat redundancy as restored until the rebuild completes and the volume reports an online state. If the rebuild reports errors, preserve the surviving data and backup before attempting additional repair.

        Bootable Mirrors #

        Boot support depends on the platform and softraid discipline. Current softraid(4) documents RAID1 boot support on selected architectures. installboot(8) can install boot code so all chunks of a supported volume are bootable.

        A bootable-root migration requires architecture-specific outer partitioning, boot areas, filesystem layout, /etc/fstab, boot-code installation, and a physical test of booting from each component. Do not convert this data-volume procedure into a root migration by adding installboot alone.

        See Storage and File Systems for softraid concepts and Back Up and Restore an OpenBSD System for independent recovery copies.

        Report a bug
        • Synopsis
        • Plan the Mirror
        • Identify and Label the Component Disks
        • Create the Mirror
        • Monitor Mirror Health
        • Replace a Failed Component
        • Bootable Mirrors