Azure Stack HCI

This section introduces the process of backing up and restoring Azure Stack HCI.

Overview

Azure Stack HCI (Hyper-Converged Infrastructure) is a Microsoft solution designed for running virtualized workloads on-premises, with deep integration into the Azure ecosystem. It builds on familiar Windows Server technologies like Hyper-V, Storage Spaces Direct, and Software-Defined Networking (SDN), offering a modern, high-performance platform for hybrid cloud deployments.

Key Features:

Virtualization with Hyper-V Azure Stack HCI uses Hyper-V as its core virtualization engine for running Windows and Linux virtual machines.
Hyper-Converged Infrastructure Combines compute, storage, and networking in a single, integrated solution with high availability through clustering.
Azure Integration Seamlessly connects with Azure services, such as:
- Azure Arc for centralized management
- Azure Monitor for performance and health monitoring
Modern Management Administered through Windows Admin Center (WAC) with simplified tools for cluster deployment, updates, and monitoring.
Subscription-Based Licensing Licensed through an Azure subscription, billed per physical CPU core.

Resilient Change Tracking (RCT) in Azure Stack HCI

In Azure Stack HCI, Storware Backup and Recovery leverages the Resilient Change Tracking (RCT) feature to perform efficient full and incremental backups of virtual machines (VMs). RCT is a native Hyper-V capability that allows Storware to identify and back up only the blocks of data that have changed since the last backup, significantly improving backup performance and reducing storage and network load.

RCT operates at the block level, eliminating the need to scan entire virtual disks to detect changes. Instead, it tracks block-level changes over time and maintains metadata that Storware can use to quickly determine which blocks need to be included in an incremental backup.

This functionality is essential in Azure Stack HCI environments where performance, scale, and operational efficiency are critical.

To ensure data integrity and resilience, RCT uses a three-tier bitmap storage approach:

In-memory bitmap – used during normal VM operation for fast and granular change tracking.
Two on-disk bitmaps – persist through host migrations or unexpected shutdowns.

When a VM is running normally, Storware uses the RCT file to detect changes. However, in scenarios such as a host crash or VM migration, the in-memory bitmap may be lost. In these cases, Storware uses the Modified Region Table (MRT) file stored on disk. The MRT contains detailed change tracking data and ensures backup consistency even after disruptions.

RCT metadata is associated with VHD/VHDX files and follows the virtual machine during live migrations, maintaining continuity of backup operations.

Benefits of RCT-Based Backups

Faster incremental backups
Reduced system load
Improved backup reliability
Better resilience during failures or migrations

Network requirements

Supported features

Hyper-V agent installation

Prerequisites

Before installing the Hyper-V agent, ensure the following requirements are met:

.NET Framework 4.7.2 or higher must be installed on the system.
- The agent installation package includes the required .NET components, but it's recommended to verify that the appropriate version is already present or updated during installation.
- You can also download it from the official Microsoft website:
Visual C++ Redistributable 2013 and 2015 are required if Dell EMC Data Domain is used as the backup destination. Download from Microsoft:
Hyper-V VM configuration version 6.2 or higher is required for Resilient Change Tracking (RCT) to function correctly. RCT is supported on Windows Server 2016 and later, but only for VMs with the appropriate configuration version.\
To check the VM version, run the following PowerShell command on the Hyper-V host:
```
Get-VM * | Format-Table Name, Version
```
Production checkpoints must be supported and enabled for quiesced (application-consistent) snapshots. The backup process relies on the Production Checkpoints feature to create consistent VM snapshots without shutting down or suspending the VM.
To verify or configure checkpoint type:
1. Open Hyper-V Manager.
2. Right-click the virtual machine and select Settings.
3. Under Management, select Checkpoints.
4. Ensure that "Use production checkpoints" is selected.
  - If the VM does not support production checkpoints, fallback to standard checkpoints may be automatically enabled.
Alternatively, use PowerShell to check and configure:
```
Get-VM -Name "<VMName>" | Select-Object Name, CheckpointType
```

Installation

To enable backup and restore operations for Microsoft Hyper-V, you must install the Hyper-V Agent on each Hyper-V host. Follow the steps below to complete the installation:\

Prepare the Installation Files - Copy the extracted installation files to the target Hyper-V host. - Navigate to the installation folder and launch setup.exe.\
Run the Installation Wizard
1. In the welcome screen, click Next to proceed.
2. Choose the installation directory for the agent or accept the default path. Click Next.
3. Enter a secure password for agent authentication.
  This password will be required when adding the Hyper-V host to Storware Backup and Recovery. Important: Do not use the ^ or \ characters in the password, as they may cause issues during inventory synchronization.
4. Review your settings and click Next to begin the installation.
5. If prompted by Windows User Account Control (UAC), click Yes to allow the installation.
6. Once installation is complete, click Finish to exit the wizard.

Quiet installation

The Hyper-V Agent installer supports a silent (non-interactive) installation mode using command-line parameters. This is useful for automated deployments or scripted installations across multiple hosts.

Syntax

setup.exe /S /v"PASS=<YourPassword> TRANSPORT=<TransportMethod>"

