Node Configuration
Overview
After installing Storware Backup & Recovery, configure each Node and register it with the Server.
This procedure covers HTTPS connectivity, operating system configuration, LVM filtering for disk attachment, Node registration, and service verification.
Run commands as root on the indicated host. Replace example hostnames, addresses, and passwords with the values used in your environment.
Configuration steps
1. Configure HTTPS Connectivity
The examples use storware.example.com and HTTPS port 8181. If port 443 is configured, use it consistently instead.
1.1. Select the Server Hostname
Use a fully qualified domain name (FQDN) matching the Server certificate.
Deployment
Hostname to use
Server and Node on the same host, using the default certificate
localhost.localdomain
Node connecting to a separate Server
Server FQDN, such as storware.example.com
High-availability Server
Shared cluster FQDN
For local connections using the default certificate, use localhost.localdomain, not localhost. Remote connections require a certificate matching the Server FQDN.
On each Node, verify name resolution:
If DNS is unavailable, add the appropriate entry to /etc/hosts:
1.2. Prepare the Server Certificate
Run on the Server.
If the Server already presents a valid certificate for the selected hostname, continue with Trust the Server Certificate on the Node.
Otherwise, prepare either a self-signed certificate or a certificate signed by your certificate authority (CA).
Create a protected working directory:
Option A: Self-Signed Certificate
Generate an encrypted private key and a certificate containing the Server hostname in the Subject Alternative Name (SAN):
Enter a private-key passphrase when prompted.
Option B: CA-Signed Certificate
Generate an encrypted private key and a certificate signing request (CSR):
Submit storware.csr to your CA. Save the issued certificate as storware.crt and any intermediate certificates as ca-chain.crt.
1.3. Create the Server Keystore
Run on the Server, from /root/storware-tls.
For a self-signed certificate:
For a CA-signed certificate with intermediate certificates:
Provide the private-key passphrase and choose an export password. The PKCS12 bundle contains the private key and certificate chain.
Import the bundle into a new Java keystore:
Use the same password for the PKCS12 export and destination keystore, so the imported private key and keystore have matching passwords.
The destination filename must not contain an unrelated existing keystore. docs.oracle.com
Set ownership and permissions:
Back up /opt/vprotect/server/quarkus.properties, then update its existing keystore settings:
Use the destination keystore password, not the original private-key passphrase.
Restart the Server:
1.4. Trust the Server Certificate on the Node
Run on each Node.
Inspect the certificate presented by the Server:
Verify its hostname, validity, and fingerprint against the certificate approved by your administrator before importing it.
Import it using the supplied script:
If the Node’s Java truststore uses a custom password, supply it as the third argument:
This password belongs to the Node truststore, independently of the Server keystore password.
For a local Node using the default certificate:
Repeat certificate verification and import when a certificate change requires updating the Node’s truststore.
2. Configure the Operating System
Run on each Node.
Execute:
The documented configuration script adjusts QEMU ownership settings, adds the vprotect account to the disk group, configures privileged command access through sudoers, and disables SELinux.
Allow the script to complete successfully before continuing. These changes affect the host’s operating system configuration.
3. Configure LVM for Disk Attachment
Complete this section if the Node operates as a proxy VM using a disk attachment backup strategy. Otherwise, proceed to Register the Node.
Attached backup disks can contain LVM metadata identical to the Node’s own disks, particularly when VMs originate from the same template. Restrict host LVM scanning to the Node’s own required devices to avoid discovering or activating volume groups from attached backup disks.
3.1. Identify the Node’s Disks
Run on the Node before attaching backup disks.
Inspect the device layout:
Identify every physical volume required by the Node, including devices containing root, swap, and any other local LVM filesystems.
Back up the LVM configuration:
3.2. Configure Device Filters
Edit the existing devices section in /etc/lvm/lvm.conf.
The following example assumes that all required local LVM devices are on /dev/sda:
The acceptance rules permit the specified disk and its partitions. The final rule rejects other devices.
Adapt both filters to include every required local device. For production configurations, prefer stable /dev/disk/by-id/ paths where appropriate, because kernel device names can change.
3.3. Account for the LVM Devices File
On RHEL 9, the devices file is enabled by default and replaces ordinary LVM filtering.
To use the filter-based configuration above, also set the following in the same devices section:
On other systems, apply this setting only if their LVM version supports the devices-file feature.
3.4. Validate the Configuration
Verify that the Node’s required volume groups and logical volumes remain visible:
If required volumes are missing, correct the filters or restore the saved configuration before rebooting.
On RHEL systems, rebuild the initramfs after validating the filters:
This makes the updated filtering available during boot.
4. Register the Node
Run on each Node.
Register the Node with an administrative Server account:
Parameter
Description
--name
Name identifying the Node in Storware Backup & Recovery.
--login
Administrative account used for registration.
--password
Password for that account.
--apiurl
Server API URL, including the HTTPS port and /api suffix.
Use the same hostname and port as in the certificate configuration.
For a local Node using the default certificate, set:
Confirm that registration succeeds before proceeding.
5. Reboot and Verify the Node
Reboot the Node host to apply the operating system changes:
After reconnecting, check the service:
The expected state is active (running). Also verify in the web interface that the registered Node is connected.
Troubleshooting
If the Node fails to start or connect, check:
Server hostname resolution and network reachability.
Whether the configured port matches the actual HTTPS endpoint.
Certificate hostname, expiry, and trust.
Registration credentials and API URL.
Availability of the Node’s required local volumes after LVM configuration.
Inspect service messages:
Application logs are stored under:
Last updated