Parameters

PASS=<YourPassword> Sets the password for secure communication between the agent and Storware Backup and Recovery.
⚠️ Note: Avoid using the characters ^ and \ in the password to prevent synchronization errors.
TRANSPORT=[HTTP|HTTPS|BOTH] Specifies the communication method(s) the agent should support:
- HTTP – Use unencrypted communication
- HTTPS – Use encrypted communication
- BOTH – Enable both methods

Example Command

setup.exe /S /v"PASS=MySecurePassword123 TRANSPORT=HTTPS"

The installer will run silently and complete the installation using the provided parameters. No user interaction is required.

Protecting Azure Stack HCI

After installing the Hyper-V Agent on the host machine, the next step is to register the Azure Stack HCI environment within the Storware Backup & Recovery WebUI.

Adding an Azure Stack HCI

Log in to the Storware Backup & Recovery WebUI.
Navigate to: Virtual Environments → Virtualization Providers.
Click the Create button to open the Add new Virtualization Provider.
Select Microsoft Hyper-V / Azure Stack HCI from the drop down menu.

Fill in the Required Fields

General Tab

Node Config Select the node configuration used during communication with the Hyper-V.
Infrastructure
- Failover Cluster Select this option when adding an Azure Stack HCI.
Host Enter the IP address or hostname of the Hyper-V host or SCVMM server address in URL format, using either http or https depending on the transport method selected during the agent installation.
Password Provide the password set during the Hyper-V Agent installation. This password is used for secure communication with the host.
Trust Cerificates Enables or disables certificate validation for secure connections - when enabled, system will verify that the remote system presents a trusted SSL/TLS certificate.

Microsoft Hyper-V / Azure Stack HCI Settings Tab

Number of Disk Import/Export Threads Set the number of parallel threads used for importing and exporting disk data during backup and restore operations.
- Default: 1

Restoring Hyper-V virtual machines

Storware Backup and Recovery offers flexible restore options for Microsoft Hyper-V virtual machines (VMs). Depending on the recovery scenario, you can restore entire VMs or recover individual virtual disks.

Restores can be performed directly from the Storware WebUI, with options to restore to the original location or an alternate host.

Types of Restore Operations

Restore to virtualization manager Restores the virtual machine directly to the hypervisor or virtualization platform (e.g., Hyper-V or SCVMM). This method recreates the VM within the managed environment, preserving its configuration and metadata. This method allows you to restore individual virtual disks selectively.
Restore to the node Exports the virtual machine or its disks to the Storware node’s local filesystem or a specified path. Typically used for manual recovery, migration, or advanced troubleshooting.
Instant restore Mounts the backup image directly from the backup storage without transferring data. The VM becomes immediately accessible and operational, significantly reducing recovery time for critical systems. Live Storage Migration option can be used to transfer the data in the background.

Restore to virtualization manager

Log in to the Storware Backup & Recovery WebUI.
Navigate to: Virtual Environments → Instances
Locate the VM you wish to restore.
From the Action menu, select Restore, or click the VM name to open its details and choose Restore from the top menu of the detailed view.
Select Restore to virtualization manager
In the Restore Wizard, configure the following:
- General
  - Select backup location Select the specific backup instance from which the virtual machine will be restored.
  - Virtualization Provider Specify the target hypervisor or virtualization manager where the VM should be restored.
  - Change name of the restored virtual environment Enable this option to assign a custom name to the restored VM; disable it to retain the original name.
- Storage For each virtual disk, you can configure the following restore options:
  - Disk allocation format Choose the disk provisioning type for the restored virtual disk:
    Fixed size – Pre-allocates the full disk size on storage.
    Dynamically allocated – Allocates storage space as data is written.
  - Restore path Define the target directory on the Hyper-V host where the virtual disk will be restored.
  - Exclude Enable this option to exclude the selected disk from the restore operation. Useful when partial disk recovery is required.
- Networking Choose the virtual switch or network to which the restored virtual machine will be connected.
- Advanced
  - Delete if virtual machine already exist Automatically removes the existing VM with the same name before restoring.
  - Power on VM after restore Starts the restored virtual machine immediately after the restore process completes.
  - Fail task if restored VM cannot be powered on. Marks the restore task as failed if the virtual machine fails to start after restoration.
Review the summary
Click Restore

Restore to the node

Log in to the Storware Backup & Recovery WebUI.
Navigate to: Virtual Environments → Instances
Locate the VM you wish to restore.
From the Action menu, select Restore, or click the VM name to open its details and choose Restore from the top menu of the detailed view.
Select Restore to the node
In the Restore windows configure the following:
- Select backup location Select the specific backup instance from which the virtual machine will be restored.
- Choose node Select the Storware node where the restored data will be saved.
- Choose restore path Specify the destination directory on the selected node for the restored files.
- Restore only selected files Enable this option to browse and restore specific virtual disk or metadata files, rather than restoring the entire virtual machine.
Click Restore

Instant Restore

Instant Restore in Storware Backup and Recovery allows you to quickly recover a virtual machine by mounting its backup image directly from the backup storage. Instead of waiting for the full data to be copied to the production environment, the VM becomes immediately accessible and operational.

This feature significantly reduces recovery time, especially for critical systems that require fast availability.

Toghether with Instant Restore Live Storage Migration option can be used to transfer the data in the background

Instant Restore requires that the backup destination used for the VM is a synthetic type.

Storage Live Migration

When used in combination with Instant Restore, Storage Live Migration allows seamless background transfer of virtual machine data from backup storage to production storage.

Storage Live Migration allows you to move the virtual disk of a running virtual machine to a different storage location without shutting down the VM. This feature is particularly useful during an Instant Restore scenario, where the VM initially runs directly from the backup storage.

Preparing the Environment with Active Directory

In Active Directory-based environments, Storware Backup and Recovery nodes must be joined to the domain to support Instant Restore.

Prerequisites

Before configuration, ensure the following are available:

Fully Qualified Domain Name (FQDN), e.g., demo.lab
NetBIOS Domain Name, e.g., DEMOLAB
Domain Administrator Account
Required Packages:
```
yum install samba samba-winbind
```

Configuration Steps

Verify DNS Configuration Ensure the node uses the correct AD DNS servers and the search domain is set:
```
cat /etc/resolv.conf
```
Example output:
```
search demo.lab
nameserver 10.0.0.1
nameserver 10.0.0.2
```
Configure Kerberos to integrate with Active Directory The /etc/krb5.conf file defines how the system interacts with the Kerberos authentication infrastructure, which is essential for integrating with an Active Directory (AD) domain.\
Here is example of a /etc/krb5.conf file:
```
[logging]
  default = FILE:/var/log/krb5libs.log
  kdc = FILE:/var/log/krb5kdc.log
  admin_server = FILE:/var/log/kadmind.log

[libdefaults]
  default_realm = DEMO.LAB
  dns_lookup_realm = false
  dns_lookup_kdc = true
```
Here's what each section and setting does in the provided configuration:
- [logging] Specifies where log files related to Kerberos operations will be written. This helps in debugging Kerberos issues.
  - default – Logs for general Kerberos library functions.
  - kdc – Logs for Key Distribution Center operations.
  - admin_server – Logs related to administrative functions such as managing principals.
- [libdefaults] Controls global Kerberos client behavior.
  - default_realm – Sets the default Kerberos realm the system will use (must match your AD domain, in uppercase).
  - dns_lookup_realm = false – Disables automatic realm detection via DNS TXT records (manual configuration is used).
  - dns_lookup_kdc = true – Enables automatic lookup of Key Distribution Center (KDC) servers via DNS SRV records. This simplifies configuration by not requiring static KDC entries.
Synchronize Time
Kerberos authentication requires accurate time synchronization between the Storware Backup & Recovery node and the Active Directory (AD) domain controllers. A time drift of more than 5 minutes can result in authentication failures.
Synchronizing Time
You can synchronize time using either timedatectl (with systemd) or ntpd.
Option 1: Using timedatectl (systemd-based systems)
1. Check the current time settings:
  timedatectl status
2. Enable NTP time synchronization:
  timedatectl set-ntp true
3. If needed, manually set the time:
  timedatectl set-time "YYYY-MM-DD HH:MM:SS"
Note: You must have internet access or a configured internal NTP server for NTP sync to work.
Option 2: Using ntpd
1. Install the NTP service (if not already installed):
  yum install ntp
2. Enable and start the service:
  systemctl enable ntpd --now
3. Verify synchronization:
  ntpq -p
Verify hostname
The hostname must be correctly set and resolvable within the domain environment. Kerberos and SMB services use the system hostname during authentication and file share access.
1. Check the current hostname:
  hostnamectl status
  Example output:
  Static hostname: demo-node
2. Ensure the hostname is not set to localhost or a generic value.
3. Confirm that the hostname maps to the correct IP in /etc/hosts:
  10.0.0.11 demo-node.demo.lab demo-node
Configure Samba
Samba is responsible for providing SMB (Server Message Block) protocol support on Linux systems, which is required for Instant Restore operations. In an Active Directory-integrated environment, Samba must be properly configured to:
- Join the domain
- Authenticate users via Kerberos
- Allow Storware Backup & Recovery to expose and access SMB shares securely
The configuration must reflect your domain structure, network interfaces, and identity mapping scheme. Key parameters include:
- realm – Specifies the Kerberos realm (AD domain) used for authentication.
- security = ADS – Enables Active Directory domain services mode.
- workgroup – The NetBIOS domain name.
- idmap config – Defines how user and group IDs are mapped between AD and the local system.
- interfaces – Limits Samba to specific network interfaces.
- winbind – Ensures proper domain user and group resolution.
Example of samba configuration file /etc/samba/smb.conf:
```
[global]
  bind interfaces only = Yes
  dedicated keytab file = /etc/krb5.keytab
  disable spoolss = Yes
  interfaces = lo eth0
  kerberos method = secrets and keytab
  realm = DEMO.LAB
  security = ADS
  server max protocol = SMB2_02
  template homedir = /home/%U
  template shell = /bin/bash
  username map = /usr/local/samba/etc/user.map
  winbind enum groups = Yes
  winbind enum users = Yes
  winbind nss info = rfc2307
  winbind refresh tickets = Yes
  winbind use default domain = Yes
  workgroup = DEMOLAB
  idmap config * : range = 2000-9999
  idmap config storlab:backend = ad
  idmap config storlab:schema_mode = rfc2307
  idmap config storlab:range = 10000-999999
  idmap config storlab:unix_nss_info = yes
  idmap config * : backend = tdb
  guest ok = Yes
  map acl inherit = Yes
  printing = bsd
  vfs objects = acl_xattr
```
Create User Map File
Samba uses a user mapping file to map Windows domain users to local Linux users. This is especially important for ensuring correct permissions and access control during file-sharing operations, such as Instant Restore.
In the smb.conf configuration (Step 5), the following line defines the path to the user map file:
```
username map = /usr/local/samba/etc/user.map
```
You need to create this file and define user mapping rules as follows:
1. Create the user map file (if it doesn’t already exist):
  mkdir -p /usr/local/samba/etc nano /usr/local/samba/etc/user.map
2. Add the following content to the file:
  !root = STORLAB\Administrator !vprotect = *
  - !root = STORLAB\Administrator maps the domain Administrator user to the local root user.
  - !vprotect = * maps all other users to the local vprotect user, which is used by Storware Backup and Recovery.
Join the domain
After configuring Kerberos and Samba, the system must be joined to the Active Directory (AD) domain. This step establishes trust between the Storware Backup & Recovery node and the domain, enabling domain-based authentication via Kerberos and SMB.
Steps:
1. Use the net ads join command to join the domain:
  net ads join -U administrator
  - Replace administrator with a domain user that has permission to join machines to the domain.
  - You will be prompted to enter the domain password.
2. If successful, you should see output similar to:
  Using short domain name -- DEMO.LAB Joined 'DEMO-NODE' to dns domain 'demo.lab'
Update NSS Configuration
To allow the system to recognize and resolve domain users and groups provided by Active Directory, you need to update the Name Service Switch (NSS) configuration. This tells Linux to use the winbind service (from Samba) alongside local files for user and group resolution.
Steps:
1. Open the NSS configuration file:
  nano /etc/nsswitch.conf
2. Locate the following lines:
  passwd: files group: files
3. Modify them to include winbind as shown below:
  passwd: files winbind group: files winbind
Enable and Start winbind Service Start and enable the service:
```
systemctl enable winbind --now
```

Preparing the Environment without Active Directory

In environments where Active Directory is not used, Instant Restore can still function by configuring Samba in standalone mode. In this case, access to the SMB share is provided using a local system account.

Samba Configuration (Standalone Mode)

To configure Samba without domain integration:

Open or create the Samba configuration file:
```
nano /etc/samba/smb.conf
```
Add the following minimal configuration to the [global] section:
```
[global]
    guest account = vprotect
    security = USER
    server max protocol = SMB2_02
    idmap config * : backend = tdb
```
- guest account – Defines the local system user used for guest access (e.g., vprotect).
- security = USER – Enables standalone user-based access control (not domain-authenticated).
- server max protocol – Limits the SMB protocol version for compatibility (optional but recommended).
- idmap config – Specifies the backend used for mapping user and group IDs (for basic local handling).
Ensure that the user defined in the guest account parameter exists on the system. This user is used by Samba to handle unauthenticated (guest) access, which is required for Instant Restore operations in environments without Active Directory. How to Verify If the User Exists
To check if the user (e.g., vprotect) exists on the system, run:
```
id vprotect
```
- If the user exists, the command will return information about the user's UID, GID, and group memberships.
- If the user does not exist, you will see an error like:
  id: ‘vprotect’: no such user
How to Create the User
If the user does not exist, create it using the following command:
```
useradd --system --no-create-home --shell /sbin/nologin vprotect
```
This creates a system-level user with no login access and no home directory, which is suitable for use as a service account.

Restore

Log in to the Storware Backup & Recovery WebUI.
Navigate to: Virtual Environments → Instances
Locate the VM you wish to restore.
From the Action menu, select Restore, or click the VM name to open its details and choose Restore from the top menu of the detailed view.
Select Instant Restore
In the Instant Restore Wizard, configure the following:
- General
  - Select backup location Select the specific backup instance from which the virtual machine will be restored.
  - Virtualization Provider Specify the target hypervisor or virtualization manager where the VM should be restored.
  - Change name of the restored virtual environment Enable this option to assign a custom name to the restored VM; disable it to retain the original name.
- Storage
  - Live Storage Migration An option that enables you to migrate the virtual disk of a running virtual machine to a different storage location without requiring a shutdown. You must specify the target path where the disk will be restored during the process.
  - Customize disk layout You can exclude a disk from the restore operation or define a custom target path for restoring the selected disk.
  - Time for auto-unmount This setting is used to define how long an instant-restored virtual machine stays mounted from the backup storage before the system performs a cleanup and releases the storage resources.
- Networking Choose the virtual switch or network to which the restored virtual machine will be connected.
- Advanced
  - Power on VM after restore Starts the restored virtual machine immediately after the restore process completes.
  - Fail task if restored VM cannot be powered on. Marks the restore task as failed if the virtual machine fails to start after restoration.
Review the summary
Click Restore

Collecting Hyper-v Agent logs

For Storware Backup and Recovery Hyper-v agent, logs are stored in this folder: c:\Program Files\Hyper-v Agent\bin\Logs

PreviousMicrosoft Hyper-V NextNutanix Acropolis Hypervisor (AHV)

Last updated 21 days ago

Azure Stack HCI

This section introduces the process of backing up and restoring Azure Stack HCI.

Overview

Key Features:

Virtualization with Hyper-V Azure Stack HCI uses Hyper-V as its core virtualization engine for running Windows and Linux virtual machines.
Hyper-Converged Infrastructure Combines compute, storage, and networking in a single, integrated solution with high availability through clustering.
Azure Integration Seamlessly connects with Azure services, such as:
- Azure Arc for centralized management
- Azure Monitor for performance and health monitoring
Modern Management Administered through Windows Admin Center (WAC) with simplified tools for cluster deployment, updates, and monitoring.
Subscription-Based Licensing Licensed through an Azure subscription, billed per physical CPU core.

Resilient Change Tracking (RCT) in Azure Stack HCI

This functionality is essential in Azure Stack HCI environments where performance, scale, and operational efficiency are critical.

To ensure data integrity and resilience, RCT uses a three-tier bitmap storage approach:

In-memory bitmap – used during normal VM operation for fast and granular change tracking.
Two on-disk bitmaps – persist through host migrations or unexpected shutdowns.

RCT metadata is associated with VHD/VHDX files and follows the virtual machine during live migrations, maintaining continuity of backup operations.

Benefits of RCT-Based Backups

Faster incremental backups
Reduced system load
Improved backup reliability
Better resilience during failures or migrations

Network requirements

Source

Destination

Ports

Description

Node

Hyper-V host

50881/tcp for HTTP

Storware Backup & Recovery Hyper-V agent - firewall rules are automatically applied when the agent is installed.

Node

Hyper-V host

50882/tcp for HTTPS

Hyper-V agent - firewall rules are automatically applied when the agent is installed.

Node

Hyper-V host

445/tcp

Instant Restore using SMB

Supported features

Hyper-V Agent

Supported versions

20H2, 21H2, 22H2, 23H2

The last snapshot is kept on the hypervisor for incremental backups

Yes

Access to hypervisor OS required

Proxy VM required

Full backup

Supported

Incremental backup

Supported

Restore

Supported

File-level restore

Supported

VM disk exclusion

Supported

Quiesced snapshots

Supported

Snapshots management

Supported

Snapshots management

Supported

Pre/post command execut

Supported

Access to VM disk backup over iSCSI

Supported

VM name-based policy assignme

Supported

VM tag-based policy assignment

Not supported

Power-on VM after restore

Supported

Hyper-V agent installation

Prerequisites

Before installing the Hyper-V agent, ensure the following requirements are met:

.NET Framework 4.7.2 or higher must be installed on the system.
- The agent installation package includes the required .NET components, but it's recommended to verify that the appropriate version is already present or updated during installation.
- You can also download it from the official Microsoft website:
Visual C++ Redistributable 2013 and 2015 are required if Dell EMC Data Domain is used as the backup destination. Download from Microsoft:
Hyper-V VM configuration version 6.2 or higher is required for Resilient Change Tracking (RCT) to function correctly. RCT is supported on Windows Server 2016 and later, but only for VMs with the appropriate configuration version.\
To check the VM version, run the following PowerShell command on the Hyper-V host:
```
Get-VM * | Format-Table Name, Version
```
Production checkpoints must be supported and enabled for quiesced (application-consistent) snapshots. The backup process relies on the Production Checkpoints feature to create consistent VM snapshots without shutting down or suspending the VM.
To verify or configure checkpoint type:
1. Open Hyper-V Manager.
2. Right-click the virtual machine and select Settings.
3. Under Management, select Checkpoints.
4. Ensure that "Use production checkpoints" is selected.
  - If the VM does not support production checkpoints, fallback to standard checkpoints may be automatically enabled.
Alternatively, use PowerShell to check and configure:
```
Get-VM -Name "<VMName>" | Select-Object Name, CheckpointType
```

Installation

To enable backup and restore operations for Microsoft Hyper-V, you must install the Hyper-V Agent on each Hyper-V host. Follow the steps below to complete the installation:\

Download the installer Download the latest Hyper-V Agent package from the official Storware repository: 📦
Prepare the Installation Files - Copy the extracted installation files to the target Hyper-V host. - Navigate to the installation folder and launch setup.exe.\
Run the Installation Wizard
1. In the welcome screen, click Next to proceed.
2. Choose the installation directory for the agent or accept the default path. Click Next.
3. Enter a secure password for agent authentication.
  This password will be required when adding the Hyper-V host to Storware Backup and Recovery. Important: Do not use the ^ or \ characters in the password, as they may cause issues during inventory synchronization.
4. Review your settings and click Next to begin the installation.
5. If prompted by Windows User Account Control (UAC), click Yes to allow the installation.
6. Once installation is complete, click Finish to exit the wizard.

Quiet installation

Syntax

setup.exe /S /v"PASS=<YourPassword> TRANSPORT=<TransportMethod>"

Parameters

PASS=<YourPassword> Sets the password for secure communication between the agent and Storware Backup and Recovery.
⚠️ Note: Avoid using the characters ^ and \ in the password to prevent synchronization errors.
TRANSPORT=[HTTP|HTTPS|BOTH] Specifies the communication method(s) the agent should support:
- HTTP – Use unencrypted communication
- HTTPS – Use encrypted communication
- BOTH – Enable both methods

Example Command

setup.exe /S /v"PASS=MySecurePassword123 TRANSPORT=HTTPS"

The installer will run silently and complete the installation using the provided parameters. No user interaction is required.

Protecting Azure Stack HCI

After installing the Hyper-V Agent on the host machine, the next step is to register the Azure Stack HCI environment within the Storware Backup & Recovery WebUI.

Adding an Azure Stack HCI

Log in to the Storware Backup & Recovery WebUI.
Navigate to: Virtual Environments → Virtualization Providers.
Click the Create button to open the Add new Virtualization Provider.
Select Microsoft Hyper-V / Azure Stack HCI from the drop down menu.

Fill in the Required Fields

General Tab

Node Config Select the node configuration used during communication with the Hyper-V.
Infrastructure
- Failover Cluster Select this option when adding an Azure Stack HCI.
Host Enter the IP address or hostname of the Hyper-V host or SCVMM server address in URL format, using either http or https depending on the transport method selected during the agent installation.
Password Provide the password set during the Hyper-V Agent installation. This password is used for secure communication with the host.
Trust Cerificates Enables or disables certificate validation for secure connections - when enabled, system will verify that the remote system presents a trusted SSL/TLS certificate.

Microsoft Hyper-V / Azure Stack HCI Settings Tab

Number of Disk Import/Export Threads Set the number of parallel threads used for importing and exporting disk data during backup and restore operations.
- Default: 1

Restoring Hyper-V virtual machines

Restores can be performed directly from the Storware WebUI, with options to restore to the original location or an alternate host.

Types of Restore Operations

Restore to virtualization manager Restores the virtual machine directly to the hypervisor or virtualization platform (e.g., Hyper-V or SCVMM). This method recreates the VM within the managed environment, preserving its configuration and metadata. This method allows you to restore individual virtual disks selectively.
Restore to the node Exports the virtual machine or its disks to the Storware node’s local filesystem or a specified path. Typically used for manual recovery, migration, or advanced troubleshooting.
Instant restore Mounts the backup image directly from the backup storage without transferring data. The VM becomes immediately accessible and operational, significantly reducing recovery time for critical systems. Live Storage Migration option can be used to transfer the data in the background.

Restore to virtualization manager

Log in to the Storware Backup & Recovery WebUI.
Navigate to: Virtual Environments → Instances
Locate the VM you wish to restore.
From the Action menu, select Restore, or click the VM name to open its details and choose Restore from the top menu of the detailed view.
Select Restore to virtualization manager
In the Restore Wizard, configure the following:
- General
  - Select backup location Select the specific backup instance from which the virtual machine will be restored.
  - Virtualization Provider Specify the target hypervisor or virtualization manager where the VM should be restored.
  - Change name of the restored virtual environment Enable this option to assign a custom name to the restored VM; disable it to retain the original name.
- Storage For each virtual disk, you can configure the following restore options:
  - Disk allocation format Choose the disk provisioning type for the restored virtual disk:
    Fixed size – Pre-allocates the full disk size on storage.
    Dynamically allocated – Allocates storage space as data is written.
  - Restore path Define the target directory on the Hyper-V host where the virtual disk will be restored.
  - Exclude Enable this option to exclude the selected disk from the restore operation. Useful when partial disk recovery is required.
- Networking Choose the virtual switch or network to which the restored virtual machine will be connected.
- Advanced
  - Delete if virtual machine already exist Automatically removes the existing VM with the same name before restoring.
  - Power on VM after restore Starts the restored virtual machine immediately after the restore process completes.
  - Fail task if restored VM cannot be powered on. Marks the restore task as failed if the virtual machine fails to start after restoration.
Review the summary
Click Restore

Restore to the node

Log in to the Storware Backup & Recovery WebUI.
Navigate to: Virtual Environments → Instances
Locate the VM you wish to restore.
From the Action menu, select Restore, or click the VM name to open its details and choose Restore from the top menu of the detailed view.
Select Restore to the node
In the Restore windows configure the following:
- Select backup location Select the specific backup instance from which the virtual machine will be restored.
- Choose node Select the Storware node where the restored data will be saved.
- Choose restore path Specify the destination directory on the selected node for the restored files.
- Restore only selected files Enable this option to browse and restore specific virtual disk or metadata files, rather than restoring the entire virtual machine.
Click Restore

Instant Restore

This feature significantly reduces recovery time, especially for critical systems that require fast availability.

Toghether with Instant Restore Live Storage Migration option can be used to transfer the data in the background

Instant Restore requires that the backup destination used for the VM is a synthetic type.

Storage Live Migration

When used in combination with Instant Restore, Storage Live Migration allows seamless background transfer of virtual machine data from backup storage to production storage.

Preparing the Environment with Active Directory

In Active Directory-based environments, Storware Backup and Recovery nodes must be joined to the domain to support Instant Restore.

Prerequisites

Before configuration, ensure the following are available:

Fully Qualified Domain Name (FQDN), e.g., demo.lab
NetBIOS Domain Name, e.g., DEMOLAB
Domain Administrator Account
Required Packages:
```
yum install samba samba-winbind
```

Configuration Steps

Verify DNS Configuration Ensure the node uses the correct AD DNS servers and the search domain is set:
```
cat /etc/resolv.conf
```
Example output:
```
search demo.lab
nameserver 10.0.0.1
nameserver 10.0.0.2
```
Configure Kerberos to integrate with Active Directory The /etc/krb5.conf file defines how the system interacts with the Kerberos authentication infrastructure, which is essential for integrating with an Active Directory (AD) domain.\
Here is example of a /etc/krb5.conf file:
```
[logging]
  default = FILE:/var/log/krb5libs.log
  kdc = FILE:/var/log/krb5kdc.log
  admin_server = FILE:/var/log/kadmind.log

[libdefaults]
  default_realm = DEMO.LAB
  dns_lookup_realm = false
  dns_lookup_kdc = true
```
Here's what each section and setting does in the provided configuration:
- [logging] Specifies where log files related to Kerberos operations will be written. This helps in debugging Kerberos issues.
  - default – Logs for general Kerberos library functions.
  - kdc – Logs for Key Distribution Center operations.
  - admin_server – Logs related to administrative functions such as managing principals.
- [libdefaults] Controls global Kerberos client behavior.
  - default_realm – Sets the default Kerberos realm the system will use (must match your AD domain, in uppercase).
  - dns_lookup_realm = false – Disables automatic realm detection via DNS TXT records (manual configuration is used).
  - dns_lookup_kdc = true – Enables automatic lookup of Key Distribution Center (KDC) servers via DNS SRV records. This simplifies configuration by not requiring static KDC entries.
Synchronize Time
Kerberos authentication requires accurate time synchronization between the Storware Backup & Recovery node and the Active Directory (AD) domain controllers. A time drift of more than 5 minutes can result in authentication failures.
Synchronizing Time
You can synchronize time using either timedatectl (with systemd) or ntpd.
Option 1: Using timedatectl (systemd-based systems)
1. Check the current time settings:
  timedatectl status
2. Enable NTP time synchronization:
  timedatectl set-ntp true
3. If needed, manually set the time:
  timedatectl set-time "YYYY-MM-DD HH:MM:SS"
Note: You must have internet access or a configured internal NTP server for NTP sync to work.
Option 2: Using ntpd
1. Install the NTP service (if not already installed):
  yum install ntp
2. Enable and start the service:
  systemctl enable ntpd --now
3. Verify synchronization:
  ntpq -p
Verify hostname
The hostname must be correctly set and resolvable within the domain environment. Kerberos and SMB services use the system hostname during authentication and file share access.
1. Check the current hostname:
  hostnamectl status
  Example output:
  Static hostname: demo-node
2. Ensure the hostname is not set to localhost or a generic value.
3. Confirm that the hostname maps to the correct IP in /etc/hosts:
  10.0.0.11 demo-node.demo.lab demo-node
Configure Samba
Samba is responsible for providing SMB (Server Message Block) protocol support on Linux systems, which is required for Instant Restore operations. In an Active Directory-integrated environment, Samba must be properly configured to:
- Join the domain
- Authenticate users via Kerberos
- Allow Storware Backup & Recovery to expose and access SMB shares securely
The configuration must reflect your domain structure, network interfaces, and identity mapping scheme. Key parameters include:
- realm – Specifies the Kerberos realm (AD domain) used for authentication.
- security = ADS – Enables Active Directory domain services mode.
- workgroup – The NetBIOS domain name.
- idmap config – Defines how user and group IDs are mapped between AD and the local system.
- interfaces – Limits Samba to specific network interfaces.
- winbind – Ensures proper domain user and group resolution.
Example of samba configuration file /etc/samba/smb.conf:
```
[global]
  bind interfaces only = Yes
  dedicated keytab file = /etc/krb5.keytab
  disable spoolss = Yes
  interfaces = lo eth0
  kerberos method = secrets and keytab
  realm = DEMO.LAB
  security = ADS
  server max protocol = SMB2_02
  template homedir = /home/%U
  template shell = /bin/bash
  username map = /usr/local/samba/etc/user.map
  winbind enum groups = Yes
  winbind enum users = Yes
  winbind nss info = rfc2307
  winbind refresh tickets = Yes
  winbind use default domain = Yes
  workgroup = DEMOLAB
  idmap config * : range = 2000-9999
  idmap config storlab:backend = ad
  idmap config storlab:schema_mode = rfc2307
  idmap config storlab:range = 10000-999999
  idmap config storlab:unix_nss_info = yes
  idmap config * : backend = tdb
  guest ok = Yes
  map acl inherit = Yes
  printing = bsd
  vfs objects = acl_xattr
```
Create User Map File
Samba uses a user mapping file to map Windows domain users to local Linux users. This is especially important for ensuring correct permissions and access control during file-sharing operations, such as Instant Restore.
In the smb.conf configuration (Step 5), the following line defines the path to the user map file:
```
username map = /usr/local/samba/etc/user.map
```
You need to create this file and define user mapping rules as follows:
1. Create the user map file (if it doesn’t already exist):
  mkdir -p /usr/local/samba/etc nano /usr/local/samba/etc/user.map
2. Add the following content to the file:
  !root = STORLAB\Administrator !vprotect = *
  - !root = STORLAB\Administrator maps the domain Administrator user to the local root user.
  - !vprotect = * maps all other users to the local vprotect user, which is used by Storware Backup and Recovery.
Join the domain
After configuring Kerberos and Samba, the system must be joined to the Active Directory (AD) domain. This step establishes trust between the Storware Backup & Recovery node and the domain, enabling domain-based authentication via Kerberos and SMB.
Steps:
1. Use the net ads join command to join the domain:
  net ads join -U administrator
  - Replace administrator with a domain user that has permission to join machines to the domain.
  - You will be prompted to enter the domain password.
2. If successful, you should see output similar to:
  Using short domain name -- DEMO.LAB Joined 'DEMO-NODE' to dns domain 'demo.lab'
Update NSS Configuration
To allow the system to recognize and resolve domain users and groups provided by Active Directory, you need to update the Name Service Switch (NSS) configuration. This tells Linux to use the winbind service (from Samba) alongside local files for user and group resolution.
Steps:
1. Open the NSS configuration file:
  nano /etc/nsswitch.conf
2. Locate the following lines:
  passwd: files group: files
3. Modify them to include winbind as shown below:
  passwd: files winbind group: files winbind
Enable and Start winbind Service Start and enable the service:
```
systemctl enable winbind --now
```

Preparing the Environment without Active Directory

Samba Configuration (Standalone Mode)

To configure Samba without domain integration:

Open or create the Samba configuration file:
```
nano /etc/samba/smb.conf
```
Add the following minimal configuration to the [global] section:
```
[global]
    guest account = vprotect
    security = USER
    server max protocol = SMB2_02
    idmap config * : backend = tdb
```
- guest account – Defines the local system user used for guest access (e.g., vprotect).
- security = USER – Enables standalone user-based access control (not domain-authenticated).
- server max protocol – Limits the SMB protocol version for compatibility (optional but recommended).
- idmap config – Specifies the backend used for mapping user and group IDs (for basic local handling).
Ensure that the user defined in the guest account parameter exists on the system. This user is used by Samba to handle unauthenticated (guest) access, which is required for Instant Restore operations in environments without Active Directory. How to Verify If the User Exists
To check if the user (e.g., vprotect) exists on the system, run:
```
id vprotect
```
- If the user exists, the command will return information about the user's UID, GID, and group memberships.
- If the user does not exist, you will see an error like:
  id: ‘vprotect’: no such user
How to Create the User
If the user does not exist, create it using the following command:
```
useradd --system --no-create-home --shell /sbin/nologin vprotect
```
This creates a system-level user with no login access and no home directory, which is suitable for use as a service account.

Restore

Log in to the Storware Backup & Recovery WebUI.
Navigate to: Virtual Environments → Instances
Locate the VM you wish to restore.
From the Action menu, select Restore, or click the VM name to open its details and choose Restore from the top menu of the detailed view.
Select Instant Restore
In the Instant Restore Wizard, configure the following:
- General
  - Select backup location Select the specific backup instance from which the virtual machine will be restored.
  - Virtualization Provider Specify the target hypervisor or virtualization manager where the VM should be restored.
  - Change name of the restored virtual environment Enable this option to assign a custom name to the restored VM; disable it to retain the original name.
- Storage
  - Live Storage Migration An option that enables you to migrate the virtual disk of a running virtual machine to a different storage location without requiring a shutdown. You must specify the target path where the disk will be restored during the process.
  - Customize disk layout You can exclude a disk from the restore operation or define a custom target path for restoring the selected disk.
  - Time for auto-unmount This setting is used to define how long an instant-restored virtual machine stays mounted from the backup storage before the system performs a cleanup and releases the storage resources.
- Networking Choose the virtual switch or network to which the restored virtual machine will be connected.
- Advanced
  - Power on VM after restore Starts the restored virtual machine immediately after the restore process completes.
  - Fail task if restored VM cannot be powered on. Marks the restore task as failed if the virtual machine fails to start after restoration.
Review the summary
Click Restore

Collecting Hyper-v Agent logs

For Storware Backup and Recovery Hyper-v agent, logs are stored in this folder: c:\Program Files\Hyper-v Agent\bin\Logs

PreviousMicrosoft Hyper-V NextNutanix Acropolis Hypervisor (AHV)

Last updated 21 days ago