# Storware Backup & Recovery documentation

<figure><img src="/files/p41lVphPZVC8XHDD8pL5" alt=""><figcaption></figcaption></figure>

This is the official documentation for Storware Backup & Recovery software. Here you will find all the information needed to setup, configure and manage backup for your virtual and cloud infrastructure.

## About Storware Backup & Recovery

Storware Backup & Recovery is the backup and snapshot-management solution suite for virtual environments and the cloud. With the "freedom of choice" philosophy, Storware Backup & Recovery provides robust data protection and disaster recovery capabilities. In this documentation, you will learn how to use, install and deploy Storware Backup & Recovery.

## Contact

www: [https://www.storware.eu](http://www.storware.eu)

support: <https://storware.atlassian.net/servicedesk/customer/portal/10>

e-mail: <info@storware.eu>


# Table of Contents

1. [Changelog](/70/changelog)
2. [Overview](/70/overview)
   * [Main Features](/70/overview/main-features)
   * [Architecture](/70/overview/architecture)
   * [Typical Scenarios](/70/overview/typical-scenarios)
   * [Support Matrix](/70/overview/support-matrix)
   * [Platform Requirements](/70/deployment/platform-requirements)
   * [Sizing Guide](/70/deployment/sizing)
     * [Small](/70/deployment/sizing/small-environment)
     * [Medium](/70/deployment/sizing/medium)
     * [Large](/70/deployment/sizing/large-environment)
   * [Storware Endpoints](/70/deployment/sizing/storware-endpoints)
     * [Small](/70/deployment/sizing/storware-endpoints/small)
     * [Medium](/70/deployment/sizing/storware-endpoints/medium)
     * [Large](/70/deployment/sizing/storware-endpoints/large)
     * [Very large](/70/deployment/sizing/storware-endpoints/very-large)
   * [Licensing](/70/overview/licensing)
   * [Product Life Cycle](/70/overview/life-cycle)
3. [Deployment](/70/deployment)
   1. [Quick Install (All-In-One)](/70/deployment/installation/quick-install-all-in-one)
   2. [Installation using Ansible playbook](/70/deployment/installation/installation-using-ansible-playbook)
   3. [Installation with RPMs](/70/deployment/installation/installation-with-rpms)
   4. [Virtual Appliance](/70/deployment/installation/virtual-appliance)
   5. [RHV/oVirt/OLVM Virtual Appliance](/70/deployment/installation/virtual-appliance/rhv-ovirt-olvm-virtual-appliance)
   6. [Citrix Hypervisor | XCP-ng Virtual Appliance](/70/deployment/installation/virtual-appliance/citrix-hypervisor-or-xcp-ng-virtual-appliance)
   7. [VMware Virtual Appliance](/70/deployment/installation/virtual-appliance/vmware-virtual-appliance)
   8. [Nutanix Acropolis Hypervisor (AHV)](/70/deployment/installation/virtual-appliance/nutanix-virtual-appliance)
   9. [Backup Destinations](/70/deployment/backup-destinations)
      * [File System](/70/deployment/backup-destinations/filesystem)
        * [Synthetic File System](/70/deployment/backup-destinations/filesystem/synthetic-file-system)
          * [XFS](/70/deployment/backup-destinations/filesystem/synthetic-file-system/synthetic-xfs)
          * [DD Boost](/70/deployment/backup-destinations/filesystem/synthetic-file-system/synthetic-ddboost)
        * [isoLayer (Synthetic)](/70/deployment/backup-destinations/filesystem/isolayer)
        * [File system](/70/deployment/backup-destinations/filesystem/regular-filesystem)
          * [Virtual Data Optimizer (VDO)](/70/deployment/backup-destinations/filesystem/regular-filesystem/virtual-data-optimizer-vdo)
        * [Catalogic Software vStor](/70/deployment/backup-destinations/filesystem/catalogic-software-vstor)
      * [Deduplication Appliances](/70/deployment/backup-destinations/deduplication-appliances)
        * [Dell EMC Data Domain](/70/deployment/backup-destinations/deduplication-appliances/dell-emc-data-domain)
        * [Huawei OceanProtect](/70/deployment/backup-destinations/deduplication-appliances/huawei-oceanprotect)
        * [HPE StoreOnce](/70/deployment/backup-destinations/deduplication-appliances/hpe-storeonce)
        * [Exagrid](/70/deployment/backup-destinations/deduplication-appliances/exagrid)
        * [Neverfail HybriStor](/70/deployment/backup-destinations/deduplication-appliances/neverfail-hybristor)
      * [Object Storage](/70/deployment/backup-destinations/object-storage)
        * [Alibaba Cloud OSS](/70/deployment/backup-destinations/object-storage/alibaba-cloud)
        * [AWS S3 or S3-compatible](/70/deployment/backup-destinations/object-storage/aws-s3-or-s3-compatible)
        * [Ceph Rados Gateway](/70/deployment/backup-destinations/object-storage/ceph-rados-gateway)
        * [Cloudian S3](/70/deployment/backup-destinations/object-storage/cloudian)
        * [Wasabi](/70/deployment/backup-destinations/object-storage/wasabi)
        * [Google Cloud Storage](/70/deployment/backup-destinations/object-storage/google-cloud-storage)
        * [IBM Cloud Object Storage](/70/deployment/backup-destinations/object-storage/ibm-cloud-object-storage)
        * [Microsoft Azure Blob Storage](/70/deployment/backup-destinations/object-storage/microsoft-azure-blob-storage)
        * [Nutanix Objects](/70/deployment/backup-destinations/object-storage/nutanix-objects)
        * [OpenStack SWIFT](/70/deployment/backup-destinations/object-storage/openstack-swift)
        * [Oracle Cloud Infrastructure Object Storage](/70/deployment/backup-destinations/object-storage/oracle-cloud-infrastructure-object-storage)
        * [Scality RING](/70/deployment/backup-destinations/object-storage/scality-ring)
      * [Enterprise Backup Providers](/70/deployment/backup-destinations/enterprise-backup-providers)
        * [Dell EMC Avamar](/70/deployment/backup-destinations/enterprise-backup-providers/dell-emc-avamar)
        * [Dell EMC Networker](/70/deployment/backup-destinations/enterprise-backup-providers/dell-emc-networker)
        * [IBM Spectrum Protect](/70/deployment/backup-destinations/enterprise-backup-providers/ibm-spectrum-protect)
        * [Micro Focus Data Protector](/70/deployment/backup-destinations/enterprise-backup-providers/micro-focus-data-protector)
        * [Veritas NetBackup](/70/deployment/backup-destinations/enterprise-backup-providers/veritas-netbackup)
        * [Rubrik Managed Volumes](/70/deployment/backup-destinations/filesystem/rubrik)
      * [Tape Pools (Technical Preview)](/70/deployment/backup-destinations/tape-pools)
   10. [Initial Configuration](/70/deployment/initial-configuration)
   11. [High Availability](/70/deployment/high-availability)
       * [2 Node Cluster](/70/deployment/high-availability/2-node-cluster)
       * [3 Node Cluster](/70/deployment/high-availability/3-node-cluster)
   12. [Common tasks](/70/deployment/common-tasks)
       * [Staging space configuration](/70/deployment/common-tasks/staging-space-configuration)
       * [Enabling HTTPS connectivity for nodes](/70/deployment/common-tasks/enabling-https-connectivity-for-nodes)
       * [LVM setup on Storware Backup & Recovery Node for disk attachment backup mode](/70/deployment/common-tasks/lvm-setup-on-storware-backup-and-recovery-node-for-disk-attachment-backup-mode)
       * [Full versions of libvirt/qemu packages installation](/70/deployment/common-tasks/full-versions-of-libvirt-qemu-packages-installation)
       * [SSH public key authentication](/70/deployment/common-tasks/ssh-public-key-authentication)
       * [Enabling HTTP(S) Proxy for Storware Backup & Recovery](/70/deployment/common-tasks/enabling-proxy)
   13. [Endpoints – how to install](/70/deployment/endpoints-how-to-install)
       * [Installation overview](/70/deployment/endpoints-how-to-install/installation-overview)
         * ["All-in-One" Installation](/70/deployment/endpoints-how-to-install/installation-overview/all-in-one-installation)
         * [Installation with RPMs](/70/deployment/endpoints-how-to-install/installation-overview/installation-with-rpms)
         * [IBM Spectrum Protect server configuration](/70/deployment/endpoints-how-to-install/installation-overview/ibm-spectrum-protect-server-configuration)
       * [Administration levels](/70/deployment/endpoints-how-to-install/administration-levels)
       * [Initial configuration](/70/deployment/endpoints-how-to-install/initial-configuration)
       * [Client deployment](/70/deployment/endpoints-how-to-install/client-deployment)
         * [Deployment packages](/70/deployment/endpoints-how-to-install/client-deployment/deployment-packages)
         * [Client installer](/70/deployment/endpoints-how-to-install/client-deployment/client-installer)
         * [Deployment email](/70/deployment/endpoints-how-to-install/client-deployment/deployment-email)
         * [Client installation using GPO](/70/deployment/endpoints-how-to-install/client-deployment/client-installation-using-gpo)
         * [Silent install](/70/deployment/endpoints-how-to-install/client-deployment/silent-install)
         * [Client application components](/70/deployment/endpoints-how-to-install/client-deployment/client-application-components)
         * [First time log in](/70/deployment/endpoints-how-to-install/client-deployment/first-time-log-in)
       * [Backup and recovery tests](/70/deployment/endpoints-how-to-install/backup-and-recovery-tests)
       * [Common tasks](/70/deployment/endpoints-how-to-install/common-tasks)
         * [OS update](/70/deployment/endpoints-how-to-install/common-tasks/os-update)
         * [Server upgrade](/70/deployment/endpoints-how-to-install/common-tasks/server-upgrade)
         * [Client upgrade](/70/deployment/endpoints-how-to-install/common-tasks/client-upgrade)
         * [Client uninstall](/70/deployment/endpoints-how-to-install/common-tasks/client-uninstall)
4. [Protecting Virtual Environments](/70/protecting-virtual-machines)
   * [Virtual Machines](/70/protecting-virtual-machines/virtual-machines)
     * [VMware vSphere/ESXi](/70/protecting-virtual-machines/virtual-machines/vmware-vsphere)
     * [Microsoft Hyper-V](/70/protecting-virtual-machines/virtual-machines/microsoft-hyper-v)
     * [Azure Stack HCI](/70/protecting-virtual-machines/virtual-machines/azure_stack_hci)
     * [Nutanix Acropolis Hypervisor (AHV)](/70/protecting-virtual-machines/virtual-machines/nutanix-acropolis-ahv)
     * [Red Hat Openshift Virtualization](/70/protecting-virtual-machines/virtual-machines/openshift-virtualization)
     * [Red Hat Virtualization](/70/protecting-virtual-machines/virtual-machines/red-hat-virtualization)
     * [oVirt](/70/protecting-virtual-machines/virtual-machines/ovirt)
     * [Oracle Linux Virtualization Manager](/70/protecting-virtual-machines/virtual-machines/oracle-linux-virtualization-manager)
     * [Oracle VM](/70/protecting-virtual-machines/virtual-machines/oracle-vm)
     * [Proxmox VE](/70/protecting-virtual-machines/virtual-machines/proxmox-ve)
     * [OpenStack](/70/protecting-virtual-machines/virtual-machines/openstack)
     * [OpenNebula](/70/protecting-virtual-machines/virtual-machines/opennebula)
     * [Virtuozzo](/70/protecting-virtual-machines/virtual-machines/virtuozzo)
     * [Citrix Hypervisor (XenServer)](/70/protecting-virtual-machines/virtual-machines/citrix-hypervisor-xenserver)
     * [XCP-ng](/70/protecting-virtual-machines/virtual-machines/xcp-ng)
     * [HPE SimpliVity](/70/protecting-virtual-machines/virtual-machines/hpe-simplivity)
     * [SC//Platform](/70/protecting-virtual-machines/virtual-machines/scale-computing-hc3)
   * [Cloud](/70/protecting-virtual-machines/cloud)
     * [Amazon EC2](/70/protecting-virtual-machines/cloud/aws-ec2)
     * [GCP GCE](/70/protecting-virtual-machines/cloud/gcp-gce)
     * [Azure Cloud](/70/protecting-virtual-machines/cloud/azure-cloud)
   * [Containers](/70/protecting-virtual-machines/protecting-containers)
     * [Kubernetes](/70/protecting-virtual-machines/protecting-containers/kubernetes)
     * [Red Hat OpenShift](/70/protecting-virtual-machines/protecting-containers/red-hat-openshift)
     * [Proxmox VE](/70/protecting-virtual-machines/protecting-containers/proxmox-ve)
   * [Backup & Restore](/70/protecting-virtual-machines/backup-and-restore)
5. [Protecting Microsoft 365](/70/protecting-microsoft-365)
   * [Microsoft 365 organization management](/70/protecting-microsoft-365/microsoft-365-organization-management)
     * [Configure Microsoft 365 access](/70/protecting-microsoft-365/microsoft-365-organization-management/configure-microsoft-365-access)
     * [Add Microsoft 365 organization manually](/70/protecting-microsoft-365/microsoft-365-organization-management/add-microsoft-365-organization-manually)
     * [Add Microsoft 365 organization using the Setup Assistant](/70/protecting-microsoft-365/microsoft-365-organization-management/add-microsoft-365-organization-using-the-setup-assistant)
     * [Account auto-synchronization](/70/protecting-microsoft-365/microsoft-365-organization-management/account-auto-synchronization)
   * [Backup & Restore](/70/protecting-microsoft-365/backup-and-restore)
   * [Suppoted Sharepoint templates and limitations](/70/protecting-microsoft-365/supported-templates-and-limitations)
6. [File Level Backup and Restore - OS Agent](/70/os-agents)
7. [Protecting Applications](/70/protecting-applications)
   * [Applications](/70/protecting-applications/applications)
     * [MSSQL](/70/protecting-applications/applications/mssql)
     * [MySQL/MariaDB](/70/protecting-applications/applications/mysql-mariadb)
     * [PostgreSQL](/70/protecting-applications/applications/postgresql)
     * [DB2](/70/protecting-applications/applications/db2)
     * [Oracle](/70/protecting-applications/applications/oracle)
     * [Relax and Recover - ReaR](/70/protecting-applications/applications/relax-and-recover)
     * [Git](/70/protecting-applications/applications/git)
     * [oVirt/RHV/OLVM](/70/protecting-applications/applications/ovirt-rhv-olvm)
     * [Kubernetes/OpenShift etcd](/70/protecting-applications/applications/kubernetes-openshift-etcd)
   * [Backup & Restore](/70/protecting-applications/backup-and-restore)
8. [Protecting Storage Providers](/70/protecting-storage-providers)
   * [Storage Providers](/70/protecting-storage-providers/storage-providers)
     * [File System](/70/protecting-storage-providers/storage-providers/file-system)
     * [Ceph RBD](/70/protecting-storage-providers/storage-providers/ceph-rbd)
     * [Nutanix Files](/70/protecting-storage-providers/storage-providers/nutanix-files)
     * [Nutanix Volume Groups](/70/protecting-storage-providers/storage-providers/nutanix-volume-groups)
   * [Backup & Restore](/70/protecting-storage-providers/backup-and-restore)
9. [Protecting Endpoints](/70/protecting-endpoints)

* [Add Endpoints](/70/protecting-endpoints/add-endpoints)
* [Backup & Restore](/70/protecting-endpoints/backup-and-restore)
* [Endpoint client](/70/protecting-endpoints/endpoint-client)
  * [Client components](/70/protecting-endpoints/endpoint-client/client-components)
  * [Pausing and resuming](/70/protecting-endpoints/endpoint-client/pausing-and-resuming)
  * [Client console menu](/70/protecting-endpoints/endpoint-client/client-console-menu)
  * [Modifying backup policy](/70/protecting-endpoints/endpoint-client/modifying-backup-policy)

10. [Administration](/70/administration)
11. [Dashboard](/70/administration/dashboard)
12. [Virtual Environments](/70/administration/virtual-environments)
    * [Instances](/70/administration/virtual-environments/instances)
      * [Backup on-demand](/70/administration/virtual-environments/instances/backup-on-demand)
      * [Restore on-demand](/70/administration/virtual-environments/instances/restore-on-demand)
      * [Snapshot Management](/70/administration/virtual-environments/instances/snapshot-management)
    * [Infrastructure](/70/administration/virtual-environments/infrastructure)
    * [Backup SLAs](/70/administration/virtual-environments/backup-slas)
      * [Policies](/70/administration/virtual-environments/backup-slas/policies)
      * [Schedules](/70/administration/virtual-environments/backup-slas/schedules)
    * [Snapshot SLAs](/70/administration/virtual-environments/snapshot-slas)
      * [Policies](/70/administration/virtual-environments/snapshot-slas/policies)
      * [Schedules](/70/administration/virtual-environments/snapshot-slas/schedules)
    * [Recovery Plans](/70/administration/virtual-environments/recovery-plans)
      * [Policies](/70/administration/virtual-environments/recovery-plans/policies)
      * [Schedules](/70/administration/virtual-environments/recovery-plans/schedules)
    * [Mounted Backups (File-level Restore)](/70/administration/virtual-environments/file-level-restore-mounted-backup)
13. [Storage](/70/administration/storage-providers)
    * [Instances](/70/administration/storage-providers/instances)
      * [Backup on-demand](/70/administration/storage-providers/instances/backup-on-demand)
      * [Restore on-demand](/70/administration/storage-providers/instances/restore-on-demand)
    * [Infrastructure](/70/administration/storage-providers/infrastructure)
    * [Backup SLAs](/70/administration/storage-providers/backup-slas)
      * [Policies](/70/administration/storage-providers/backup-slas/policies)
      * [Schedules](/70/administration/storage-providers/backup-slas/schedules)
    * [Snapshot SLAs](/70/administration/storage-providers/snapshot-slas)
      * [Policies](/70/administration/storage-providers/snapshot-slas/policies)
      * [Schedules](/70/administration/storage-providers/snapshot-slas/schedules)
    * [Mounted Backups (File-level Restore)](/70/administration/storage-providers/file-level-restore-mounted-backup)
14. [Cloud](/70/administration/cloud)
    * [Instances](/70/administration/cloud/instances)
    * [Service Providers](/70/administration/cloud/service-providers)
    * [Backup SLAs](/70/administration/cloud/backup-slas)
      * [Policies](/70/administration/cloud/backup-slas/policies)
      * [Schedules](/70/administration/cloud/backup-slas/schedules)
    * [Download](/70/administration/cloud/download)
15. [Applications](/70/administration/applications)
    * [Instances](/70/administration/applications/instances)
    * [Execution Configurations](/70/administration/applications/execution-configurations)
    * [Backup SLAs](/70/administration/applications/backup-slas)
16. [Endpoints](/70/administration/endpoints)
    * [Environment](/70/administration/endpoints/environment)
    * [Administrators](/70/administration/endpoints/administrators)
    * [Endpoints Server Management](/70/administration/endpoints/admin)
      * [Dashboard](/70/administration/endpoints/admin/dashboard)
      * [Packages](/70/administration/endpoints/admin/packages)
      * [Organizations](/70/administration/endpoints/admin/organizations)
    * [Endpoints Administrator](/70/administration/endpoints/organization-admin)
      * [Dashboard](/70/administration/endpoints/organization-admin/dashboard)
      * [Users](/70/administration/endpoints/organization-admin/users)
        * [Local users](/70/administration/endpoints/organization-admin/users/local-users)
        * [LDAP users](/70/administration/endpoints/organization-admin/users/ldap-users)
      * [Devices](/70/administration/endpoints/organization-admin/devices)
        * [Devices list view](/70/administration/endpoints/organization-admin/devices/devices-list-view)
        * [Device status](/70/administration/endpoints/organization-admin/devices/device-status)
      * [Backup SLA](/70/administration/endpoints/organization-admin/backup-sla)
        * [Create a new Backup SLA](/70/administration/endpoints/organization-admin/backup-sla/create-a-new-backup-sla)
          * [GENERAL](/70/administration/endpoints/organization-admin/backup-sla/create-a-new-backup-sla/general)
          * [WINDOWS](/70/administration/endpoints/organization-admin/backup-sla/create-a-new-backup-sla/windows)
          * [MAC OS (technical preview)](/70/administration/endpoints/organization-admin/backup-sla/create-a-new-backup-sla/mac-os-technical-preview)
          * [EMAIL CLIENTS](/70/administration/endpoints/organization-admin/backup-sla/create-a-new-backup-sla/email-clients)
          * [Backup SLA management](/70/administration/endpoints/organization-admin/backup-sla/backup-sla-management)
          * [Backup SLA removal](/70/administration/endpoints/organization-admin/backup-sla/backup-sla-removal)
      * [Restore Jobs](/70/administration/endpoints/organization-admin/restore-jobs)
      * [Client Deployments](/70/administration/endpoints/organization-admin/client-deployments)
17. [Reporting](/70/administration/reporting)
    * [Virtual Environments](/70/administration/reporting/virtual-environments)
    * [Storage](/70/administration/reporting/storage-providers)
    * [Cloud](/70/administration/reporting/cloud)
    * [Applications](/70/administration/reporting/applications)
    * [Audit Log](/70/administration/reporting/audit-log)
18. [Nodes](/70/administration/nodes)
    * [Instances](/70/administration/nodes/instances)
    * [Node Configurations](/70/administration/nodes/node-configurations)
19. [Access Management](/70/administration/users)
    * [Users](/70/administration/users/users)
    * [Groups](/70/administration/users/groups)
    * [Roles](/70/administration/users/roles)
    * [OS Credentials](/70/administration/users/os-credentials)
20. [Settings](/70/administration/settings)
    * [Global Settings](/70/administration/settings/settings)
    * [Internal DB Backup](/70/administration/settings/internal-db-backup)
    * [Notification Rules](/70/administration/settings/notification-rules)
    * [Mailing Lists](/70/administration/settings/mailing-lists)
    * [Endpoints Global Settings](https://github.com/Storware/backup-and-recovery-manual/blob/master/readme/administration/settings/endpoints-global-settings.md)
21. [Upgrade](/70/administration/upgrade)
22. [CLI Reference](/70/administration/cli-reference)
23. [CLI v2 Reference (technical preview)](/70/administration/cli-v2-reference)
24. [Integration](/70/api-integration)
25. [Integration Plugins](/70/integrations-plugins)
    * [Red Hat Virtualization UI Plugin](/70/integrations-plugins/redhat-virtualization-plugin)
    * [oVirt UI Plugin](/70/integrations-plugins/ovirt-plugin)
    * [Oracle Linux Virtualization Manager UI Plugin](/70/integrations-plugins/oracle-linux-virtualization-manager-plugin)
    * [OpenStack UI Plugin](/70/integrations-plugins/openstack-plugin)
26. [Troubleshooting](/70/troubleshooting)
    * [How to enable Storware Backup & Recovery DEBUG mode](/70/troubleshooting/how-switch-vprotect-to-debug-mode)
    * [Collecting logs](/70/troubleshooting/collecting-logs)
    * [External log targets](/70/troubleshooting/external-log-targets)
    * [Disaster Recovery](/70/troubleshooting/disaster-recovery)
27. [Known software issues and limitations](https://github.com/Storware/backup-and-recovery-manual/blob/master/readme/known-software-issues-and-limitations.md)
28. [Glossary](/70/glossary)


# Changelog

## Storware Backup & recovery 7.0

**25.09.2024**

Let’s start with expanded platform support, including Debian and Ubuntu. This addition expands user options by providing greater backup and recovery flexibility. Furthermore, the integration with [**Canonical OpenStack**](https://ubuntu.com/openstack) and Canonical KVM ensures seamless operations within this cloud infrastructure, catering to the growing demand for robust cloud solutions.

&#x20;Support for backup sources has also been expanded to include [**VergeOS**](https://www.verge.io/), providing the ultimate protection for the ultra-converged infrastructure of this VMware alternative.

What’s more, you can now back up Proxmox environments with CEPH storage, similar to the functionality offered in OpenStack.

Virtualization support sees a significant boost with the inclusion of generic volume groups for OpenStack and Virtuozzo. This improvement enables users to perform consistent backups for multi-disk VMs.

In the upcoming release, we have also added support for a new backup location: [**Impossible Cloud Storage**](https://www.impossiblecloud.com/).

Deployment has never been easier, thanks to the introduction of an ISO-based installation. Users can now deploy their backup and recovery solutions with unprecedented simplicity, ensuring quick and hassle-free operations.

User experience takes a leap forward with the redesigned configuration wizard. Users can now navigate through configuration with ease, reducing the time and effort required to get the system up and running.

In addition to these key features, Storware Backup and Recovery 7.0 also includes a server framework update from Payara Micro to Quarkus, enhancing performance, scalability and advanced security. The system now automatically detects if the proper network storage is mounted in the backup destination path, adding an extra layer of convenience and security.

Additionally, the OS Agent now detects the type of operating system (Desktop/Server) for Windows and Linux, and includes an option to re-register the agent for better management.

As Storware evolves, certain features will be deprecated, including the “Keep last backup” flag, support for CentOS 7, SSH Transfer backup strategy for RHV, support for Xen and Oracle Virtualization Manager, and the old CLI version from the node.

Storware 7.0 key highlights:

✔️ VergeIO support&#x20;

✔️ Canonical OpenStack and Canonical KVM support&#x20;

✔️ Debian and Ubuntu support&#x20;

✔️ ISO-based Quick Installation&#x20;

✔️ Support for Proxmox and CEPH Integration

## Storware Backup & Recovery 6.2

**14.03.2024**

We’re starting with enhanced Virtuozzo integration, introducing a disk-attachment backup strategy, replacing the conventional SSH Transfer method. Additionally, our latest update allows you to specify MAC addresses for decommissioned instances in both OpenStack and Virtuozzo, ensuring flexibility in restoration processes (of course you can use the original one). KVM standalone hypervisors also received a file-system freeze option for more consistent backups.

What’s more, we've introduced support for OpenMetal. Now you can protect OpenMetal's workloads across OpenStack On-Demand Cloud and Hosted Private Cloud services.

Enjoy enhanced tape management, highlighted by data encryption and support for the object-lock feature in S3 backup destinations. All backup destinations now support an "infinite number of versions retention" setting in the backup policies. Notably, the Data Protector backup destination has undergone significant optimization, promising enhanced performance in this release.

In the realm of Microsoft 365, brace yourself for two updates: private channel support for Teams and a centralized backup/restore data flow enabling the utilization of all supported backup destinations for M365 workloads. Experience efficiency with optimized data verification and clean-up mechanisms within both the OS Agent and M365 integration module.

Our commitment to user experience shines through in the UI enhancements introduced, offering a refreshed and standardized interface across various views including M365, Storage, RBAC, and beyond.

Security remains paramount, with enhancements catering to Horizon plugin users, Kubernetes/OpenShift certificate handling, and data encryption algorithms compliant with FIPS 140-2 standards. As part of our ongoing commitment to security, RHEV v3 and SSH Transfer for QCOW2 files have been retired in this release.

&#x20;

**Changes:**

* OpenStack/Virtuozzo - option to specify MAC address (or use original one) during restoration
* OpenMetal support
* S3 - object lock support
* KVM standalone - quiesced snapshot (FS freeze) support
* An infinite number of version retention settings in the backup policies
* Option to disable file system scanning during backup tasks
* Notification rules - "low free space on staging/backup destination" condition
* Tapes - encryption support
* Tapes - read-only/cleaning tapes handling
* Tapes - tape listing for each backup (to see, which tapes are needed for recovery)&#x20;
* &#x20;M365 - support for private channels in Teams
* &#x20;M365 - centralized data transfer workflow to support all backup providers as in other platforms
* M365/OS-Agent - data verification/clean-up improvements
* Data Protector connector performance improvements
* Web UI - updated navigation and views for M365, Storage, SLAs, RBAC, Application Execution Configs, and Node Configs
* Web UI Backup statistics counters improved
* Support for FIPS 140-2 compliant algorithms used in encryption
* Security enhancements for accessing the API from the Horizon plugin
* SSL certificate handling improvements for Kubernetes/OpenShift
* Removed RHEV (v3) and export storage domain backup strategy support
* Removed: OpenStack/Virtuozzo/KVM - removed support for incremental backups for SSH Transfers using QCOW2 files

## Storware Backup & Recovery 6.1&#x20;

**25.10.2023**

Storware is thrilled to announce the release of Storware Backup & Recovery 6.1. The latest version introduces an array of new features and enhancements that cater to the diverse needs of its user base. OpenStack administrators, VMware enthusiasts, OpenNebula users, and Microsoft 365 subscribers are in for a treat with the following key improvements:

\
For OpenStack administrators, Storware Backup & Recovery 6.1 introduces the much-requested Instant Restore feature, providing the ability to quickly recover data, minimizing downtime. Additionally, users can now configure more than one Ceph cluster per Availability Zone for enhanced flexibility. The release also includes basic snapshot management for cinder volumes.

For VMware environments, this release brings support for distributed switches, while OpenNebula users receive support for QCOW2-based VM disks.

Microsoft 365 subscribers will appreciate the significant performance boost during backup operations and the convenience of a brand-new restore wizard for easier data recovery.

In this release, Tape Manager gains the capability to support multiple tape drives per backup destination, providing improved performance and greater configuration flexibility.

Robust Server-Side Enhancements: Storware Backup & Recovery Version 6.1 includes substantial server-side changes. The virtualization platforms and backup destinations’ detailed views have been reorganized to include job history and additional charts, offering administrators a more comprehensive view of their backup activities. It is worth emphasizing that all warnings are now displayed in the notification center. Furthermore, this version introduces the ability to log in using Multi-Factor Authentication (MFA) with Keycloak for enhanced security.

Additional Enhancements for a Seamless Ex

perience: Version 6.1 doesn’t stop there. It introduces certificate management sections for virtualization providers, a dedicated reporting tab for OS Agents, and numerous other smaller improvements aimed at delivering a better user experience.

**Changes:**

* OpenStack - Instant restore
* OpenStack - support for multiple Ceph Storage Providers per Availability Zone
* OpenStack - snapshot management for storage volumes
* OpenNebula - Support for QCOW2-based disks
* VMware - support for distributed virtual switch
* Notification Center
* M365 - performance improvements
* UX - new restore wizard for M365
* UX - new detailed view for Backup Destination, Virtualization Providers, Virtual Instances

## Storware Backup & Recovery 6.0 (Frontier)

**04.07.2023**

**Release notes:**

We're pleased to announce that Storware Backup & Recovery 6.0, with several major features! Let's start with the OS agent for Linux and Windows - while in general, we try to stick to the agent-less approach - we know that in many cases agents can be very helpful to protect your systems on the file level. A completely new tab appeared in the menu and you can specify which folders are going to be protected - both full and incremental backups are supported.

Another big one - a technical preview of tape support. Now, you can deploy a new component called Tape Manger which is going to directly handle all of the tape-related operations. Once it is registered in the system, you can define tape pool backup destinations that can be used to protect VMs, Applications, and Storage instances.

OpenShift users also receive a massive enhancement - OpenShift Virtualization support! Now you can protect virtual machines in your OpenShift environment like in any other platform - and even more - incremental backups are also supported! Moreover - for regular container deployments - we now also support Stateful Sets.

6.0 brings also another huge one - OpenNebula support. Disk-attachment backup strategy that is used for this platform also supports incremental backups.

And you know? There are tons of other improvements: additional RBAC objects covered, a new wizard for DD Boost backup destination creation, Keycloak support, automatic clean-up of a VM after an instant restore and... more! So, check out a brand new release by yourself!

**Changes:**

* OS-Agent - File-level backup for Microsoft Windows and Linux
* Tape - Support for tape libraries (technical preview)
* Support for OpenShift Virtualization
* Stateful set support for K8s and OpenShift
* Support for Red Hat OpenShift Data Foundation (OpenShift Container Storage)
* OpenNebula - support for full and incremental backups
* M365 - Support for contacts photos
* Hyper-V - An automatic clean-up after instant restore
* Security - Support for Keycloak
* Security - RBAC improvements
* Security - SELinux improvements - support enforcing mode
* Security - Source SSL certificates management
* UI - wizard for DD Boost backup destination setup
* UI - Server hostname added to reports and notifications
* Support for additional Linux distros: SLES, Alma, Rocky

## Storware Backup & Recovery 5.2 (Fusion)

**12.12.2022**

**Release notes:**

Even though it is a bit too early for Santa - we already have prepared a gift for you - a brand new release of Storware Backup & Recovery!

And what's new? Let's start with new platforms that have been introduced - support for Azure Cloud, Azure Stack HCI and Google Cloud Platform to better protect more "cloudy" or "hybrid-cloudy" environments.

VMware users will enjoy instant restore capability on the synthetic file system backup provider, especially that one can use it together with live storage migration capability.

Storage configuration customization during the restore feature has just arrived at KVM, Virtuozzo, and Huawei Fusion Compute station. And while we talk about storage, we can't skip over the incremental backup capability for the OpenStack environments (now it is supported also in the Disk Attachment backup strategy with just cinder being used).

Microsoft 365 users will enjoy improvements such as the option to download contacts and calendars in vCard and iCalc formats. Oh, and BTW - Microsoft also updated their Teams APIs - but don't worry we always catch up, so it is supported in 5.2!

We've also added support for RHEL/CentOS Stream 9 as the supported OS on which you can deploy Storware. And because these release notes are getting long, we now really encourage you just to download and check out other improvements by yourself! Enjoy!

**Changes:**

* Azure Cloud support
* Azure Stack HCI support
* Google Cloud Platform support
* VMware vCenter - Instant restore support
* VMware vCenter - Storage live migration for VMware
* Storage customization during restore for KVM (stand-alone), Virtuozzo and Huawei FusionCompute
* Support for OpenShift API for Data Protection (OADP)
* OpenStack incremental backup using Disk Attachment (cinder) strategy
* M365 - Download contacts and calendars in vCard and iCalc format
* M365 - Support for Microsoft Teams API
* Support for installation on RHEL/Centos Stream 9
* Web UI - backup/restore transfer rate charts

## Storware Backup & Recovery 5.1.1 (Fusion)

* New: Hyper-V - Storage Live migration
* New: Command line interface (CLI) v2 - technical preview
* New: Restore individual disk to datastore - Citrix, Hyper-V, Nutanix AHV
* New: Multi-select filter for virtual machines list
* New: Restore wizard
* New: Option to define schedules and policies with the same name
* New: Support for Virtuozzo hypervisor manager

## Storware Backup & Recovery 5.1 (Fusion)

**08.07.2022**

**Release notes:**

Storware Backup & Recovery 5.1 expands its capabilities even more! Let's start with Microsoft 365 - now administrators will be able to export emails to PST and also protect M365 Groups.

All VM/Application/Storage sources now also support retention adjustment, so that you will now be able to keep selected backups longer (than policy retention settings) or mark them as expired to remove unwanted backups earlier.

For oVirt-based environments, B\&R now supports instant restore capability. What is more - you can also optionally initiate live storage migration once the VM is restored. Individual disk restore (back to the environment's storage) has also been implemented for oVIrt-based environments and OpenStack.

And while we're talking about OpenStack - the 5.1 version introduces several improvements, such as option to select flavor o key-pair during the restore, manage the visibility of AZ in the OpenStack Horizon plugin, and for more complex environments - the option to set credentials for multiple authentication domains in a single Hypervisor Manager.

Hyper-V is another area with multiple enhancements - with cluster awareness you can define a single Hypervisor Manager that is able to use either cluster IP or SCVMM to cover all hypervisors and VMs and detect if VM changed its host between inventory synchronizations. This release also added support for Storage Spaces Direct (S2D) and the agent's restore location browser in the restore modal.

Among the other improvements, it is worth mentioning Swift multi-threading transfer, network mapping in Recovery Plans, push notifications based on defined rules, improved reporting tab, and more!

**Changes:**

* M365 - Export protected mailbox data to PST
* M365 - Support for Microsoft 365 Groups
* Option to mark individual backups to be kept longer or to expire
* RHV/oVirt/OLVM - Instant restore with live storage migration
* RHV/oVirt/OLVM - Individual VM disk restoration to the specific datastore (per device)
* OpenStack - Individual VM disk restoration with a specific 'Volume Type'
* OpenStack - Restore with selected Flavor
* OpenStack - Support for multiple authentication domains in a single hypervisor manager
* OpenStack - Support for key-pair selection during the restore
* OpenStack - Support for managing the visibility of Availability Zones in the OpenStack Horizon plugin
* Hyper-V - Support for remote restore location file browser in restore modal
* Hyper-V - Hypervisor Manager support based on SCVMM (Cluster Awareness)
* Hyper-V - Hypervisor Manager support based on cluster IP (Cluster Awareness)
* Hyper-V - Storage Spaces Direct (S2D) support
* Swift - Support for multithreading during backup and restore operations
* Support for network selection in Recovery Plans
* Push notifications based on rules
* WebUI - Auto-assignment rules preview (and application) in a policy
* WebUI - Work-flows that aggregate many different tasks in one chain (Task console in WebUI)
* WebUI - Improved last 24h backup reports
* WebUI - Improved reporting tab for transfer and backup size
* WebUI - License usage
* WebUI - lists - select all check-box with the option to select all items on all pages
* Support for using the native repository for Maria-DB in RHEL based environments

## Storware Backup & Recovery 5.0 (Fusion)

**31.01.2022**

**Release notes:**

This release is like a fusion reactor - pure and unlimited power of data protection! Well, that's not the only reason why its codename is "Fusion"...

Storware Backup & Recovery 5.0 (formerly vProtect) unifies Storware's product portfolio and allows it to cover all backup sources with a single pane of glass. This means that you can now also backup your Microsoft 365 and endpoints with one solution.

Virtual Environments now have one more source available - Scale Computing HC3 Hypervisor Manager with Storware supporting 2 backup strategies! One with incremental backups (CBT) and one using standard VM export using SMB Share (full backups only).

Backups can also now be stored in a new enterprise-grade MicroFocus DataProtector backup provider. Swift backup provider has received encryption support. This update also allows administrators to specify the secondary backup destination in the policies to keep backup data in more than one location!

Here you can find another big change - retention settings have now been moved from backup destination to the policy, so now you don't have to define multiple backup destinations just to have different retention for different entities.

Hyper-V is the first platform for which we introduced instant restore (using Mounted Backups feature) to allow users to quickly instantiate VM from backup without the need to import data back to the hypervisor. What is more - if Dell EMC Data Domain is used as the backup provider - there is a new option available that allows uploading backup data to the DD directly from the Hyper-V agent.

If you're using an XFS-based backup destination - the 5.0 release also introduces an Immutable Backup feature (like the retention lock in DD), which also allows protecting your backup data from being encrypted by some ransomware.

This release also introduces multiple smaller improvements such as support for projects in Nutanix Prism, snapshot history view, option to automatically unmount mounted backups, manage SSH/WinRM credentials used in UI from the dedicated module, and many, many more!

* New: Cloud providers - Microsoft Office 365 support:
  * Incremental forever
  * Granular restore for all supported features
  * Exchange Online: mailboxes, contacts, calendars, archives
  * Microsoft Teams
  * OneDrive for Business
  * Sharepoint Online - sites and subsites
* New: Storware Endpoints integration - possibility to manage endpoint backup directly from Storware B\&R Web UI
* New: HC3 Scale Computing Hypervisor Manager - 2 strategies: Disk Attachment with CBT incremental backup and SMB Share (only for full backups)
* New: MicroFocus DataProtector backup provider
* New: Backup Copy - option to replicate backup data to the second backup destination
* New: Hyper-V - instant restore (new Mounted Backup mode)
* New: Hyper-V - direct transfer to DataDomain (when backup destination is set as Synthetic DataDomain)
* New: Hyper-V - Cluster Shared Volumes Support
* New: Swift Backup Provider - encryption support
* New: Nutanix - projects support
* New: Nutanix & VMware - improved error handling in Disk Attachment Strategies
* New: Option to automatically unmount backup after the specified time
* New: WinRM support for pre/post snapshot action
* New: Immutable Backup Destination
* New: Destination network selection for restored VM
* New: Retention settings are now attached to the backup policy
* New: Slack notifications
* New: Snapshot clean up task is now extracted from Store task and triggered separately
* New: Old backup removal task is now extracted from Export task and triggered separately
* New: Restore files from Mounted Backup to remote host over SSH/WinRM
* New: Web UI - snapshot history view
* New: Web UI - storage description field
* New: Web UI - dedicated section to manage SSH/WinRM credentials
* New: Web UI - restore to the file system with the option to restore only selected metadata/volume files
* New: Web UI - inventory synchronization now collects Hypervisor/Hypervisor Manager/Storage Provider version
* New: Web UI - SSH key upload

## vProtect 4.3 (Nova)

**28.07.2021**

vProtect 4.3 brings a Nutanix Volume Groups storage provider and a technical preview of Huawei FusionCompute support, which means that now you can protect 20 different virtualization platforms and storage providers! Woo-hoo!

The synthetic backup provider now can also use Data Domain as the backend to provide both forever incremental and highly effective deduplication. Additionally, the S3 backup provider now also supports Cloudian S3 and Alibaba Cloud OSS.

This release has RBAC has also been extended to support instance-level permissions in the roles, so that administrators can control access even more granularly.

We also included additional UI enhancements such as configuration wizard changes, task duration in the task console, option to export reports in HTML or PDF format, or option to disable all schedules at the policy level.

**Changes:**

* New: Huawei FusionCompute technical preview support
* New: Storage Provider - Nutanix Volume Groups support
* New: Synthetic backup with DD Boost FS
* New: S3 backup provider - support for Cloudian S3
* New: S3 backup provider - support for Alibaba Cloud OSS
* New: RBAC - VM/Application/Storage instance-level permissions
* New: Backup quotas for projects
* New: Notification rules
* New: VMware - support for node installation on CentOS 8/Stream
* New: option to disable scheduled backups per policy
* New: Web UI - backup/restore report export in PDF and HTML formats
* New: Web UI - configuration wizard with added support for Storage Providers and additional policy types
* New: Web UI - task duration in console

## vProtect 4.2 (Nova)

**22.04.2021**

A brand new vProtect release - v4.2 adds synthetic backup provider based on XFS which allows forever-incremental backups and significantly faster restores.

This release also introduces RBAC system-level roles to give administrators more control over vProtect security. User groups and roles enable administrators to specify which actions and views are accessible to which users, either by using build-in roles or define their own.

Version 4.2 adds snapshot-management for Ceph RBD Storage Provider and SMB support for Nutanix Files. Snapshot management has also been enabled for OpenStack with disk-attachment strategy.

Management interface have also been enhanced with additional notifications related to VDO space occupancy, transfer rate charts, inventory synchronization statuses and for oVirt/RHV/OLVM - option to easily configure metadata DB backups directly from hypervisor manager's section.

For oVirt/RHV/OLVM distributions we also added 2 transfer optimizations - BZIP2 compression when using SSH Transfer and direct transfers to/from hypervisors in Disk Image Transfer strategy - both should result in even faster backups.

**Changes:**

* New: Synthetic file-system backup provider using XFS
* New: RBAC - system-level roles and user groups
* New: Storage Providers - Ceph RBD - snapshot management
* New: Storage Providers - Nutanix Files - SMB shares support
* New: OpenStack - snapshot management for disk-attachment strategy
* New: RHV/oVirt/OLVM - metadata DB backup setup from Hypervisor Manager details pane
* New: RHV/oVirt/OLVM 4.3+ - Disk Image Transfer now supports direct transfers to/from hypervisors
* New: RHV/oVirt/OLVM - data compression during transfer with BZIP2 for SSH Transfer
* New: Connectivity test action for Backup Destinations
* New: Connectivity test action for Virtualization Platforms
* New: Hyper-V multithreaded import during restore
* New: RHV/oVirt UI plugin update - now reflecting vProtect Main menu and views and with additional reporting
* New: Web UI - transfer rate charts
* New: e-mail notifications - when VDO runs out of space
* New: inventory synchronization status for Virtualization Platforms
* New: inventory synchronization status for Storage Providers

## vProtect 4.1 (Nova)

**28.01.2021**

vProtect 4.1 introduces a new type of backup source - storage provider. Now you can protect Ceph RBD volumes, plain file systems and - Nutanix Files (AFS) as technical preview. You can execute full and incremental backups, recover individual files using mounted backups or share them over iSCSI.

This release introduces also and important enhancement for multi-AZ OpenStack environments with separate Ceph clusters in each AZ. Now you can assign individual storage providers to each AZ ("hypervisor cluster"). For OpenStack and OpenShift environments, vProtect also adds Projects to its inventory during synchronization.

When using Dell EMC PowerProtect DD (Data Domain) as a backup provider, you can now enable retention lock feature to protect your backups. This release adds also backup size report which may be essential for chargeback reporting. Starting from 4.1 release Java 11 will be used.

**Changes:**

* New: Storage Provider - Ceph RBD - support for backup/restore/mount of RBD volumes
* New: Storage Provider - File system - support for backup/restore/mount of plain file systems mounted on the nodes
* New: Storage Provider - Nutanix Files (AFS) - technical preview of support for backup/restore/mount of Nutanix Files
* New: multi-AZ OpenStack environments support
* New: OpenStack/OpenShift - project scanning
* New: Backup size reporting for chargeback
* New: PowerProtect DD (DataDomain) retention lock
* New: Hyper-V multi-threated disk export
* New: Java update to v11
* New: Task API performance optimizations

## vProtect 4.0 (Nova)

**30.09.2020**

vProtect 4.0 is a brand new major release that optimizes web interface for even more intuitive user experience.

Two new backup strategies for RHV/oVirt and Proxmox significantly widen range of backup strategies available for administrators with focus on incremental backup enhancements.

Restore process also now allows to automatically power on VMs or automatically customize names of restored VMs in Recovery Plans. This opens additional test scenarios, in which administrators can validate if VMs restore successfully and do a test power on. This release also simplifies Nutanix setup - administrators now also can add Prism Central directly instead of individual Prism Elements. This allows administrators to use categories (corresponding to "tags" in vProtect) and assign policies automatically based them in policies. Last, but not least - S3/S3-compatible backup provider can optionally be connected via proxy. This provider now also supprots Nutanix Objects.

**Changes:**

* New: Proxmox VE - new backup strategy for Proxmox VE (includes incremental backups, FS freeze, and option to share backups over iSCSI)
* New: RHV/oVirt - new backup strategy using CBT (using new RHV/oVirt backup APIs, currently in Technical Preview)
* New: Nutanix AHV – option to connect via Prism Central instead of individual Prism Elements
* New: Nutanix AHV – option to automatically assign VMs to the policies based on Nutanix categories (vProtect tags) when using Prism Central as hypervisor manager
* New: Option to automatically power on VM after restore
* New: Option to automatically generate VM name with prefix/suffix in Recovery Plans
* New: Major Web UI update and reorganization - better arrangment of views related to the artifacts in the same domain, such as Virtual Environment-related schedules, policies etc.
* New: S3/S3-compatitble backup provider - Nutanix Objects support
* New: S3/S3-compatible backup provider - proxy support
* New: Kubernetes/OpenShift - token-based authentication
* New: Task APIs optimizations
* New: Support for Chrome SameSite cookie security flag
* Fix: oVirt/RHV UI plugin minor enhancements and fixes
* Fix: Hyper-V delta snapshot files merge issue

## vProtect 3.9.2 (Quasar)

**01.06.2020**

vProtect 3.9 Update 2 is a provides multiple - mostly periodic, security-related - updates of internal database, API and web UI.

This update also introduced CentOS/RHEL 8 support for vProtect deployments. OpenStack and OpenShift environments using Ceph storage can also be now protected - incremental backups as well.

OpenShift backups allow also to perform pre/post export remote command execution on the deployment (which are useful to trigger i.e. DB quiesce/resume operations).

One also can notice restore history visible in UI (both on a single VM/app level as well as in Recovery Plan details view).

All restore jobs are also now reported in e-mail and you can browse them from the dashboard. Installation playbooks now also allow administrators to specify alternative MariaDB repository location and version.

**Changes:**

* New: restore history in reporting (dashboard and report mail)
* New: restore history in Recovery Plans
* New: OpenStack - disk attachment with Ceph-based deployments - incremental backups (technical preview)
* New: OpenShift - Ceph-backed PVs support - full and incremental backups with RBD-NBD (technical preview)
* New: OpenShift - pre/post export remote command execution
* New: CentOS/RHEL 8 support
* New: Ansible-based installation with option to customize MariaDB source, version and distribution
* Update: vProtect server security updates in API and UI layers
* Update: MariaDB 10.4 in new deployments

## vProtect 3.9.1 (Quasar)

**10.02.2020**

vProtect 3.9 Update 1 introduces several enhancements for OpenStack and KVM stand-alone environments. This release introduces new strategy for OpenStack, which uses Cinder-based disk-attachment to perform backups.

For KVM stand-alone vProtect now supports LVM thin-pools and mixed configurations (i.e. QCOW2+LVM). This update also introduces Ceph RBD support for stand-alone KVM hypervisors.

With 3.9 Update 1 we also provide oVirt integration, so that you can now invoke backup & restore operations directly from oVirt/RHV administration interface.

**Changes:**

* New: OpenStack - disk attachment backup strategy using Cinder
* New: KVM stand-alone - LVM thin-pool support
* New: KVM stand-alone - support for VMs with mixed disk types
* New: KVM stand-alone - Ceph support
* New: oVirt/RHV Backup & Restore UI integration for vProtect
* New: UI - configuration wizard enhancements

## vProtect 3.9 (Quasar)

**28.10.2019**

vProtect 3.9 is a major release adding officially support for VMware and Hyper-V virtualization platforms. Both full and incremental backups are supported and it also allows you to restore individual files. Second huge improvement, for all supported platforms we introduce Recovery Plans. Now, you'll be able to define rules, how and where multiple VMs should be restored when you need DR. You also are able to schedule them and restore set of VMs periodically to your test locations, to be sure that you're able to restore them if you need to.

Several improvements are related to Application backup. Quasar release introduced several build-in application backup templates for common use cases ready to be used. You also are now able to parametrize you command execution configurations to force set of parameters that are required for you command or script. Application restore will also provide several option how to cope with automatic archive extraction or overwrite existing files.

For Amazon users we also have good news - now S3 backup provider allows to enable extended retention for stored backups and change storage class for oldest objects to Glacier giving you option to reduce your storage costs significantly.

RHV/oVirt/OLVM users can also boost their backups with netcat transfer and for SSH transfer mode, restore operations now use direct connection instead of Disk Image Transfer API. This release also improves Web UI especially in configuration related activities, adds restore history and improves task console and many more.

**Changes:**

* New: VMware - official release - significant changes in integration layer
* New: VMware - restore - target disk format selection
* New: VMware - added Hot-Add transfer option if available
* New: VMware - support for tag-based policy auto-assignment
* New: Hyper-V - full/incremental backup
* New: Hyper-V - snapshot management
* New: Hyper-V - file-level restore with mountable backups
* New: Hyper-V - option to share drives over iSCSI
* New: Recovery Plans - batch VM restore for DR
* New: Recovery Plans - periodic VM restore for DR tests
* New: Mountable backups - option to mount QCOW2 with NTFS file systems
* New: Restore operation - option to delete VM (if one already exists with the same name)
* New: Application backup - command execution configuration parameters
* New: Application backup - templates and ready scripts for several common use cases
* New: Application backup - option to clone applications and command execution configurations
* New: Application backup - automatic archive extraction and option to overwrite
* New: Application backup - option to ignore error codes or standard error output for user-provided scripts
* New: OpenStack - Ceph-based storage support
* New: RHV/oVirt/OLVM - netcat transfer option
* New: RHV/oVirt/OLVM - SSH transfer - restore operation now also over SSH
* New: Swift - compression support
* New: Dell-EMC Avamar support
* New: AWS Glacier support
* New: Storware Insight - detailed backup status to reporting option
* New: Ansible playbooks for installation
* New: UI - configuration wizard
* New: UI - task console improvements
* New: UI - global search for quick access to any item
* New: UI - restore jobs history

## vProtect 3.8 Update 1 (Nebula)

**19.06.2019**

vProtect 3.8 Update 1 introduces 3rd backup strategy for RHV/oVirt 4.2+ environments. Using direct SSH transfer from hypervisors vProtect will be able to perform backups significantly faster. All of the features that currently vProtect supports for oVirt 4.2 are now also available for Oracle Linux Virtualization Manager. Another big update is OpenStack support. Currently for environments with KVM VMs using QCOW2 disks. We also provided Horizon integration to allow more seamless integration. For Oracle VM we introduced option to exclude drives. This version also updates our encryption mechanism for Azure and File System backup destinations to support large VM backups. Update 1 also provides minor UI improvements and fix for "snapshot ID not found in the DB" if full backup has not been done yet.

**Changes:**

* New: RHV/oVirt - new "SSH transfer" export/import mode
* New: Oracle Linux Virtualization Manager support - same feature set as for oVirt 4.2
* New: OpenStack - full/incremental backup support
* New: OpenStack - file-level restore support
* New: OpenStack - Horizon integration
* New: Oracle VM - disk exclusion support
* New: Kubernetes - support for containerd
* New: Web UI - improvements in batch hypervisor operations like node/password modification
* New: Web UI - improved backup status reporting
* Update: updated Azure/file system encryption mechanism to support 64+ GB backups
* Fix: automatic full backup if snapshot ID for incremental backup has not been recorded yet

## vProtect 3.8 (Nebula)

**11.04.2019**

vProtect 3.8 (Nebula) is a massive update. It introduces Amazon EC2 backup support with snapshot-management and file-level restore capabilities. Proxmox users will have multiple additional features including automatic backup import to the Proxmox hypervisor, disk-exclusion, Snapshot-management and pre/post snapshot remote command execution. You also will be able to store your backups in Google Cloud Storage.

In Nebula release we enhanced mounted backup capabilities. Now you can browse and restore backup files directly in Web UI, or share RAW-based backups over iSCSI and mount them directly in your target system (especially useful when you want to preserve Windows file permissions). RAW-based backups with NTFS file systems can now be mounted automatically as well (previously it was only manual mount).

Web UI has been improved with new list views with improved paging and filtering. Logs from remote logs can now are automatically shared with the server so that you can browse them in Web UI or download all of them with a single click. New languages - German and Spanish - are also available.

Version 3.8 also improved restore options. Citrix XVA-based backups are now restored as a VM automatically, RHV backups can have allocation type specified and for OpenShift/Kubernetes we added fix for „restore to the specific project” option.

Last, but not least, we updated our application server and data access layer and added option to automatically send vProtect logs to Storware Insight service.

**Changes:**

* New: Amazon EC2 - full backup with disk-exclusion support - for EC2-based VMs
* New: Amazon EC2 - file-level restore with mountable backups
* New: Amazon EC2 - snapshot/management
* New: Proxmox - automatic backup import to the Proxmox hypervisor
* New: Proxmox - file-level restore with mountable backups
* New: Proxmox - snapshot management
* New: Proxmox - disk exclusion for backups
* New: Proxmox - pre/post snapshot remote command execution (post-export for VMs, post-snapshot for containers)
* New: Google Cloud Storage support
* New: Mounted backups - option to share RAW disks over iSCSI (for platforms that use RAW format in backups)
* New: Mounted backups - file-level restore directly from Web UI
* New: download-all logs feature in Web UI
* New: option to browse logs from remote nodes in Web UI - now mounted automatically
* New: Citrix - XVA restored as a VM
* New: NTFS auto-mount (for RAW-based backups)
* New: RHV - sparse/preallocated format option for restore
* New: German and Spanish language support in Web UI
* New: Storware Insight - automatic logs upload
* Update: Payara 5 pplication Server and data access layer
* Fix: Kubernetes/OpenShift - fixed restore to the specific project option

## vProtect 3.7 Update 2 (Multiverse)

**28.02.2019**

vProtect 3.7 Update 2 adds support for OpenShift. Now you'll be able to use the same backup methodology as for Kubernetes to protect your persistent volumes on OpenShift platform.

We also updated our sample CloudForms integration to match current vProtect API level.

**Changes:**

* New: OpenShift - support for full backup of persistent volumes and deployment configuration
* Update: CloudForms integration matching 3.7.x API.

## vProtect 3.7 Update 1 (Multiverse)

**21.12.2018**

vProtect 3.7 Update 1 extends Multiverse release with additional snapshot management capabilities, such as option to revert snapshots directly from UI and adds support for Nutanix VMs. Moreover, application backup now allows you to define environment variables for each application. This gives more flexibility when reusing same scripts for multiple instances of the same application.

This update also introduces Chinese language support in UI, as well provides further CLI and backup destination improvements. These include ability to restore backup chains residing on multiple backup destinations and gives additional option for file systems where random access may cause issues when reading data randomly when using mounted backups.

**Changes:**

* New: Snapshot management - Nutanix AHV
* New: Revert snapshots from vProtect console - RHV/oVirt, Citrix XenServer, Nutanix AHV
* New: Application backup - environment variables support
* New: UI - Chinese language supported
* New: updated RedHat CloudForms integration to match 3.7 APIs
* New: option to disable random access for FS backup destinations (which may be essential for file systems such as LTFS)
* New: CLI - backup time details
* New: option to restore backup chains residing on multiple backup destinations
* Fix: arguments in pre/post snapshot command, pre/post BD access command were forced to be unique

## vProtect 3.7 (Multiverse)

**30.10.2018**

vProtect 3.7 (Multiverse) introduces many significant changes. First of them, and the reason why we given such code name was snapshot management. Now you can have state of your environments being periodically saved without exporting backup itself. This comes together with new interval-based schedules that allow you to snapshot VM i.e. every hour.

"Multiverse" also relates to multiple platforms that we support and new possible sources of backup. That is basic backup/restore capabilities for Kubernetes as well as generic approach to backup any application that you can provide us script for. This means that you should be able to cover use cases such as database or hypervisor backup directly using vProtect. A good example is that vProtect DB now can be setup as an "application" that is being backed up using the settings directly from UI.

What is more we have provided way to deploy vProtect using Dockerfiles, introduced support for Oracle VM tags in auto-assignment of VMs, and made significant changes in UI - especially related to the concept of Policies.

**Changes:**

* New: Snapshot Management - for RHV/Citrix/KVM
* New: KVM - incremental backup support
* New: KVM - RAW file (.img) VM disk support
* New: Kubernetes support - backup and restore of Persistent Volumes used in Kubernetes Deployments
* New: Application backup - generic mechanism to backup any application using custom commands
* New: automatic vProtect database backup
* New: Oracle VM - support for tags (VM auto-assignment)
* New: vProtect deployment using Dockerfiles
* New: VM Backup Policies replaced VM groups
* New: Interval-based schedules
* New: UI - non-present VMs cleanup button
* Fix: Schedule/VM group checkboxes race-condition - now working also in Firefox

## vProtect 3.6 (Stardust)

**26.07.2018**

Stardust release enhances file system backup destination with VDO deduplication. One can say that VDO literally "turns data into dust" and can be enabled directly from UI. KVM-standalone users will also benefit with pre/post snapshot command execution and ability to import VM back to the hypervisor. As the GDPR is already effective, we implemented encryption option for S3, Azure and file system backup destinations.

vProtect 3.6 also introduces also many smaller (resembling stardust again), but long-awaited features such as LDAP authentication, detailed time statistics for backups, improved dashboard, or VM auto-assignment based on hypervisor clusters.

**Changes:**

* New: File system backup destination – deduplication with VDO
* New: FS/S3/Azure backup destinations – data encryption
* New: LDAP authentication
* New: RHV/oVirt/KVM/Xen/XenServer - option to set restored VM name
* New: RHV/oVirt optimized snapshot for selected disks only
* New: KVM/Xen – LVM VG scanning (Hypervisor Storage)
* New: VM auto-assignment based on cluster
* New: Web UI – improved dashboard
* New: Web UI – additional backup statistics: size and time in VM details
* New: other UI improvements
* Fix: Server-Node communication optimizations

## vProtect 3.5 (Parsec)

**30.05.2018**

vProtect 3.5 introduces support for incremental backups of RHV/oVirt environments. With the new Disk Image Transfer mode, administrators will be able to protect their environments without the need to use export storage domain or Proxy VM.

New vProtect also does additional storage space checking (with configurable thresholds), to protect virtualization platform storage to be filled up.

With pre/post snapshot mechanism administrators will be able to quiesce services before snapshot backup with their own custom scripts to make backups application-level consistent.

Similarly, it is also possible now to customize mounting volumes before it is accessed dynamically with backup destination pre/post access command execution. A good example of its usage is Catalogic vStor Server support, including backups being replicated to the remote location.

Version 3.5 also introduces support for Microsoft Azure as another cloud-based option for storing backups.

**Changes:**

* New: RHV/oVirt 4.2+ - Disk Image Transfer backup mode (incremental backup support)
* New: RHV/oVirt/Citrix/Nutanix - pre/post snapshot remote command execution
* New: RHV/oVirt/Citrix/Nutanix - available storage check before snapshot creation
* New: pre/post backup destination access custom command execution
* New: Microsoft Azure backup destination
* New: Catalogic vStor Server support (with replication)
* New: logging improvements for backup destinations
* Fix: UI node reassignment failed for HV/HVM after original has been removed

## vProtect 3.4 (Mars)

**06.04.2018**

vProtect 3.4 introduces API v4 support for oVirt/RHV environments, which comes together with a new backup strategy available. This means that vProtect Node can now act as a proxy VM, without the need of using export storage domain and a cloning step.

This release also introduces cluster and storage scanning to allow administrators to easily select destination storage from the list in restore dialog box. Moreover, new vProtect version also extends scheduling options to allow administrators to configure backups to be done on monthly or even annually basis.

Last but not least, vProtect now can fail remaining backup tasks in the queue if it detects that certain percent of backup tasks have already failed. This helps administrator to address cases when unavailability of backup provider or VM infrastructure causes multiple backups to constantly fail during scheduled backup process.

**Changes:**

* New: RHV/oVirt API v4 support - backup without export storage domain
* New: extended scheduling options
* New: Cluster and storage indexing (RHV/oVirt/OVM/Nutanix/XenServer)
* New: automatic stop of scheduled backup if more than X % of backups already failed
* Fix: backup retention settings could result in full backups being kept longer than configured
* Fix: Nutanix - backup of VMs with mounted ISOs resulted in error

## vProtect 3.3 (Warp)

**01.03.2018**

vProtect 3.3 introduces support for Nutanix AHV hypervisors. It is also able to create incremental backups using Nutanix CRT (CBT) feature, and provides selective disk backup for this platform.

For Citrix hypervisors vProtect now allows to set transfer NIC used to transfer backups. Backups of VMs running on KVM/Xen (stand-alone) hypervisors can be performed with exclusion of certain drives.

This release also provides updated application server, including multiple security fixes and code optimizations. Moreover initial configuration of the node has been scripted to make the process easier.

**Changes:**

* New: Nutanix AHV support including CBT for incremental backups
* New: Nutanix AHV - file-level restore
* New: Nutanix AHV - disk exclusion
* New: KVM (stand-alone) and legacy Xen - disk exclusion
* New: Citrix - option to specify transfer NIC for hypervisor
* New: NetBackup - option to access the same NB server from multiple nodes
* New: e-mail reports with VM grouping
* New: updated application server
* New: scripted OS preparation for node
* Fix: Networker - empty versions list caused exception
* Fix: additional code optimizations and fixes

## vProtect 3.2.3 (Gravity)

**16.02.2018**

vProtect 3.2.3 release fixes incremental backup related issues, which are mostly related to Citrix CBT backup implementation. It also adds S3 DNS based round-robin support for local object storage installations and provides minor UI fixes and improvements.

**Changes:**

* Fix: Citrix - CBT - retention handling for incremental backups
* Fix: Citrix - CBT backups had wrong relationship recorded
* Fix: Citrix - session management problem during incremental backup import
* Fix: UI - selecting incremental backup in backup window resulted in error being shown
* Fix: prevent schedules to be executed if they have just been created and time passed

  (tasks would be expired)
* New: UI - add Node Config selection in Backup Destination create/edit forms
* New: Citrix - restart CBT on all VHDs during full backup
* New: S3 backup destination - if DNS name is used in endpoint URL, try to resolve and

  reconnect, so that DNS Round-Robin can be effective (third party S3 API)

## vProtect 3.2.2 (Gravity)

**22.01.2018**

vProtect 3.2.2 release adds new settings for third party S3 API implementations (i.e. Scality) It also fixes minor bugs in UI and CLI.

**Changes:**

* Fix: UI - filtering - select all option was not using filter settings
* Fix: CLI - incorrect name used while creating backup destination
* New: S3 backup destination option - record backup time after storing object (third party S3 API)
* New: S3 backup destination mode - single bucket with disabled versioning (third party S3 API)

## vProtect 3.2.1 (Gravity)

**15.01.2018**

vProtect 3.2.1 release is focused on UI fixes and enhancements. Administrators will now be able to backup whole VM group with just one click. A new chart in the VM details makes also easier to keep track of backup size.

**Changes:**

* Fix: UI - missing tooltips
* Fix: UI - drop-down lists arrows handling
* Fix: logo in e-mail reports was not rendered properly in Outlook
* Fix: empty backup log download handling
* New: CLI - node registration in batch mode
* New: VM backup size chart
* New: VM group backup
* New: Task console full screen mode and task counters
* New: other UI improvements (additional info in forms, filtering)

## vProtect 3.2 (Gravity)

**22.12.2017**

vProtect 3.2 adds new backup capabilities for Citrix environments.

Now you will be able to use XenServer 7.3 Changed Block Tracking feature to boost your incremental backups. vProtect is now also able to mount Citrix backups on the vProtect Nodes without the need to restore it to the XenServer. One can also exclude selected VM disks from backup (Citrix).

Proxmox users will now also be able to configure compression of their backups. For RHV/oVirt environments. This release also adds option to freeze filesystems before snapshot creation.

This release also optimizes integration related functions used by backup providers, adds instant notifications for failed backups and provides multiple enhancements in the web UI.

**Changes:**

* New: Changed Block Tracking support for XenServer 7.3+
* New: option to exclude selected VM disks from backup (Citrix)
* New: file-level restore for Citrix XenServer
* New: file-level restore for KVM (stand-alone) and Xen (legacy)
* New: quiesced-snapshot (Citrix)/file system freeze before snapshot (RHV/oVirt) option on VM level
* New: instant notification about recently failed backups
* New: UI enhancements and optimizations
* New: compression options for Proxmox
* New: backup provider integration optimizations

## vProtect 3.1.5 (New Horizons)

**15.11.2017**

vProtect 3.1.5 fixes several task handling issues, including timeout settings not being used properly used. Node removal also removes mounted backups and HV/HVM type fields are kept even when VM is removed.

**Changes:**

* New: node stacktraces logging enhancements
* Fix: timeouts in settings were not used when creating a task (default 1h always assigned)
* Fix: store task now cleans up files on expiration
* Fix: node removal should remove mounted backups
* Fix: HV/HVM type field should not be cleared when VM no longer exists

## vProtect 3.1.4 (New Horizons)

**06.11.2017**

vProtect 3.1.4 introduces enhanced auto-assign feature. Now users can add/remove automatically VMs based on set of tags and regular expression using both include and exclude rules. There are also few UI related bug fixes.

**Changes:**

* New: RHV/oVirt/Citrix - include/exclude VMs automatically to/from groups

  using set of regular expressions or tags
* Fix: backup priority is always 50 in web UI
* Fix: S3 keys could not be saved in web UI
* Fix: error handling when backup is not found in backup destination during restore

## vProtect 3.1 (New Horizons)

**10.10.2017**

Release 3.1 is a completely new vProtect. Brand new UI, CLI, open API, app server and database. It introduces also support for Proxmox hypervisors. With 3.1 you can now scale horizontally with multi-node centralized management and store backups in different backup destinations.

New Horizons release introduces also RPM based installation and upgrade, XVA compression (Citrix) and several security enhancements.

**Changes:**

* New: Web UI
* New: open API for 3rd-party integration
* New: multi-node deployments
* New: multiple backup destinations - now they can be used simultaneously
* New: database changed to MariaDB and embedded application server
* New: refreshed CLI
* New: RPM based installations and updates
* New: Proxmox support
* New: Citrix XVA compression
* New: user management
* New: security enhancements

## vProtect 2.6.4 (Pulsar)

**10.08.2017**

Release 2.6.4 fix solves problem with XenServer environments when multiple hypervisors have same SR name (which results in import issues). Now users can pass SR UUID to uniquely identify target SR for import. This release also includes DB optimizations and introduces move operation in file system BP for vProtect environments using same file system for staging and as a storage for stored backups.

**Changes:**

* Fix: Citrix XenServer - SR UUID can now be passed as SR name for import operation

  (when multiple SRs are with the same name)
* Fix: DB optimizations
* New: File System backup provider moves file if it is on the same FS (store operation)

## vProtect 2.6.3 (Pulsar)

**11.07.2017**

Release 2.6.3 fix solves problem with Oracle VM environments with VMs that use different storage repositories for config and VM disks. It also provides minor enhancement in exception logging and support for SuSE Linux in installer.

**Changes:**

* Fixed: Oracle VM - failed export when VM uses multiple storage repositories
* Fixed: minor installation script fixes
* New: SUSE Linux support in installer
* New: extended logging for hypervisor related exceptions

## vProtect 2.6.2 (Pulsar)

**27.06.2017**

Release 2.6.2 provides workaround for RHEV 3.5.x API which doesn’t provide all information needed to automatically select appropriate export domain for datacenters. It also fixes NetWorker restore operation (which previously did not bring original paths after files have been restored).

**Changes:**

* Fixed: optional setting - storage domain to datacenter mapping in settings
* Fixed: NetWorker restored files to wrong location, which resulted in mount failure

## vProtect 2.6.1 (Pulsar)

**13.06.2017**

Release 2.6.1 fixes several issues regarding removal of task and backup objects from the DB and addresses old RHEV API issue related to storage domains. It also fixes S3 timestamp mismatch problem, which may result in failed backups.

**Changes:**

* Fixed: task removal failure in some situations
* Fixed: RHEV 3.6 - old API did not provide info about export domains
* Fixed: backup removal fixed
* Fixed: S3 wrong timestamp in the DB

## vProtect 2.6 (Pulsar)

**31.05.2017**

With release 2.6 we have introduced file-level restore for RHV/oVirt and Oracle VM environments. Together with possibility to stream backup directly from file system backup provider, now users can almost instantly access specific files in VM backups.

Citrix and RHV/oVirt environments also received tag-based auto-assignment feature to simplify process of grouping VMs and scheduling backups.

In this version we also added Dell-EMC Networker support, which means that currently users have option to store backups in 3 enterprise-grade backup providers.

Amazon S3 backup provider also has been enhanced with secondary mode - one bucket for all data, which is required by some vendors using S3 protocol. This means that vProtect can now also use IBM Cleversafe as the backup provider.

**Changes:**

* New: Dell-EMC Networker support
* New: IBM Cleversafe support
* New: Amazon S3 - single bucket mode
* New: File-level restore with mountable backups (RHV/oVirt and Oracle VM)
* New: VM auto-assignment based on tags (Citrix XenServer and RHV/oVirt)
* New: Backup size in Virtual Machines view (web UI)
* Updated: Keep last backup locally option - optimizations + support for all hypervisor types
* Updated: Improved installer

## vProtect 2.5 (Trappist)

**16.03.2017**

The key feature of this version is support for incremental backups (Citrix XenServer). vProtect is now also able to restore VMs directly to XenServer hypervisors. With added support for Amazon S3 as a backup provider one can also store backups directly in the cloud. Last but not least, version 2.5 includes several updates and bug fixes in the backup providers’ libraries and multiple optimizations in engine’s code.

**Changes:**

* New: Incremental backup (Citrix XenServer)
* New: Restore to hypervisor (Citrix XenServer)
* New: Amazon S3 backup provider
* New: Retention settings managed by vProtect
* Updated: TSM API library, which includes multiple fixes and improvements
* Updated: OpenStack Swift API library
* Updated: improved installer

## vProtect 2.4.1

**30.01.2017**

This is a bugfix release focused on DB mapping issues when hypervisors were removed. It also verifies which backup providers are covered by license and fixes minor license-related issues.

**Changes:**

* Fixed: removal of hypervisors, hypervisor managers and VM groups now is properly reflected in foreign keys in DB
* Fixed: verbose message if license is not valid when starting engine
* Fixed: license verification for backup providers
* Fixed: configuration refresh before starting the engine

## vProtect 2.4

**11.01.2017**

Main improvements compared to 2.3:

1. **File System as the backup provider**, which means that:
   * you can use any mounted set of file systems (mount points) as the storage space
   * especially those can have deduplication capabilities like DD Boost (Data Domain) or OpenDedup
   * then you can use them as the destination for your backups (retention settings:

     N last versions and keep not older than N days backup - same as for Swift)
   * technically, you can use ANY mountable file system, even remote (or set of file systems)
   * vProtect will balance the usage based on the amount of free space
2. Small but important - **auto-assignment of VMs to groups**
   * I’ve heard about this requirement several times from the customers
   * Index task will try to match name agains regular expressions and assign to the group

     Just a short reminder, cause I think I haven’t summarize 2.3 (previous) version to you:
   * added OracleVM support
   * added Veritas NetBackup as the backup provider

This means that there is already quite a lot of supported virtualization platforms and possible backup destinations.

## vProtect 2.3

**19.12.2016**

* added OracleVM support
* added Veritas NetBackup as the backup provider

## vProtect 2.2

**16.05.2016**

A brand new release - vProtect 2.2 - extends range of supported platforms.

With vProtect 2.2 you can now easily implement backup of virtual machines running in **Red Hat Enterprise Virtualization and oVirt** environments.

Moreover, you can now store you backups both in IBM Spectrum Protect and in **Openstack Swift object storage**. With just a few clicks you can connect to your existing Swift environment and set retention policy for your VM backups.

In vProtect 2.2 we also significantly improved engine and enabled dynamic reconfigurations directly from web interface.

## vProtect 2.1

**18.02.2016**

* Added Web UI
* KVM/Xen support (full backup only)

## vProtect 1.0

**30.06.2015**

* Basic CLI
* backup/restore Citrix XenServer (restore to node’s file system only)
* TSM support


# Overview

In this section, we'll briefly discuss the architecture and main features of Storware Backup & Recovery as well as some typical use case scenarios.

The [Main Features](/70/overview/main-features) section briefly summarizes the key functionalities of the Storware Backup & Recovery solution.

In the [Support Matrix](/70/overview/support-matrix), you can check versions of supported virtualization platforms, backup, and cloud providers. [Platform requirements](/70/deployment/platform-requirements) present what are hardware and [software requirements](/70/deployment/platform-requirements#software-requirements) needed to run Storware Backup & Recovery components.

The [High Availability](/70/deployment/high-availability) section provides guidance to plan Storware Backup & Recovery solutions resistant to failures.

[Licensing ](/70/overview/licensing)is the source of options we provide to optimize your costs while keeping the functionality that fulfills your needs.


# Main Features

Storware Backup and Recovery is a data protection solution for virtual environments, storage, M365, and endpoints. It provides a centralized and automated solution for data protection. It can be deployed in minutes and start to protect your environment within hours.

![](/files/m3Hm8GXLzKDJMvJqL7oM)

## Supported backup platforms

### Virtual Machines:

* VMware vSphere
* Microsoft Hyper-V / Azure Stack HCI
* Nutanix
* HC3/Scale
* Red Hat Virtualization
* oVirt
* Oracle Linux Virtualization Manager
* Nutanix Acropolis Hypervisor (AHV)
* HPE SimpliVity
* OpenNebula
* XCP-ng with CBT support
* Virtuozzo
* Proxmox VE
* Oracle VM
* OpenStack&#x20;
* OpenShift Virtualization
* libvirt hypervisors (KVM, PowerKVM, KVM for IBM z, Xen)
* KVM
* VergeOS
* Huawei FusionCompute
* Verge

### Containers:

* Kubernetes (deployment-level protection for Persistent Volumes)
* Red Hat OpenShift (deployment-level protection for Persistent Volumes)
* Proxmox VE

### Cloud solutions:

* Amazon EC2
* Google Cloud Platform / Google Computer Engine
* Azure Cloud
* Microsoft 365

### Storage:

* remote file system (including NAS file shares)
* Ceph RBD (with snapshot difference support)
* Nutanix Files (with Changed-File Tracking)
* Nutanix Volume Groups (with Changed-Region Tracking)
* SUSE Enterprise Storage

### Applications:

* the generic backup mechanism for the custom backup processes
* templates for commonly used applications

### Filesystem backup:

* Windows
  * Support for VSS
* Linux

## Advanced backup features:

* Snapshot Management (Copy Data Management)
* Snapshot consistent technology (quiesced/application-consistent snapshots or filesystem freeze)
* Pre/post snapshot remote command execution on VM to enable operations such as database quiesce
* Change Block Tracking (CBT) and Change file tracking (CFT) for faster incremental backups
* VM disks exclusion option
* Hyper-V direct transfer to the DataDomain (DD Boost API)
* Backup schedules
* Backup SLAs:
  * VM automatic policy assignment based on regular expressions and tags
  * backup job prioritization
  * multiple policy rules (with different scheduling and backup destinations) for the same protected object
* Multi-node architecture:
  * scalability
  * automatic task load balancing
  * suitable for geographically distributed environments
* Built-in Storware Backup & Recovery database backup

## Recovery features

* File-level restore using mountable backups
  * directly via a web browser
  * transfer to the remote host over SSH and WinRM
* Backup mount - RAW disks shareable over iSCSI (for direct block-access to your backup data)
* Recovery plans for automated Disaster Recovery
  * on-demand restore of multiple instances
  * automated schedules for recovery testing
* Customizable networking and disk layout during a restore
* Instant restore
  * Hyper-V
  * oVirt/RHV/OLVM instant restore
  * VMware instant restore
* Individual disk recovery

## Supported backup destinations

* File-based:
  * A synthetic backup provider using XFS, NFS 4.2, or Dell Data Domain Virtual Synthetic Full (DD Boost API)
  * Any mounted file system (local or remote, especially GlusterFS for replication, CephFS, NFS, SMB, and many more)
  * Dell EMC Data Domain (BoostFS integration)
  * Rubrik Managed Volumes
  * Catalogic vStor
* Object Storage:
  * Amazon S3 (with Amazon Glacier as a 2nd tier archive storage),
  * S3-compliant storage (IBM Cloud, Oracle Cloud, Scality RING)
  * Google Cloud Storage
  * Microsoft Azure Blob Storage
  * OpenStack Swift
* Enterprise-grade backup providers:
  * IBM Spectrum Protect (TSM)
  * Dell EMC Networker
  * Dell EMC Avamar
  * Veritas Netbackup
  * MicroFocus Data Protector
* Tapes
* Built-in data deduplication with Virtual Data Optimizer (VDO)
* Backup Copy - secondary backup destination to store data in more than one location
* Pre/post backup destination access command execution to execute custom operations on external storage providers such as replication

## Security features

* Role-based access control (RBAC) for administrative accounts
* Audit-log for administrative actions
* Customizable logging configuration for external SIEM support
* Data-at-rest encryption for file system backup destination
* Ransomware protection
  * Immutable Backup (XFS-based backup destination) that protects backup data from being encrypted by ransomware
  * Air-Gap Data Protection with:
    * Rubrik Managed Volumes
    * Catalogic vStor
    * isoLayer - using remote Red Hat linux based host and NFS

## Other features

* Web-based (HTML5) central management portal
* Advanced reporting
  * administrative portal
  * e-mail
* Event notifications using e-mail, Slack, or custom API call
* Command Line Interface (CLI\_ for advanced administrators
* Open API for 3rd party software integration (REST API)
* LDAP authentication
* OpenStack Horizon plugin
* oVirt/RHV/OLVM console integration


# Support Matrix

## Virtualization Platforms

### Azure Stack HCI

**Supported backup strategies:** 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**                                    | No                     |
| **Proxy VM required**                                                   | No                     |

| **Full backup**                         | Supported     |
| --------------------------------------- | ------------- |
| **Incremental backup**                  | Supported     |
| **Restore**                             | Supported     |
| **File-level restore**                  | Supported     |
| **VM disk exclusion**                   | Supported     |
| **Quiesced snapshots**                  | Supported     |
| **Snapshots management**                | Supported     |
| **Pre/post command execution**          | Supported     |
| **Access to VM disk backup over iSCSI** | Supported     |
| **VM name-based policy assignment**     | Supported     |
| **VM tag-based policy assignment**      | Not supported |
| **Power-on VM after restore**           | Supported     |

### Microsoft Hyper-v

**Supported backup strategies:** 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                                    | No                     |
| Proxy VM required                                                   | No                     |

| Full backup                         | Supported     |
| ----------------------------------- | ------------- |
| Incremental backup                  | Supported     |
| Restore                             | Supported     |
| File-level restore                  | Supported     |
| VM disk exclusion                   | Supported     |
| Quiesced snapshots                  | Supported     |
| Snapshots management                | Supported     |
| Pre/post command execution          | Supported     |
| Access to VM disk backup over iSCSI | Supported     |
| VM name-based policy assignment     | Supported     |
| VM tag-based policy assignment      | Not supported |
| Power-on VM after restore           | Supported     |

### Huawei FusionCompute

**Supported backup strategies:** CBT

| Supported versions                                                  | 8.0, 8,1, 8.2, 8.3, 8.5, 8.6 |
| ------------------------------------------------------------------- | ---------------------------- |
| The last snapshot is kept on the hypervisor for incremental backups | Yes                          |
| Access to hypervisor OS required                                    | No                           |
| Proxy VM required                                                   | No                           |

| Full backup                         | Supported     |
| ----------------------------------- | ------------- |
| Incremental backup                  | Supported     |
| Restore                             | Supported     |
| File-level restore                  | Supported     |
| VM disk exclusion                   | Supported     |
| Quiesced snapshots                  | Not supported |
| Snapshots management                | Supported     |
| Pre/post command execution          | Supported     |
| Access to VM disk backup over iSCSI | Supported     |
| VM name-based policy assignment     | Supported     |
| VM tag-based policy assignment      | Not supported |
| Power-on VM after restore           | Not supported |

###

### KVM

**Supported backup strategies: SSH transfer**

| Supported versions                                                  | QEMU 2.1 and higher |
| ------------------------------------------------------------------- | ------------------- |
| The last snapshot is kept on the hypervisor for incremental backups | Yes                 |
| Access to hypervisor OS required                                    | Yes                 |
| Proxy VM required                                                   | No                  |

| Full backup                         | Supported     |
| ----------------------------------- | ------------- |
| Incremental backup                  | Supported \*  |
| Restore                             | Supported     |
| File-level restore                  | Supported     |
| VM disk exclusion                   | Supported     |
| Quiesced snapshots                  | Supported     |
| Snapshots management                | Not supported |
| Pre/post command execution          | Supported     |
| Access to VM disk backup over iSCSI | Supported     |
| VM name-based policy assignment     | Supported     |
| VM tag-based policy assignment      | Not supported |
| Power-on VM after restore           | Supported     |

*\* Not supported for LVM disks*

{% hint style="info" %}
Supported VM storage formats: QCOW2/RAW, Ceph RBD volume, LVM volume, LVM-thin volume
{% endhint %}

### Nutanix AHV

**Supported backup strategies:** Disk attachment

| Supported versions                                                  | 5.5, 5.6, 5.8, 5.9, 5.10, 5.11, 5.15, 5.16, 5.17, 5,18, 5.19, 5.20, 6.0, 6.1, 6.5, 6.6, 6.7, 6.8 |
| ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ |
| The last snapshot is kept on the hypervisor for incremental backups | Yes                                                                                              |
| Access to hypervisor OS required                                    | No                                                                                               |
| Proxy VM required                                                   | Yes                                                                                              |

| Full backup                         | Supported    |
| ----------------------------------- | ------------ |
| Incremental backup                  | Supported    |
| Restore                             | Supported    |
| File-level restore                  | Supported    |
| VM disk exclusion                   | Supported    |
| Quiesced snapshots                  | Supported    |
| Snapshots management                | Supported    |
| Pre/post command execution          | Supported    |
| Access to VM disk backup over iSCSI | Supported    |
| VM name-based policy assignment     | Supported    |
| VM tag-based policy assignment      | Supported \* |
| Power-on VM after restore           | Supported    |

*\* When using Prism Central*

{% hint style="warning" %}
Backup of virtual machines with vTPM enabled is not supported
{% endhint %}

### Proxmox VE

**Supported backup strategies:** Export storage repositories, SSH transfer

<table data-full-width="false"><thead><tr><th width="274"></th><th width="240">Export storage repository</th><th width="230">SSH transfer</th></tr></thead><tbody><tr><td>Supported versions</td><td>5.2, 5.3, 5.4, 6.0, 6.1, 6.2, 6.3, 6.3, 6.4, 7.0, 7.1, 7.2, 7.3, 7.4, 8.0, 8.1, 8.2</td><td>5.2, 5.3, 5.4, 6.0, 6.1, 6.2, 6.3, 6.3, 6.4, 7.0, 7.1, 7.2, 7.3, 7.4, 8.0, 8.1, 8.2</td></tr><tr><td>The last snapshot is kept on the hypervisor for incremental backups</td><td>Yes</td><td>Yes</td></tr><tr><td>Access to hypervisor OS required</td><td>Yes</td><td>Yes</td></tr><tr><td>Proxy VM required</td><td>Yes</td><td>No</td></tr></tbody></table>

<table><thead><tr><th width="273"></th><th width="239">Export storage repository</th><th>SSH transfer</th></tr></thead><tbody><tr><td>Full backup</td><td>Supported</td><td>Supported</td></tr><tr><td>Incremental backup</td><td>Not supported</td><td>Supported</td></tr><tr><td>Restore</td><td>Supported</td><td>Supported</td></tr><tr><td>File-level restore</td><td>Supported</td><td>Supported</td></tr><tr><td>VM disk exclusion</td><td>Not supported</td><td>Supported</td></tr><tr><td>Quiesced snapshots</td><td>Supported</td><td>Supported</td></tr><tr><td>Snapshots management</td><td>Supported</td><td>Supported</td></tr><tr><td>Pre/post command execution</td><td>Supported</td><td>Supported</td></tr><tr><td>Access to VM disk backup over iSCSI</td><td>Not supported</td><td>Supported</td></tr><tr><td>VM name-based policy assignment</td><td>Supported</td><td>Supported</td></tr><tr><td>VM tag-based policy assignment</td><td>Not supported</td><td>Not supported</td></tr><tr><td>Power-on VM after restore</td><td>Supported</td><td>Supported</td></tr></tbody></table>

### OpenNebula

**Supported backup strategies:** CBT

| Supported versions                                                  | 6.6, 6.7, 6.8, 6.9 |
| ------------------------------------------------------------------- | ------------------ |
| The last snapshot is kept on the hypervisor for incremental backups | No                 |
| Access to hypervisor OS required                                    | No                 |
| Proxy VM required                                                   | Yes                |

| Full backup                         | Supported                 |
| ----------------------------------- | ------------------------- |
| Incremental backup                  | Supported                 |
| Restore                             | Supported                 |
| File-level restore                  | Supported                 |
| VM disk exclusion                   | Supported                 |
| Quiesced snapshots                  | Supported                 |
| Snapshots management                | Supported                 |
| Pre/post command execution          | Supported                 |
| Access to VM disk backup over iSCSI | Supported                 |
| VM name-based policy assignment     | Supported                 |
| VM tag-based policy assignment      | Supported                 |
| Power-on VM after restore           | Not Supported (always on) |

{% hint style="info" %}
During the data export phase, the hypervisor may experience higher CPU usage
{% endhint %}

### OpenStack

**Supported backup strategies:** Disk attachment, Image transfer, CBT

<table data-full-width="false"><thead><tr><th width="273"></th><th width="159">Disk attachment</th><th width="157">CBT</th><th>SSH Transfer</th></tr></thead><tbody><tr><td>Supported versions</td><td>Queens, Rocky, Stein, Train, Ussuri, Victoria, Wallaby, Xena, Yoga, Zed, Antelope, Bobcat, Caracal</td><td>Queens, Rocky, Stein, Train, Ussuri, Victoria, Wallaby, Xena, Yoga, Zed, Antelope, Bobcat, Caracal</td><td>Queens, Rocky, Stein, Train, Ussuri, Victoria, Wallaby, Xena, Yoga, Zed, Antelope, Bobcat, Caracal</td></tr><tr><td>The last snapshot is kept on the hypervisor for incremental backups</td><td>Yes</td><td>No</td><td>Yes</td></tr><tr><td>Access to hypervisor OS required</td><td>No</td><td>No</td><td>Yes</td></tr><tr><td>Proxy VM required</td><td>Yes</td><td>Yes</td><td>No</td></tr></tbody></table>

<table><thead><tr><th width="273"></th><th>Disk attachment</th><th width="158">CBT</th><th>SSH Transfer</th></tr></thead><tbody><tr><td>Full backup</td><td>Supported *</td><td>Supported</td><td>Supported</td></tr><tr><td>Incremental backup</td><td>Not supported</td><td>Supported</td><td>Supported</td></tr><tr><td>Restore</td><td>Supported</td><td>Supported</td><td>Supported</td></tr><tr><td>File-level restore</td><td>Supported</td><td>Supported</td><td>Supported</td></tr><tr><td>VM disk exclusion</td><td>Supported</td><td>Supported</td><td>Supported</td></tr><tr><td>Quiesced snapshots</td><td>Supported **</td><td>Supported **</td><td>Supported **</td></tr><tr><td>Snapshots management</td><td>Supported ***</td><td>Supported ***</td><td>Not supported</td></tr><tr><td>Pre/post command execution</td><td>Supported</td><td>Supported</td><td>Supported</td></tr><tr><td>Access to VM disk backup over iSCSI</td><td>Supported</td><td>Supported</td><td>Supported ****</td></tr><tr><td>VM name-based policy assignment</td><td>Supported</td><td>Supported</td><td>Supported</td></tr><tr><td>VM tag-based policy assignment</td><td>Supported</td><td>Supported</td><td>Supported</td></tr><tr><td>Power-on VM after restore</td><td>Not supported (always on)</td><td>Not supported (always on)</td><td>Not supported (always on)</td></tr></tbody></table>

*\* Ceph RBD volumes only*\
*\*\* Hypervisor dependent*\
*\*\*\* Without snapshot revert*\
*\*\*\*\* RAW/LVM disks only*

### Oracle Linux Virtualization Manager

**Supported backup strategies:** Disk attachment, Image transfer, CBT

<table data-full-width="false"><thead><tr><th width="273"></th><th width="159">Disk attachment</th><th width="157">Image transfer</th><th>CBT</th></tr></thead><tbody><tr><td>Supported versions</td><td>4.3, 4.4, 4.5</td><td>4.3, 4.4, 4.5</td><td>4.4, 4.5</td></tr><tr><td>The last snapshot is kept on the hypervisor for incremental backups</td><td>No</td><td>Yes</td><td>No</td></tr><tr><td>Access to hypervisor OS required</td><td>No</td><td>No</td><td>No</td></tr><tr><td>Proxy VM required</td><td>Yes</td><td>No</td><td>No</td></tr></tbody></table>

<table><thead><tr><th width="273"></th><th>Disk attachment</th><th width="158">Image Transfer</th><th>CBT</th></tr></thead><tbody><tr><td>Full backup</td><td>Supported</td><td>Supported</td><td>Supported</td></tr><tr><td>Incremental backup</td><td>Not supported</td><td>Supported</td><td>Supported</td></tr><tr><td>Restore</td><td>Supported</td><td>Supported</td><td>Supported</td></tr><tr><td>File-level restore</td><td>Supported</td><td>Supported</td><td>Supported</td></tr><tr><td>VM disk exclusion</td><td>Supported</td><td>Supported</td><td>Supported</td></tr><tr><td>Quiesced snapshots</td><td>Supported</td><td>Supported</td><td>Supported</td></tr><tr><td>Snapshots management</td><td>Supported</td><td>Supported</td><td>Supported</td></tr><tr><td>Pre/post command execution</td><td>Supported</td><td>Supported</td><td>Supported</td></tr><tr><td>Access to VM disk backup over iSCSI</td><td>Supported</td><td>Supported <strong>*</strong></td><td>Supported</td></tr><tr><td>VM name-based policy assignment</td><td>Supported</td><td>Supported</td><td>Supported</td></tr><tr><td>VM tag-based policy assignment</td><td>Supported</td><td>Supported</td><td>Supported</td></tr><tr><td>Power-on VM after restore</td><td>Supported</td><td>Supported</td><td>Supported</td></tr></tbody></table>

*\* Only for RAW disk types*

{% hint style="warning" %}
Direct LUN disks are not supported
{% endhint %}

### Oracle VM

**Supported backup strategies:** Export storage repository

| Supported versions                                                  | 3.4 |
| ------------------------------------------------------------------- | --- |
| The last snapshot is kept on the hypervisor for incremental backups | n/a |
| Access to hypervisor OS required                                    | No  |
| Proxy VM required                                                   | No  |

| Full backup                         | Supported     |
| ----------------------------------- | ------------- |
| Incremental backup                  | Not supported |
| Restore                             | Supported     |
| File-level restore                  | Supported     |
| VM disk exclusion                   | Supported     |
| Quiesced snapshots                  | Not supported |
| Snapshots management                | Not supported |
| Pre/post command execution          | Not supported |
| Access to VM disk backup over iSCSI | Supported     |
| VM name-based policy assignment     | Not supported |
| VM tag-based policy assignment      | Supported     |
| Power-on VM after restore           | Not Supported |

### oVirt

**Supported backup strategies:** Disk attachment, Image transfer, CBT

<table data-full-width="false"><thead><tr><th width="273"></th><th width="159">Disk attachment</th><th width="157">Image transfer</th><th>CBT</th></tr></thead><tbody><tr><td>Supported versions</td><td>4.0, 4.1, 4.2, 4.3, 4.4, 4.5</td><td>4.3, 4.4, 4.5</td><td>4.4, 4.5</td></tr><tr><td>The last snapshot is kept on the hypervisor for incremental backups</td><td>No</td><td>Yes</td><td>No</td></tr><tr><td>Access to hypervisor OS required</td><td>No</td><td>No</td><td>No</td></tr><tr><td>Proxy VM required</td><td>Yes</td><td>No</td><td>No</td></tr></tbody></table>

<table><thead><tr><th width="273"></th><th>Disk attachment</th><th width="158">Image Transfer</th><th>CBT</th></tr></thead><tbody><tr><td>Full backup</td><td>Supported</td><td>Supported</td><td>Supported</td></tr><tr><td>Incremental backup</td><td>Not supported</td><td>Supported</td><td>Supported</td></tr><tr><td>Restore</td><td>Supported</td><td>Supported</td><td>Supported</td></tr><tr><td>File-level restore</td><td>Supported</td><td>Supported</td><td>Supported</td></tr><tr><td>VM disk exclusion</td><td>Supported</td><td>Supported</td><td>Supported</td></tr><tr><td>Quiesced snapshots</td><td>Supported</td><td>Supported</td><td>Supported</td></tr><tr><td>Snapshots management</td><td>Supported</td><td>Supported</td><td>Supported</td></tr><tr><td>Pre/post command execution</td><td>Supported</td><td>Supported</td><td>Supported</td></tr><tr><td>Access to VM disk backup over iSCSI</td><td>Supported</td><td>Supported <strong>*</strong></td><td>Supported</td></tr><tr><td>VM name-based policy assignment</td><td>Supported</td><td>Supported</td><td>Supported</td></tr><tr><td>VM tag-based policy assignment</td><td>Supported</td><td>Supported</td><td>Supported</td></tr><tr><td>Power-on VM after restore</td><td>Supported</td><td>Supported</td><td>Supported</td></tr></tbody></table>

*\* Only for RAW disk types*

### Red Hat Virtualization

**Supported backup strategies:** Disk attachment, Image transfer, CBT

<table data-full-width="false"><thead><tr><th width="273"></th><th width="159">Disk attachment</th><th width="157">Image transfer</th><th>CBT</th></tr></thead><tbody><tr><td>Supported versions</td><td>4.0, 4.1, 4.2, 4.3</td><td>4.3, 4.4</td><td>4.4</td></tr><tr><td>The last snapshot is kept on the hypervisor for incremental backups</td><td>No</td><td>Yes</td><td>No</td></tr><tr><td>Access to hypervisor OS required</td><td>No</td><td>No</td><td>No</td></tr><tr><td>Proxy VM required</td><td>Yes</td><td>No</td><td>No</td></tr></tbody></table>

<table><thead><tr><th width="273"></th><th>Disk attachment</th><th width="158">Image Transfer</th><th>CBT</th></tr></thead><tbody><tr><td>Full backup</td><td>Supported</td><td>Supported</td><td>Supported</td></tr><tr><td>Incremental backup</td><td>Not supported</td><td>Supported</td><td>Supported</td></tr><tr><td>Restore</td><td>Supported</td><td>Supported</td><td>Supported</td></tr><tr><td>File-level restore</td><td>Supported</td><td>Supported</td><td>Supported</td></tr><tr><td>VM disk exclusion</td><td>Supported</td><td>Supported</td><td>Supported</td></tr><tr><td>Quiesced snapshots</td><td>Supported</td><td>Supported</td><td>Supported</td></tr><tr><td>Snapshots management</td><td>Supported</td><td>Supported</td><td>Supported</td></tr><tr><td>Pre/post command execution</td><td>Supported</td><td>Supported</td><td>Supported</td></tr><tr><td>Access to VM disk backup over iSCSI</td><td>Supported</td><td>Supported <strong>*</strong></td><td>Supported</td></tr><tr><td>VM name-based policy assignment</td><td>Supported</td><td>Supported</td><td>Supported</td></tr><tr><td>VM tag-based policy assignment</td><td>Supported</td><td>Supported</td><td>Supported</td></tr><tr><td>Power-on VM after restore</td><td>Supported</td><td>Supported</td><td>Supported</td></tr></tbody></table>

*\* Only for RAW disk types*

### SC//Platform

**Supported backup strategies:** Export storage domain, disk attachment

<table data-full-width="false"><thead><tr><th width="274"></th><th width="240">Export storage domain</th><th width="230">Disk attachment</th></tr></thead><tbody><tr><td>Supported versions</td><td>8.9</td><td>8.9</td></tr><tr><td>The last snapshot is kept on the hypervisor for incremental backups</td><td>No</td><td>Yes</td></tr><tr><td>Access to hypervisor OS required</td><td>No</td><td>No</td></tr><tr><td>Proxy VM required</td><td>No</td><td>Yes</td></tr></tbody></table>

<table><thead><tr><th width="273"></th><th width="239">Export storage repository</th><th>SSH transfer</th></tr></thead><tbody><tr><td>Full backup</td><td>Supported</td><td>Supported</td></tr><tr><td>Incremental backup</td><td>Not supported</td><td>Supported</td></tr><tr><td>Restore</td><td>Supported</td><td>Supported</td></tr><tr><td>File-level restore</td><td>Not supported</td><td>Supported</td></tr><tr><td>VM disk exclusion</td><td>Supported</td><td>Supported</td></tr><tr><td>Quiesced snapshots</td><td>Not supported</td><td>Not supported</td></tr><tr><td>Snapshots management</td><td>Supported</td><td>Supported</td></tr><tr><td>Pre/post command execution</td><td>Supported</td><td>Supported</td></tr><tr><td>Access to VM disk backup over iSCSI</td><td>Supported</td><td>Supported</td></tr><tr><td>VM name-based policy assignment</td><td>Supported</td><td>Supported</td></tr><tr><td>VM tag-based policy assignment</td><td>Supported</td><td>Supported</td></tr><tr><td>Power-on VM after restore</td><td>Supported</td><td>Supported</td></tr></tbody></table>

### Verge

**Supported backup strategies:** CBT

| Supported versions                                                  | 4.13 |
| ------------------------------------------------------------------- | ---- |
| The last snapshot is kept on the hypervisor for incremental backups | No   |
| Access to hypervisor OS required                                    | No   |
| Proxy VM required                                                   | No   |

| Full backup                         | Supported     |
| ----------------------------------- | ------------- |
| Incremental backup                  | Supported     |
| Restore                             | Supported     |
| File-level restore                  | Supported     |
| VM disk exclusion                   | Supported     |
| Quiesced snapshots                  | Supported     |
| Snapshots management                | Not supported |
| Pre/post command execution          | Supported     |
| Access to VM disk backup over iSCSI | Supported     |
| VM name-based policy assignment     | Supported     |
| VM tag-based policy assignment      | Supported     |
| Power-on VM after restore           | Supported     |

### Virtuozzo

**Supported backup strategies:** Disk attachment

| Supported versions                                                  | 4.7, 5.0, 5.2, 5.3, 5.4, 6.0, 6.1, 6.2 |
| ------------------------------------------------------------------- | -------------------------------------- |
| The last snapshot is kept on the hypervisor for incremental backups | Yes                                    |
| Access to hypervisor OS required                                    | No                                     |
| Proxy VM required                                                   | Yes                                    |

| Full backup                         | Supported                 |
| ----------------------------------- | ------------------------- |
| Incremental backup                  | Supported                 |
| Restore                             | Supported                 |
| File-level restore                  | Supported                 |
| VM disk exclusion                   | Supported                 |
| Quiesced snapshots                  | Supported \*              |
| Snapshots management                | Supported \*\*            |
| Pre/post command execution          | Supported                 |
| Access to VM disk backup over iSCSI | Supported                 |
| VM name-based policy assignment     | Supported                 |
| VM tag-based policy assignment      | Supported                 |
| Power-on VM after restore           | Not Supported (always on) |

*\* Hypervisor dependent*\
*\*\* Without snapshot revert*

### VMware vSphere/ESXi

**Supported backup strategies:** HotAdd, NBD

<table data-full-width="false"><thead><tr><th width="274"></th><th width="240">HotAdd</th><th width="230">NBD</th></tr></thead><tbody><tr><td>Supported versions</td><td>6.5, 6.7, 7.0, 8.0</td><td>6.5, 6.7, 7.0, 8.0</td></tr><tr><td>The last snapshot is kept on the hypervisor for incremental backups</td><td>No</td><td>No</td></tr><tr><td>Access to hypervisor OS required</td><td>No</td><td>No</td></tr><tr><td>Proxy VM required</td><td>Yes</td><td>No</td></tr></tbody></table>

<table><thead><tr><th width="273"></th><th width="239">HotAdd</th><th>NBD</th></tr></thead><tbody><tr><td>Full backup</td><td>Supported</td><td>Supported</td></tr><tr><td>Incremental backup</td><td>Supported</td><td>Supported</td></tr><tr><td>Restore</td><td>Supported</td><td>Supported</td></tr><tr><td>File-level restore</td><td>Supported</td><td>Supported</td></tr><tr><td>VM disk exclusion</td><td>Supported</td><td>Supported</td></tr><tr><td>Quiesced snapshots</td><td>Supported</td><td>Supported</td></tr><tr><td>Snapshots management</td><td>Supported</td><td>Supported</td></tr><tr><td>Pre/post command execution</td><td>Supported</td><td>Supported</td></tr><tr><td>Access to VM disk backup over iSCSI</td><td>Supported</td><td>Supported</td></tr><tr><td>VM name-based policy assignment</td><td>Supported</td><td>Supported</td></tr><tr><td>VM tag-based policy assignment</td><td>Supported</td><td>Supported</td></tr><tr><td>Power-on VM after restore</td><td>Supported</td><td>Supported</td></tr></tbody></table>

### XCP-ng

**Supported backup strategies:** Single image (XVA), CBT

<table data-full-width="false"><thead><tr><th width="274"></th><th width="240">Single image (XVA)</th><th width="230">CBT</th></tr></thead><tbody><tr><td>Supported versions</td><td>7.4, 7.5, 7.6, 8.0, 8.1, 8.2, 8.3</td><td>7.4, 7.5, 7.6, 8.0, 8.1, 8.2, 8.3</td></tr><tr><td>The last snapshot is kept on the hypervisor for incremental backups</td><td>Yes</td><td>Yes</td></tr><tr><td>Access to hypervisor OS required</td><td>No</td><td>Yes</td></tr><tr><td>Proxy VM required</td><td>No</td><td>No</td></tr></tbody></table>

<table><thead><tr><th width="273"></th><th width="239">Single image (XVA)</th><th>CBT</th></tr></thead><tbody><tr><td>Full backup</td><td>Supported</td><td>Supported</td></tr><tr><td>Incremental backup</td><td>Supported *</td><td>Supported</td></tr><tr><td>Restore</td><td>Supported</td><td>Supported</td></tr><tr><td>File-level restore</td><td>Not supported</td><td>Supported</td></tr><tr><td>VM disk exclusion</td><td>Not supported</td><td>Supported</td></tr><tr><td>Quiesced snapshots</td><td>Supported</td><td>Supported</td></tr><tr><td>Snapshots management</td><td>Supported</td><td>Supported</td></tr><tr><td>Pre/post command execution</td><td>Supported</td><td>Supported</td></tr><tr><td>Access to VM disk backup over iSCSI</td><td>Not supported</td><td>Supported</td></tr><tr><td>VM name-based policy assignment</td><td>Supported</td><td>Supported</td></tr><tr><td>VM tag-based policy assignment</td><td>Supported</td><td>Supported</td></tr><tr><td>Power-on VM after restore</td><td>Supported</td><td>Supported</td></tr></tbody></table>

*\* Not supported when using a synthetic backup destination*

### XenServer (Citrix Hypervisor)

**Supported backup strategies:** Single image (XVA), CBT

<table data-full-width="false"><thead><tr><th width="274"></th><th width="240">Single image (XVA)</th><th width="230">CBT</th></tr></thead><tbody><tr><td>Supported versions</td><td>6.5, 7.0, 7.1, 7.2, 7.3, 7.4, 7.5, 7.6, 8.0, 8.1, 8.2</td><td>6.5, 7.0, 7.1, 7.2, 7.3, 7.4, 7.5, 7.6, 8.0, 8.1, 8.2</td></tr><tr><td>The last snapshot is kept on the hypervisor for incremental backups</td><td>Yes</td><td>Yes</td></tr><tr><td>Access to hypervisor OS required</td><td>No</td><td>Yes</td></tr><tr><td>Proxy VM required</td><td>No</td><td>No</td></tr></tbody></table>

<table><thead><tr><th width="273"></th><th width="239">Single image (XVA)</th><th>CBT</th></tr></thead><tbody><tr><td>Full backup</td><td>Supported</td><td>Supported</td></tr><tr><td>Incremental backup</td><td>Supported</td><td>Supported *</td></tr><tr><td>Restore</td><td>Supported</td><td>Supported</td></tr><tr><td>File-level restore</td><td>Not supported</td><td>Supported</td></tr><tr><td>VM disk exclusion</td><td>Not supported</td><td>Supported</td></tr><tr><td>Quiesced snapshots</td><td>Supported</td><td>Supported</td></tr><tr><td>Snapshots management</td><td>Supported</td><td>Supported</td></tr><tr><td>Pre/post command execution</td><td>Supported</td><td>Supported</td></tr><tr><td>Access to VM disk backup over iSCSI</td><td>Not supported</td><td>Supported</td></tr><tr><td>VM name-based policy assignment</td><td>Supported</td><td>Supported</td></tr><tr><td>VM tag-based policy assignment</td><td>Supported</td><td>Supported</td></tr><tr><td>Power-on VM after restore</td><td>Supported</td><td>Supported</td></tr></tbody></table>

*\* Requires XenServer 7.3 or higher*

## Containers

### Kubernetes

**Supported backup strategies:** Helper pod, Ceph RBD

<table data-full-width="false"><thead><tr><th width="274"></th><th width="240">Helper pod</th><th width="230">Ceph RBD</th></tr></thead><tbody><tr><td>Minimal version</td><td>1.10</td><td>1.10</td></tr><tr><td>The last snapshot is kept on the system for incremental backups</td><td>Yes</td><td>Yes</td></tr><tr><td>Access to OS required</td><td>No</td><td>No</td></tr><tr><td>Proxy VM required</td><td>No</td><td>No</td></tr></tbody></table>

<table><thead><tr><th width="273"></th><th width="239">Helper pod</th><th>Ceph RBD</th></tr></thead><tbody><tr><td>Full backup</td><td>Supported</td><td>Supported</td></tr><tr><td>Incremental backup</td><td>Not supportd</td><td>Supported *</td></tr><tr><td>Restore</td><td>Supported</td><td>Supported</td></tr><tr><td>File-level restore</td><td>Not supported</td><td>Supported *</td></tr><tr><td>Volume exclusion</td><td>Supported</td><td>Supported</td></tr><tr><td>Quiesced snapshots</td><td>Supported **</td><td>Supported **</td></tr><tr><td>Snapshots management</td><td>Not supported</td><td>Not supported</td></tr><tr><td>Pre/post command execution</td><td>Supported ***</td><td>Supported ***</td></tr><tr><td>Access to VM disk backup over iSCSI</td><td>Not supported</td><td>Supported *</td></tr><tr><td>Name-based policy assignment</td><td>Supported</td><td>Supported</td></tr><tr><td>Tag-based policy assignment</td><td>Supported</td><td>Supported</td></tr><tr><td>Power-on after restore</td><td>Supported</td><td>Supported</td></tr><tr><td>StatefulSet</td><td>Supported</td><td>Supported</td></tr></tbody></table>

*\* When using Ceph RBD as Persistent Volume*

*\*\* Deployment pause*

*\*\*\* Only 'post'*

### Proxmox VE

**Supported backup strategies:** Export storage repository

| Supported versions                                                  | 5.2, 5.3, 5.4, 6.0, 6.1, 6.2, 6.3, 6.3, 6.4, 7.0, 7.1, 7.2, 7.3, 7.4, 8.0, 8.1, 8.2 |
| ------------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
| The last snapshot is kept on the hypervisor for incremental backups | Yes                                                                                 |
| Access to hypervisor OS required                                    | No                                                                                  |
| Proxy VM required                                                   | Yes                                                                                 |

| Full backup                         | Supported    |
| ----------------------------------- | ------------ |
| Incremental backup                  | Supported    |
| Restore                             | Supported    |
| File-level restore                  | Supported    |
| VM disk exclusion                   | Supported    |
| Quiesced snapshots                  | Supported    |
| Snapshots management                | Supported    |
| Pre/post command execution          | Supported    |
| Access to VM disk backup over iSCSI | Supported    |
| VM name-based policy assignment     | Supported    |
| VM tag-based policy assignment      | Supported \* |
| Power-on after restore              | Supported    |

*\* When using Prism Central*

### Red Hat OpenShift

**Supported backup strategies:** Helper pod, Ceph RBD

<table data-full-width="false"><thead><tr><th width="274"></th><th width="240">Helper pod</th><th width="230">Ceph RBD</th></tr></thead><tbody><tr><td>Minimal version</td><td>4.10</td><td>4.10</td></tr><tr><td>The last snapshot is kept on the system for incremental backups</td><td>Yes</td><td>Yes</td></tr><tr><td>Access to OS required</td><td>No</td><td>No</td></tr><tr><td>Proxy VM required</td><td>No</td><td>No</td></tr></tbody></table>

<table><thead><tr><th width="273"></th><th width="239">Helper pod</th><th>Ceph RBD</th></tr></thead><tbody><tr><td>Full backup</td><td>Supported</td><td>Supported</td></tr><tr><td>Incremental backup</td><td>Not supportd</td><td>Supported *</td></tr><tr><td>Restore</td><td>Supported</td><td>Supported</td></tr><tr><td>File-level restore</td><td>Not supported</td><td>Supported *</td></tr><tr><td>Volume exclusion</td><td>Supported</td><td>Supported</td></tr><tr><td>Quiesced snapshots</td><td>Supported **</td><td>Supported **</td></tr><tr><td>Snapshots management</td><td>Not supported</td><td>Not supported</td></tr><tr><td>Pre/post command execution</td><td>Supported ***</td><td>Supported ***</td></tr><tr><td>Access to VM disk backup over iSCSI</td><td>Not supported</td><td>Supported *</td></tr><tr><td>Name-based policy assignment</td><td>Supported</td><td>Supported</td></tr><tr><td>Tag-based policy assignment</td><td>Supported</td><td>Supported</td></tr><tr><td>Power-on after restore</td><td>Supported</td><td>Supported</td></tr><tr><td>StatfuSet</td><td>Supported</td><td>Supported</td></tr></tbody></table>

*\* When using Ceph RBD as Persistent Volume*

*\*\* Deployment pause*

*\*\*\* Only 'post'*

## Cloud

### **Amazon EC2**

**Supported backup strategies:** Disk attachment, CBT

<table data-full-width="false"><thead><tr><th width="274"></th><th width="240">Disk attachement</th><th width="230">CBT</th></tr></thead><tbody><tr><td>The last snapshot is kept on the hypervisor for incremental backups</td><td>No</td><td>No</td></tr><tr><td>Access to hypervisor OS required</td><td>No</td><td>No</td></tr><tr><td>Proxy VM required</td><td>Yes</td><td>Yes</td></tr></tbody></table>

<table><thead><tr><th width="273"></th><th width="239">Disk attachement</th><th>CBT</th></tr></thead><tbody><tr><td>Full backup</td><td>Supported</td><td>Supported</td></tr><tr><td>Incremental backup</td><td>Not supported</td><td>Supported</td></tr><tr><td>Restore</td><td>Supported</td><td>Supported</td></tr><tr><td>File-level restore</td><td>Supported</td><td>Supported</td></tr><tr><td>VM disk exclusion</td><td>Supported</td><td>Supported</td></tr><tr><td>Quiesced snapshots</td><td>Not supported</td><td>Not supported</td></tr><tr><td>Snapshots management</td><td>Supported</td><td>Supported</td></tr><tr><td>Pre/post command execution</td><td>Supported</td><td>Supported</td></tr><tr><td>Access to VM disk backup over iSCSI</td><td>Supported</td><td>Supported</td></tr><tr><td>VM name-based policy assignment</td><td>Supported</td><td>Supported</td></tr><tr><td>VM tag-based policy assignment</td><td>Supported</td><td>Supported</td></tr><tr><td>Power-on VM after restore</td><td>Supported</td><td>Supported</td></tr></tbody></table>

### Microsoft Azure

**Supported backup strategies:** Disk attachment, CBT

<table data-full-width="false"><thead><tr><th width="274"></th><th width="240">Disk attachement</th><th width="230">CBT</th></tr></thead><tbody><tr><td>The last snapshot is kept on the hypervisor for incremental backups</td><td>No</td><td>No</td></tr><tr><td>Access to hypervisor OS required</td><td>No</td><td>No</td></tr><tr><td>Proxy VM required</td><td>Yes</td><td>Yes</td></tr></tbody></table>

<table><thead><tr><th width="273"></th><th width="239">Disk attachement</th><th>CBT</th></tr></thead><tbody><tr><td>Full backup</td><td>Supported</td><td>Supported</td></tr><tr><td>Incremental backup</td><td>Not supported</td><td>Supported</td></tr><tr><td>Restore</td><td>Supported</td><td>Supported</td></tr><tr><td>File-level restore</td><td>Supported</td><td>Supported</td></tr><tr><td>VM disk exclusion</td><td>Supported</td><td>Supported</td></tr><tr><td>Quiesced snapshots</td><td>Not supported</td><td>Not supported</td></tr><tr><td>Snapshots management</td><td>Not supported</td><td>Not supported</td></tr><tr><td>Pre/post command execution</td><td>Supported</td><td>Supported</td></tr><tr><td>Access to VM disk backup over iSCSI</td><td>Supported</td><td>Supported</td></tr><tr><td>VM name-based policy assignment</td><td>Supported</td><td>Supported</td></tr><tr><td>VM tag-based policy assignment</td><td>Supported</td><td>Supported</td></tr><tr><td>Power-on VM after restore</td><td>Not supported (always on)</td><td>Not supported (always on)</td></tr></tbody></table>

### Microsoft 365

#### Mailbox messages

| Full backup                | Supported |
| -------------------------- | --------- |
| Incremental backup         | Supported |
| Restore                    | Supported |
| Single item restore        | Supported |
| Restore to another path    | Supported |
| Restore to another account | Supported |
| Local restore (raw data)   | Supported |
| Restore to PST             | Supported |

#### Mailbox messages archive

| Full backup                | Supported |
| -------------------------- | --------- |
| Incremental backup         | Supported |
| Restore                    | Supported |
| Single item restore        | Supported |
| Restore to another path    | Supported |
| Restore to another account | Supported |
| Local restore (raw data)   | Supported |
| Restore to PST             | Supported |

#### Contacts

| Full backup                | Supported     |
| -------------------------- | ------------- |
| Incremental backup         | Supported     |
| Restore                    | Supported     |
| Single item restore        | Supported     |
| Restore to another path    | Supported     |
| Restore to another account | Supported     |
| Local restore (raw data)   | Supported     |
| Restore to PST             | Not supported |

#### Calendars

| Full backup                 | Supported     |
| --------------------------- | ------------- |
| Incremental backup          | Supported     |
| Restore                     | Supported     |
| Single item restore         | Supported     |
| Restore to another calendar | Supported     |
| Restore to another account  | Supported     |
| Local restore (raw data)    | Supported     |
| Restore to PST              | Not supported |

#### OneDrive for Business

| Full backup                | Supported |
| -------------------------- | --------- |
| Incremental backup         | Supported |
| Restore                    | Supported |
| Single item restore        | Supported |
| Restore to another path    | Supported |
| Restore to another account | Supported |
| Local restore (raw data)   | Supported |

#### Sharepoint sites

| Full backup              | Supported     |
| ------------------------ | ------------- |
| Incremental backup       | Supported     |
| Restore                  | Supported     |
| Single item restore      | Supported     |
| Restore to another path  | Supported     |
| Restore to another site  | Not supported |
| Local restore (raw data) | Supported     |

#### Sharepoint pages

| Full backup              | Supported     |
| ------------------------ | ------------- |
| Incremental backup       | Supported     |
| Restore                  | Supported     |
| Single item restore      | Supported     |
| Restore to another path  | Supported     |
| Restore to another site  | Not supported |
| Local restore (raw data) | Supported     |

#### Sharepoint list items

| Full backup              | Supported     |
| ------------------------ | ------------- |
| Incremental backup       | Supported     |
| Restore                  | Supported     |
| Single item restore      | Supported     |
| Restore to another path  | Supported     |
| Restore to another site  | Not supported |
| Local restore (raw data) | Supported     |

#### Sharepoint document libraries

| Full backup              | Supported     |
| ------------------------ | ------------- |
| Incremental backup       | Supported     |
| Restore                  | Supported     |
| Single item restore      | Supported     |
| Restore to another path  | Supported     |
| Restore to another site  | Not supported |
| Local restore (raw data) | Supported     |

#### Teams channel

| Full backup                      | Supported     |
| -------------------------------- | ------------- |
| Incremental backup               | Supported     |
| Restore                          | Supported     |
| Single item restore              | Not supported |
| Restore to another team          | Not supported |
| Local restore (messeges history) | Supported     |

#### Teams 1on1 chat

| Full backup                      | Supported     |
| -------------------------------- | ------------- |
| Incremental backup               | Supported     |
| Restore                          | Supported     |
| Single item restore              | Not supported |
| Restore to another team          | Not supported |
| Local restore (messeges history) | Supported     |

#### Teams files

| Full backup              | Supported     |
| ------------------------ | ------------- |
| Incremental backup       | Supported     |
| Restore                  | Supported     |
| Single item restore      | Supported     |
| Restore to another team  | Not supported |
| Local restore (raw data) | Supported     |

Storware Backup and Recovery uses [Microsoft Teams Export API](https://learn.microsoft.com/en-us/microsoftteams/export-teams-content) to export Teams data.

Utilizing the Microsoft Teams Export API generates [additional costs](https://learn.microsoft.com/en-us/graph/teams-licenses#modelb-requirements) for Microsoft tenant.

## Storage Providers

### File system

**Source type:** Any POSIX-compliant file system mounted on the node.

| Full backup                       | Supported                                  |
| --------------------------------- | ------------------------------------------ |
| Incremental backup                | Supported (file modification time or size) |
| Restore                           | Supported                                  |
| Single item restore               | Supported                                  |
| Access to files backup over iSCSI | Supported                                  |
| Name-based policy assignment      | Not supported                              |

### Ceph RBD

**Source type:** RBD Volume (RBD Export/RBD-NBD).

Requires Red Hat Ceph Storage version 4.0 or newer or Ceph v14.2.0 Nautilus or newer

| Full backup                       | Supported                 |
| --------------------------------- | ------------------------- |
| Incremental backup                | Supported (RBD snap-diff) |
| Restore                           | Supported                 |
| Single item restore               | Supported                 |
| Access to files backup over iSCSI | Supported                 |
| Name-based policy assignment      | Supported                 |

### Nutanix Files (AFS)

**Source type**: NFS and Samba shares

| Full backup                       | Supported           |
| --------------------------------- | ------------------- |
| Incremental backup                | Supported (CFT API) |
| Restore                           | Supported           |
| Single item restore               | Supported           |
| Access to files backup over iSCSI | Supported           |
| Name-based policy assignment      | Supported           |

### Nutanix Volume Groups

**Source type:** Disk attachment

| Full backup                       | Supported           |
| --------------------------------- | ------------------- |
| Incremental backup                | Supported (CBT API) |
| Restore                           | Supported           |
| Single item restore               | Supported           |
| Snapshot management               | Supported           |
| Access to files backup over iSCSI | Supported           |
| Name-based policy assignment      | Supported           |

### Ceph RBD

**Source type:** RBD Volume (RBD Export/RBD-NBD).

Requires Red Hat Ceph Storage version 4.0 or newer or Ceph v14.2.0 Nautilus or newer

| Full backup                       | Supported                 |
| --------------------------------- | ------------------------- |
| Incremental backup                | Supported (RBD snap-diff) |
| Restore                           | Supported                 |
| Single item restore               | Supported                 |
| Access to files backup over iSCSI | Supported                 |
| Name-based policy assignment      | Supported                 |

## Filesystem backup (OS Agent)

<table data-full-width="false"><thead><tr><th width="274"></th><th width="240">Windows</th><th width="230">Linux</th></tr></thead><tbody><tr><td>Supported operating systems</td><td>Windows 10, Windows 11, Windows Server 2016, Windows Server 2019, Windows Server 2022</td><td>Red Hat Enterprise Linux 8/9, CentOS 9 Stream, Ubuntu 23.10</td></tr></tbody></table>

<table data-full-width="false"><thead><tr><th width="274"></th><th width="240">Windows</th><th width="230">Linux</th></tr></thead><tbody><tr><td>Full backup</td><td>Supported</td><td>Supported</td></tr><tr><td>Incremental backup</td><td>Supported</td><td>Supported</td></tr><tr><td>Maximum number of protected objects per instance</td><td>5 million</td><td>5 million</td></tr></tbody></table>

## Backup destinations

### Filesystem

#### Generic filesystem

| Supported version          | n/a           |
| -------------------------- | ------------- |
| Syntetic backup            | Not supported |
| Random Access              | Supported     |
| Deduplication              | Supported \*  |
| Encryption                 | Supported     |
| Pre/post command execution | Supported     |

*\* When using VDO*

#### XFS filesystem

| Supported version          | Linux 4.15 and newer, xfsprogs 4.17 and newer |
| -------------------------- | --------------------------------------------- |
| Syntetic backup            | Supported                                     |
| Random Access              | Supported                                     |
| Deduplication              | Supported \*                                  |
| Encryption                 | Not supported                                 |
| Pre/post command execution | Supported                                     |

*\* When using VDO*

#### DD Boost (Dell Data Domain)

| Supported version          | DD OS 7.0 and newer |
| -------------------------- | ------------------- |
| Syntetic backup            | Supported           |
| Random Access              | Supported           |
| Deduplication              | Supported           |
| Encryption                 | Supported           |
| Pre/post command execution | Supported           |

#### isoLayer (XFS based)

| Supported version          | n/a           |
| -------------------------- | ------------- |
| Syntetic backup            | Supported     |
| Random Access              | Supported     |
| Deduplication              | Not supported |
| Encryption                 | Not supported |
| Pre/post command execution | Supported     |

### Object storages

#### Amazon S3/S3-comatible

| Syntetic backup            | Not supported |
| -------------------------- | ------------- |
| Random Access              | Not supported |
| Deduplication              | n/a           |
| Encryption                 | Supported     |
| Pre/post command execution | Supported     |

#### Impossible Cloud

| Syntetic backup            | Not supported |
| -------------------------- | ------------- |
| Random Access              | Not supported |
| Deduplication              | n/a           |
| Encryption                 | Supported     |
| Pre/post command execution | Supported     |

#### Google Cloud Storage

| Syntetic backup            | Not supported |
| -------------------------- | ------------- |
| Random Access              | Not supported |
| Deduplication              | n/a           |
| Encryption                 | Supported     |
| Pre/post command execution | Supported     |

#### Microsoft Azure Blob Storage

| Syntetic backup            | Not supported |
| -------------------------- | ------------- |
| Random Access              | Not supported |
| Deduplication              | n/a           |
| Encryption                 | Supported     |
| Pre/post command execution | Supported     |

#### OpenStack Swift

| Syntetic backup            | Not supported |
| -------------------------- | ------------- |
| Random Access              | Not supported |
| Deduplication              | n/a           |
| Encryption                 | Supported     |
| Pre/post command execution | Supported     |

### Enterprise backup providers

#### Dell Avamar

| Supported version          | 7.5 and never      |
| -------------------------- | ------------------ |
| Syntetic backup            | Not supported      |
| Random Access              | Not supported      |
| Deduplication              | Supported          |
| Encryption                 | Provider dependent |
| Pre/post command execution | Supported          |

#### Dell Networker

| Supported version          | 9.0                |
| -------------------------- | ------------------ |
| Syntetic backup            | Not supported      |
| Random Access              | Not supported      |
| Deduplication              | Supported          |
| Encryption                 | Provider dependent |
| Pre/post command execution | Supported          |

#### IBM Spectrum Protect

| Supported version          | 7.1.5 and never    |
| -------------------------- | ------------------ |
| Syntetic backup            | Not supported      |
| Random Access              | Not supported      |
| Deduplication              | Supported          |
| Encryption                 | Provider dependent |
| Pre/post command execution | Supported          |

#### Veritas Netbackup

| Supported version          | 7.5 or newer       |
| -------------------------- | ------------------ |
| Syntetic backup            | Not supported      |
| Random Access              | Not supported      |
| Deduplication              | Supported          |
| Encryption                 | Provider dependent |
| Pre/post command execution | Supported          |

#### OpenText Data Protector

| Supported version          | 11.0 or newer      |
| -------------------------- | ------------------ |
| Syntetic backup            | Not supported      |
| Random Access              | Not supported      |
| Deduplication              | Supported          |
| Encryption                 | Provider dependent |
| Pre/post command execution | Supported          |

### Tape Libraries

Storware Backup and Recovery provides native support for tape devices. The support is fully integrated into the product. Storware Backup and Recovery supports Linear Tape-Open (LTO) tape libraries.

## Integration plugins

| Red Hat Virtualization UI plugin              | oVirt we admin 4.3 and newer |
| --------------------------------------------- | ---------------------------- |
| oVirt UI Plugin                               | oVirt we admin 4.3 and newer |
| Oracle Linux Virtualization Manager UI Plugin | oVirt we admin 4.3 and newer |
| OpenStack UI Plugin                           | Horizon 17.0.0 and never     |


# Components and architecture

## Product components

The Storware Backup and Recovery consists of the following components:

### Server

This component manages the entire solution. The server consists of the MariaDB database to track different information about the system such as configuration, permissions, and various metadata. Typically there is one Storware Backup and Recovery server that can work and manage with multiple nodes. The server provides the administrative web UI.

### Node

This component is used to manage data movement. The component is responsible among others for performing operations like backup, restore, and mount. Multiple nodes can be connected and managed by the same Storware Backup and Recovery server. Depending on the type of protected systems and data, multiple nodes can be deployed for example for scalability.

The node consists of the following subcomponents:

#### Cloud agent

Data mover that performs backups and restores operations for M365.

#### Cloud server

This component is responsible for managing the metadata for M365 backup and restoring operations. The cloud server is using SQLite databases to track the metadata of M365 objects. The metadata databases are stored together with the data on the backup destination.

### Endpoints server

The Endpoint server provides the feature that allows for protecting data in the Continuous Data Protection (CDP) mode for the Windows operating system. The component is managed by the Storware Backup and Recovery system.

#### Endpoints client

The client is a component installed on the Windows operating system. It's responsible for monitoring the filesystem, detecting changes, and protecting data according to the assigned policy.

#### IBM Spectrum Protect server

The endpoint protection supports only IBM Spectrum Protect as a backup destination. This component is delivered as a part of the solution.

## Architecture

The following diagram illustrates the system data flow:

![](/files/RPLscstQG1dYvYwxByFU)

### Components deployment

Storware Backup & Recovery components (server, node, and endpoints server) can be installed on the same host.

* The server can be installed on a physical machine or as a virtual machine - externally deployed nodes require network connectivity to the server and backup destinations.
* Nodes may be deployed as physical or virtual systems unless the selected backup strategy requires the node to be installed as a virtual machine on a Hypervisor Cluster (especially with the "disk attachment" export mode).

For detailed deployment scenarios see the following sections:

[Virtual Environments](/70/protecting-virtual-machines)

[Microsoft 365](/70/protecting-microsoft-365)

[Applications](/70/protecting-applications)

[Storage Providers](/70/protecting-storage-providers)

[Endpoints](/70/protecting-endpoints)

### Typical workflows

There are several typical workflows in Storware Backup & Recovery and they result in a set of tasks.

![](/files/gmP3Ml7Ddwjiyb5I3zzo)

#### **Backup**

* **Export** - a task that creates a backup or snapshot and exports data to the staging space
* **Store** - a task that moves data to the backup destination

#### **Restore to filesystem**

* **Restore** - a task that gets data from a backup provider and puts data in the staging space

#### **Restore to a virtualization platform**

* **Restore** - a task that gets data from a backup provider and puts data in the staging space (if it is a full backup that is being restored residing on the file system backup provider - this task just informs where files are waiting for import task)
* **Import** - a task that imports data to the virtualization platform and recreates VM

#### **Mount (file-level restore)**

* **Restore** - a task that gets data from a backup provider and puts data in the staging space (if it is a full backup that is being restored residing on the file system backup provider - this task just informs where files are waiting for the mounting task)
* **Mount** - mounts backup on the Storware Backup & Recovery Node and either allows user to browse files or exposes backup over iSCSI, so that remote iSCSI initiator can access it)

**Snapshot**

A task creates a local persisted snapshot of a virtual machine in the hypervisor environment according to a policy that was assigned to the machine. Snapshot retention is managed by the policy settings.


# Typical Scenarios

## Backup & Recovery

*The core functionality of Storware Backup & Recovery is an **agentless backup** for multiple virtualization, container, cloud platforms, applications, and endpoints.*

With snapshot-based backups, you don't have to install an agent inside VMs or customize your hypervisors.

Backups performed by Storware Backup & Recovery usually are crash-consistent, but you can enable **application consistency** or enhance the backup process with your own **custom pre/post snapshot remote command execution**.

Snapshots are exported from your virtualization platform and can be stored in the backup provider of your choice. You can use enterprise-grade backup providers, object storage, or just a file system as your target.

This means that Storware Backup & Recovery can act as a **stand-alone solution** or as a **proxy to your existing storage or enterprise backup provider.**

You also can periodically restore your VMs to verify if your backups are consistent.

With mounted backups, you can also **restore individual files** from your backups via a Web UI or directly from Storware Backup & Recovery Node.

## Disaster Recovery

Real disasters can sometimes happen - with Backup & Recovery you can configure your backups to be performed in one datacenter and - if necessary - restore them in a second datacenter.

Backup & Recovery can use replicated file systems or other built-in backup provider mechanisms to allow you to keep a copy in the secondary data center.

During DR, you can use Recovery Plans to restore multiple VMs to a predefined location.

## Snapshot Management

Backups are usually quite an intensive operation. Snapshots have to be exported and stored, which usually means that you can't perform them too often. With Backup & Recovery, you can use Snapshot Management policies to periodically create additional snapshots on your VMs without the need to export them.

When you need to restore a VM to the most recent saved state, you can quickly revert to a snapshot that Storware Backup & Recovery has created for you.

## Application Backup & Recovery

There are many cases where VM-level backup may not be enough. Applications such as databases usually have their own mechanisms that guarantee consistent backups. As we are aware, in many situations you need to have the option to customize the backup process - therefore Backup & Recovery provides a **generic mechanism** for multiple scenarios.

You can prepare a custom script or invoke any backup command that produces backup artifacts (or just initiates the external backup process) on a remote host and stores backups to your backup provider.

With Application backup, you can extend your protection capabilities to:

* any remote applications with their own mechanisms
* hypervisor configuration
* files on remote hosts (physical, virtual, or containers)
  * this includes shares, mounted object-storage buckets, LVM block devices, or virtually anything which can be presented as a file
* initiating external backup processes such as RMAN


# Licensing

To use Storware Backup and Recovery, you must obtain a license key and install it on the server. Without the license, the product will be working in the trial mode and some features may be not available.&#x20;

### Capacity-based license (per frontend terabytes)

In this license type, only the size of protected data being backed is taken into account. Frontend terabytes license covers all types of supported workloads: Virtual Environments, Storage, M365 and endpoint devices.

### Capacity-based license for storage (per frontend terabytes)

To address the evolving needs of modern data management, we are introducing a cost-effective licensing model tailored for remote storage, including NAS, Ceph, Ceph RBD, and more. This change is designed to optimize costs while ensuring efficient data management.

### Virtual Environments license (per host)

This license type covers the number of physical hosts under virtualization technology. With per-host licensing, you can have an unlimited number of virtual machines of terabytes. One license covers two server sockets.&#x20;

### Virtual Environments license (per vm)

This license type covers the exact number of virtual machines you want to protect. You can have any number of hosts or terabytes. This option is a good fit for MSPs to align with managed VM services pricing.

### M365 license (per active user)

This license type covers the number of protected user accounts in the Microsoft 365 service. This license allows you to protect all types of M365 data supported by the product. Shared mailboxes, SharePoint Online, and Teams do not utilize the license.

### OS Agent license&#x20;

OS Agent allows to protect data from various filesystem types from Windows and Linux. The license was divided into two types:

#### Endpoint

Allow to protected data from user endpoint devices.

#### Servers

Allow to protect data from server devices.

### Integration Module Access

License for a module that allows using a supported backup system as a backup destination for Storware Backup and Recovery.


# Product Life Cycle

The Storware Backup and Recovery product Support Life Cycle phases are described here:

| Description                           | Full Support | Maintenance Support |
| ------------------------------------- | :----------: | :-----------------: |
| Access to previously released content |      Yes     |         Yes         |
| Technical Support                     |      Yes     |         Yes         |
| Problems and Bugs Fixes               |      Yes     |          No         |
| Security Issues Fixes                 |      Yes     |  Yes (if possible)  |

1. Technical Support depends on the service level included in your Storware Backup and Recovery license agreement.
2. Storware may choose, as an intermediate measure, to address serious issues that have an impact to customer business with a hotfix, while a Storware Bug Fix Advisory is created and verified.

## Life Cycle Dates

The Storware Backup and Recovery Product Support Life Cycle dates are described here:

|                                  | General Availability | Full support ends | End of support |
| -------------------------------- | -------------------- | ----------------- | -------------- |
| Storware Backup and Recovery 7.0 | 25.09.2024           | 25.09.2025        | 25.09.2026     |
| Storware Backup and Recovery 6.2 | 14.03.2024           | 14.03.2025        | 14.03.2026     |
| Storware Backup and Recovery 6.1 | 25.10.2023           | 25.10.2024        | 25.10.2025     |
| Storware Backup and Recovery 6.0 | 04.07.2023           | 04.07.2024        | 04.07.2025     |
| Storware Backup and Recovery 5.2 | 12.12.2022           | 12.12.2023        | 12.12.2024     |
| Storware Backup and Recovery 5.1 | 08.07.2022           | 08.07.2023        | 08.07.2024     |
| Storware Backup and Recovery 5.0 | 31.01.2022           | 30.01.2023        | 30.01.2024     |
| vProtect 4.3                     | 28.07.2021           | 27.07.2022        | 27.07.2023     |
| Kodo for Cloud 4.3               | 31.08.2021           | 30.08.2022        | 30.08.2023     |
| Kodo for Cloud 4.2               | 16.02.2021           | 15.01.2022        | 15.01.2023     |
| Kodo for Endpoint 4.1            | 24.06.2021           | 23.06.2022        | 23.06.2023     |
| Kodo for Endpoint 4.0            | 15.04.2020           | 14.04.2021        | 14.04.2022     |

## Storware Backup and Recovery Life Cycle

### Full Support Phase:

During the Full Support phase, qualified Critical and Important Security issues will be addressed with released High Priority Bug Fix as they become available. Other Fix Advisories, may be delivered as appropriate.

For any minor release made available during this phase, the available and qualified Fix Advisories will be cumulatively included with the contents of previously released product updates. This means that if a customer is running an older version of the product and reports a bug, that bug will be fixed in the latest version of the software and a customer may need to upgrade to take advantage of that fix.

### Maintenance Support Phase:

During the Maintenance Support phase, which starts with the second year after release, the defined Critical and Important Security Fix Advisories may be released as they become available. No other fixes to the software are available.

Upgrades and updates are still to be delivered within this period.

### Upgrade Policy for Major Releases:

Storware will provide a supported upgrade path between major releases for Storware Backup and Recovery. Upgrades will be supported between the latest minor release of previous version to the most current version of the next higher major release. In these cases, the upgrade process will be limited to support upgrading from the latest minor release of the previous version to the new major version.

For example:

* Upgrading from vProtect 4.0 to Storware Backup and Recovery 5.0 is supported, assuming vProtect 4.3 being the most current release of the 4.x series and intermediary update to 4.3 is required in such case.

Upgrade from Beta / Pre-release releases to a fully supported release is not supported.

### Upgrade Policy for Minor Releases:

Customers are expected to update new minor releases as and when they become available. Accelerated fixes will not be provided for issues that have been previously fixed in a subsequent release; customers are expected and encouraged to keep their systems current and upgraded to the latest version of product to keep up to date on all patches and fixes.

In circumstances where the reported issue is not fixed in the current shipping release, the customer is still expected to upgrade their systems to the latest release (n) or in some exceptional cases, the immediate previous release (n-1). This is to ensure that any fixes are developed and verified against the latest or the immediate previous release.

### Security Updates:

Throughout the support lifecycle, qualified security issues of Critical or Important impact, as well as select mission-critical bugs, will be addressed by updated packages.

### Delivery of Storware Backup and Recovery Advisories:

For the high-priority bugs and vulnerabilities Storware announces Fix Advisories with the recommendation to update to the specified version. Fixes are always included with the next version of packages (as the regular RPM updates).

Fix Advisories may contain security or bug fixes. All Fix Advisories are tested and qualified against the respective, active Storware Backup and Recovery major release.

All released Fix Advisories remain accessible to active subscribers for the entire Storware Backup and Recovery life cycle.

Storware actively develops only the last major version’s minor release (for example a bug found in vProtect 4.3 or vProtect 4.2 after the release of Storware Backup and Recovery 5.0 could only be fixed in the newest build of vProtect 4.3 release).

Fix Advisories or hotfixes for earlier releases are provided at the discretion of Storware to address critical impact security issues with a significant customer business impact.

During the life cycle of a major release Storware makes commercially reasonable efforts to maintain binary compatibility for the core runtime environment across all minor releases and Fix Advisories. If necessary, Storware may make exceptions to this compatibility goal for critical impact security issues or other significant issues.

## Storware Backup and Recovery compatibility

Each minor version of product delivers a new Compatibility Level based on the minor version number. Each release supports at least the current and previous minor release Compatibility Level.

| Release                  | Release Date | Supported Compatibility Levels                                                                                                    |
| ------------------------ | :----------: | --------------------------------------------------------------------------------------------------------------------------------- |
| 7.0                      |  25.09.2024  | <p>Storware Backup and Recovery 5.x;<br>Storware Backup and Recovery 6.x;</p>                                                     |
| 6.2                      |  14.03.2024  | <p>vProtect: 3.9.x, 4.x;<br>Storware Backup and Recovery 5.x;<br>Storware Backup and Recovery 6.x;<br>Kodo for Endpoints: 4.1</p> |
| 6.1                      |  25.10.2023  | <p>vProtect: 3.9.x, 4.x;<br>Storware Backup and Recovery 5.x;<br>Storware Backup and Recovery 6.x;<br>Kodo for Endpoints: 4.1</p> |
| 6.0                      |  04.07.2023  | <p>vProtect: 3.9.x, 4.x;<br>Storware Backup and Recovery 5.x;<br>Kodo for Endpoints: 4.1</p>                                      |
| 5.2                      |  12.12.2022  | <p>vProtect: 3.9.x, 4.x;<br>Storware Backup and Recovery 5.x;<br>Kodo for Endpoints: 4.1</p>                                      |
| 5.1                      |  08.07.2022  | <p>vProtect: 3.9.x, 4.x;<br>Storware Backup and Recovery 5.0;<br>Kodo for Endpoints: 4.1</p>                                      |
| 5.0                      |  31.01.2022  | <p>vProtect: 3.9.x, 4.1, 4.2, 4.3;</p><p>Kodo for Cloud: migration required;</p><p>Kodo for Endpoints: 4.1</p>                    |
| 4.1 (vProtect)           |  28.01.2021  | vProtect: 3.9, 3.9.1, 3.9.2                                                                                                       |
| 4.3 (Kodo for Cloud)     |  31.08.2021  | 4.2, 4.1                                                                                                                          |
| 4.1 (Kodo for Endpoints) |  24.06.2021  | 4.0                                                                                                                               |


# Deployment

1. Start with **overview**:
   * [Architecture](/70/overview/architecture)
   * [Support Matrix](/70/overview/support-matrix)
   * [Platform Requirements](/70/deployment/platform-requirements)
2. Check **where node should be installed** for your environment:
   * [Virtual Environments](/70/protecting-virtual-machines)
   * [Microsoft 365](/70/protecting-microsoft-365)
   * [Applications](/70/protecting-applications)
   * [Storage Providers](/70/protecting-storage-providers)
   * [Endpoints](/70/protecting-endpoints)
3. **Install** using one of the following options:

   * [ISO-based installation](/70/deployment/installation/iso-based-installation) (recommended)
   * [All-in-one quick installation](/70/deployment/installation/quick-install-all-in-one) (recommended)
   * [Installation using Ansible playbook](/70/deployment/installation/installation-using-ansible-playbook)
   * [Installation with RPMs](/70/deployment/installation/installation-with-rpms)
   * [Virtual Appliance](/70/deployment/installation/virtual-appliance) (recommended)

   Regardless of the installation option you choose:

   * The node requires **staging space** - assume a number of concurrent export and store tasks and multiply it by the biggest VM size (**for example:** 6 export tasks + 4 store tasks \* 100 GB should require around 1 TB)
   * The [Staging space configuration](/70/deployment/common-tasks/staging-space-configuration) will guide you to prepare storage on the spare drive
   * Storware Backup & Recovery is installed in the `/opt/vprotect` folder and staging space is assumed to be in `/vprotect_data` - these are the defaults and should not be changed.
4. **Optionally**, if you want to enable **endpoints protection** follow [Installation overview](/70/deployment/endpoints-how-to-install/installation-overview)
5. Run the **configuration wizard** ([Initial configuration](/70/deployment/initial-configuration)), where you can (or do manually the following steps):
   * upload the [license](/70/administration/settings/settings#license)
   * configure connection to the source you would like to protect
   * configure backup destination - we recommend to use [Synthetic File System](/70/deployment/backup-destinations/filesystem/synthetic-file-system)
   * configure backup SLA (policies and schedules)
   * configure backup of your internal DB (for DR purposes)
6. Once you have configured source, backup destination and backup SLA - **initiate backup and restore** operations:

* [Virtual Environments](/70/protecting-virtual-machines/backup-and-restore)
* [Microsoft 365](/70/protecting-microsoft-365/backup-and-restore)
* [Applications](/70/protecting-applications/backup-and-restore)
* [Storage Providers](/70/protecting-storage-providers/backup-and-restore)
* [Endpoints](/70/protecting-endpoints/backup-and-restore)


# Component requirements

## System requirements

### Operating System

* CentOS Linux Stream 8
* CentOS Linux Stream 9
* Red Hat Enterprise Linux 8.x
* Red Hat Enterprise Linux 9.x
* Oracle Linux 8.x
* Oracle Linux 9.x
* AlmaLinux 8.x
* AlmaLinux 9.x
* Rocky Linux 8.x
* Rocky Linux 9.x
* SUSE Linux Enterprise Server (SLES) 15
* Ubuntu 22
* Debian 12.5

{% hint style="info" %}

* Using Red Hat Enterprise Linux requires an active subscription.
* Minimal installation is required.
  {% endhint %}

### MariaDB

Storware Backup & Recovery server requires a MariaDB database server.

* Minimum supported MariaDB version: 10.6
* Latest supported MariaDB version: 10.11

We recommend installing MariaDB from the official [repository](https://mariadb.com/kb/en/mariadb-package-repository-setup-and-usage/).

{% hint style="info" %}
If you need to install MariaDB packages without accessing an external repository during Storware Backup & Recovery installation you also can download RPMs and install them manually as described [here](https://mariadb.com/kb/en/installing-mariadb-with-the-rpm-tool/)
{% endhint %}

## Hardware Requirements

#### Minimum requirements for all-in-one installation (Storware Backup & Recovery server and node on the same host):

* 64-bit 8 cores processor
* 10 GB RAM
* 20GB free disk space for the operating system and Storware Backup and Recovery installation
* Free disk space for data staging
  * You can estimate the free space requirement using the following equation:\
    `(Size of the biggest virtual machine) * (number of parallel backup threads)`

#### Minimum requirements for Storware Backup & Recovery server (standalone installation):

* 64-bit 4 cores processor
* 4 GB RAM
* 20GB free disk space for the operating system and Storware Backup and Recovery installation

#### Minimum requirements for Storware Backup & Recovery node (standalone installation):

* 64-bit 4 cores processor
* 6 GB RAM
* 20GB free disk space for the operating system and Storware Backup and Recovery installation
* Free disk space for data staging
  * You can estimate the free space requirement using the following equation:\
    `(Size of the biggest virtual machine) * (number of parallel backup threads)`

## General network requirements

For detailed information about network requirements between Storware Backup and Recovery solution and supported platforms see [Platform Requirements](/70/deployment/platform-requirements)

### Communication between node and server

| Source | Destination | Ports                                                                                                                                                                                           | Description                                                                                                                                                    |
| ------ | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Node   | Server      | 443/tcp or 8181/tcp                                                                                                                                                                             | Node <-> Server communication over HTTPS (port 443 or 8181)                                                                                                    |
| Server | Node        | 111/tcp, 111/UDP, 2049/tcp, 2049/UDP, ports specified in `/etc/sysconfig/nfs` - variables `MOUNTD_PORT` (TCP and UDP), `STATD_PORT` (TCP and UDP), `LOCKD_TCPPORT` (TCP), `LOCKD_UDPPORT` (UDP) | NFS access to browse mountable backups and logs from administrative portal (using IP that is detected as the source IP - shown in the Node list in the portal) |

### Network consideration

* Depending on where the node is located you need to verify if data will not pass via low-bandwidth links.
* Access to the internet network from the node may be required in the following scenarios:
  * Installation, when using the external repositories
  * Backup and restore of Amazon EC2, Google Cloud Platform, Azure Cloud and M365
* Storware Backup & Recovery Node requires connectivity with backup destinations
* Storware Backup & Recovery Node needs connectivity with the Hypervisor or Hypervisor Manager.
* If a netcat transfer is used for Red Hat Virtuallization/oVirt/Oracle Linux VM/Proxmox VE/KVM stand-alone environments - **16000-16999** ports must be reachable from the hypervisors to the node which is responsible for those hypervisors.


# Supported platforms requirements

## VMware vCenter/ESXi

### HotAdd

**Connection URL:** `https://VCENTER_HOST` or `https://ESXI_HOST`

| Source | Destination       | Ports   | Description  |
| ------ | ----------------- | ------- | ------------ |
| Node   | vCenter/ESXi host | 443/tcp | API access   |
| Node   | ESXi hosts        | 902/tcp | NBD transfer |

### NBD

**Connection URL:** `https://VCENTER_HOST` or `https://ESXI_HOST`

| Source | Destination       | Ports   | Description  |
| ------ | ----------------- | ------- | ------------ |
| Node   | vCenter/ESXi host | 443/tcp | API access   |
| Node   | ESXi hosts        | 902/tcp | NBD transfer |

## Nutanix AHV

### Disk attachment

**Connection URL:** `https://PRISM_HOST:9440/api/nutanix/v3` (Prism Central or Prism Elements)

{% hint style="info" %}
**Note:** when connecting via Prism Central, the same credentials will be used to access all Prism Elements
{% endhint %}

| Source | Destination                                           | Ports    | Description                       |
| ------ | ----------------------------------------------------- | -------- | --------------------------------- |
| Node   | Prism Elements (and optionally Prism Central if used) | 9440/tcp | API access to the Nutanix manager |

## OpenStack

### Disk attachment

**Connection URL:** `https://KEYSTONE_HOST:5000/v3`

| Source | Destination                    | Ports                                                       | Description                                                                                                                 |
| ------ | ------------------------------ | ----------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| Node   | Keystone, Nova, Glance, Cinder | ports that were defined in endpoints for OpenStack services | API access to the OpenStack management services - using endpoint type that has been specified in hypervisor manager details |
| Node   | Ceph monitors                  | 3300/tcp, 6789/tcp                                          | if Ceph RBD is used as the backend storage - used to collect changed-blocks lists from Ceph                                 |

### SSH transfer

**Connection URL:** `https://KEYSTONE_HOST:5000/v3`

{% hint style="info" %}
**Note:** you also must provide SSH credentials to all hypervisors that have been detected during inventory sync
{% endhint %}

| Source     | Destination   | Ports                                                                        | Description                                                                  |
| ---------- | ------------- | ---------------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
| Node       | Hypervisor    | 22/tcp                                                                       | SSH access                                                                   |
| Hypervisor | Node          | netcat port range defined in node configuration - by default 16000-16999/tcp | optional netcat access for data transfer                                     |
| Node       | Ceph monitors | 3300/tcp, 6789/tcp, 10809/tcp                                                | if Ceph RBD is used as the backend storage - used for data transfer over NBD |

## Virtuozzo

### SSH transfer

**Connection URL:** `https://KEYSTONE_HOST:5000/v3`

{% hint style="info" %}
**Note:** you also must provide SSH credentials to all hypervisors that have been detected during inventory sync
{% endhint %}

| Source     | Destination   | Ports                                                                        | Description                                                                  |
| ---------- | ------------- | ---------------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
| Node       | Hypervisor    | 22/tcp                                                                       | SSH access                                                                   |
| Hypervisor | Node          | netcat port range defined in node configuration - by default 16000-16999/tcp | optional netcat access for data transfer                                     |
| Node       | Ceph monitors | 3300/tcp, 6789/tcp, 10809/tcp                                                | if Ceph RBD is used as the backend storage - used for data transfer over NBD |

## OpenNebula

### Disk attachment

**Connection URL:** `https://MANAGER_HOST`

| Source | Destination  | Ports                                  | Description                                      |
| ------ | ------------ | -------------------------------------- | ------------------------------------------------ |
| Node   | Manager Host | XML-RPC API port - 2633/tcp by default | API access to the OpenNebula management services |

## oVirt/RHV/OLVM

### Disk attachment

**Connection URL:** `https://MANAGER_HOST/ovirt-engine/api`

| Source | Destination            | Ports   | Description               |
| ------ | ---------------------- | ------- | ------------------------- |
| Node   | oVirt/RHV/OLVM manager | 443/tcp | oVirt/RHV/OLVM API access |

### Disk Image Transfer

**Connection URL:** `https://MANAGER_HOST/ovirt-engine/api`

| Source | Destination               | Ports     | Description                                                                     |
| ------ | ------------------------- | --------- | ------------------------------------------------------------------------------- |
| Node   | oVirt/RHV/OLVM manager    | 443/tcp   | oVirt/RHV/OLVM API access                                                       |
| Node   | oVirt/RHV/OLVM hypervisor | 54322/tcp | oVirt/RHV/OLVM ImageIO services - for data transfer (primary source)            |
| Node   | oVirt/RHV/OLVM manager    | 54323/tcp | oVirt/RHV/OLVM ImageIO services - for data transfer (fallback to ImageIO Proxy) |

### SSH Transfer

**Connection URL:** `https://MANAGER_HOST/ovirt-engine/api`

{% hint style="info" %}
**Note:** you also must provide SSH credentials to all hypervisors that have been detected during inventory sync
{% endhint %}

| Source                    | Destination               | Ports                                                                        | Description                              |
| ------------------------- | ------------------------- | ---------------------------------------------------------------------------- | ---------------------------------------- |
| Node                      | oVirt/RHV/OLVM manager    | 443/tcp                                                                      | oVirt/RHV/OLVM API access                |
| Node                      | oVirt/RHV/OLVM hypervisor | 22/tcp                                                                       | SSH access for data transfer             |
| oVirt/RHV/OLVM hypervisor | Node                      | netcat port range defined in node configuration - by default 16000-16999/tcp | optional netcat access for data transfer |

### Change-Block Tracking

**Connection URL:** `https://MANAGER_HOST/ovirt-engine/api`

| Source | Destination               | Ports     | Description                                         |
| ------ | ------------------------- | --------- | --------------------------------------------------- |
| Node   | oVirt/RHV/OLVM manager    | 443/tcp   | oVirt/RHV/OLVM API access                           |
| Node   | oVirt/RHV/OLVM hypervisor | 54322/tcp | oVirt/RHV/OLVM ImageIO services - for data transfer |
| Node   | oVirt/RHV/OLVM manager    | 54323/tcp | oVirt/RHV/OLVM ImageIO services - for data transfer |

## Oracle VM

### Export storage domain

**Connection URL:** `https://MANAGER_HOST:7002`

| Source              | Destination        | Ports                                                                                                                                                                                                                                                                                                    | Description                                                                               |
| ------------------- | ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| Node                | OVM manager        | 7002/tcp                                                                                                                                                                                                                                                                                                 | OVM API access                                                                            |
| Hypervisor          | Node               | If Node is hosting staging space: 111/tcp, 111/UDP, 2049/tcp, 2049/UDP, ports specified in `/etc/sysconfig/nfs` - variables `MOUNTD_PORT` (TCP and UDP), `STATD_PORT` (TCP and UDP), `LOCKD_TCPPORT` (TCP), `LOCKD_UDPPORT` (UDP), otherwise please check the documentation of your NFS storage provider | if staging space (export storage repository) is hosted on the Node - NFS access           |
| Node and hypervisor | shared NFS storage | check the documentation of your NFS storage provider                                                                                                                                                                                                                                                     | if staging space (export storage repository) is hosted on the shared storage - NFS access |

## Citrix XenServer/xcp-ng

{% hint style="info" %}
**Note:** all hosts in the pool must be defined
{% endhint %}

### Single image (XVA-based)

| Source | Destination | Ports   | Description                                                                                                               |
| ------ | ----------- | ------- | ------------------------------------------------------------------------------------------------------------------------- |
| Node   | Hypervisor  | 443/tcp | API access (for data transfer management IP is used, unless `transfer NIC` parameter is configured in hypervisor details) |

### Changed-Block Tracking

| Source | Destination | Ports     | Description                                                                                                               |
| ------ | ----------- | --------- | ------------------------------------------------------------------------------------------------------------------------- |
| Node   | Hypervisor  | 443/tcp   | API access (for data transfer management IP is used, unless `transfer NIC` parameter is configured in hypervisor details) |
| Node   | Hypervisor  | 10809/tcp | NBD access (data transfer IP is returned by hypervisor)                                                                   |

## KVM/Xen stand-alone

### SSH transfer

| Source     | Destination   | Ports                                                                        | Description                                                                  |
| ---------- | ------------- | ---------------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
| Node       | Hypervisor    | 22/tcp                                                                       | SSH access                                                                   |
| Hypervisor | Node          | netcat port range defined in node configuration - by default 16000-16999/tcp | optional netcat access for data transfer                                     |
| Node       | Ceph monitors | 3300/tcp, 6789/tcp, 10809/tcp                                                | if Ceph RBD is used as the backend storage - used for data transfer over NBD |

## Proxmox VE

### Export storage repository

| Source              | Destination        | Ports                                                                                                                                                                                                                                                                                                    | Description                                                                           |
| ------------------- | ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
| Node                | Hypervisor         | 22/tcp                                                                                                                                                                                                                                                                                                   | SSH access                                                                            |
| Hypervisor          | Node               | If Node is hosting staging space: 111/tcp, 111/UDP, 2049/tcp, 2049/UDP, ports specified in `/etc/sysconfig/nfs` - variables `MOUNTD_PORT` (TCP and UDP), `STATD_PORT` (TCP and UDP), `LOCKD_TCPPORT` (TCP), `LOCKD_UDPPORT` (UDP), otherwise please check the documentation of your NFS storage provider | if staging space (export storage domain) is hosted on the Node - NFS access           |
| Node and hypervisor | shared NFS storage | check the documentation of your NFS storage provider                                                                                                                                                                                                                                                     | if staging space (export storage domain) is hosted on the shared storage - NFS access |

## Kubernetes

**Connection URL:** `https://API_HOST:6443`

| Source | Destination         | Ports    | Description |
| ------ | ------------------- | -------- | ----------- |
| Node   | Kubernetes API host | 22/tcp   | SSH access  |
| Node   | Kubernetes API host | 6443/tcp | API access  |

## Openshift

**Connection URL:** `https://API_HOST:6443`

| Source            | Destination         | Ports              | Description                                                    |
| ----------------- | ------------------- | ------------------ | -------------------------------------------------------------- |
| Node              | Kubernetes API host | 6443/tcp           | API access                                                     |
| Node              | Openshift Workers   | 2049/tcp, 2049/udp | NFS connection                                                 |
| Openshift Workers | Node                | 2049/tcp, 2049/udp | NFS connection                                                 |
| Node              | Openshift Workers   | 30000-32767/tcp    | access to service exposed by Storware Backup & Recovery plugin |

## Hyper-V

| Source | Destination                      | Ports                                                         | Description                                                                                                                 |
| ------ | -------------------------------- | ------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| Node   | Storware Backup & Recovery Agent | 50881/tcp for http connection, 50882/tcp for https connection | Storware Backup & Recovery Agent access and data transfer, firewall rules are added automatically during agent installation |

## Azure Stack HCI

| Source | Destination                      | Ports                                                         | Description                                                                                                                 |
| ------ | -------------------------------- | ------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| Node   | Storware Backup & Recovery Agent | 50881/tcp for http connection, 50882/tcp for https connection | Storware Backup & Recovery Agent access and data transfer, firewall rules are added automatically during agent installation |

## SC//Platform

### Export Storage Domain

**Connection URL:** `https://MANAGER_HOST`

| Source             | Destination          | Ports   | Description  |
| ------------------ | -------------------- | ------- | ------------ |
| Node               | SC//Platform manager | 443/tcp | API access   |
| Node               | SC//Platform hosts   | 445/tcp | SMB transfer |
| SC//Platform hosts | Node                 | 445/tcp | SMB transfer |

### Disk Attachment

**Connection URL:** `https://MANAGER_HOST`

| Source | Destination          | Ports   | Description |
| ------ | -------------------- | ------- | ----------- |
| Node   | SC//Platform manager | 443/tcp | API access  |

## Huawei FusionCompute

**Connection URL:** `https://MANAGER_HOST:8443`

| Source             | Destination              | Ports    | Description  |
| ------------------ | ------------------------ | -------- | ------------ |
| Node               | Huawei FusionCompute VRM | 8443/tcp | API access   |
| Node               | SC//Platform hosts       | 445/tcp  | SMB transfer |
| SC//Platform hosts | Node                     | 445/tcp  | SMB transfer |

## Microsoft 365

| Source | Destination   | Ports   | Description              |
| ------ | ------------- | ------- | ------------------------ |
| Node   | Microsoft 365 | 443/tcp | Microsoft 365 API access |

You can find more detailed descriptions of Office 365 URLs and IP address ranges on [this page](https://learn.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide).

To successfully synchronize M365 user account, it must fulfill following requirements:

* has an email,
* is not filtered by location, country or office location (user filter in UI),
* field `user type` is set to `Member`,
* has a license or is a shared mailbox.

## OS Agent

| Source   | Destination | Ports     | Description                   |
| -------- | ----------- | --------- | ----------------------------- |
| OS Agent | Node        | 15900/tcp | Node - OS Agent communication |

## Security Requirements

## User Permissions

User `vprotect` must be a member of group "disk".

Sudo privileges are required for the following commands:

**Storware Backup & Recovery Node:**

* `/usr/bin/targetcli`
* `/usr/sbin/exportfs`
* `/usr/sbin/kpartx`
* `/usr/sbin/dmsetup`
* `/usr/bin/qemu-nbd`
* `/usr/bin/guestmount`
* `/usr/bin/fusermount`
* `/bin/mount`
* `/bin/umount`
* `/usr/sbin/parted`
* `/usr/sbin/nbd-client`
* `/usr/bin/tee`
* `/opt/vprotect/scripts/vs/privileged.sh`
* `/usr/bin/yum`
* `/usr/sbin/mkfs.xfs`
* `/usr/sbin/fstrim`
* `/usr/sbin/xfs_growfs`
* `/usr/bin/docker`
* `/usr/bin/rbd`
* `/usr/bin/chown`
* `/usr/sbin/nvme`
* `/bin/cp`
* `/sbin/depmod`
* `/usr/sbin/modprobe`
* `/bin/bash`
* `/usr/local/sbin/nbd-client`
* `/bin/make`

**Storware Backup & Recovery server:**

* `/opt/vprotect/scripts/application/vp_license.sh`
* `/bin/umount`
* `/bin/mount`

## SELinux

PERMISSIVE - currently it interferes with the mountable backups (file-level restore) mechanism. Optionally can be changed to ENFORCING if the file-level restore is not required.

## Endpoints client support

KODO for Endpoints client can be installed on the following operating systems:

* Microsoft Windows 7 32-bit
* Microsoft Windows 7 64-bit## VMware vCenter/ESXi

### HotAdd

**Connection URL:** `https://VCENTER_HOST` or `https://ESXI_HOST`

| Source | Destination       | Ports   | Description  |
| ------ | ----------------- | ------- | ------------ |
| Node   | vCenter/ESXi host | 443/tcp | API access   |
| Node   | ESXi hosts        | 902/tcp | NBD transfer |

### NBD

**Connection URL:** `https://VCENTER_HOST` or `https://ESXI_HOST`

| Source | Destination       | Ports   | Description  |
| ------ | ----------------- | ------- | ------------ |
| Node   | vCenter/ESXi host | 443/tcp | API access   |
| Node   | ESXi hosts        | 902/tcp | NBD transfer |

* Microsoft Windows 8 32-bit
* Microsoft Windows 8 64-bit
* Microsoft Windows 8.1 64-bit
* Microsoft Windows 8.1 64-bit
* Microsoft Windows 10 32-bit
* Microsoft Windows 10 64-bit

## Windows 7 (32-bit, 64-bit)

The following packages need to be installed on the operating system:

* Microsoft Vistual C++ 2012 Redistributable (x64) package-11.0.61030 (<https://my.visualstudio.com/Downloads?pid=1452>)
* Microsoft Vistual C++ 2012 Redistributable (x86) package-11.0.61030 (<https://my.visualstudio.com/Downloads?pid=1452>)
* Microsoft Vistual C++ 2015-2019 Redistributable (x64) package-14.20.27508 (<https://aka.ms/vs/16/release/vc_redist.x86.exe>)
* Microsoft Vistual C++ 2015-2019 Redistributable (x86) package-14.20.27508 (<https://aka.ms/vs/16/release/vc_redist.x64.exe>)
* .NET Framework 4.7.2

## Windows 8 (32-bit, 64-bit)

The following packages need to be installed on the operating system:

* Microsoft Vistual C++ 2012 Redistributable (x64) package-11.0.61030 ([https://my.visualstudio.com/Downloads?pid=1452](https://www.microsoft.com/en-us/download/details.aspx?id=30679))
* Microsoft Vistual C++ 2012 Redistributable (x86) package-11.0.61030 (<https://my.visualstudio.com/Downloads?pid=1452>)
* Microsoft Vistual C++ 2015-2019 Redistributable (x64) package-14.20.27508 (<https://aka.ms/vs/16/release/vc_redist.x86.exe>)
* Microsoft Vistual C++ 2015-2019 Redistributable (x86) package-14.20.27508 (<https://aka.ms/vs/16/release/vc_redist.x64.exe>)
* .NET Framework 4.8

## Windows 8.1 (32-bit, 64-bit)

The following packages need to be installed on the operating system:

* Microsoft Vistual C++ 2012 Redistributable (x64) package-11.0.61030 (<https://my.visualstudio.com/Downloads?pid=1452>)
* Microsoft Vistual C++ 2012 Redistributable (x86) package-11.0.61030 (<https://my.visualstudio.com/Downloads?pid=1452>)
* Microsoft Vistual C++ 2015-2019 Redistributable (x64) package-14.20.27508 (<https://aka.ms/vs/16/release/vc_redist.x86.exe>)
* Microsoft Vistual C++ 2015-2019 Redistributable (x86) package-14.20.27508 (<https://aka.ms/vs/16/release/vc_redist.x64.exe>)
* .NET Framework 4.8

## Windows 10 (32-bit, 64-bit)

The following packages need to be installed on the operating system:

* Microsoft Vistual C++ 2010 x64 Redistributable package-10.0.40219 (<https://www.microsoft.com/en-us/download/details.aspx?id=26999>)
* Microsoft Vistual C++ 2012 Redistributable (x64) package-11.0.61030 (<https://my.visualstudio.com/Downloads?pid=1452>)
* Microsoft Vistual C++ 2012 Redistributable (x86) package-11.0.61030 (<https://my.visualstudio.com/Downloads?pid=1452>)
* Microsoft Vistual C++ 2015-2019 Redistributable (x64) package-14.20.27508 (<https://aka.ms/vs/16/release/vc_redist.x86.exe>)
* .NET Framework 4.8


# Sizing Guide

There are two types of people: those who are doing backups, and those who will be doing them. But just **doing** backups is not everything. To avoid unnecessary surprises the best strategy is to **plan** your backup environment/procedure **before implementing** it. In this chapter, we have collected generic hints and guides which you might find useful while thinking about your Storware Backup & Recovery implementation.

1. Collect information about the `TotalSizeOfData` to be protected in your environment
   * this is the size of your VMs/Storage that will be transferred within the backup window
     * for general sizing, assume all backups to be full
   * if your staging space is separate from the backup destination, also check what are the biggest VMs/Storage that may end up in your staging area
2. Assume `BackupWindow` length - backups are usually executed overnight, so 10h-12h is common practice
3. Run a **test transfer** on a test file to estimate the maximum achievable bandwidth per thread (`SingleThreadTransfer`) from the hypervisor (or manager) to the node
   * we recommend 10 simultaneous transfers with the result divided by 10 threads to see if other limitations of the environment do not impact the total transfer rate (one such common limitation is disk read performance on the virtualization platform)
   * all the methods usually use snapshots to do backup - check if snapshot removal in your environment does not take a significant amount of time, as it is a highly resource-intensive operation that impacts overall backup time - especially when running multiple export jobs in parallel
4. Estimate **the** **number of the nodes**
   * required bandwidth per node:

     `RequiredBandwidth = TotalSizeOfData / BackupWindow`
   * the total number of export tasks (note that other aspects such as snapshot handling, file system scanning during export, and infrastructure bottlenecks when using multiple threads will usually impact the overall speed):

     `TotalNumberOfExportTasks = RequiredBandwidth / (70% * SingleThreadTransferSpeed)`
   * the number of nodes:

     `NumberOfTheNodes = TotalNumberOfExportTasks / 10` **(10 is the recommended maximum number of export tasks per Node)**
   * note that the `TotalSizeOfData` does not mean that it is only a full backup, as you can mix full and incremental backups
   * granularity is a single hypervisor or storage provider, so at the maximum, you cannot have more nodes than hypervisor storage providers in your environment
   * if you have multiple clusters and you want to use the disk-attachment method, this automatically implies a minimum of 1 node per cluster
5. Estimate the total **store rate** in the backup destination
   * if multiple nodes are required, add up the total amount of data from all nodes
   * if your backup destination is accessible over LAN
     * do a test transfer from the node to the backup destination to verify if the performance on the backup destination is able to receive such a load
6. `NumberOfExportTasksPerNode`
   * we recommend using the same node configuration for multiple nodes, so the same limit value will be applied to all nodes sharing the configuration
   * this implies that we recommend assuming this value as follows (rounded down):

     `NumberOfExportTasksPerNode = TotalNumberOfExportTasks / NumberOfTheNodes`
7. `NumberOfStoreTasksPerNode` usually depends on destination backup performance
   * we recommend a value equal to the `NumberOfExportTasksPerNode` or higher
   * reduce this value only if your backup provider starts to have significant I/O latency eventually leading to a slower write rate than with the lower number of threads - this will typically result in higher staging space occupation as backups will be kept for a longer period of time in the temporary space
8. **Node resource requirements:**
   * **CPU**: Assume 0.5 CPU per task, minimum 2 cores - rounded up to get the full core count supported by the hypervisor or physical server (it may be required to round up 2.5 cores to 4 vCPUs if the hypervisor on which the node is deployed doesn't allow to 3 vCPUs to be assigned)
     * if SSH transfer (without netcat) or client-side deduplication is used (like VDO) assume 1 CPU per task
   * **Memory**: 256 MB RAM per task, with a minimum of 2GB
   * **Staging space:** if not shared with the backup destination - the biggest VM/Storage multiplied by the number of tasks
   * when counting tasks for each node assume: `NumberOfExportTasksPerNode + NumberOfStoreTasksPerNode`
9. **Server resource requirements:**
   * **CPU**: Assume 0.5 CPU per task, minimum 2 cores - rounded up to full core count supported by the hypervisor or physical server (it may be required to round up 2.5 cores to 4 vCPUs if the hypervisor on which the node is deployed doesn't allow 3 vCPUs to be assigned)
   * **Memory**: 256 MB RAM per task, with a minimum of 6GB
   * when counting tasks assume:

     `TotalNumberOfExportTasks + TotalNumberOfStoreTasks`
10. Finally, if the resulting node count is too big:
    * divide your VMs into multiple backup policies with separate schedules so that some full backups of your VMs will be done on Monday, some on Tuesday, while the rest will run incremental backups at the same time - this will reduce the value of `TotalSizeOfData` in the previous equations
    * check if the backup window cannot be extended
      * exports usually impact infrastructure more, while store tasks can also safely be done during the day
      * Storware Backup & Recovery will start backups only within the backup window, but once the tasks are started, they may continue even after your backup window ends

## Notes on sizing using different setups

### **Disk-attachment methods**

* read data from locally attached drives (which may use LAN or SAN behind the scenes depending on your virtualization platform setup) and write it to the staging space (local or remote)
* run a read test from one device to the staging storage to estimate the processing rate
* this method requires usually 1 node per cluster, so treat each cluster separately
* this method also requires time for attachment/detachment of drives

### **Export storage repository methods**

* export data from a specific host to the staging space of Storware Backup & Recovery via NFS
* run a test export on any VM to estimate the export speed in your environment
* export methods also usually have limitations on the hypervisor side, so OVM can process only 1 export job simultaneously using a specific set of storage repositories (on which the VM disks reside, and to which the VM is being exported), which may impact overall performance - please consult your hypervisor documentation to check for export process limitations
* it is common to share a backup destination with staging space from an external backup provider via NFS (not from each node) so that exports are done directly to the backup destination storage

### Direct export from hypervisors or underlying storage

* if you can enable the netcat in SSH Transfer methods, it should result in 2-3 times faster transfer rates compared to standard SSH
* export tasks run against stand-alone hypervisors will be automatically balanced, while those managed by hypervisor managers will be subject to global and per source limits
  * this means that if you configure a maximum number of export tasks per source to 5 and the global number to 10, you will have no more than 5 export tasks running against a single manager regardless of the number of hosts
* when using Ceph RBD in KVM stand-alone or the OpenStack SSH Transfer method, the actual transfer is done directly from Ceph monitors, and this is the network path that needs to be checked when estimating bandwidth - use `rbd export` or mount a test volume over RBD-NBD to test it

**Backup destination**

* if you plan to use common storage for the staging space and backup destination, your reads from the source will be limited by the write speed of your backup destination
* make sure you have the appropriate bandwidth between the nodes and the backup destination
* verify if the backup destination is able to process IOPS coming from multiple sources - it is common to assume the export rate as the minimum required store rate


# Small

* Network: minimum 1Gb/s
* Number of sites: 1
* Number of **Storware Backup & Recovery** installations: 1 server along with node
* Storware Backup & Recovery min. 4 vCPU and 6 GB RAM
* Number of backup threads: 3-4 (default)
* Backup window: 8 hours
* Data to backup: up to 2.5 TB
* staging space: your\_largest\_VM \* backup threads

As mentioned above, network speed is a very important factor. If you have a 1Gb/s connection between the server, node, and backup clients, then during the 8 hours of the backup window we can assume that if we load the network at 70% of its capacity, we should transfer 2.5TB of data

In this scenario, **Storware Backup & Recovery** (server and node) can, for example, be deployed as a VM using any of the installation methods.

![](/files/fX0TWMHVMibYnyuFHMQf)


# Medium

* Network: minimum 10Gb/s
* Number of sites: 1
* Number of **Storware Backup & Recovery** installations: 1 server and (min.) 1 node
* min. 4 vCPU and 8 GB RAM
* Number of backup threads: 6
* Backup window: 8 hours
* Data to back up: up to 25 TB
* staging space: your\_largest\_VM \* backup threads - per node
* Number of parallel backup threads: depending on the number of virtual machines (maximum 10 per node)

![](/files/XpMP8SY5Eu7J7n5oVxfK)


# Large

Environments of this size are the most difficult to describe because they introduce a large number of variables. Treat this more as a proof of concept which probably needs some tailoring to suit your specific needs.

* Network: minimum 10Gb/s
* Number of sites: 1+
* Number of **Storware Backup & Recovery** installations: 2 server and (min.) + 2 nodes
* min. 8 vCPU and 16 GB RAM
* Number of backup threads: 10 per node
* Backup window: 12 hours
* Data to back up: 25 TB+
* staging space: your\_largest\_VM \* backup threads - per node
* Number of parallel backup threads: depending on the number of virtual machines (maximum 10 per node)

![](/files/CWPv35CigQ4BAQKmL374)


# Storware Endpoints

The sizing guide describes requirements for a virtual or physical machine to install Storware Endpoints server with IBM Spectrum Protect server.

First, you need to gather information about the total amount of data to be protected in your environment. This can be a daunting task when it comes to endpoint protection, but you have to make some assumptions because the amount of data to protect is different on each workstation or laptop.

To calculate the required backup storage space, multiply the number of devices you own by the assumed average amount of data per device and divide by 2 (the assumed deduplication and compression ratio 2:1). This is our recommendation, but the deduplication ratio may vary depending on the data characteristic of the devices.

The other requirement is to calculate the disk space required to store information about protected files in the IBM Spectrum Protect server database.

We've made a sample calculation for the database storage. If a single client has 500k files to protect and each file has 3 versions, then the protected environment with 500 endpoints requires about 1.7 TB of additional storage for the database. Reserve appropriate database disk space on the server.

Based on our best practice, we have prepared four configurations that are typical of most use cases.

Browse the next sections and find the appropriate system configuration that fits your organization size.

{% hint style="info" %}
**Note:** The maximum number of endpoints protected by a single instance of the Storware Endpoints server is 25,000. If your organization has more endpoints to protect, please install another instance of the Storware Endpoints server.
{% endhint %}


# Small

As an example for a small organization (up to 200 endpoints) the following system configuration is recommended:

| OS platform requirement                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| <ul><li>at least 4 cores</li><li>at least 16 GB RAM</li><li>at least 50 GB free disk space for operating system binaries, MySQL database and Storware Endpoints server binaries </li><li>at least 104 GB dedicated disk for /isp/db folder</li><li>at least 35 GB dedicated disk for /isp/activelog folder</li><li>at least 67 GB dedicated disk for /isp/archlog folder</li><li>at least 207 GB dedicated disk for /isp/dbbackup folder</li><li>3 TB for IBM Spectrum Protect backup storage space (assuming 200 endpoints protected with 30 GB of data on each and a deduplication/compression ratio of 2:1)</li><li>Network: minimum 1Gb/s connection</li></ul> |

Now you can go over to the [Endpoints – how to install](/70/deployment/endpoints-how-to-install) chapter to choose Storware Endpoints server installation type or go to the [Medium organization](/70/deployment/sizing/storware-endpoints/medium) chapter.


# Medium

As an example for a medium organization (up to 1000 endpoints) the following system configuration is recommended:

| OS platform requirements                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| <ul><li>at least 6 cores</li><li>at least 24 GB RAM</li><li>at least 60 GB free disk space for operating system binaries, MySQL database and Storware Endpoints server binaries </li><li>at least 90 GB dedicated disk for /isp/db folder</li><li>at least 70 GB dedicated disk for /isp/activelog folder</li><li>at least 134 GB dedicated disk for /isp/archlog folder</li><li>at least 630 GB dedicated disk for /isp/dbbackup folder</li><li>Network: minimum 1Gb/s connection</li><li>15 TB for IBM Spectrum Protect backup storage space (assuming 1000 endpoints protected with 30 GB of data on each and deduplication/compression ratio of 2:1)</li><li>Network: minimum 1Gb/s connection</li></ul> |

Now you can go over to the [Endpoints – how to install](/70/deployment/endpoints-how-to-install) chapter to choose Storware Endpoints server installation type or go to the [Large organization](/70/deployment/sizing/storware-endpoints/large) chapter.


# Large

link do how to install

As an example for a large organization (up to 2000 endpoints) the following system configuration is recommended:

| OS platform requirements                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              |
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| <ul><li>at least 8 cores</li><li>at least 32 GB RAM</li><li>at least 80 GB free disk space for operating system binaries, MySQL database and Storware Endpoints server binaries </li><li>at least 120 GB dedicated disk for /isp/db folder</li><li>at least 79 GB dedicated disk for /isp/activelog folder</li><li>at least 134 GB dedicated disk for /isp/archlog folder</li><li>at least 840 GB dedicated disk for /isp/dbbackup folder</li><li>30 TB for IBM Spectrum Protect backup storage space (assuming 2000 endpoints protected with 30 GB of data on each and a deduplication/compression ratio of 2:1)</li><li>Network: minimum 1Gb/s connection</li></ul> |

Now you can go over to the [Endpoints – how to install](/70/deployment/endpoints-how-to-install) chapter to choose Storware Endpoints server installation type or go to the [Very large organization](/70/deployment/sizing/storware-endpoints/very-large) chapter.


# Very large

As an example for a very large organization (above 2000 endpoints) the following system configuration is recommended:

| OS platform requirements                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| <ul><li>at least 12 cores</li><li>at least 64 GB RAM</li><li>at least 90 GB free disk space for operating system binaries, MySQL database and Storware Endpoints server binaries</li><li>at least 2 GB dedicated disk for /isp/db folder</li><li>at least 50 GB dedicated disk for /isp/activelog folder</li><li>at least 50 GB dedicated disk for /isp/archlog folder</li><li>at least 50 GB dedicated disk for /isp/dbbackup folder</li><li> calculations for IBM Spectrum Protect backup storage space: <strong>number of endpoints</strong> \* <strong>average amount of endpoint data to protect and the outcome divide by 2 (2:1 deduplication/compression ratio)</strong> </li><li>Network: minimum 1Gb/s connection</li></ul> |

Go to the [Endpoints – how to install](/70/deployment/endpoints-how-to-install) chapter to choose your Storware Endpoints server installation type.


# Installation

{% hint style="info" %}
Before installing Storware Backup & Recovery solution we recommend performing an operating system update and reboot if neccesary
{% endhint %}

Before starting installation review the following chapters:

* [Component requirements](/70/deployment/component-requirements)
* [Supported platforms requirements](/70/deployment/platform-requirements)
* [Sizing guide](/70/deployment/sizing)

You can deploy Storware Backup and Recovery using one of the following methods

* [ISO-based installation](/70/deployment/installation/iso-based-installation) (recommended) The iso image can be used to boot a virtual machine from it in order to install CentOS 9 Stream with Storware Backup & Recovery application.
* [Quick installation using all-in-one script](/70/deployment/installation/quick-install-all-in-one) (recommended) To quickly deploy server and node on one host
* [Installation using Ansible playbook](/70/deployment/installation/installation-using-ansible-playbook) You can install the complete Storware Backup & Recovery solution using the roles, available on Ansible Galaxy
* [Installation with RPMs](/70/deployment/installation/installation-with-rpms) To deploy server and node from the scratch
* [Virtual Appliance](/70/deployment/installation/virtual-appliance) (recommended) The virtual appliance (VA) is a preconfigured virtual machine image. VA is available for the following hypervisors: RHV/oVirt/OLVM, Citrix/XCP-ng, VMware, Nutanix Acropolis


# ISO-based installation

This guide details the step-by-step process of installing Storware Backup & Recovery using an ISO image. We'll be using vCenter Hypervisor Manager as an example, but these instructions can be adapted to any Storware-supported Hypervisor Manager.

## Prerequisites:

* Storage Requirements: At least two virtual disks are required for deployment:
  * Disk 1: Minimum 30GB for the operating system and SBR installation.
  * Disk 2: Minimum 200GB for data staging (you will be able to allocate more disk space when required).
* Download the ISO: Visit the Storware repository and download the latest ISO file for deploying the SBR virtual machine.

## Preparation:

1. **Download the ISO:** Visit the Storware repository and download the latest ISO file for deploying the Storware Backup & Recovery virtual machine.

   [Click for current ISO](https://repo.storware.eu/storware/iso/storware-br-current.iso)
2. **Upload the ISO to your Datastore:** Within your virtualization platform's interface, locate the "Datastore" section and upload the downloaded ISO file.

   ![](/files/mo3rb3L6DuCTyUi94idN)

## Deployment:

1. **Create a New Virtual Machine:** Right-click on the desired folder or datacenter within your virtualization platform and select "New Virtual Machine.

   ![](/files/vHkqpPMAg8bzg24pfZG9)
2. **Configure Virtual Machine Settings:** Follow the prompts in the wizard to complete the virtual machine creation process. Here's a breakdown of the key steps:
   * Enter a descriptive name for your virtual machine.

     ![](/files/vzT1K5OiimGVQKIgyuk1)
   * Allocate storage for the virtual machine from your available datastores

     ![](/files/ItxS780m3bsthTewWy3d)
   * Choose the compatibility mode based on your virtualization platform's requirements.

     ![](/files/gb5ZHjGVWhQzbiui2rHA)
   * Select the guest operating system - ideally CentOS Linux 9. If unavailable, choose CentOS 8.

     ![](/files/EsOyt8Xeq0HYdKvGtOVo)
   * Select the appropriate compute resources (CPU, memory) for your needs.

     ![](/files/Cl6qBDPn7bc3VvkOuDdc)
   * Refer to the provided screenshot to configure the virtual machine's hardware specifications (CPU cores, memory, etc.).
   * **CD/DVD Drive:**
     * In the next step, select "Datastore ISO File" as the CD/DVD drive source.

       ![](/files/HaeSPncK7a6bZ5IcvrVU)
     * Choose the ISO file you uploaded earlier.

       ![](/files/Wh7Z8G6e6DeLLI5RlXSP)
     * Ensure "Connect at power on" is checked for the CD/DVD drive.

       ![](/files/BFIgkUdMjqNWTgozQ8se)
   * **VM Options:** Verify that "Secure Boot" is disabled in the VM Options section.

     ![](/files/b1a9QfzBGyCE4cpkGvIu)
   * Review the configuration summary and click "Finish" to create the virtual machine.

     ![](/files/uDOjgS2DOFezFJxwYE2Z)

**Starting the Virtual Machine:**

3. Locate the newly deployed virtual machine in your virtualization platform's interface.

   ![](/files/c5VteoG5ZKkMV3ujsjM6)
4. **Booting the System:** Power on the virtual machine. You might be redirected to a Storware installation process window.

   ![](/files/hpzCKIOQXtE9GjEx6z4O)
5. Typically, pressing "Enter" will initiate the installation process. Wait for it to complete.

   ![](/files/8dyGxqpEbgspwAbrUdtn)
6. You will need to select a disk to be used for both the System and Storware Backup and Recovery. To do this, click on the highlighted field.

   ![](/files/pZXwcEbJvpjFDrkc0PLl)
7. Select the desired disk and click "Done."

   <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p>During the installation, select only the drive designated for the system, the other drives will be used as data storage for your backups automatically during the initial configuration.</p></div>

<figure><img src="/files/k19y5XTMIkteav1Cpd14" alt=""><figcaption></figcaption></figure>

8\. After these steps you will be able to click “Begin Installation”.

<figure><img src="/files/wnl9XRPzJ1lggOjHVBfP" alt=""><figcaption></figcaption></figure>

9\. The configuration process might require additional steps. Follow the on-screen prompts.

<figure><img src="/files/4rnPKCw2wcWsP2dY00mm" alt=""><figcaption></figcaption></figure>

10\. After a system restart, you should see the Storware installation completion screen.

<figure><img src="/files/19P8lwi0oUaWA8rJNJHg" alt=""><figcaption></figcaption></figure>

## WebUI Access:

With the installation complete, you can access the Storware WebUI using the Linux host's IP address in a web browser.

![](/files/wJQy2OBI06QQbovUkdWI)

**Default Login Credentials:**

* Login: **admin**
* Password: **vPr0tect** (Hint: vPr(zero)tect)


# Quick Installation using all-in-one script

Using this method of installation you will deploy the server and node on the same host. The installation script will perform the following actions:

* Install the server
* Install the node
* Generate an SSL certificate based on the hostname

The installation script is deploying components using the Ansible playbooks

## Installation steps

1. Log in to the machine using SSH
2. The installation requires root privileges
3. Use the following command to start the installation:

```
bash <(curl -s https://repo.storware.eu/storware/sbr-local-install.sh)
```

## Using script to install only server or only node component

This script allows to install just server or node (which can be registered to the existing server).

### Server only installation

Before running the installation command - export the following variable:

```
export SBR_INSTALL_NODE=n
```

### Node only installation

Before running the installation command - export the following variables:

```
export SBR_INSTALL_SERVER=n
export SBR_SERVER_FQDN=your.server.host.com
export SBR_NODE_NAME=your-node-name
```

where `your.server.host` should be a FQDN of your server component, and `your-node-name` should be a unique name for a node being installed. Optionally, you can export `SBR_ADMIN_USER` if you want to register your nodes using non-admin accounts.

## Disabling password prompts

If you want to use this script without being prompted for admin user or database password you can export `SBR_ADMIN_PASS` and `SBR_DB_PASS` variables.

## Post-installation

Now you should be able to log in to the Storware Backup & Recovery server using `https://IP_OF_YOUR_MACHINE` with the local node registered and running. By default, Storware Backup & Recovery has one admin account - `admin` with the password `vPr0tect` (with a zero).

After the initial log in you can configure [single sign-on using LDAP or Keycloak](/70/administration/settings/settings).

Remember to prepare your staging space as described in the [Staging space configuration](/70/deployment/common-tasks/staging-space-configuration).

Now proceed with the [Initial configuration](/70/deployment/initial-configuration) instructions, to configure access to the hypervisors and backup destinations.


# Installation using Ansible playbook

You can install the complete Storware Backup & Recovery solution using the following 2 roles, available on Ansible Galaxy:

* Storware Backup & Recovery Server: <https://galaxy.ansible.com/ui/standalone/roles/xe0nic/ansible_vprotect_server/>
* Storware Backup & Recovery Node: <https://galaxy.ansible.com/ui/standalone/roles/xe0nic/ansible_vprotect_node/>

This approach installs a server and one or more nodes on remote hosts and generates an SSL certificate based on the server hostname. The end result should be the same as an RPM-based installation without the staging setup. Configuration (such as backup destination definition or hypervisor connectivity) still needs to be done after installation. You can also add more nodes in the future if necessary.

## Prerequisites

{% hint style="info" %}
You can find list of all supported operating systems in [this chapter](/70/deployment/component-requirements#system-requirements)
{% endhint %}

You need to prepare CentOS or RHEL minimal for Storware Backup & Recovery (both roles can be installed on the same or different hosts). The Ansible control host should have Ansible installed so that it uses Python 3.x.0

This example assumes that you have `root` access to this host and you have configured your Ansible to connect with SSH public keys to your host. For example:

generate key:\
`ssh-keygen -f ~/.ssh/id_rsa -P ""`

and copy it to your CentOS/RHEL box:\
`ssh-copy-id -i ~/.ssh/id_rsa.pub root@YOUR_HOST`

The nodes will communicate with the Storware Backup & Recovery Server via port 8181, so they need to be able to access it using the server's FQDN (this needs to be resolvable).

## Ansible variables

These two roles use just a few variables. Both plays use the `server_fqdn` variable. If not defined, the server play sets the variable `server_fqdn` to the hostname reported by the OS on which it is installed. The server play will generate an SSL certificate for this FQDN, and node play will automatically use this value if defined. You can also provide this variable manually (either in the `hosts` file or with the extra vars switch in the `ansible-playbook` command `-e "server_fqdn=vprotect.server.local"`

Node play needs a `node_name` for the registration process. If not provided, it will just use the hostname reported by the OS, however, keep in mind that it needs to be **unique** for each node. We recommend that you set them in the host inventory file.

Optionally, you may want to set a `db_password` for the root DB access which is set during server installation. Note, that the Server service uses its own account with an auto-generated password.

By default, Storware Backup & Recovery uses MariaDB 10.6 for CentOS - you can control the source, distribution and version of your MariaDB with the following variables (with their respective default values):

```yaml
mariadb_version: "10.6"
mariadb_distro: "centos"
mariadb_repo_url: "http://mirror.mariadb.org/yum/{{ mariadb_version }}/{{ mariadb_distro }}/{{ ansible_distribution_major_version }}/x86_64"
mariadb_repo_gpg_key: "https://yum.mariadb.org/RPM-GPG-KEY-MariaDB"
```

## Installation steps

{% hint style="info" %}
Before installing Storware Backup & Recovery we highly recommend doing a system update and reboot.
{% endhint %}

This example assumes that you want to install both the Storware Backup & Recovery Server and Node **using a single playbook** and **on the same host.** However, keep in mind that you may also install them separately by providing different target hosts and using separate playbooks like in the examples in the readme roles (links above).

Run these on the system from which you run Ansible playbooks:

* Install Ansible roles:

  ```
  ansible-galaxy install xe0nic.ansible_vprotect_server
  ansible-galaxy install xe0nic.ansible_vprotect_node
  ```
* Install additional collections

  ```
  ansible-galaxy install -r  ~/.ansible/roles/xe0nic.ansible_vprotect_server/meta/collections.yml
  ansible-galaxy install -r  ~/.ansible/roles/xe0nic.ansible_vprotect_node/meta/collections.yml
  ```
* Create a playbook directory and change it to a working directory: `mkdir storware && cd storware`
* Create an inventory file - `hosts` and refer to the location to where you extracted the repository

  * in this example we have specified one node and server, but you can define more nodes (each one must be in a separate line and have a unique node name)
  * the server can be on a different host
  * we recommend having at least one node installed together with the server to run DB backups

  ```
  [all:vars] 
  ansible_user=root
  admin_pass=password
  db_pass=password

  [server]
  192.168.1.2 

  [nodes]
  192.168.1.2 node_name=node1
  ```

  where:

  * `admin_pass` - password for admin user
  * `db_pass` - password for mysql root user
  * `node_name` - name under which node will be registered

{% hint style="info" %}
If you don't provide password for admin user and mysql root user, it will be set to `vPr0tect`
{% endhint %}

* Create a playbook file - `site.yml`:

  ```yaml
  ---

  - hosts: server
    roles:
    - xe0nic.ansible_vprotect_server

  - hosts: nodes
    roles:
    - xe0nic.ansible_vprotect_node
  ```
* Run the playbook: `ansible-playbook -i hosts site.yml`

## Post-installation

Now you should be able to log in to the Storware Backup & Recovery server using `https://IP_OF_YOUR_MACHINE`. By default, Storware Backup & Recovery has one admin account - `admin` with the password `vPr0tect` (with a zero).

After the initial log in you can configure [single sign-on using LDAP or Keycloak](/70/administration/settings/settings).

Remember to prepare your staging space as described in the [Staging space configuration](/70/deployment/common-tasks/staging-space-configuration).

Now proceed with the [Initial configuration](/70/deployment/initial-configuration) instructions, to configure access to the hypervisors and backup destinations.


# Installation with RPMs

To install Storware Backup and Recovery components, you can use RPM packages.

## Procedure

### Create a repository file for Storware Backup and Recovery

The repository file must be created on each host where the product components will be deployed.

1. Create a repository file`/etc/yum.repos.d/vProtect.repo` with the following content:

**For Red Hat Enterprise Linux 8 and compatible**&#x20;

```
# Storware Backup & Recovery - Enterprise backup solution for virtual environments repository
[vprotect]
name = vProtect
baseurl = https://repo.storware.eu/storware/7.0.0/el8/
gpgcheck = 0
```

**For Red Hat Enterprise Linux 9 and compatible**&#x20;

```
# Storware Backup & Recovery - Enterprise backup solution for virtual environments repository
[vprotect]
name = vProtect
baseurl = https://repo.storware.eu/storware/7.0.0/el9/
gpgcheck = 0
```

**For SUSE Linux Enterprise Server 14 and compatible**&#x20;

```
# Storware Backup & Recovery - Enterprise backup solution for virtual environments repository
[vprotect]
name = vProtect
baseurl = https://repo.storware.eu/storware/7.0.0/suse15/
gpgcheck = 0
```

### Create a repository file for MariaDB&#x20;

Installing MariaDB is required only on the host where the Storware Backup and Recovery server is deployed.&#x20;

1. Generate repository file at [MariaDB download](https://downloads.mariadb.org/mariadb/repositories) site
2. Copy and paste the generated repo file into `/etc/yum.repos.d/MariaDB.repo`

### Red Hat Enterprise Linux or  and compatible

#### Server installation

1. Install package "sudo":

   ```
   dnf install sudo
   ```
2. Install the Storware Backup and Recovery server using the following command:

   ```
   dnf install vprotect-server
   ```

#### Node installation

1. Install the Storware Backup and Recovery node using the following command

   ```
   dnf install vprotect-node
   ```

### SUSE Linux Enterprise Server  and compatible

#### Server installation

1. Add Desktop Application Tools module:

   ```
   SUSEConnect -p sle-module-desktop-applications/15.4/x86_64
   ```
2. Add Development tools module:

   ```
   SUSEConnect -p sle-module-development-tools/15.4/x86_64
   ```
3. Install package "sudo":

   ```
   zypper install sudo
   ```
4. Install the Storware Backup and Recovery server using the following command:

   ```
   zypper install vprotect-server
   ```

#### Node installation

1. Install the Storware Backup and Recovery node using the following command

   ```
   zypper install vprotect-node
   ```

### Server configuration

1. Configure access to the database. Run the following command:

   ```
   vprotect-server-configure
   ```
2. Start the Storware Backup and Recovery server service:

   ```
   systemctl start vprotect-server
   ```

### Open a firewall port

By default, the server service listens on port 8181. Open the port using the following commands:

```
firewall-cmd --add-port=8181/tcp --permanent
firewall-cmd --complete-reload
```

**(optional)** Forward the default HTTPS port 443 to port 8181:

```
/opt/vprotect/scripts/./ssl_port_forwarding_firewall-cmd.sh
```

### Node registration

1. Each installed node needs to be registered in the server:

   ```
   vprotect node -r <node name> <admin user> https://<server address>:<port>/api
   ```

   where:

   * \<node name> - the name under which the node will appear in the system
   * \<admin user> - the login of the administrative user
   * \<server address>:\<port> - address and port of the installed server

   Example:

   ```
   vprotect node -r node1 admin https://localhost:8181/api
   ```
2. Start the Storware Backup & Recovery node service:

   ```
   systemctl start vprotect-node
   ```
3. Run the script to configure the operating system. Script changes the QEMU user/group to vprotect, disables SELinux, adds Storware Backup and Recovery to the disk group and sudoers policy to allows run privileged commands:

   ```
   vprotect-node-configure
   ```
4. Reboot the Storware Backup and Recovery host to apply the operating system changes:

   ```
   reboot
   ```

## Post-installation

Now you should be able to log in to the Storware Backup & Recovery server using `https://IP_OF_YOUR_MACHINE`. By default, Storware Backup & Recovery has one admin account - `admin` with the password `vPr0tect` (with a zero).

Verify in the node section that the node that you installed is connected to the server.

After the initial log in you can configure [single sign-on using LDAP or Keycloak](/70/administration/settings/settings).

Remember to prepare your staging space as described in the [Staging space configuration](/70/deployment/common-tasks/staging-space-configuration).

Now proceed with the [Initial configuration](/70/deployment/initial-configuration) instructions, to configure access to the hypervisors and backup destinations.


# Deployment in Microsoft Azure

Storware Backup and Recovery for Azure is provided to you as an IaaS solution - Azure Managed Application which deploys: managed application in chosen Resource Group, a new Resource Group with Storware Virtual Machine and other resources inside.&#x20;

## Prerequisites

### Check enabled Azure Resource providers and user permissions&#x20;

The following Resources providers must be enabled for your Azure subscription:

* Microsoft.Resources
* Microsoft.Solutions

The user account used to deploy Storware Backup and Recovery must have assigned at least a Contributor role at the subscription level (Owner role is recommended).

## Azure Managed Application deployment

Login to your account at <https://portal.azure.com>, at the home page click **Create a resource** button.

<figure><img src="/files/c0HN3X05LuYbJdZAe0ao" alt=""><figcaption></figcaption></figure>

Using the search bar search for the **Storware Backup and Recovery** offer, click **Create** and choose your offer.

<figure><img src="/files/nDuNkt3lcnsu4QMuS4i0" alt=""><figcaption></figcaption></figure>

Fill up the configuration form, choose your Azure Subscription and Resource Group where the new Managed Application will be created.

Region - a region where new resources will be deployed.

{% hint style="info" %}
Note that the Storware Backup and Recovery machine need to be deployed in the same region and availability zone as the machines that will be backed up. Backing up machines from different regions or zones requires deploying an additional Storware Node in each of them.
{% endhint %}

Vm name - the name of Storware VM.

Admin Username - username for the VMs operating system.

Authentication Type - choose between password-based or ssh key-based authentication. For password-based you need to provide the password, for key-based you can generate a new ssh key, use the key stored in Azure or provide the public key that you are already using.

Dns Label Prefix - dns name which will be used together with Azure domain (e. g. storware.eastus.cloudapp.azure.com).

Vm size - the size of the VM, default is **Standard D2s v5** and it shouldn't be changed to the smaller size.

Virtual Network Name, Subnet Name, Network Security Group Name - the names of newly created resources.&#x20;

Security Type - leave Standard.

Application name - the name of the managed application.

Managed Resource Group - the name of the newly created Resource Group for the resource of the Storware VM.&#x20;

<figure><img src="/files/EmDHmehO3o6hheot57xI" alt=""><figcaption></figcaption></figure>

Complete the configuration and click **Review + create** button.

<figure><img src="/files/lax8gSUSZa3ghsNya9Gq" alt=""><figcaption></figcaption></figure>

Review your configuration and click **Create**. Now new resources will be deployed to your Azure subscription.

## Post-deployment configuration

After properly deploying Storware VM into Azure you need to open TCP port 8181 to be able to reach Storware Backup and Recovery Web UI. To add the **Inbound port rule** go to the VM details, and from the lefthand menu choose Networking, click **Add inbound port rule** and configure the security rule for TCP port 8181 according to your security policies.

The default Storware deployment comes with the Public IP address attached to the VM which can be used for management and connecting additional resources from outside Azure infrastructure.


# Virtual Appliance

Download Virtual Appliance images from [Storware repository](https://repo.storware.eu/storware/current/virtual-appliance/).

## Prerequisites (Storware Backup & Recovery image)

* [RHV/oVirt/Oracle Linux VM](/70/deployment/installation/virtual-appliance/rhv-ovirt-olvm-virtual-appliance)
* [Citrix XenServer/XCP-ng](/70/deployment/installation/virtual-appliance/citrix-hypervisor-or-xcp-ng-virtual-appliance)
* [VMware/ESXi](/70/deployment/installation/virtual-appliance/vmware-virtual-appliance)
* [Nutanix Acropolis Hypervisor (AHV)](/70/deployment/installation/virtual-appliance/nutanix-virtual-appliance)

**Minimum requirements:** 8 vCPU core and 10 GB RAM

**Recommended requirements:** 8 vCPU core and 16GB RAM

For more information, please check [sizing guide](/70/deployment/sizing)

### Default login, and password

* Operating system / SSH: login: **root** password: **vPr0tect**
* WebUI: login: **admin** password: **vPr0tect**

## First steps after deployment

After downloading and importing the image to the environment set the IP address:

* run `nmtui`
* `Edit a connection`
* Select network interface, and edit its network settings.

Now you should be able to log in to the web console using the URL:

```
https://STORWARE_HOST
```

where STORWARE\_HOST is the hostname or IP of your Storware Backup & Recovery Server

Increase disk size (in this example to 500G):

```
vdo growPhysical -n /dev/mapper/FileSystem
vdo growLogical -n /dev/mapper/FileSystem --vdoLogicalSize 500G
xfs_growfs /dev/mapper/FileSystem
```

Then go to [Initial configuration](/70/deployment/initial-configuration) to add virtualization hosts.

{% hint style="info" %}
**Note:** Importing the image will install both the server and node. If You need only the Storware Backup & Recovery node, then You have to stop and disable Storware Backup & Recovery server service.
{% endhint %}

```
systemctl stop vprotect-server
systemctl disable vprotect-server
```

You can register nodes installed manually (RPM/Ansible) to the Storware Backup & Recovery server installed from OVA.

## Credentials

### SSH

user name: root

password: vPr0tect

### WebUI

URL: **<https://IP\\_address>**

user name: admin

password: vPr0tect

### MariaDB

user name: root

password: vPr0tect


# RHV/oVirt/OLVM Virtual Appliance

## Installation

1. Upload OVA image to RHV host storage, or repository.
2. Login to RHV manager.
3. Go to tab Compute -> Virtual Machines.
4. On the right bottom of the screen click ellipsis button, and chose "Import".
5. Select source "Virtual Appliance (OVA).
6. Select host with uploaded OVA image.
7. Enter "File Path" to the OVA image file.
8. Click the button "Load".
9. Move from list "Virtual Machines on Source" our image to list "Virtual Machines to Import".
10. Click "Next".
11. Chose your target Storage Domain, Cluster, CPU Profile, Allocation Policy.
12. In tab "General" edit Name.
13. In the tab "Network Interfaces" choose Network for your nic's in VM.
14. Click "OK", import task is started.
15. When VM is imported and running login to SSH to get VM IP, and next you can access Storware Backup & Recovery by WebUI.

{% hint style="info" %}
**Note:** You can find the login credentials [here](/70/deployment/installation/virtual-appliance).
{% endhint %}

## Deinstallation

1. Remove VM from a virtual environment.
2. If the backup destination is outside VM, then remove backup files from the backup destination.


# Citrix Hypervisor | XCP-ng Virtual Appliance

1. Download storware.backup.recovery.x.x-citrix.ova file from [Storware repository](https://repo.storware.eu/storware/current/virtual-appliance/).
2. Open XenCenter.
3. Click on File -> Import...
4. Browse, and selct OVA file from your computer.
5. In Location select Citrix host to import image.
6. In Storage select storage to deploy vProtect VM.
7. In Networking select "Target Network" for Network Interface.
8. In Security leave empty "Verify manifest content".
9. In OS Fixup Settings, select "Don't use Operating System Fixup".
10. In Transfer VM Settings Select Network, and chose Network Settings.
11. In Finish tab view summary, and if all settings are correct then click button "Finish".
12. When VM is imported and running login to SSH to get VM IP, and next you can access vProtect by WebUI.

After importing the image to the environment set IP address, run "nmtui" -> "Edit a connection". Select network interface, and edit its network settings.

Increase disk size (in this example to 500G):

```
vdo growPhysical -n /dev/mapper/FileSystem
vdo growLogical -n /dev/mapper/FileSystem --vdoLogicalSize 500G
xfs_growfs /dev/mapper/FileSystem
```

{% hint style="info" %}
**Note:** You can find the login credentials [here](/70/deployment/installation/virtual-appliance).
{% endhint %}


# VMware Virtual Appliance

* Log in to VMware vCenter/ESXi then click on "Create/Register VM".

  ![](/files/naEOLrYuDdT9iSDueRi1)
* Select "Deploy a virtual machine from an OVF/OVA file".

  ![](/files/T9UltPmJaiCklxwGBpIQ)
* Enter a name for the virtual machine, and select the ova file.

  ![](/files/OVxmck85p6im45mVdngl)
* Select the storage.

  ![](/files/rMZuzwN8jj80KTR07Xx3)

The detailed deployment process is described on the VMware site: <https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.vm_admin.doc/GUID-AFEDC48B-C96F-4088-9C1F-4F0A30E965DE.html>

After importing the image to the environment, set the IP address and run "nmtui" > "Edit a connection". Select the network interface and edit the network settings.

{% hint style="info" %}
**Note:** You can find the login credentials [here](/70/deployment/installation/virtual-appliance).
{% endhint %}


# Nutanix Acropolis Hypervisor (AHV)

## Installation

### Using Prism Element

1. Unpack ova file.

```
tar -xvf storware.backup.recovery-oVirt.ova
```

1. Log in to Nutanix Prism. Go to Image Configuration on the left pane and click Upload Image.

   ![](/files/2Xw4TtQwXRu4JK1tcKYU)
2. Provide a name for the image. Select Image Type as DISK and upload the file that is extracted from Step 2.

   ![](/files/kliQGgTKB7iKCUFzBLPN)
3. Wait for the Image Create and Image Update tasks to complete.

   ![](/files/EOpjQZ1KRYPywP23CmLj)
4. Go to VM pane and click Create VM.

   ![](/files/seHIJ2cm4Tle0rIuoJFW)
5. In the Create VM dialog box, provide details about the VM name and Time zone. Allocate 4 vCPU and 8 GB RAM as per the documented guidelines. Leave the Boot Configuration as the default Legacy BIOS. Click Add New NIC, and assign the VLAN for the VM.

   ![](/files/hcWm64zyF8gXulWSr8kw)
6. Under Disk option, click Add New Disk. Select Type as DISK. Select Operation as Clone for Image Service. Select BUS type as SCSI (default). Select the Image that we created in Step 5 (Size of the OS disk is 59 GiB as of version 19.10.) Click ADD and Save.

   ![](/files/0WzwLc4cfU8KVwtKqkJ6)
7. Once the VM is built, click Power On to start the VM.

   ![](/files/345eH628qFqdQqHRTKY3)
8. Once the VM is ON, connect to the VM using virtual console (from Prism) and configure networking with "NetworkManager TUI" tool.

   * SSH to VM with default credentials: Username: root Password: vPr0tect
   * Run the command "nmtui" for the options to setup hostname, IP Address, Netmask, Gateway, and DNS details.

   ![](/files/FTMxH03NwBQAHC3L8vJ5)

## Deinstallation

1. Remove VM from the virtual environment.
2. If the backup destination is outside VM, then remove backup files from the backup destination.


# Initial Configuration

## Node

1. Set up the backup destinations (examples):
   * [File System](/70/deployment/backup-destinations/filesystem/regular-filesystem)
   * [Virtual Data Optimizer (VDO)](/70/deployment/backup-destinations/filesystem/regular-filesystem/virtual-data-optimizer-vdo)
2. For backup strategies involving **disk attachment** mode, follow these steps: [LVM setup on Storware Backup & Recovery Node for disk attachment backup mode](/70/deployment/common-tasks/lvm-setup-on-storware-backup-and-recovery-node-for-disk-attachment-backup-mode).

## Server

1. Upload your license key:
   * if you don't have it, you can contact the Storware team.
   * log in to the web UI and go to the `Settings -> License` and upload your `license.key` file.
2. It is **highly recommended** to set up Storware Backup & Recovery DB backup - the database is key to restoring your Storware Backup & Recovery environment and later all of the backups that you need.
3. Admin account setup:
   * for audit purposes, it is recommended to add individual admin accounts using the [Access Management](/70/administration/users) section

{% hint style="info" %}
**Note:** make sure to set the correct **time zone** for each user - the default admin account has **UTC** by default.
{% endhint %}

## Configuration Wizard

* The configuration wizard can be accessed from the main dashboard by clicking on the "configuration wizard" button on the right.

![](/files/e5lZVXjIAPrHWcCmZYMC)

### Welcome page - nodes

* On the welcome page, you should see the Storware Backup & Recovery nodes summary. You need at least one fully running node to continue. If you meet this requirement, click on the Next button.

![](/files/i1sWjTxHDF1xNwZfeaYw)

### Add a hypervisor

* In the Hypervisor section, you will start by selecting the hypervisor manager or hypervisor that you want to add. You can repeat this step if you have many types of virtualization providers.

![](/files/ErnunK0s0vwqTla9DmzU)

* For the Citrix hypervisor (as an example) you have to enter the following parameters

![](/files/Kv8KDbP7NkpV7EuXQCl1)

* Choose node configuration

![](/files/emnmB5b6ZdGHcyIQ98W7)

Select a backup strategy for your hypervisor

![](/files/BaDQY6LgBzn53GZFMbJx)

* Optionally, you can add an additional NIC for transfer purposes (provide IP address)

![](/files/egruV8awQ0fwpgahQ9cA)

* At the end, you will see a popup window that allows you to run inventory synchronization. After that, you should see all the virtual machines from that hypervisor.

![](/files/CCVEkTxCpwvI7wFfXeuR)

### Add backup destination

* In the next section, you can add a backup destination. In this case, you can also repeat the whole process so that you can add multiple providers using the wizard.
* Choose a backup destination (we used File System as an example)

![](/files/rBIkwa4kpYon8aNinDR5)

* First, enter a name for your backup destination

![](/files/US7mhR18YDDVNCwuzdCM)

* Choose, if you want to use deduplication based on [Virtual Data Optimizer (VDO)](/70/deployment/backup-destinations/filesystem/regular-filesystem/virtual-data-optimizer-vdo)

![](/files/mKhxL2L0cyx1Up46rKxP)

* Set up a storage path, where your data should be stored

![](/files/YD5trdC3o4psFF3XBzwi)

* Optionally you can enable encryption (AES-256 algorithm) - if you enable it, remember that you will not benefit from deduplication.

![](/files/tDQmcW17WiCzd3cxoIMy)

* configuration for pre/post execution command. If you use a File System with [VDO](/70/deployment/backup-destinations/filesystem/regular-filesystem/virtual-data-optimizer-vdo) or [Dell EMC Data Domain](/70/deployment/backup-destinations/deduplication-appliances/dell-emc-data-domain) integration of standard filesystem, skip this step.

![](/files/lZ223d0jwFx3pnXMgKZN)

* Decide if you want to set up this backup destination as the default one.

![](/files/u8kzZKc5L0AnxAn0hPTI)

* Finish this step by going to the next section or adding another backup destination

![](/files/gunW2QonSSU8xDDWzsSZ)

### Add SLA

In this example, we will add SLA for Virtual Environment backup.

![](/files/3D1wjlcVBBk31d2SXTUq)

### Add policy

* Choose a name for the policy, auto-remove non-present virtual environments (if Storware Backup & Recovery should remove VM from a policy that no longer exists) tick the checkbox, and set the priority

![](/files/AE3FiAq88rkmSWMEvsxw)

* Choose if you want to use auto assign mode based on tags and regular expressions (matched against the VM name, `.*` matches all characters 0 or more times)

{% hint style="info" %}
**Note:** check the [Administration](/70/administration) section for details of Backup SLAs to each protected platform
{% endhint %}

![](/files/7s6B3f8JgNZQYu74ffg1)

* Manually add the VMs if you do not want to use the auto-assignment mode

![](/files/PI4dWwxVApEIThw1qVBE)

* Choose a backup destination target for this policy

{% hint style="info" %}
**Note:** You can now customize retention. Each backup destination has its own retention settings. Whichever condition is met first (either number of versions has been reached or the backup is older than the given limit), it is removed from the backup destination.
{% endhint %}

![](/files/wNwFTrFxMNxPpZC2eqoi)

Configure the following thresholds:

* Fail rest of the backup tasks if more than X % of EXPORT tasks already failed
* Fail rest of the backup tasks if more than X % of STORE tasks already failed

![](/files/IYIvQvhBshnEoDJJketL)

### Add schedule

* Choose a name for the schedule and define the type:
  * Full
  * Incremental

![](/files/vApJ0qrszjUZOPSNooxe)

* Define the execution type:
  * time
  * interval
* Define the start window length
* Choose the time of day for backup

![](/files/Ft3iL57ZUsSWQth6h2AY)

* Choose
  * days (required).
  * day of week occurrence (optional)
  * selected months (optional)

![](/files/MQ52m9NMQi6lLFrKSHub)

* Finish this step by going to the next section or adding another SLA.

![](/files/7Aijvdwe6CSWXPc28oV9)

### Add internal DB backup

* Choose which node config should be used to perform a Storware Backup & Recovery DB backup

![](/files/WNin6cfyjA4gusrMz8aL)

* Choose the backup destination for the DB backup

![](/files/pq7jnQ7mu5ly8F4LqfbO)

Choose when the DB backup should be run (daily basis)

![](/files/TjClKATXn7wKrIx1RvkV)

* Finalize the configuration and/or run the backup manually (on demand)

![](/files/jvCk9Pg1Emflu59xoXRr)

* you are ready to go!

![](/files/prLG06FG0UhDLrATmjyQ)


# Backup Destinations

A backup destination is a storage location where Storware Backup & Recovery keeps VMs, Containers, Cloud, and applications backup copies. To configure a backup destination, you can use the following storage types:

* [File System](/70/deployment/backup-destinations/filesystem)
* [Deduplication Appliances](/70/deployment/backup-destinations/deduplication-appliances)
* [Object Storage](/70/deployment/backup-destinations/object-storage)
* [Enterprise Backup Providers](/70/deployment/backup-destinations/enterprise-backup-providers)
* [Tape Pools](/70/deployment/backup-destinations/tape-pools)

The backup destination is defined by the backup provider configuration and retention settings. Each policy can be backed up to the selected backup destination. Backup destinations must be assigned to the nodes in the node configuration.

{% hint style="info" %}
**Note:** removal of any backup destination leaves data in the backup provider without an option to re-attach it in the future.
{% endhint %}

## Retention

{% hint style="info" %}
**Note:** Retention settings are described in chapter Backup SLAs - Policy - Rule
{% endhint %}

## Pre/post access command execution

* Prepare your scripts
  * the pre-script is invoked before every access to the Backup Destination - common usage - create and mount the remote volume
  * the post-script is executed after Node finishes store, restore, and clean-up operations
* The following environment variables are set before each execution - you can use them later in your scripts:
  * `VP_VM_GUID` - GUID of the VM in Storware Backup & Recovery
  * `VP_VM_UUID` - UUID of the VM used by the hypervisor or hypervisor manager
  * `VP_VM_NAME` - the name of the VM
  * `VP_VM_TMP_DIR` - path to the folder containing files in the staging
  * `VP_BD_GUID` - GUID of the Backup Destination being accessed
  * `VP_BD_NAME` - the name of the Backup Destination being accessed
  * `VP_CONTAINER_NAME` - standard container name generated by Storware Backup & Recovery that can be used for names of the volumes (format `<VM-NAME>__<PART-OF-UUID>`, for example `Centos 7__8d3ef6f1`, may contain special characters)
  * `VP_EXPORT_PATH` - an export path from Node Configuration, can be used as the mount root for backup destination volumes
  * `VP_TASK_TYPE` - the name of the task type, e.g.: `STORE`/`RESTORE`/`DELETE_VM`/`OLD_BACKUPS_REMOVAL` - to distinguish operation type when scripts are being invoked
* Upload your scripts to the **node**, where the `vprotect` user is able to access them
* Optionally, you may need to add a new file in the `/etc/sudoers.d/` directory to enable the `vprotect` user to execute privileged script (like chown operations in some file system locations): `%vprotect ALL=(root) NOPASSWD: /opt/vprotect/scripts/myscripts/privileged.sh`
* Open the "BACKUP DESTINATIONS" section from the left menu:

![](/files/N4htTYJ15nziuQ3QHoCD)

* Open your Backup Destination (click on the name)
* Provide pre/post access command arguments (the first argument is the command executed locally on the **node**):

![](/files/RDXQomhWkxkS5AAUNFWR)

## Encryption

| Backup Destination Name     | Encryption supported? | Encrypted by                                                            | Encryption key stored in                                                              | Encryption key generation method | Encryption Algorithm |
| --------------------------- | --------------------- | ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | -------------------------------- | -------------------- |
| Filesystem                  | Yes                   | Storware Node                                                           | Generated based on metadata in the database. Separated keys are generated per object. | automatically                    | AES                  |
| Filesystem (synthetic, XFS) | No                    | n/a                                                                     | n/a                                                                                   | n/a                              | n/a                  |
| isoLayer (synthetic, XFS)   | n/a                   | n/a                                                                     | n/a                                                                                   | n/a                              | n/a                  |
| PowerProtect DD             | Yes                   | Storware Node                                                           | Generated based on metadata in the database. Separated keys are generated per object. | automatically                    | AES                  |
| Huawei OceanProtect         | Yes                   | Storware Node                                                           | Generated based on metadata in the database. Separated keys are generated per object. | automatically                    | AES                  |
| MS Azure Blob Storage       | Yes                   | Storware Node                                                           | Generated based on metadata in the database. Separated keys are generated per object. | automatically                    | AES                  |
| Amazon S3                   | Yes                   | Server Side (Backup Destination own mechanism, not managed by Storware) | Generated based on metadata in the database. Separated keys are generated per object. | automatically                    | n/a                  |
| S3 compatible               | Yes                   | Server Side (Backup Destination own mechanism, not managed by Storware) | Generated based on metadata in the database. Separated keys are generated per object. | automatically                    | n/a                  |
| Cloudian S3                 | Yes                   | Server Side (Backup Destination own mechanism, not managed by Storware) | Generated based on metadata in the database. Separated keys are generated per object. | automatically                    | n/a                  |
| Alibaba Cloud OSS           | Yes                   | Server Side (Backup Destination own mechanism, not managed by Storware) | Generated based on metadata in the database. Separated keys are generated per object. | automatically                    | n/a                  |
| Nutanix Objects             | Yes                   | Server Side (Backup Destination own mechanism, not managed by Storware) | Generated based on metadata in the database. Separated keys are generated per object. | automatically                    | n/a                  |
| OpenStack Swift             | Yes                   | Server Side (Backup Destination own mechanism, not managed by Storware) | Generated based on metadata in the database. Separated keys are generated per object. | automatically                    | n/a                  |
| Scality Ring                | Yes                   | Server Side (Backup Destination own mechanism, not managed by Storware) | Generated based on metadata in the database. Separated keys are generated per object. | automatically                    | n/a                  |
| Dell EMC Avamar             | Provider dependent    | n/a                                                                     | n/a                                                                                   | n/a                              | n/a                  |
| Dell EMC Networker          | Provider dependent    | n/a                                                                     | n/a                                                                                   | n/a                              | n/a                  |
| IBM Spectrum Protect        | Provider dependent    | n/a                                                                     | n/a                                                                                   | n/a                              | n/a                  |
| Veritas Netbackup           | Provider dependent    | n/a                                                                     | n/a                                                                                   | n/a                              | n/a                  |
| Micro Focus Data Protector  | Provider dependent    | n/a                                                                     | n/a                                                                                   | n/a                              | n/a                  |


# File System

This section presents the key steps necessary for configuring a file system as your backup destination. You can use a:

local [File System](/70/deployment/backup-destinations/filesystem/regular-filesystem) or remote (NFS, SMB, etc.) or attach a block device with enabiling there [Virtual Data Optimizer (VDO)](/70/deployment/backup-destinations/filesystem/regular-filesystem/virtual-data-optimizer-vdo) or others like

[Synthetic File System](/70/deployment/backup-destinations/filesystem/synthetic-file-system)

[isoLayer (Synthetic)](/70/deployment/backup-destinations/filesystem/isolayer)

[Catalogic Software vStor](/70/deployment/backup-destinations/filesystem/catalogic-software-vstor)

.


# Rubrik Managed Volumes

## Overview

With Stoware supporting a wide range of sources one can easily expand Rubrik capabilities by integrating both solutions. Storware supports file-based backup destinations with mechanism to run custom pre/post storage access integration scripts. Rubrik on the other hand is able to expose Managed Volumes which can easily be used as snapshot-driven file system backup destination. Storware initiates backups for all supported virtualization platforms or storage providers. File system backup destination has enabled pre/post storage access integration scripts which are executed in each storage-related activity (before and after changes are made). For each VM/storage instance integration assumes a separate managed volume.

Pre script locates the managed volume in Rubrik (create it if necessary), exposes it over NFS, mounts it on the node and invokes “begin snapshot” Rubrik API call. Then the changes are made to the volume (new data is being stored, expired data is removed according to the retention).

Finally, post script is being invoked to unmount the volume and invoke “end snapshot” Rubrik API call. This script is also invoked in any failure of pre script or task activity.

Example for OpenStack using Ceph RBD storage environment:

![](/files/Eog2QoMQbsCAUvIKsi6C)

## Requirements

1. A working Rubrik cluster (IP floating address or FQDN)
2. Opened network communication between Rubrik and Storware on ports:
   * TCP 443
   * NFS v3 (TCP and UDP): 111, 2049
3. User name and password for Rubrik software, with the following permissions:
   * Create, delete, modify Managed Volumes
   * Create snapshots for Managed Volumes
   * Resize Managed Volumes
   * Change mode: Read Only to Read-Write, and form Read-Write to Read Only on Managed Volumes

## Setup

In Rubrik software cluster you need to create:

1. SLA Domains -> Local Domains: SLA with your retention settings for backup from Storware in Managed Volumes.
2. Very important: We don’t need to create any Managed Volumes on Rubrik manually – this will be created automatically by Storware, and size managed volume needed for backup is dynamically growing by Storware, so on each step, we are not losing any extra space on Rubrik.

On the Storware node you need to make the following changes:

1. Go to /opt/vprotect/scripts/rubrik
2. Edit config file and fill variables with your own information, for example:

   ```
   R_API=https://your_rubrik floating_ip_address/api
   R_USER=login_to_rubrik
   R_PASS=password_for_rubrik_user
   R_NFS_HOST_ PATTERN=IP_address_this_storware_node
   R_SLA_NAME=name_of_your_sla_domain_in_rubrik
   ```
3. Save this config file
4. Next, edit /etc/sudoers.d/01\_vprotect-node file and add below lines

   ```
   %vprotect ALL=(root) NOPASSWD: /opt/vprotect/scripts/rubrik/privileged.sh
   %vprotect ALL=(root) NOPASSWD: /usr/bin/rmdir
   ```

   before line:

   ```
   Defaults!VPROTECTNODE !requiretty
   ```

Now we need to configure your Storware server by using a web interface. Please enter web address: <https://your\\_Storware\\_IP/or/FQDN\\_address>, login as Global administrator into Storware.

Go to section on the left menu: **Backup Destinations** -> **File System**, and we need to create new Backup Destination – on the right click on button **Create Backup Destination**, choose **File System**:

![](/files/UZoCwKAWkTBFcEAtm5kx)

Next, enter the name for the new backup destination and choose node configuration:

![](/files/ijs3CAGOTdMeWPKrJ4wE)

Add your temporary path, where Storware Backup & Recovery can mount Rubrik Managed Volume to store your backup data, for example:

![](/files/wdSzMjeyp6Da8fTqUYdX)

Finally, you need to activate pre and post store commands. In each, add two command arguments like in example:

![](/files/YOd6M0ELxxIuERagK4dU)

## Limitations&#x20;

Based on the number of nodes the Rubrik cluster has the following limitations:

* three nodes configuration - protection up to 256 virtual machine instances
* two nodes configuration - protection up to 128 virtual machine instances

A single Rubrik node can protect up to 64 virtual machine instances.


# Synthetic File System

## **Synthetic File System**

A synthetic file system allows us to store and use incremental backups as if they were full backup files, but they take up a fraction of full file size.

To start using Synthetic File System read **Prerequisites** for two supported scenarios:

Synthetic filesystem [**XFS/NFS 4.2**](/70/deployment/backup-destinations/filesystem/synthetic-file-system/synthetic-xfs)

Synthetic filesystem [**DD Boost**](/70/deployment/backup-destinations/filesystem/synthetic-file-system/synthetic-ddboost)


# XFS

**Prerequisites:**

{% hint style="info" %}
**Note:**

* The only prerequisite to using synthetic XFS as a backup destination is that the selected storage path is on the XFS
* For a basic setup of file systems on the Node check [File system](/70/deployment/backup-destinations/filesystem/regular-filesystem)
  {% endhint %}

## Creating a Synthetic Filesystem Backup Destination

1. Select File System from Backup Destinations,

![](/files/pL5BrHYH4UP1qJD0LZMr)

1. Select Create Backup Destination -> File System (Synthetic),

![](/files/UZoCwKAWkTBFcEAtm5kx)

1. Configuration is similar to a regular Filesystem.
   * You just need to select XFS as the Storage Backend:

     <img src="/files/SLWMfQvsWn28d1THfX7x" alt="" data-size="original">
   * **When setting the path, make sure it's actually on the XFS!**


# DD Boost

**Prerequisites:**

{% hint style="info" %}
**Note:**

* To create a new storage unit (or use an existing one) you can use [Power Protect DD Storage Unit Creator](#power-protect-dd-storage-unit-creator)
* See How to setup [DD Boost FS Plugin](/70/deployment/backup-destinations/deduplication-appliances/dell-emc-data-domain#dd-boost-fs-plugin).

  (Do not set up an additional Backup Destination! You just need to follow the instructions regarding boostFS and storage unit setup)
* For the basic setup of file systems on the Node check [File system](/70/deployment/backup-destinations/filesystem/regular-filesystem).
  {% endhint %}

## Creating a Synthetic Filesystem Backup Destination

* Select File System from Backup Destinations,

  <img src="/files/pL5BrHYH4UP1qJD0LZMr" alt="" data-size="original">
* Select Create Backup Destination -> File System (Synthetic)

  <img src="/files/UZoCwKAWkTBFcEAtm5kx" alt="" data-size="original">
* Configuration is similar to a regular filesystem.

  <img src="/files/4hP5H1Cbe9ElBpXTDTea" alt="" data-size="original">

  * **Host**: address of Data Domain server
  * **Account name** and **password**: credentials for Data Domain
  * **Storage unit**: storage unit name from Data Domain
  * **Storage path**: path for storing backups.
  * Optionally you can switch on "Data Domain is mounted to a different directory than backup destination path" and set up a different **Storage path** than the **DD mount path**.

{% hint style="info" %}
***Note:***

* The **Storage path** must be inside the **DD mount path**.
* The **DD mount path** (or **Storage path**, in case only a **Storage path** is set) must point to the mount point of boostFS with the corresponding Storage Unit (see setting up boostFS).
  {% endhint %}

### Power Protect DD Storage Unit Creator

This configuration wizard will guide you through creating a storage unit to use as a backup destination for your protected data. You can create a new user, a new storage unit, or use existing ones as well.

![](/files/20tHDkWZhHGQ8pDuDetw)

To use the wizard, you need the prepare the following:

* PowerProtect DD address
* Administrator username
* Administrator password

Follow the steps of the wizard to configure the storage unit and user. After you will go through all the steps wizard will fill up all of the necessary fields in the form.

### Retention lock

Retention lock option allows you to protect your backups from any changes for a certain number of days. It requires Data Domain retention lock to be enabled. It must be set to `Manual` mode and allow you to set the required retention lock (it is limited by Data Domain):

![](/files/kX3hZSg2J2qHFHRwy371)


# isoLayer (Synthetic)

## Prerequisites

You need a NFS server with storage with XFS filesystem to properly configure isoLayer Backup Destination in Storware Backup & Recovery.

## Preparation

1. On NFS server we need to create NFS share, for example:

   ```
   mkdir /NFS
   ```
2. Edit file `/etc/exports` to add access to this share:

   ```
   /NFS SBR_NODE_IP(rw,sync,no_all_squash,no_root_squash)
   ```

   Where SBR\_NODE\_IP is IP of Storware Backup & Recovery Node, which will have access to this share
3. Generate new SSH keys, without any password:

   ```
   ssh-keygen 
   Generating public/private rsa key pair.
   Enter file in which to save the key (/root/.ssh/id_rsa): 
   Enter passphrase (empty for no passphrase): 
   Enter same passphrase again: 
   Your identification has been saved in /root/.ssh/id_rsa.
   Your public key has been saved in /root/.ssh/id_rsa.pub.
   The key fingerprint is:
   SHA256:H2NJwORiG3oJDm78sKEx4EuOzIm13vUsJ6NfMOPVgt0 root@vpro43-vmware
   The key's randomart image is:
   +---[RSA 3072]----+
   |       oo        |
   |       ...       |
   |. . . + . .      |
   |oo o + B + .     |
   |ooB o O S E      |
   |B*o* o = + o     |
   |+*o . o . .      |
   | . . .++.        |
   |  . oo.=o        |
   +----[SHA256]-----+
   ```
4. Add new public key to `/root/.ssh/authorized_keys` file

   ```
   cat /root/.ssh/id_rsa.pub > /root/.ssh/authotized_keys
   ```
5. Copy generated private key (id\_rsa) to Storware Backup & Recovery Node host

   ```
   scp /root/.ssh/id_rsa root@SBR_NODE_IP:/opt/vprotect/.ssh/
   ```
6. SSH to Storware Backup & Recovery Node and change owner of this file:

   ```
   chown vprotect:vprotect /opt/vprotect/.ssh/id_rsa
   ```
7. Connect from Storware Backup & Recovery Node to NFSs:

   ```
   ssh -i /opt/vprotect/.ssh/id_rsa root@NFSs
   ```

   accept new fingerprint and exit from remote session
8. Copy last line from `/root/.ssh/known_hosts` file into `/opt/vprotect/.ssh/known_hosts` file
9. Configure isoLayer connection. Edit `/opt/vprotect/scripts/isoLayer/config` file:

   ```
   vi /opt/vprotect/scripts/isoLayer/config)
   NFS_HOST=NFS4.2_HOST_IP
   SSH_USER=root
   SSH_KEY=~/.ssh/id_rsa
   NFS_HOST_PATTERN=NODE_IP
   NFS_ROOT=PATH_FOR_MOUNT_POINTS
   NFS_OPTS=rw,sync,insecure,no_root_squash,no_subtree_check
   ```

   where:

   `NFS_HOST` - IP address of NFS server

   `NFS_HOST_PATTERN` - IP address (CIDR) of NFS server, for example: 10.10.0.0/24

   `NFS_ROOT` - NFS server share path, where we want to store our backups, for example /NFS/backup

## Creating isoLayer backup destination

1. Login into Storware Backup & Recovery UI.
2. From menu on the left, select **Backup Destinations** -> **File System**.
3. On the right, click **Create Backup Destination** button and choose **isoLayer (Synthetic)**.
4. In new window:

   * type name for the backup destination
   * select Node Configurations
   * provide backup destination path – this is place, where from Storware Backup & Recovery Node perspective, isoLayer will be temporary mount share from NFS server
   * Check if pre and post scripts are active, and correct paths are provided like in example:

   ![](/files/1lHxY0pKAmpoUyzdlGBd)

   * Click **Save** button
5. Now you can use this isoLayer connection to store your backup.


# File system

In this section, we'll show you how to set up a file system (it can be a local or remote file system, but this example assumes that you have a dedicated disk that you're going to use as a backup destination with a local XFS file system)

{% hint style="info" %}
**Note:**

* Any remote FS like **NFS, SMB, etc.** - needs to be mounted by the user, and the `vprotect` user/group must own the directories within the backup destination. Storware Backup & Recovery expects an already mounted file system and mount point in the backup destination.
* You should add this file system to your `/etc/fstab` file on the node so that it gets mounted automatically if the OS is rebooted.
* Consider using the same file system for the staging and backup destination (this boosts storage tasks, as no data needs to be copied again) - in such a scenario, the only difference would be that the presented `/backupdestination`mount point becomes a subdirectory of the staging space (usually `/vprotect_data/backups`).
  {% endhint %}

## Preparation

1. Log in to Storware Backup & Recovery Node and create the mount directory as in the example `/backupdestination`

   ```
   mkdir /backupdestination
   ```
2. List all existing disks and find your drive:

   ```
   [root@vProtect01 ~]# fdisk -l | grep dev
   Disk /dev/sda: 32.2 GB, 32212254720 bytes, 62914560 sectors
   /dev/sda1   *        2048     1026047      512000   83  Linux
   /dev/sda2         1026048    62914559    30944256   8e  Linux LVM
   Disk /dev/sdc: 500 GB, 17179869184 bytes, 33554432 sectors
   Disk /dev/sdb: 21.5 GB, 21474836480 bytes, 41943040 sectors
   Disk /dev/mapper/centos-root: 28.5 GB, 28462546944 bytes, 55590912 sectors
   Disk /dev/mapper/centos-swap: 3221 MB, 3221225472 bytes, 6291456 sectors
   ```
3. Prepare a filesystem on it:

   ```
   mkfs.xfs -K /dev/sdc
   ```
4. Add permission for the Storware Backup & Recovery user to access the directory `/backupdestination`

   * we assume here that you use a separate file system than your staging space
   * as an alternative, you also can point Storware Backup & Recovery to use a subdirectory on the same file system as your staging space, i.e. `/vprotect_data/backups` (which you probably don't have to initialize at this point, as you may have already prepared it in the [Staging space configuration](/70/deployment/common-tasks/staging-space-configuration), and you can just jump to the Web UI part in the next steps).

   ```
   chown vprotect:vprotect -R /backupdestination
   ```
5. Add this line to the `/etc/fstab` file to automatically mount new the filesystem after reboot:

   ```
   /dev/sdc    /backupdestination    xfs    defaults 0 0
   ```

   or if you want to store backups on NFS share then it will look like this (where 10.50.1.28 is your host):

   ```
   10.50.1.28:/example_nfs_share /backupdestination nfs defaults  0 0
   ```
6. Check if the fstab entry is OK and mount the filesystem:

   ```
   mount /backupdestination
   ```
7. Log in to the Storware Backup & Recovery web UI.
8. Go to **Backup Destinations.**
9. Click on **Create Backup Destination**, choose a **File system.**
10. Type the name for the new backup destination, set the retention, and select at least one node configuration.
11. You have to decide if your backup destination is a separate entity from the staging space.
    * If the **staging space is different than your backup storage destination:**
      * In **Storage paths** type `/backupdestination` - this path will be used to mount the prepared file system (XFS) on top of the VDO volume.
    * If the **staging space needs to be the same as your backup storage destination:**
      * In **Storage paths** type `/vprotect_data/backups`, where you point to a subdirectory (i.e. `backups` on your staging space path, i.e. `/vprotect_data).`
12. Save the configuration.


# Virtual Data Optimizer (VDO)

In this section, you can find information on how to enable deduplication using basically any block storage available. We assume that you have prepared your storage provider and have exposed the block device to the system where Storware Backup & Recovery Node is installed.

## Preparation

{% hint style="info" %}
Disable Secure Boot option for the VM to allow VDO work properly. Run below command to check status of Secure Boot option:

```
mokutil --sb-state
```

{% endhint %}

1. Log in to Storware Backup & Recovery Node and create a mount directory as in the example `/backupdestination`

   ```
   mkdir /backupdestination
   ```
2. List all existing disks, and find your drive. Let's assume `/dev/sdc` is your empty block device that you want to use:

   ```
   [root@vProtect01 ~]# fdisk -l | grep dev
   Disk /dev/sda: 32.2 GB, 32212254720 bytes, 62914560 sectors
   /dev/sda1   *        2048     1026047      512000   83  Linux
   /dev/sda2         1026048    62914559    30944256   8e  Linux LVM
   Disk /dev/sdc: 500 GB, 17179869184 bytes, 33554432 sectors
   Disk /dev/sdb: 21.5 GB, 21474836480 bytes, 41943040 sectors
   Disk /dev/mapper/centos-root: 28.5 GB, 28462546944 bytes, 55590912 sectors
   Disk /dev/mapper/centos-swap: 3221 MB, 3221225472 bytes, 6291456 sectors
   ```
3. Log in to the vProtect web UI.
4. Go to **Backup Destinations.**
5. Click on **Create Backup Destination**, choose a **File system.**
6. Type the name for the new backup destination, set the retention, and select at least one node configuration.
7. Based on whether the staging space is same as backup destination or not, do one of the following:
   * If the **staging space is different than your backup destination** storage:
     * In **Storage paths** type `/backupdestination` - this path will be used to mount the prepared file system (XFS) on top of the VDO volume.
     * Check **Enable deduplication.**
     * Provide your block device (for example `/dev/sdc`) as your Deduplication device.
   * If the **staging space needs to be the same as your backup destination** storage:
     * In **Storage paths** type `/vprotect_data/backups` - this path assumes that `/vprotect_data` is your staging space path and `backups` is a subdirectory of the staging space.
     * Check **Enable deduplication.**
     * Provide your block device (for example `/dev/sdc`) as your **Deduplication device.**
     * Enable **Mount deduplicated file system to a different directory than backup destination path** and provide the mount point - your staging space path, for example `/vprotect_data` - this will force Storware Backup & Recovery to mount XFS on top of VDO in the staging space directory rather than in the backup subdirectory.

![](/files/jPyLqbwElHaX9ZuyGAmV)

{% hint style="info" %}
**Note**: Only one file system backup destination with deduplication using VDO pointing to a specific directory can be used. If you want to add another backup destination using the same VDO device, but just a different subdirectory, create it without deduplication enabled.
{% endhint %}

## Importing existing VDO volumes to LVM

The python-based VDO management software has been deprecated and removed from RHEL 9/CentOS 9 Stream. It has been replaced by the LVM-VDO integration. If you are using VDO on RHEL 8/CentOS 8 Stream and plan to upgrade to version 9, you need to convert VDO volume.

In this example we have VDO volume called VDOexample created and managed by Storware Backup & Recovery.

```
[root@sbr-node ~]# lsblk
NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda            8:0    0   40G  0 disk 
|-sda1         8:1    0  600M  0 part /boot/efi
|-sda2         8:2    0    1G  0 part /boot
`-sda3         8:3    0 38.4G  0 part 
  |-cs-root  253:0    0 34.4G  0 lvm  /
  `-cs-swap  253:1    0    4G  0 lvm  [SWAP]
sdb            8:16   0  100G  0 disk 
`-VDOexample 253:2    0  300G  0 vdo  /backups
sr0           11:0    1 1024M  0 rom  
```

1. On Storware Backup & Recovery Node, stop vprotect-node service.

   ```
   [root@sbr-node ~]# systemctl stop vprotect-node
   ```
2. Unmount VDO volume from backup destination path.

   ```
   [root@sbr-node ~]# umount /backups
   ```
3. Convert VDO volume. Change `/dev/sdb` to the device on which you have created VDO.

   ```
   [root@sbr-node ~]# lvm_import_vdo /dev/sdb
   Convert VDO device "/dev/sdb" to VDO LV "vdovg/vdolvol"? [y|N]: Yes
   Stopping VDO VDOexample
   Converting VDO VDOexample
       Opening /dev/sdb exclusively
       Loading the VDO superblock and volume geometry
       Checking the VDO state
       Converting the UDS index
       Converting the VDO
       Conversion completed for '/dev/sdb': VDO is now offset by 2097152 bytes
   Physical volume "/dev/sdb" successfully created.
   Volume group "vdovg" successfully created
   WARNING: Logical volume vdovg/vdolvol_vpool not zeroed.
   Logical volume "vdolvol_vpool" created.
   WARNING: Converting logical volume vdovg/vdolvol_vpool to VDO pool volume WITHOUT formating.
   WARNING: Using invalid VDO pool data MAY DESTROY YOUR DATA!
   Logical volume "vdolvol" created.
   Converted vdovg/vdolvol_vpool to VDO pool volume and created virtual vdovg/vdolvol VDO volume.
   ```
4. Rename volume group and logical volume names. They must be the same as the original VDO volume name.

   ```
   [root@sbr-node ~]# vgrename vdovg VDOexample
   Volume group "vdovg" successfully renamed to "VDOexample"
   [root@sbr-node ~]# lvrename /dev/VDOexample/vdolvol /dev/VDOexample/VDOexample
   Renamed "vdolvol" to "VDOexample" in volume group "VDOexample"
   ```
5. Edit /etc/yum.repos.d/vProtect.repo and change `baseurl` to point to `el9`.

   ```
   [root@sbr-node ~]# vim /etc/yum.repos.d/vProtect.repo

   [vProtect]
   baseurl = http://repo.storware.eu/storware/current/el9
   gpgcheck = 0
   name = vProtect repo
   ```
6. On Storware Backup & Recovery Server machine, create a vprotect database backup and copy it to safe place. Wait for all tasks to finish before stopping the vprotect-server service.

   ```
   [root@sbr-server ~]# stop systemctl vprotect-server
   [root@sbr-server ~]# /opt/vprotect/scripts/backup_db.sh
   [root@sbr-server ~]# cp /tmp/vprotect_db.sql.gz /root
   ```
7. Login to mysql and execute below SQL query.

   ```
   [root@sbr-node ~]# mysql -uroot -p vprotect

   update filesystembackupdestination
   inner join backupdestination on filesystembackupdestination.guid = backupdestination.guid
   set filesystembackupdestination.dedupvolume = CONCAT('/dev/', REGEXP_REPLACE(backupdestination.name,'\\W','_'), '/', REGEXP_REPLACE(backupdestination.name,'\\W','_'))
   where filesystembackupdestination.dedupvolume is not null;

   MariaDB [vprotect]> quit
   ```
8. Start vprotect-server service.

   ```
   [root@sbr-server ~]# systemctl start vprotect-server
   ```
9. Proceed with the system upgrade of the Storware Backup & Recovery Node machine. After the reboot, you should have new LVM-VDO mounted on your backupdestination directory.

   ```
   [root@sbr-node ~]# lsblk
   NAME                               MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
   sda                                  8:0    0   40G  0 disk 
   ├─sda1                               8:1    0  600M  0 part /boot/efi
   ├─sda2                               8:2    0    1G  0 part /boot
   └─sda3                               8:3    0 38.4G  0 part 
   ├─cs-root                        253:0    0 34.4G  0 lvm  /
   └─cs-swap                        253:1    0    4G  0 lvm  [SWAP]
   sdb                                  8:16   0  100G  0 disk 
   └─VDOexample-vdolvol_vpool_vdata   253:2    0  100G  0 lvm  
   └─VDOexample-vdolvol_vpool-vpool 253:3    0  300G  0 lvm  
       └─VDOexample-VDOexample        253:4    0  300G  0 lvm  /backups
   ```


# Catalogic Software vStor

Storware Backup & Recovery supports Catalogic vStor Server and integrates with it with extended File System Backup Destination logic.

You can use Catalogic volumes like any other file system (mount a single volume over NFS) or you can use the scripts provided to automatically create and replicate volumes whenever vStor volume is being accessed. This documentation describes a setup with 2 vStor servers and a 1-volume-per-VM approach (with optional replication).

1. Storware Backup & Recovery accesses vStor Servers using SSH public key authentication - first generate the key:

   ```
   [root@vProtectbuild ~]# sudo -u vprotect ssh-keygen
   Generating public/private rsa key pair.
   Enter file in which to save the key (/opt/vprotect/.ssh/id_rsa):  
   Created directory '/opt/vprotect/.ssh'.
   Enter passphrase (empty for no passphrase): 
   Enter same passphrase again: 
   Your identification has been saved in /opt/vprotect/.ssh/id_rsa.
   Your public key has been saved in /opt/vprotect/.ssh/id_rsa.pub.
   The key fingerprint is:
   SHA256:xeceRtL4kq3zzQrUQH/K5SbiT/nv9QvAtBEfOxeT5us vprotect@vProtectbuild.lab.local
   The key's randomart image is:
   +---[RSA 2048]----+
   |          .. . o.|
   |         o +o ooo|
   |          *o=+=. |
   |         .o%o=o. |
   |        S =+@ o .|
   |         o *.= . |
   |          = +.. .|
   |           * +.Eo|
   |            +.++=|
   +----[SHA256]-----+
   ```
2. Add the VM fingerprint to the SSH known\_hosts on the **node** for the primary (and optionally secondary) vStor Server:

   * It must be a `known_hosts` file that belongs to the `vprotect` user
   * The algorithm must be set to `ssh-rsa`

   ```
   sudo -u vprotect ssh -o HostKeyAlgorithms=ssh-rsa admin@VSTOR_HOST
   ```

   **Example:**

   ```
   [root@vProtectbuild ~]# sudo -u vprotect ssh -o HostKeyAlgorithms=ssh-rsa admin@10.10.10.1
   The authenticity of host '10.10.10.1 (10.10.10.1)' can't be established.
   RSA key fingerprint is SHA256:65M/6jNBXJTFqti/798STSFeZigRzHMivDNl0t95FNI.
   RSA key fingerprint is MD5:cc:91:7d:17:8e:21:68:19:4b:c9:e4:76:bd:f5:4d:fc.
   Are you sure you want to continue connecting (yes/no)? yes
   Warning: Permanently added '10.10.10.1' (RSA) to the list of known hosts.
   ```
3. Copy the key to each vStor Server:

   ```
   [root@vProtectbuild ~]# sudo -u vprotect ssh-copy-id admin@10.10.10.1
   /bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/opt/vprotect/.ssh/id_rsa.pub"
   /bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
   /bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
   admin@10.10.10.1's password: 
   _
   Number of key(s) added: 1
   _
   Now try logging into the machine, with:   "ssh 'admin@10.10.10.1'"
   and check to make sure that only the key(s) you wanted were added.
   ```
4. Open the "BACKUP DESTINATIONS" section on the left menu.
5. Create a new Catalogic vStor Server Backup Destination (choose from the top-right drop-down menu).
6. Fill in the template with your information.

![](/files/tNgpiRDNVCoCIXnBjZT4)

* `FIRST_VS_HOST` - your primary vStor Server IP/hostname
* `SECOND_VS_HOST` - optional, secondary vStor Server IP/hostname, where the data will be replicated to
* `VS_PARTNER_ID` - optional, secondary vStor partner ID - you can get this ID by running this command on the vStor Server shell:

  ```
  [admin@localhost ~]# vstor partner show
  ID                               | MGMT ADDRESS | API PORT | SSH PORT
  55cd380b7dc848bbb439bfd444bc1799 | 10.10.10.2   | 8900     | 22
  ```
* If a secondary server is not provided, Storware Backup & Recovery will assume that no replication is needed.

![](/files/4ydfh28mysJAiHOh9yII)

1. Initiate backup to test if the scripts have been executed correctly - in the `vprotect_daemon.log` files you should be able to see messages like this:

   ```
   2018-05-04 15:31:39.133  INFO
   [0f2b9705-61a1-44d5-876f-ac81985c4a94] Executing pre/post store command...
   ```


# Deduplication Appliances

This section presents the key steps necessary for configuring integration with deduplication appliances as your backup destination. You can use NFS or SMB to attach deduplication appliances such as:

* [Dell EMC Data Domain](/70/deployment/backup-destinations/deduplication-appliances/dell-emc-data-domain)
* [Huawei OceanProtect](/70/deployment/backup-destinations/deduplication-appliances/huawei-oceanprotect)
* [HPE StoreOnce](/70/deployment/backup-destinations/deduplication-appliances/hpe-storeonce)
* [Exagrid](/70/deployment/backup-destinations/deduplication-appliances/exagrid)
* [Neverfail HybriStor](/70/deployment/backup-destinations/deduplication-appliances/neverfail-hybristor)


# Dell EMC Data Domain

## Create a new Backup Destination (Dell EMC Data Domain)

* Go into the backup destination menu and click on Create a backup destination.
* Provide a name and description for the new backup destination.
* Specify the retention days for full and incremental backups.
* Specify the retention versions for full and incremental backups.
* Choose and assign the node configuration to which you want to attach the new backup destination.
* Add to one or more storage paths.
  * `example - /vprotect_data/backupdestination`
* Save the configuration.

## DD Boost FS Plugin

* To boost the backup process we recommend using a **single** Storage Unit and mtree, and subfolders on the BoostFS for multiple backup destinations (with possibly different retention settings).
  * No additional data copy is needed in the store phase if staging is using the same file system as the backup destination.
  * The Setup assumes a single Storage Unit and a single mtree for all backup destinations.
  * The staging space should always be a top directory, and all backup destinations should be defined as separate subfolders of this file system.
  * Storware Backup & Recovery handles retention, and each backup destination may have different retention configured.
  * A single Storage Unit will also affect replication as it has to cover all backup destinations, and may replicate temporary data from the staging space or mounted backups.
* **Sharing** the same BoostFS across multiple nodes allows the administrator to create backups on one node (one host/environment) and restore using a different node (to a different host/environment).
  * UID/GID ownership and permissions must allow Storware Backup & Recovery to read/write contents of the BoostFS share.
  * To meet these requirements, the user and group named vprotect that was created during the installation process must have the same UID and GID on each Storware Backup & Recovery node machine. You can create this before installing Storware Backup & Recovery packages or change it after installation.
* Data Domain User requirements:
  * user must have **backup-operator** management role
  * user must be assigned to DD Boost Storage Unit

Prepare your PowerProtect DD as a backup destination:

* Login to PowerProtect DD and create an NFS Storage Unit called `storware-vprotect`

![PowerProtect DD - login screen](/files/YUJzZPBtEJVV2J7dLO9m)

![DD Boost - storage units](/files/E3bNH8dDOa6uackpMLsN)

* Download BoostFS RPM from the Dell EMC site.
* Install BoostFS:

  ```
  rpm -ivh DDBoostFS-7.0.0.0-633922.rhel.x86_64.rpm
  ```
* Save the password for BoostFS.

  ```
  # Syntax
  /opt/emc/boostfs/bin/boostfs lockbox set -d [DataDomain_IP_OR_DNS_NAME] -u [Access_User_Name] -s [Storage_Area_Name]
  # Example
  /opt/emc/boostfs/bin/boostfs lockbox set -d 10.1.10.100 -u vprotect -s vprotectbackup
  ```
* Add the /etc/fstab entry:

  ```
  # Syntax
  [DataDomain_IP_OR_DNS_NAME]:/[Storage_Area_Name] /[Mount_Point] boostfs defaults,_netdev,bfsopt(allow-others=true) 0 0
  # Example
  10.1.10.100:/vprotectbackup /vprotect_data boostfs defaults,_netdev,bfsopt(allow-others=true) 0 0
  ```
* Mount the fstab entry:

  ```
  mount -a
  ```
* For a manual, one-time mount you can run this command:

  ```
  # Syntax
  /opt/emc/boostfs/bin/boostfs mount -o allow-others=true -d [DataDomain_IP_OR_DNS_NAME] -s [Storage_Area_Name] /[Mount_Point]
  # Example
  /opt/emc/boostfs/bin/boostfs mount -o allow-others=true -d 10.1.10.100 -s vprotectbackup /vprotect_data
  ```
* Confirm with `df -h` that your `/vprotect_data` is mounted\
  **Note:** Remember to specify the backup destination path as a subdirectory of /vprotect\_data if you would like to use the same storage unit as a staging space and backup destination - for example: /vprotect\_data/my-backups.

  ```
  mkdir /vprotect_data/my-backups
  ```
* Set ownership to the vprotect user on the directory /vprotect\_data.

  ```
  chown vprotect -R /vprotect_data
  ```
* Set ownership to the vprotect user and data domain group on the directory /vprotect\_data/my-backups.

  ```
  chown vprotect:gid /vprotect_data/my-backups
  ```

where 'gid' is the GID of data domain user specified in Synthetic DD Boost backup destination configuration.

* Set read and write privileges for both user and group to the directory /vprotect\_data/my-backups.

  ```
  chmod 0775 /vprotect_data/my-backups
  ```

{% hint style="info" %}
**Note:** Synthetic DD Boost

To configure a synthetic backup destination, follow the instructions that are described in the [documentation](/70/deployment/backup-destinations/filesystem/synthetic-file-system/synthetic-ddboost).
{% endhint %}

## Microsoft Hyper-V

Additional actions are required when protecting Microsoft Hyper-V. Mounting the Data Domain share should be done in the same way as described above. After mounting the share, do the following:

* Log in to your Data Domain and check UID of the user that is used to connect to Storware Backup & Recovery

  ```
  sysadmin@localhost# user show list

  User list from node "localhost".
  Name        Uid   Role              Last Login From   Last Login Time            Status    Disable Date
  ---------   ---   ---------------   ---------------   ------------------------   -------   ------------                   enabled   never
  vprotect   501   admin             <unknown>         never                      enabled   never
  --
  ```
* Log in to Storware Backup & Recovery Node and set the vprotect user ID to the same as the DataDomain user. If there are multiple nodes, the ID must be changed on each of them.
  * First, make sure that no other user has this ID

    ```
    grep ":YOUR_UID:" /etc/passwd
    ```
  * If the command returns a result, it means that this UID is taken, for example:

    ```
    [root@localhost ~]# grep ":501:" /etc/passwd
    user:x:0:0:user:/user:/bin/bash
    ```
  * In this case, the ID of that user should be changed to another first, and only then ID of the vprotect user can be changed.

    If this command returns no results, it means that this ID is not taken and it is possible to change the vprotect user ID

    ```
    # Stop vprotect services
    systemctl stop vprotect-server vprotect-node

    # Change vprotect user and group ID
    usermod -u 501 vprotect
    groupmod -g 501 vprotect
    ```
* Reload permissions

  ```
  chown vprotect:vprotect -R /opt/vprotect/
  chown vprotect:vprotect -R /tmp
  chown vprotect:vprotect -R /mnt/vprotect/
  chown vprotect:vprotect -R /vprotect_data/
  # If you use a path other than /vprotect_data for staging space / backup destination, change the permissions for it as well.
  # Start vprotect services
  systemctl start vprotect-server vprotect-node
  ```


# Huawei OceanProtect

## Create DataTurbo user

1. Go to Services -> vStore Service -> vStores

   ![Create\_DT\_user\_01.png](/files/YKzyCMEYvtgFOf26zBcD)
2. Select vStore -> Create new user with role "vStore DataTurbo administrator"

   ![Create\_DT\_user\_02.png](/files/qGf4q7hFSD4XxbZvoUXT)

## Create logical port

1. Go to Services -> Network -> Logical Ports

   ![Create\_LP\_01.png](/files/CV6qdp4Ttx3Y4sErcax3)
2. Create new logical port

   ![Create\_LP\_02.png](/files/7SrDbUraqqpFa6EPp43A)
3. Settings for NFS

   ![Create\_LP\_03.png](/files/U67HjSFN37jhUK8HWpUu)
4. Settings for DataTurbo

   ![Create\_LP\_04\_DT.png](/files/oBujRFjU4iK8LSvHjgYr)

## Create Filesystem

1. Go to Services -> File Service -> File Systems

   ![Create\_FS\_01.png](/files/SE7vuJiG99D7SFs8LK9D)
2. Create new file system

   ![Create\_FS\_02.png](/files/atcvWnqh6L86rSSEnvG6)

   * Fill:
     * Name
     * Capacity
     * Application Type

   ![Create\_FS\_03.png](/files/c6MsAGrKhPhaXGr9hNIm)

   * With NFS, and DataTurbo share

   ![Create\_FS\_04.png](/files/JoQUP4J6ab5REeJDSUZU)
3. On NFS share modify settings:

   ![Create\_FS\_05.png](/files/bdqJpMmX2iLpX5tvOG8F)
4. In permissions add new client, or modify existing:

   ![Create\_FS\_06.png](/files/P9QUJFoO3yPMRQgBQzYb)

   * Client - \* , or IP of Storware node machine
   * root Permission Constraint - no\_root\_squash
5. Save settings and modify DataTurbo share:

   ![Create\_FS\_07.png](/files/B7yAtzZPq6vHJBzLNWPD)
6. In Permissions add user to share:

   ![Create\_FS\_08.png](/files/a8fKwDolKzgrS1JzGcNR)

## Mount NFS share

1. In Storware Backup & Recovery Node, mount NFS share which was created in previous step:

   ```
   mount OceanProtectIP:/Storware /vprotect_data
   ```
2. Go to the [Create File System Backup Destination](#create-file-system-backup-destination) section to learn how to create backup destination.

## Mount DataTurbo share

{% hint style="info" %}
**Note:** DataTurbo share is possible for mounting only in CentOS/Red Hat 7
{% endhint %}

1. Install DataTurbo package in Storware Backup & Recovery Node:

   ```
   unzip OceanStor_DataTurbo_1.0.0_Linux.zip
   ```

   ```
   [root@localhost ~]# unzip OceanStor_DataTurbo_1.0.0_Linux.zip
   Archive:  OceanStor_DataTurbo_1.0.0_Linux.zip
      creating: OceanStor_DataTurbo_1.0.0_Linux/
      creating: OceanStor_DataTurbo_1.0.0_Linux/doc/
   inflating: OceanStor_DataTurbo_1.0.0_Linux/install.sh  
      creating: OceanStor_DataTurbo_1.0.0_Linux/packages/
   inflating: OceanStor_DataTurbo_1.0.0_Linux/packages/oceanstor_dataturbo_1.0.0-202211151736.linux.x86_64.rpm  
   inflating: OceanStor_DataTurbo_1.0.0_Linux/upgrade.sh
   ```

   ```
   cd OceanStor_DataTurbo_1.0.0_Linux/
   chmod a+x install.sh
   ./install.sh 
   ```

   ```
   [root@localhost ~]# cd OceanStor_DataTurbo_1.0.0_Linux/
   [root@localhost OceanStor_DataTurbo_1.0.0_Linux]# chmod a+x install.sh
   [root@localhost OceanStor_DataTurbo_1.0.0_Linux]# ./install.sh 
   Preparing...                          ################################# [100%]
   CUSTOM_USER=dataturbo
   begin to create dufault user[dataturbo] and group[dataturbo] ......
   Updating / installing...
      1:dataturbo-1.0.0-202211151736     ################################# [100%]
   The DataTurbo client supports three performance levels: high, medium, and low. A higher level consumes more memory and CPU, you can use cgroup 
   command to limit the CPU usage of the DataTurbo process. The current remaining memory of the system is 4 GB. You are advised to select 
   level 1(recommended) or lower. If the level selection process stops abnormally, the recommended level will be used.
   <0>--Select Default Level. The recommended level will be used.
   <1>--Select Low Level. It is estimated that at most 4 GB memory is consumed.
   <2>--Select Medium Level. It is estimated that at most 6 GB memory is consumed.
   <3>--Select High Level. It is estimated that at most 12 GB memory is consumed.
   please input your selection:0
   your selection is [0]
   install dataturbo succeed.
   ```
2. Start DataTurbo service

   ```
   systemctl start dataturbo
   ```

   ```
   [root@localhost ~]# systemctl start dataturbo
   [root@localhost ~]# systemctl status dataturbo
   ● dataturbo.service - dataturbo
      Loaded: loaded (/usr/lib/systemd/system/dataturbo.service; enabled; vendor preset: disabled)
      Active: active (running) since śro 2023-01-25 15:32:21 CET; 4s ago
   Process: 18488 ExecStart=/opt/oceanstor/dataturbo/script/start.sh (code=exited, status=0/SUCCESS)
   Main PID: 18558 (dpc)
      Tasks: 95 (limit: 65535)
      CGroup: /system.slice/dataturbo.service
            └─18558 /opt/oceanstor/dataturbo/bin/dpc

   sty 25 15:32:20 localhost.localdomain systemd[1]: Starting dataturbo...
   sty 25 15:32:21 localhost.localdomain su[18660]: (to dataturbo) root on none
   sty 25 15:32:21 localhost.localdomain su[18751]: (to dataturbo) root on none
   sty 25 15:32:21 localhost.localdomain systemd[1]: Started dataturbo.
   ```
3. Create DataTurbo storage object, with DataTurbo user

   ```
   dataturbo create storage_object storage_name=Storware ip_list=OceanProtectIP
   ```

   ```
   [root@localhost ~]# dataturbo create storage_object storage_name=Storware ip_list=10.30.0.66
   Please input username:
   storware
   Please input password:
   ********
   Create storage object successfully.
   ```
4. Check if storage is created

   ```
   dataturbo show storage_object
   ```

   ```
   [root@localhost ~]# dataturbo show storage_object
   Storage Name:	Storware
   User        :	storware
   Ips         :	10.30.0.66
   IpPair      :
   ID	Local Address		Remote Address		Status
   ---------------------------------------------------------------
   1	10.30.1.242		10.30.0.66		Normal
   ```
5. Create mount directory, and mount DataTurbo share

   ```
   mkdir /vprotect_data
   dataturbo mount storage_object storage_name=Storware filesystem_name=/Storware mount_dir=/vprotect_data
   ```
6. Check if share is mounted:

   ```
   [root@localhost ~]# df -hT
   Filesystem              Type            Size  Used Avail Use% Mounted on
   devtmpfs                devtmpfs        2,6G     0  2,6G   0% /dev
   tmpfs                   tmpfs           2,6G  8,0K  2,6G   1% /dev/shm
   tmpfs                   tmpfs           2,6G  8,7M  2,6G   1% /run
   tmpfs                   tmpfs           2,6G     0  2,6G   0% /sys/fs/cgroup
   /dev/mapper/centos-root xfs              17G  1,7G   16G  10% /
   /dev/sda1               xfs            1014M  181M  834M  18% /boot
   tmpfs                   tmpfs           523M     0  523M   0% /run/user/0
   tmpfs                   tmpfs           523M     0  523M   0% /run/user/1000
   /Storware               fuse.dataturbo  8,0T     0  8,0T   0% /vprotect_data
   ```
7. Grant privileges for vprotect user

   ```
   chown vprotect:vprotect -R /vprotect_data
   ```

## Create File System Backup Destination

{% hint style="info" %}
**Note:** Only regular File System Backup Destination is currently available.
{% endhint %}

1. Go to **Backup Destinations.**
2. Click on **Create Backup Destination**, choose a **File system.**
3. Type the name for the new backup destination and select at least one node configuration.
4. In **Storage paths** type `/vprotect_data/backups`, where you point to a subdirectory in your staging space, where Storware Backup & Recovery will store the backups.
5. Save the configuration.


# HPE StoreOnce

## Overview

HPE StoreOnce is another product that allows you to store backups from our Storware Backup & Recovery application. As with other providers, here we can also use NFS share.

### Example

To create NFS share from the StoreOnce dashboard, after login goes to StoreOnce -> NAS -> Shares on the left side tree menu. Next, click on the "Create" button in the top right.

![](/files/L1xnQ9f5a3otRlO5yfel)

Only one change is required, the rest is optional and depends on your preferences.\
This is the "access protocol", you must select the NFS option.

![](/files/CGF5NSHDj629tQ9LRs3r)

After creating it, you'll see a summary window. (remember "Network Path")

![](/files/ZjuONUuRNC3Ezqko62Oa)

Now connect to the Storware Backup & Recovery node host:

* Create an NFS directory mount point

  `mkdir /directorypath`
* Mount NFS Share

  `mount -t nfs Storeonce_IP:/nas/sharename /mountdirectory`
* Check if you are connected with NFS Share

  `df -kh`

![](/files/731acMiyiJ4Q00Gjgu8V)

To permanently add NFS share, you must edit the /etc/fstab file\
`Storeonce_IP:/nas/sharename /mountdirectory nfs defaults 0 0`

![](/files/9nLqwcVyTvBYDppTc1Lm)

Now we can create a backup destination for our backups.\
Please log in to the Storware Backup & Recovery dashboard and go to the "Backup Destination" tab on the left side menu.\
Then choose "File system" from the list of backup destinations you can create.

![](/files/HfLI5ubdALgcm0WNwx0W)

You only need to enter the unique name of the backup destination and mount point as the storage path.

![](/files/bwYY64l0kjHlEnbmyqdK)


# Exagrid

## Overview

Storware Backup & Recovery supports integration with Exagrid. You can create two types of shares (NFS and CIFS), but in this case, we recommend using a CIFS share as the backup destination.

### Examples

To create a network share, log in to the Exagrid dashboard and go to Manage -> Shares.

![](/files/FSY9AMlIGavPqBs3s0Mb)

Then create a new share. From here, you can create an NFS or CIFS share, depending on the protocol you choose.

![](/files/tVJwFBFCS49UU3MzWXsd)

### NFS

As we said before, we do not recommend this method for storing backups, but we will describe the basic steps for creating an NFS share.

So, after clicking on "New Share" you'll see this window. Change the "Protocol" to NFS, configure the rest according to your requirements.

![](/files/IDgnkMnO2q0kktokTM5Y)

After creation, you will see a summary window with commands that allow you to mount the NFS share under the Storware Backup & Recovery node machine.

![](/files/5tX36y9Adg14iMNTWlRj)

From the menu, you can see that we have a new share.

![](/files/iAW3lMZqjM8oeBviW5cj)

It is good practice to create an NFS share access policy.

![](/files/XEbypeNXjNqegcKfdpNn)

As you can see, you can limit access to a single host or the entire address pool.\
Remember to edit the share and select Access Policy.

![](/files/7zLTr5PIcXGkNseVSYDF)

### CIFS

Now it is time for the method we recommended. After clicking "New Share" you'll see this window. Change "Protocol" to CIFS/SMB, configure the rest according to your requirements.

![](/files/Mjcw0EaP25wH12ZMyM1x)

After creation, you will see a summary window with basic information about CIFS share.

![](/files/ESGZnJJMAce5k3MxXnBn)

From the menu, you can see that we have a new share.

![](/files/EQ7PxH9HGzGolUrTFriw)

It is good practice to create a CIFS share user access policy.

![](/files/F3yo4UeW8xlWO6bOsnyx)

Select a single user or a whole group of users.

![](/files/d1rH8xXIXlbKuEXiZYDl)

### Mounting Exagrid network shares

To mount NFS share:

* Create an NFS directory mount point on the Storware Backup & Recovery node host machine `mkdir /directorypath`
* Mount NFS Share `mount -t nfs Exagrid_IP:/sharename /mountdirectory`
* Check if you are connected with NFS Share `df -kh`

To permanently add an NFS share, you must edit the /etc/fstab file\
`Exagrid_IP:/sharename /mountdirectory nfs defaults 0 0`

To mount CIFS share:

* Install the required packages `yum install cifs-utils`
* Create a mount point directory `mkdir /directorypath`
* To mount a CIFS share `mount.cifs //hostname-or-ip_address/sharename /mnt/testmnt -o ro,guest`
* To permanently add a CIFS share, you must edit the /etc/fstab file `//hostname-or-ip_address/sharename /mnt/testmnt cifs ro,guest 0 0`

### Creating a Backup Destination

Now we can create a backup destination for our backups.\
Please log in to the Storware Backup & Recovery dashboard and go to the "Backup Destination" tab on the left side menu.\
Then choose "File system" from the list of backup destinations you can create.

![](/files/HfLI5ubdALgcm0WNwx0W)

You only need to enter the unique name of the backup destination and mount point as the storage path.

![](/files/bwYY64l0kjHlEnbmyqdK)


# Neverfail HybriStor

Storware Backup & Recovery supports integration with Neverfail HybriStor. You can use HybriStor volumes like any other file system (mount a single volume over NFS).

Login to the HybriStore dashboard and create NFS share:

![](/files/PO5e23yHcKSCqZBlarGx)

In "Clients" enter your Storware Backup & Recovery node IP address and choose "No" for the "allow all clients" option:

![](/files/bAoGgvPGD83CoaNfmvAS)

Now log in to the Storware Backup & Recovery node host and mount NFS share:

```
# To create mountpoint:
mkdir /vprotect_data/backups

# To be sure of correctly set credentials:
chown -R vprotect:vprotect /vprotect_data

# For temporary mount:
mount -t nfs -o sync HybriStor_IP:/vprotect_data /vprotect_data/backups

# For persistent mount edit /etc/fstab file:
#   <file system>               <dir>             <type> <options> <dump> <pass>
HybriStor_IP:/vprotect_data /vprotect_data/backups  nfs   defaults    0     0

# To mount NFS from fstab:
mount -a
```

Now go to the dashboard and create a new File System Backup Destination.

![](/files/bwYY64l0kjHlEnbmyqdK)


# Object Storage

A backup destination is a storage location where Storware Backup & Recovery keeps VMs, Containers, Cloud, and application backup copies. Storware Backup & Recovery supports different types of object storage.

* [Alibaba Cloud OSS](/70/deployment/backup-destinations/object-storage/alibaba-cloud)
* [AWS S3 or S3-compatible](/70/deployment/backup-destinations/object-storage/aws-s3-or-s3-compatible)
* [Ceph Rados Gateway](/70/deployment/backup-destinations/object-storage/ceph-rados-gateway)
* [Cloudian S3](/70/deployment/backup-destinations/object-storage/cloudian)
* [Wasabi](/70/deployment/backup-destinations/object-storage/wasabi)
* [Google Cloud Storage](/70/deployment/backup-destinations/object-storage/google-cloud-storage)
* [IBM Cloud Object Storage](/70/deployment/backup-destinations/object-storage/ibm-cloud-object-storage)
* [Microsoft Azure Blob Storage](/70/deployment/backup-destinations/object-storage/microsoft-azure-blob-storage)
* [Nutanix Objects](/70/deployment/backup-destinations/object-storage/nutanix-objects)
* [OpenStack SWIFT](/70/deployment/backup-destinations/object-storage/openstack-swift)
* [Oracle Cloud Infrastructure Object Storage](/70/deployment/backup-destinations/object-storage/oracle-cloud-infrastructure-object-storage)
* [Scality RING](/70/deployment/backup-destinations/object-storage/scality-ring)


# Alibaba Cloud OSS

## Overview

Alibaba Cloud is an S3-compatible backup provider. Configuration as a backup destination is similar to AWS S3.

## Example

After logging in, go to the Object Storage Service and create a new bucket.

![](/files/6nY64PpdHPeyKYOLDhdx)

Provide necessary details for your bucket and enable versioning.

![](/files/F9ixkj7VKzElQWEU16QW)

Next, go to Manage AccessKey Management and create new AccessKey

![](/files/33e1Xt8xzDzDW33i0MIn)

Now go to the Backup destination tab on the Storware Backup & Recovery dashboard and change the sub-tab to object storage. Provide the bucket name and key credentials, and then configure the remaining options according to your requirements:

![](/files/CLKsDgvz4ZUVSzkH9JyZ)


# AWS S3 or S3-compatible

## Overview

Storware Backup & Recovery can store backups in AWS S3 or S3-compatible backup providers. In most cases, you just need to prepare a bucket (with versioning enabled if possible) and generate an access/secret key for Storware Backup & Recovery. Storware Backup & Recovery can be installed in AWS (if EC2 backup is used), but in most cases, S3 is used just as a cloud backup provider for on-prem environments.

Typical use cases are:

* When AWS is used - choose a single bucket with **versioning enabled** - all backup objects will have names in `/container_name/path/to/backup` format, where `container_name` typically is the VM name with an identifier.
* When a 3rd party is used - you need to verify:
  * Which strategy is supported by the vendor - i.e. Scality requires a single bucket without versioning.
  * When timestamp recording of the object should occur - i.e. Scality does it after data is stored (unlike AWS).

Storware Backup & Recovery also support **encryption**. It uses server-side encryption with customer-provided encryption keys (SSE-C). Once enabled, new data is stored as encrypted with keys generated and kept by Storware Backup & Recovery. For performance improvements, we also recommend using AWS Direct Connect to access S3. Otherwise, backups would be sent over the Internet, which could result in poor performance.

{% hint style="info" %}
**Note:** S3 has a **limit of 5TB** per object. This means that depending on the virtualization platform and backup format used by export/import mode you may have a limit of 5TB per VM (if it is Proxmox VMA or Citrix XVA image-based backup) or per VM disk (in most cases). Bigger files are currently not supported.
{% endhint %}

### Permissions

Depending on the selected mode, you may have different permission sets. For a single bucket, you need to use the access keys of a user that has the ability to control objects within the bucket over the specific bucket - here is an example of IAM policy:

```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1568968204280",
      "Action": [
        "s3:DeleteObject",
        "s3:DeleteObjectTagging",
        "s3:DeleteObjectVersion",
        "s3:DeleteObjectVersionTagging",
        "s3:GetBucketTagging",
        "s3:GetBucketVersioning",
        "s3:GetObject",
        "s3:GetObjectRetention",
        "s3:GetObjectTagging",
        "s3:GetObjectVersion",
        "s3:GetObjectVersionTagging",
        "s3:ListBucket",
        "s3:ListBucketVersions",
        "s3:PutObject",
        "s3:PutObjectTagging",
        "s3:PutObjectVersionTagging",
        "s3:RestoreObject"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::BACKUP_DESTINATION_BUCKET/*"
    }
  ]
}
```

You can also use a predefined role and create a user from the AWS console:\
<https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey>

{% hint style="info" %}
**Note:** It is recommended to periodically rotate your access/secret keys. More information can be found here: <https://aws.amazon.com/blogs/security/how-to-rotate-access-keys-for-iam-users/>. After changing the key in AWS, remember to update it in Storware Backup & Recovery as well.
{% endhint %}

### Bucket replication

Even though S3 is a highly available service, you may want to be prepared in case of a region failure. We recommend following this guide[ https://docs.aws.amazon.com/AmazonS3/latest/dev/replication.html](https://github.com/Storware/vprotect-manual/tree/e7b7039b975e5a518e099f05a9079b281ece5f7c/AmazonS3/latest/dev/replication.html) to set up bucket replication so that your data is replicated to another region in a worst-case scenario. Remember to point Storware Backup & Recovery to the replicated bucket in case of a disaster.

### Glacier/Deep Archive support

Starting from version 3.9 of vProtect now Storware Backup & Recovery is able to move older backups to a Glacier/Deep Archive storage tier. In the S3 backup provider settings, you need to enable the `Move old versions to other storage class` toggle and provide extended retention settings.

Keep in mind that Storware Backup & Recovery will try to restore it to S3 with an expiration set to 2 days. You'll notice that although the task is running, no progress is taking place as it is waiting for the object to be restored from Glacier to S3. This **may take several hours** as Glacier doesn't provide instant access to archival data. Once this part is completed, Storware Backup & Recovery will proceed with regular restore from a temporary S3 object.

### Costs

When storing backups in S3, additional charges will occur for stored backups. Retention setting in Storware Backup & Recovery can limit the storage costs of stored backups.

Please visit <https://aws.amazon.com/s3/pricing/> to check current AWS S3 pricing.

## Example

Now we will show you how to quickly create S3 storage and integrate it with Storware Backup & Recovery as a backup destination.\
After logging in, expand the services tab a choose S3 under the Storage section:

![](/files/IrZ14iXuKFxj2HMr6MW4)

Now create a new bucket for your backups:

![](/files/LGn5EZ4qm05wJoTijE77)

In "Configure options" activate versioning:\
(In all other tabs, you can leave the default settings)

![](/files/SuJmqoJIzl1JBM6c0GsX)

After creating a bucket, we need to create a new user with appropriate permissions:

![](/files/9fyY1NbavICYZIKkSVhf)

Remember to choose the "Programmatic access" account type:

![](/files/1DLnMoxEgJzV64GhdzCb)

From the predefined roles, you can choose "AmazonS3FullAccess" or you can create a new one as described in the Permissions section:

![](/files/3WekiT1e3hwhmwPaH1HA)

![](/files/5Zmt7p3zkAVVcDMZpvwO)

Remember to download the .csv or copy the key credentials manually:

![](/files/b7k9du3fAL0bgt80rQS4)

Now go to the Backup destination tab on the Storware Backup & Recovery dashboard and change the sub-tab to object storage. Provide the bucket name and key credentials, and then configure the remaining options according to your requirements:

![](/files/bd9pN50cuvWlFgFsXpgc)


# Ceph Rados Gateway

## Overview

Ceph Object Gateway supports a RESTful API that is compatible with the basic data access model of the Amazon S3 API. Ceph Object Gateway is an object storage interface built on top of librados to provide applications with a RESTful gateway to Ceph Storage Clusters. Ceph Object Storage supports two interfaces:

* **S3-compatible**: Provides object storage functionality with an interface that is compatible with a large subset of the Amazon S3 RESTful API.
* **Swift-compatible**: Provides object storage functionality with an interface that is compatible with a large subset of the OpenStack Swift API.

### Example

Log in to the ceph dashboard. Open Object gateway and then go to "Buckets".

![](/files/FznTLRO0ZkGbgjdY3xRp)

Then click on the "Create" button.

![](/files/WDAojVbPHPe3xaeJBTcP)

Fill in the required fields.

![](/files/ApEuFKF8w8srooKo30kl)

Now create a dedicated access account for the backup destination. Open the Users tab under the object gateway menu.

![](/files/J49ywuEGZzPllZtlkPpt)

Fill in the username field, you can leave the other settings as default.

![](/files/ZIrX7I6YDRyZpNPtQTFH)

To see the account key and secret key, expand the user details and open the keys tab, click on the key, and then on the show button.

![](/files/jyWs5Un99TJYlcvCWGLS)

The access key and secret key will be needed to create a backup destination in Storware Backup & Recovery.

![](/files/E7AGU9g5gLsgydAdTp7p)

Now we can go to the Storware Backup & Recovery Dashboard. Open the "Backup Destination" tab from the left side menu and choose "Amazon S3 / S3-compatible" as the new type of backup destination.

![](/files/CcouxeqwA9ovqy2aXpAz)

By default, Ceph provides S3 via port 8000. Also, remember to enable the "record backup time after store" option.

![](/files/rBEyGAwJ6Qzj9QaFaHku)


# Cloudian S3

## Overview

Cloudian is an S3-compatible backup provider. Configuration as the backup destination is similar to AWS S3.

## Example

After logging in, create a new bucket for your backups

![](/files/mL9GcDv1Gb3ysksvvlG8)

Next, go to security credentials and generate a new access key.

![](/files/iMAoMoMQQvbC5Mo96yDB)

Now go to the Backup destination tab on the Storware Backup & Recovery dashboard and change the sub-tab to object storage. Provide the bucket name and key credentials, and then configure the remaining options according to your requirements. Also, enable `Path style access enabled` option:

![](/files/ESVRGkNrweu80tLiQ03H)


# Wasabi

## Overview

Wasabi is an S3-compatible backup provider. Configuration as the backup destination is similar to AWS S3.

## How to use Storware Backup and Recovery with Wasabi.

1\. Make sure you have the necessary data to enter in Storware Backup and Recovery.

2\. We will require you to provide:

* Service URLs
* Bucket name
* Region

3\. If you do not have this information you will need to:

* Log in to <https://console.wasabisys.com/>.
* Create a new bucket.

![](/files/WZQQ8VGVSP7UjKMkPEeS)

* Enter your bucket name.
* Select a region.
* On the second tab, you can choose versioning within the bucket, login, and protect your bucket with object locking (a function used to protect against ransom attacks)

![](/files/XhpnSPGEDrdKFHxdxkvq)

* Save your configuration.
* Then you need to generate an Access Key and a Secret key.

![](/files/Ffb02ITV2hYlcDnclicz)

* For the service URL please use that website: <https://wasabi-support.zendesk.com/hc/en-us/articles/360015106031-What-are-the-service-URLs-for-Wasabi-s-different-storage-regions->

4\. Log in to Storware Backup and Recovery WebUI.

5\. Go into Backup destination -> Object Storage -> Create Backup Destination - Amazon S3 / S3-compatible.

![](/files/o2wi2DPMEQZoevf1MUVQ)

6\. Name Your Backup destination.

7\. Select a proper node-configuration.

![](/files/GDxQ7eQ8ggG7mOYhppNz)

8\. In AMAZON S3 / S3-COMPATIBLE SETTINGS provide information about your bucket.

![](/files/Hp2Qmv9wJ3m6XEq22d62)

9\. Make sure options Path style access enabled and Parallel Download enabled are enabled.

10\. Provide Access key and Secret key.

![](/files/CotD5x3W7Prr6Z8aRbgX)

11\. Save a configuration.


# Google Cloud Storage

**Google Cloud Storage** allows data to be stored and accessed on Google Cloud Platform infrastructure. It combines the performance and scalability of Google's cloud with advanced security and sharing capabilities.

## How to use **GCS** as a backup destination for Storware Backup & Recovery:

1. Create a project: Click [here](https://cloud.google.com/resource-manager/docs/creating-managing-projects) for more info about **Creating and Managing Projects**.
2. Create a bucket: Click [here](https://cloud.google.com/storage/docs/creating-buckets) for more info about **Creating Storage Buckets**.

   ![](/files/D0iFCnMUkPfNSclpZTkN)
3. Enable versioning in your bucket: Click [here](https://cloud.google.com/storage/docs/using-object-versioning#gsutil) for more info about **Enabling Object Versioning**.
4. Generate a service account key: Click [here](https://cloud.google.com/iam/docs/creating-managing-service-account-keys) for more info about **Creating service account keys**. The service account key should have the **Role** set to **Storage Admin and Service Usage Consumer**.

   ![](/files/s6qSNwqVOzWDs6Euoy6O)

   ![](/files/XY7Ni5v7Bx298gMci2uQ)

   ![](/files/sfvFXadFHA3QRyMH4Xux)

   You can leave the third tab - Grant users access to this service account (optional).\
   To generate an account key, click on the "three-dot" button next to your service account and then click on "create key".\
   You should then see the window below - click on create to download the JSON file. You'll need its content in the last step.

   ![](/files/luYC1Ie1KagWxQYxBsDd)
5. After the key is created, open your Storware Backup & Recovery Web UI (you can also use **CLI**), click on **BACKUP DESTINATIONS**, then on the **Create Backup Destination** button, and then select **Google Cloud Storage** from the drop-down list. In addition to the standard properties, you need to specify:
6. The **Bucket name** was specified during bucket creation.
7. The **Service account key** - paste the content of the service account key .json file created before.

![](/files/XaLDfknyAeXdedFwjifv)

![](/files/6fr7VQ9lqG7o3cXNdPPl)

Now you can store Storware Backup & Recovery backups on Google Cloud Storage.


# IBM Cloud Object Storage

## Overview

*IBM Cloud Object Storage is a push-button deployed cloud storage service and is available in IBM Cloud global data centers. It offers leading data protection, high durability, and fast access to your data. You can use it to store and protect data with easy-to-use management features to organize your data and to configure finely-tuned access controls.*

### Example

Log in to your IBM Cloud account. On the main dashboard, you will see the "Create a resource" button - Click on it.

![](/files/suMr07wcXBLqcliDA60d)

On the next screen, search for a resource named "Object Storage" and click on it.

![](/files/PNQEbEiieYm6Y6JFcpoT)

On the next screen, you can choose piercing plans, etc. Please select the options according to your requirements.

![](/files/h6Va22eovOsqPjnLqsgo)

After creating a storage resource we need to create a bucket.

![](/files/Fba1bI2sYl2qt9OZUNbo)

You can choose predefined templates or select the option to create a bucket with your own settings. In this example, we will choose "Custom bucket".

![](/files/6OP00gyiYLOFzJKsBbNF)

Storware Backup & Recovery has no special requirements for the bucket, all options can be configured according to customer needs.

![](/files/Xs74wQW9a477s1HCe1Ew)

After creating the bucket, you'll see the objects page. From the menu on the left select the configuration tab. You will see a summary of the resource you have created. To create a backup destination you will need the ***"public" address from the endpoints section*** from here.

![](/files/D6pg0kuJk6oeM1cbuBUr)

We are almost done here, now we need to create API access and a secret key. Go to "Service credentials" on the left side menu then create new credentials using the blue button on the right.

![](/files/0VCFp4MiEGrZe8mms2LI)

There are two important options on this screen. You must select the appropriate role (for Storware Backup & Recovery it is the "Writer" role) and select the option "Include HMAC credential".

![](/files/mGLYQ0fH1UaiqEW3N4jd)

Now expand the detailed information about the created credentials by clicking on the arrow next to the name. What we need is "access\_key\_id" and "secret\_access\_key".

![](/files/WLAxM8fDX4zQPD53snMM)

Now we can log in to the Storware Backup & Recovery Dashboard and create a backup destination. Please go to the backup destination tab on the left side menu and then choose "Amazon S3 / S3-compatible".

![](/files/LhHZudNOefl6y6i9Vj9c)

As IBM cloud storage is compatible with Amazon-S3, many settings will be very similar. However, remember to enter the API URL (remember about "https\://" at the beginning), select the "Record backup time after store" option, and enter the region.

![](/files/TPtDGQ8AMTXHRH0OEerf)


# Microsoft Azure Blob Storage

Storware Backup & Recovery supports integration with MS Azure Blob Storage. An Azure storage account contains all of your Azure Storage data objects: blobs, files, queues, tables, and disks. The storage account provides a unique namespace for your Azure Storage data that is accessible from anywhere in the world over HTTP or HTTPS. If you don't already know Azure Blob storage, please read this great documentation <https://docs.microsoft.com/en-gb/azure/storage/blobs/>.

![](/files/dwR7fmh4suDe8hRjXqK3)

To configure Azure as a backup destination for Storware Backup & Recovery, we just need:

* The storage account name
* One of the account keys

![](/files/je4jUD3fco4bNy9Yh1Cl)

Now you can go to the backup destinations tab in Storware Backup & Recovery and create a new Microsoft Azure backup destination.

![](/files/LhHZudNOefl6y6i9Vj9c)

You just need to provide an account name, bucket name and key.

![](/files/tIwjaLAKP5c8FNpu7Kf0)

And that's all. As you see, in a few minutes you can integrate Storware Backup & Recovery with Azure Blob storage to securely store your backups


# Nutanix Objects

Nutanix Objects is an S3-compatible backup provider. Configuration as the backup destination is similar to AWS S3.

## Example

In the Storware Backup & Recovery system, go to the `Backup Destinations` -> `Object Storage` tab, then press the `Create Backup Destination` button and select the `Amazon S3 / S3-compatible` option.

In this step, complete the name, retention, add: API URL, Access key, and Secret key, indicate the name of the bucket to be used.

Then go to the `AMAZON S3/S3-COMPATIBLE SETTINGS` the segment in which you should **deselect** the `Parallel Download enabled` option for Nutanix Objects.

![](/files/11T9H8VaYSQ0g1bGUH30)

{% hint style="info" %}
When using Nutanix Objects version 3.5, the region "us-east-1" may be required.
{% endhint %}

After entering the settings, press the `Save` button to be able to use Nutanix Objects as Backup Destination.


# OpenStack SWIFT

Storware Backup & Recovery supports integration with OpenStack SWIFT.

## Example

In the Storware Backup & Recovery system, go to the `Backup Destinations` -> `Object Storage` tab, then press the `Create Backup Destination` button and select the `OpenStack Swift` option.

Enter the name of the new backup destination, assign it to `Node Configuration` and set up the retention.

Next, provide settings specific to `OpenStack Swift`:

* Authentication URL - URL pointing to authentication service, it should be similar to the following

  ```
  https://SWIFT_HOST:5000/v3/auth/tokens
  ```
* User name - domain formatted username used by Storware Backup & Recovery to log into OpenStack Swift
* Authentication method - BASIC / TEMPAUTH / KEYSTONE / KEYSTONE\_V3
  * in the case of KEYSTONE\_V3 authentication method, you also need to enter `Authentication method scope`, `Domain` and `Project`
* Name of Swift service intended to be used
* Number of thread used (Swift connector supports multithreading)
* Endpoint interface type - type of interface used by connector (PUBLIC / INTERNAL / ADMIN)

![](/files/sRHr44y3GxqCXUMVPCs1)


# Oracle Cloud Infrastructure Object Storage

## Overview

*The Oracle Cloud Infrastructure Object Storage service is an internet-scale, high-performance storage platform that offers reliable and cost-efficient data durability. The Object Storage service can store an unlimited amount of unstructured data of any content type, including analytic data and rich content.*

### Example

Log in to the Oracle cloud dashboard, expand the left side menu and go to the Object Storage tab.

![](/files/i5zppNP7ysCgkMbv24Q2)

Now let's create a new bucket.

![](/files/F9W5K1oFelEOcWcFRXXM)

We do not require specific bucket settings for Storware Backup & Recovery. The bucket name will be needed when we want to create a backup destination in Storware Backup & Recovery.

![](/files/Q5L37PS7VO4kEpn78XNR)

After creating the bucket, you'll see a list of buckets. Click on the name to view the details of the object. Remember the "namespace", we also need it when creating a backup destination.

![](/files/LmK9DK5TR3qlYOAHlSO7)

Now we need to create a user that we will use to authenticate our backup destination. Please go to the Users tab under the Identity tab in the menu on the left.

![](/files/WhHOki5t6jrB5UCOmyih)

Now create a new user.

![](/files/3Wc0BFj1mfT7kmi47aBR)

Fill in the required fields.

![](/files/X5dzvii03cHzuLMZN6sc)

Then go to the Groups page, which you can also find under the identity tab in the left side menu.

![](/files/oTNDv2TiaSN5MRX86wYW)

Now click on the existing group "Administrators".

![](/files/fntZjc9emuaOEQWT717h)

Now click on "Add User to Group" and choose the user you created previously.

![](/files/YGZCkP41tgd1WxDMTQrA)

Go back to the Users page and go to the details page of our user.

![](/files/EHPYiwEPOse4ATHI3wrV)

Scroll down and open the "Customer Secret Keys" tab. Click on "Generate Secret Key".

![](/files/mI0XIYHBkLPLzChBbQGi)

Enter any name.

![](/files/jbje2xio1KzSZ1eQuRsx)

As you see in the note below, copy and save the secret key because you can only do this now.

![](/files/V8D3U6RRvNubSqAdkBlg)

After generating the secret key, you can view the access key, just move the mouse over it.

![](/files/cPT9YNDEBxKkNsAowcMF)

Now we can go to the Storware Backup & Recovery Dashboard. Open the "Backup Destination" tab from the left side menu, then the sub-tab "Object Storage" and choose "Amazon S3 / S3-compatible" as the new type of backup destination.

![](/files/CcouxeqwA9ovqy2aXpAz)

First, let's focus on the "S3-Compatible" section.\
To generate an API URL, you will need this site: <https://docs.cloud.oracle.com/en-us/iaas/api/#/en/s3objectstorage/20160918/>\
As We mentioned earlier, you will need an object storage namespace (choose the API URL from the list according to your region).\
Then provide your bucket name and region, and finally switch on "Record time after backup" and "Path style access enabled".\
Configure the rest of the settings as desired.

![](/files/xifMh2AKtkj9fkEcZxR4)


# Scality RING

## Overview

*Scality Ring offers an object storage solution with a native and comprehensive S3 interface. Scality S3 Connector is the first AWS S3-compatible object storage for enterprise S3 applications with secure multi-tenancy and high performance.*\
*AWS has achieved incredible traction with services such as S3 for a wide variety of cloud application and service provider businesses. However, for many service providers and enterprise corporations who require an on-premises deployment model in order to maintain control over sensitive data, for performance optimization, or for reasons of security or compliance –* [*Scality’s new S3 Connector*](https://www.scality.com/ring-s3-connector/) *for the RING provides an optimal solution. The S3 Connector offers a solution that is application-compatible with AWS S3 at both the data API level and also with the rapidly evolving* [*AWS multi-tenancy model termed IAM*](https://aws.amazon.com/iam/?sc_channel=PS\&sc_campaign=acquisition_US\&sc_publisher=google\&sc_medium=iam_b_test_q32016\&sc_content=aws_iam_e\&sc_detail=aws%20iam\&sc_category=iam\&sc_segment=105093067122\&sc_matchtype=e\&sc_country=US\&s_kwcid=AL!4422!3!105093067122!e!!g!!aws%20iam\&ef_id=V75hMAAAATJKuR0S:20160901212902:s) *(Identity and Access Management).*

### Example

In this example, we will show you how to use the Scality S3 connector to create the backup destination for Storware Backup & Recovery.\
*It assumes that the S3 connector is installed and configured*

We will start by creating a user, please launch the S3 connector user interface.

![](/files/c1EU5FVXva7QMpMBM5yp)

Log in as an account user using the password set in *Setting an account Password* from the S3 console GUI.\
Select the user to open the user management window.\
Click Add user to open the add user window.\
Enter the user name and make sure to check the box for "FullAccessGroup".

![](/files/UHArvtPWgktlZX6FUHg7)

The user management panel displays the user name and the Amazon Resource Name (ARN).\
Now we will generate the access and secret keys for the user.\
Click on the key icon in the Actions column of the user row.

![](/files/lZRJNDh30xqATPHlKevk)

Click on Generate a new key.

![](/files/bQwox1n2Ut8cxDvfPgYK)

Click on Proceed to generate the user's AccessKey and SecretAccessKey.

![](/files/z3rjnVErIall04XC5tbs)

Copy and save the SecretAccessKey to a secure location. It is not shown again and cannot be recovered later.

![](/files/5XnsfK9GjDMQJXnqcRM8)

Now we can go to bucket creation. Please go to the S3 Browser interface.

![](/files/hbBaG4HNjT4faJ6Z03Ta)

The S3 Browser opens the main window, from which one can see the entire roster of buckets.\
Click the Create Bucket button in the top left of the main window.

![](/files/MLA7vu0gAsfCkcvxGJSK)

Enter a name for the new bucket and click on Create button.

![](/files/e7eeHl9uppcKDULhT842)

That's all on the Scality side. Now we can go to Storware Backup & Recovery.\
Open the "Backup Destination" tab from the left side menu and choose "Amazon S3 / S3-compatible" as the new type of backup destination.

![](/files/CcouxeqwA9ovqy2aXpAz)

Like in other S3-compatible backup destinations, you have to fill in the fields below and provide the access and secret key.

![](/files/fgVq2k7wHkLZ5YWVb1iM)

That's it, you can now safely store your backups.


# Enterprise Backup Providers

This section presents the key steps necessary for configuring integration with enterprise backup providers as your backup destination. In this scenario, Storware Backup & Recovery works as a Proxy VM, providing backup & recovery for the vendors below:

* [Dell EMC Avamar](/70/deployment/backup-destinations/enterprise-backup-providers/dell-emc-avamar)
* [Dell EMC Networker](/70/deployment/backup-destinations/enterprise-backup-providers/dell-emc-networker)
* [IBM Spectrum Protect](/70/deployment/backup-destinations/enterprise-backup-providers/ibm-spectrum-protect)
* [Micro Focus Data Protector](/70/deployment/backup-destinations/enterprise-backup-providers/micro-focus-data-protector)
* [Veritas Netbackup](/70/deployment/backup-destinations/enterprise-backup-providers/veritas-netbackup)


# Dell EMC Avamar

To integrate Storware Backup & Recovery with Dell EMC Avamar, complete the following on **Storware Backup & Recovery Node**:

1. Download the required software:
   * **mccli**
   * Avamar Linux Client
   * **Pubkey** (\*.pub + sh)

You can obtain the above by browsing the downloads section of your Avamar server installation, provided you have installed 'UpgradeClientDownloads" from the EMC repository to the Avamar server. When in doubt, consult the Avamar documentation.

![](/files/vjvhUbnYWVmC0FfdKEfR)

![](/files/8mmiDSI4pSadF16RYnqy)

1. Import the GPG key by invoking the script:

```
sh import_avpkgkey.sh
```

1. Run avregister and fill in the required info.

```
# /usr/local/avamar/bin/avregister

=== Client Registration and Activation
This script will register and activate the client with the Administrator server.

Enter the Administrator server address (DNS text name or numeric IP address, DNS name preferred): <your_Avamar_server_address>

Enter the Avamar server domain [clients]:
avagent.d Info: Stopping Avamar Client Agent (avagent)...
avagent.d Info: Client Agent stopped.                      [  OK  ]
avagent Info <5008>: Logging to /usr/local/avamar/var/avagent.log
avagent.d Info: Client activated successfully.             [  OK  ]
avagent.d Info: Client Agent service started in systemd    [  OK  ]
avagent Info <5008>: Logging to /usr/local/avamar/var/avagent.log
avagent Info <5417>: daemonized as process id 17479
avagent.d Info: Client Agent started.                      [  OK  ]
avagent.d Info: Stopping Avamar Client Agent (avagent)...
avagent.d Info: Client Agent stopped.                      [  OK  ]
Registration Complete.
```

1. Install the ***Management Console Command Line Interface*** (mccli).

```
# rpm -Uvh --force dpnmccli-19.2.0-155.rhel_64.x86_64.rpm
Preparing...                          ################################# [100%]
Updating / installing...
  1:dpnmccli-19.2.0-155              ################################# [100%
```

**Note:** please change the RPM name to match the file downloaded from your Avamar installation.

1. Run ***avsetup\_mccli*** to configure the management console.

You need to point mccli to your JRE installation, fill in the connection details, and provide the admin username and password.

```
# /usr/local/avamar/19.2.0-155/bin/avsetup_mccli
setting linux default
ls: cannot access /usr/java/latest: No such file or directory
Enter the location of your JRE (1.8) installation []: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-0.el7_7.x86_64/jre
Enter the root directory of your Avamar installation [/usr/local/avamar/19.2.0-155]:
Enter the user data directory of your Avamar installation [~/.avamardata/19.2.0-155/var]:

Configuring default local mcsprofile in /usr/local/avamar/19.2.0-155/lib/mcclimcs.xml

Enter default mcs host name (mcsaddr) [localhost]: 
Enter default mcs port number on localhost (mcsport) [7778]:
Enter default userid on localhost (mcsuserid) [MCUser]: root
Enter password for root (mcspasswd): adminuserpass

       Avamar CLI 19.2.0 has been configured correctly
       Type mccli command to use it
```

Quickly test the correctness of this config by typing in:

```
# /usr/local/avamar/19.2.0-155/bin/mccli activity show
```

If the output shows the latest activity on Avamar, everything is OK.

Otherwise, check your config and/or Avamar documentation,

1. Install **avtar** - <https://www.dellemc.com/en-us/collaterals/unauth/technical-guides-support-information/products/data-protection/docu91839.pdf> - page 16.
2. Use the `avregister` command to register the backup client.
3. Install **mccli** - <https://www.dellemc.com/en-us/collaterals/unauth/quick-reference-guides/products/data-protection/docu91838.pdf> - page 18.
4. Use `avsetup_mccli` to set up the client.
   * **When choosing JRE - do NOT use** `/usr/java/latest` but `/usr/java/jre1.8...`
5. Proceed with the configuration and add a ***backup destination.***

On the left side menu, click on ***Backup Destinations***, then change to the ***enterprise*** sub-tab, click on the ***Create Backup Destination*** button and choose:

![](/files/LRawxDrAPjpFutDTIXwR)

Fill in the required info. It may look similar to the example below:

![](/files/O5Rk8Mx2ky4S3GfKB6pR)


# Dell EMC Networker

1. To enable Dell-EMC Networker support, please install NetWorker Client as follows:

   ```
   yum install lgtoxtdclnt-9.1.0.2-1.x86_64.rpm lgtoclnt-9.1.0.2-1.x86_64.rpm
   ```
2. Register the client on the Networker server. More information about the installation and configuration of the Networker client can be found in the [Networker documentation](https://www.dellemc.com/fr-mg/collaterals/unauth/technical-guides-support-information/products/storage-5/docu81532.pdf).
3. Log in to Storware Backup & Recovery and go to "Backup Destinations". Click on "Create Backup Destination" and choose "Dell EMC NetWorker". Type the name for the new backup destination and set the retention. Enter the Networker client name and the Server address.

![](/files/aAhXhgjjjewoMyTTAj7X)

**Note:** Add the Storware Backup & Recovery user to the group "Application Administrators" to enable Storware Backup & Recovery to delete backups from the Networker server.


# IBM Spectrum Protect

1. Register the ISP node on your ISP server.
   * Log in to your ISP server and prepare a policy set for Storware Backup & Recovery backups.

     ```
      Def dom vprotect
      Def pol vprotect vprotect
      Def mgmt vprotect vprotect vprotect
      Def co vprotect vprotect vprotect dest=<StoragePoolName> vere=nolimit verd=nolimit rete=nolimit reto=nolimit
      Assign defmgmt vprotect vprotect vprotect
      Activate pol vprotect vprotect
     ```
   * Register the node on the ISP server:

     ```
     register node vprotect_proxy <SecretPassword> dom=<VMdomain> maxnummp=10 passe=0 dedup=cli backdel=yes
     ```
2. Use a script to automatically download and install the ISP API and client.

   ```
   /opt/vprotect/scripts/setup_isp.sh
   ```

{% hint style="warning" %}
Make sure to type the IP address of your ISP server, TCP port, and node name correctly. For example:
{% endhint %}

![](/files/A0tw5OX0vOZqk3rRR7X2)

3. Next step is to set up the Backup Destination in our UI.

   * Go to **Backup Destination** and select **Enterprise**
   * Now you can add IBM Spectrum Protect Backup Destination

   ![](/files/AttUUGsdj2CEFQK1zOzC)

   * Type name and attach Backup Destination to Node Configuration. You also need to set:
     * path to dsm.opt file (Default is `/opt/tivoli/tsm/client/api/bin64/dsm.opt`), where are saved information of IBM Spectrum Protect Nodes,
     * name of IBM Spectrum Protect Node,
     * password to ISP node.


# Micro Focus Data Protector

To integrate Storware Backup & Recovery with Micro Focus Data Protector, list device names by running following command on Storware Backup & Recovery Node:

```
[root@protectorvp ~]# /opt/omni/bin/omnidownload -list_devices

Device Name                      Host                                                             Device Type                          Pool Name
=======================================================================================================================================================================
dyskd_gw1                        win-srv-proxy                                                    Backup To Disk StoreOnce software de dyskd_MediaPool                 
vp_gw2                           protector11.storware.local                                       Backup To Disk StoreOnce software de vp_MediaPool                    
vp_protectorstorware_gw1         protectorstorware.storware.local                                 Backup To Disk StoreOnce software de vp_protectorstorware_MediaPool  
vp_protectorvp_gw1               protectorvp.storware.local                                       Backup To Disk StoreOnce software de vp_protectorvp_MediaPool        
=======================================================================================================================================================================
```

Next, go to Storware Backup & Recovery and go to `Backup Destinations` -> `Enterprise`. Clik `Create Backup destination` and choose `Micro Focus Data Protector`. Type the name for new backup destination and provide `Device name` which you get from first step.

![](/files/CV9VNHDwinGj0KEqYmdL)


# Veritas NetBackup

* Before we start, you have to generate a token for the clients.
* To do this, please log in to the Netbackup Administration Console:

![](/files/eG1oN1hB8QJHwrwvPjJE)

* After successful login, please click on the “Token Management” submenu under “Certificate Management”. Next, click the right mouse button on the empty space and select “New Token…”.

![](/files/xabknM8eGLMvOQK1yIHV)

* The next step is to generate a token:

![](/files/yRaPTbsFpuhWOm5pleQQ)

* Now we must copy the token to the clipboard before we start the installation of the client software.

![](/files/YyafpBTan7boHvb99CzV)

* To enable Veritas NetBackup support, please download and install Veritas NetBackup Client:
* Download the CLIENTS1 package for UNIX clients or the CLIENTS2 package for Linux clients to a system with sufficient space.

![](/files/DmKbZ05tSqaHKa6SClqG)

* Extract the contents of the CLIENTS1 or the CLIENTS2 file.

```
Example:
     AIX         gunzip NetBackup_8.x_CLIENTS1.tar.gz; tar - xvf NetBackup_8.x_CLIENTS1.tar
     HP-UX        gunzip -dc NetBackup_8.x_CLIENTS1.tar.gz | tar -xvf
     Linux        tar -xzvf NetBackup_8.x_CLIENTS2.tar.gz
     Solaris        tar -xzvf NetBackup_8.x_CLIENTS1.tar.gz
```

* Change to the directory for your desired operating system.

```
 Example:
     AIX, HP-UX, Solaris, Solaris SPARC    cd [path_to_downloaded_tar.gz file]/NetBackup_8.x_CLIENTS1
     Linux, Linux - s390x            cd [path_to_downloaded_tar.gz file]/NetBackup_8.x_CLIENTS2
```

* Type ./install and answer the questions as follows
* When the following message appears, press Enter to continue:

![](/files/F4jGWMuJWKF5wfspdWFc)

The client binaries represent the operating system versions where the binaries were compiled. The binaries typically function perfectly on later versions of the operating system. The installation procedure attempts to load the appropriate binaries for your system. If the script does not recognize the local operating system, it presents choices.

* Type y and press Enter to continue with the software installation.
* Type the FQDN name of your NetBackup master server (for example NetBackup.organization.local) and press Enter to continue.
* Confirm the NetBackup client name and press Enter to continue.
* (Conditional) Enter one or more media servers if prompted
* After you confirm you want to continue, the installer fetches the authority certificate details.

**Note:** Be aware that if you press Ctrl+C, this action requires you to rerun the installation or continue with the installation without the required security components. If these security components are absent, backups and restores fail.

* When prompted, review the fingerprint information and confirm that it is accurate.

![](/files/sfKeT4yO8AYaTAwiNegx)

* After you have confirmed the fingerprint information, the installer stores the authority certificate details.

**Note:** Be aware that if you press Ctrl+C, this action requires you to rerun the installation or continue with the installation without the required security components. If these security components are absent, backups and restores fail.

* After the authority certificate is stored, the installer fetches the host certificate.

**Note:** Be aware that if you press Ctrl+C, this action requires you to rerun the installation or continue with the installation without the required security components. If these security components are absent, backups and restores fail.

* (Conditional) If prompted for the Authorization Token, please enter it.

![](/files/eLSYxxfjNiKKIbv4dsNX)

The token format is 16 upper case letters. Be aware that if you press Ctrl+C, this action requires you to rerun the installation or continue with the installation without the required security components. If these security components are absent, backups and restores fail.

* This is the last question. Next, the setup will carry out some operations, after which it will finish its work and exit.

![](/files/vNidM0NMN30lk7tci2Jk)

* Once we have finished the installation of the client software, we need to modify the firewall service to allow two-way communication between the server and our client. We need to allow input communication on ports 13724/tcp, 13724/udp, 1556/tcp and 1556/udp. To do this, enter the commands as below:
* First, we need to know what our default zone is:

```
firewall-cmd --get-default-zone
```

```
[root@vpro43-vmware ~]# firewall-cmd --get-default-zone
public
```

```
firewall-cmd --get-active-zones
```

```
[root@vpro43-vmware ~]# firewall-cmd --get-active-zones
public
  interfaces: ens192
```

```
firewall-cmd --list-all
```

```
[root@vpro43-vmware ~]# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens192
  sources: 
  services: cockpit dhcpv6-client iscsi-target mountd nfs rpc-bind ssh
  ports: 8181/tcp 16001-16999/tcp 8080/tcp
  protocols: 
  forward: no
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 
	rule family="ipv4" forward-port port="443" protocol="tcp" to-port="8181"
```

* As we can see, there is no permission for these ports, so we need to open them and restart the firewall.

```
firewall-cmd --zone=public --permanent --add-port=13724/tcp && firewall-cmd --zone=public --permanent --add-port=13724/udp

firewall-cmd --zone=public --permanent --add-port=1556/tcp && firewall-cmd --zone=public --permanent --add-port=1556/udp

firewall-cmd --complete-reload
```

* Now we can check the status of our firewall:

```
firewall-cmd --zone=public --permanent --list-ports && firewall-cmd --list-all
```

```
[root@vpro43-vmware ~]# firewall-cmd --zone=public --permanent --list-ports && firewall-cmd --list-all
1556/tcp 8080/tcp 8181/tcp 13724/tcp 16001-16999/tcp 1556/udp 13724/udp
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens192
  sources: 
  services: cockpit dhcpv6-client iscsi-target mountd nfs rpc-bind ssh
  ports: 8181/tcp 16001-16999/tcp 8080/tcp 13724/tcp 13724/udp 1556/tcp 1556/udp
  protocols: 
  forward: no
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 
	rule family="ipv4" forward-port port="443" protocol="tcp" to-port="8181"
```

* The last action is to bind the port to the NetBackup client "deamon bpnd”. To do this, type the following command in the terminal.

```
/usr/openv/netbackup/bin/bpcd -port 13724
```

* To add a new client, we need to create a policy rule for it where we will configure the type and schedule of this client backup. The client will be added automatically after the creator finishes.

Add a new Policy:

![](/files/OZ8TEgYMBMNtd69iQtJC)

![](/files/7RfoVdmtxdZcWcYct7LP)

![](/files/gG9JQTFfoXEls2P5uIaX)

* Select the type of machine to back up:

![](/files/IDELi68nGXUYczJ1509W)

![](/files/qUjxL0WC0BsbSWnpsyzK)

* Add the client to back up:

![](/files/e7eBBdBcZvD82HuJ2cDK)

![](/files/kKEpqY9MNuYnmTLkeNXU)

![](/files/KZJA34fWTsR8qLcncMmx)

* Set up the configuration details according to your requirements:

![](/files/G2mcSKlUoK8qEqZCwb7L)

![](/files/HQBvDCraE67tomnQ68lB)

![](/files/8YqmKKl3vEuCRlUySSuZ)

![](/files/ix0ibL9ZPJ9pYp6urJcQ)

* We now have the client connected to the server.

![](/files/qJYEIE8Z5tCMTIgWLFpk)

* Allow manual backup for the Storware Backup & Recovery node client on the Netbackup server.
* Log in to Storware Backup & Recovery, go to "Backup Destinations" and select the "enterprise" sub-tab. Click on "Create Backup Destination" and choose "Veritas Netbackup". Type the name for the new backup destination, client home path, and real export path. Finally, set the Netbackup parameters:

Client home path\
Real export path\
Policy Name\
Schedule name\
Client name

![](/files/ID9IotgFqVVDMKkDkEaD)


# Tape Pools

Storware Backup & Recovery provides tape libraries support. The tape storage provides a scalable and easy to configure storage solution.

From the main administrative console you can manage all operations on libraries and tapes, such as:

* Managing tape libraries
* Managing tape drives
* Managing tapes
  * Browse
  * Delete
  * Editing barcode
  * Assign them to offsite location

## Create a Tape Manager

### Prerequisites

Before creating Tape Manager in Storware Backup & Recovery you need to install Tape Manager service on machine with tape library. You can download Tape Manager RPM file from [Storware Repository](https://repo.storware.eu/storware/current/).

Example:

```
rpm -ivh sbr-tape-manager-x.x.x-x.el8.x86_64.rpm 
```

Tape Manager service by default runs on ports 8686 (HTTP) and 8787 (HTTPS).

### Udev configuration

For correct discover tape library and drives, is required to configure udev rule. Tape drives order in udev should be the same as drives order in the tape library.

#### 1. Display wwid of all devices in system

Display first 10 devices by command:

```
for i in {1..10}; do udevadm info -a -p $(udevadm info -q path -n /dev/sg$i) | grep wwid; done
```

Example output:

```
ATTRS{wwid}=="naa.61866da058dd2c002810433a0a94e18c"
ATTRS{wwid}=="t10.IBM     ULT3580-TD6     10WT036783"
ATTRS{wwid}=="t10.IBM     3573-TL         00L4U78W3142_LL0"
ATTRS{wwid}=="t10.IBM     ULT3580-TD6     90WT064679"
ATTRS{wwid}=="t10.IBM     3573-TL         00L4U78W3142_LL0"
```

I have here 2 tape drives, and one changer visible by two paths.

#### 2. Create udev rules

To make persistent names for my tape devices I need create udev rules. Create a file `/etc/udev/rules.d/sbr.rules` with content:

```
KERNEL=="sg*", ATTRS{wwid}=="t10.IBM     ULT3580-TD6     10WT036783", MODE="0666", SYMLINK="sbr/Library0_Drive0"
KERNEL=="sg*", ATTRS{wwid}=="t10.IBM     ULT3580-TD6     90WT064679", MODE="0666", SYMLINK="sbr/Library0_Drive1"
KERNEL=="sg*", ATTRS{wwid}=="t10.IBM     3573-TL         00L4U78W3142_LL0", MODE="0666", SYMLINK="sbr/Library0"
```

* Value of `ATTRS{wwid}==` must be equal to values from previous udevadm output.
* By value `SYMLINK=` you create your own name for changer, or tape drive.
* For Storware Backup & Recovery use schema name "LIBRARY\_DRIVE".

#### 3. Apply changes

To apply our changes we must execute two command:

```
udevadm control --reload-rules
udevadm trigger
```

#### 4. Validate if it is applied correctly:

To validate it, you need check if persistent devices were created:

```
ll /dev/sbr/
lrwxrwxrwx. 1 root root 3 Oct 26 12:46 Library0_Drive0 -> sg2
lrwxrwxrwx. 1 root root 3 Oct 26 12:46 Library0_Drive1 -> sg4
lrwxrwxrwx. 1 root root 3 Oct 26 12:46 Library0 -> sg5
```

### Create Tape Manager

To create Tape Manager, log in to Storware Backup & Recovery and go to `Backup Destinations` -> `Tape Pools` -> `Tape Managers` tab and click `Create` button. You need to specify:

* Name of Tape Manager instance
* URL of Tape Manager service

  ```
  http://IP_of_tape_manager:8686
  or
  https://IP_of_tape_manager:8787
  ```
* Node Config for scanning Inventory of Tape Manager service
* Secret Key generated by Tape Manager service

Secret Key is generated during first startup of Tape Manager service. It’s located in service directory `/opt/vprotect/tapemanager/config/secretKey.jwk`. In Storware Backup & Recovery you need to provide the value from “k” property without quotation marks.

Example of secretKey.jwk:

```
{
    "kty": "oct",
    "k": "ZtOPeOvdJq0M62ka2I8BJmUi7GJbCVEpJyxAsOs4JO0=",
    "alg": "HS256"
}
```

{% hint style="warning" %}
If you remove this file, new secret api key will be generated at startup of Tape Manager service.
{% endhint %}

### Inventory Synchronization

After creating Tape Manager you need to run Inventory Synchronization to fetch all Tape Libraries, Tape Drives and Tapes from Tape Manager.

## Managing Tape Manager

In Tape Manager details you have access to all Tape Libraries, Tape Drives and Tapes associated with this Tape Manager.

### Tape Libraries

In Tape Libraries View you have access to all Tape Libraries synced from Tape Manager service. Currently you can only browse or delete Libraries from this view.

### Tape Drives

In Tape Drives View you have access to all Tape Drives synced from Tape Manager service. Currently you can only browse or delete Drives from this view.

### Tapes

In Tapes View you have access to all Tapes synced from Tape Manager service. In this view, you can:

* Browse Tapes.
* Delete them (this operation will result in loosing all data stored on them).
* If they are not present you can change their name (barcode).
* If they are not present you can assign them to location where they are physically stored.

### Locations

Locations are physical places where you store Tapes when they are outside of Tape Library.

To create Location you need to specify name with an optional description.

You can only assign **not present** tapes to Location. During Tape Manager Inventory Sync Task if a Tape that is in Location will be present again it will be automatically removed from Location.

### Notes and limitations

Only environments with a single Tape Library per Tape Manager are supported. Drives visible by the operating system need to be in the same order as drives in Tape Library.

## Create a Tape Pool

### Prerequisites

Before creating a Tape Pool Backup destination you need to:

* Have working Tape Manager.
* Do a Tape Inventory Synchronization.

### Setup

To create Tape Pool you need to specify:

* Name of Backup Destination.
* Tape Manager.
* Tape Library from previously selected Tape Manager.
* Tape Drive from selected Library.
* One or more Tapes from selected Library.

### Initialization

After creating or updating Tape Pool Backup Destination wait for a Backup Destination Initialization Task. This Task will initialize all Tapes associated with this Tape Pool. After that your Backup Destination is ready to use.

### Notes and limitations

* At all times only one task that uses certain Tape Pool can run, (affects Tasks: Export, Store, Restore, Backup Destination Initialization), all other tasks will wait in queue.
* Moving Tapes between Tape Pools will result in erasing all their contents.
* You are not allowed to assign or remove Tape with valid backups.
* Updating the Tape Pool when there are running tasks that use it is prohibited.


# High Availability

Storware Backup & Recovery can work in high availability cluster. This section shows two configuration examples on how to achieve this:

* [2 Node Cluster](/70/deployment/high-availability/2-node-cluster)
* [3 Node Cluster](/70/deployment/high-availability/3-node-cluster)


# 2 Node Cluster

## Overview

In this scenario, we are going to set up two Storware Backup & Recovery servers in High Availability, Active/Passive mode. This is possible by using techniques such as a pacemaker, corosync, and DRBD. At least a basic understanding of these is highly desirable. This how-to is intended for RPM-based systems such as Red Hat / CentOS. If you run Storware Backup & Recovery on a different OS, you may need to refer to your distribution docs.

Our environment is built of the following elements:

1. storware1 - first Storware Backup & Recovery server + Storware Backup & Recovery node, IP: 10.40.1.50
2. storware2 - second Storware Backup & Recovery server + Storware Backup & Recovery node, IP: 10.40.1.52
3. Cluster IP: 10.40.1.100 - We will use this IP to connect to our **active** Storware Backup & Recovery service. This IP will float between our servers and will point to an active instance.
4. DRBD (optionally with VDO) for data replication and deduplication between nodes.
5. MariaDB master <-> master replication

![](https://github.com/Storware/backup-and-recovery-manual/blob/master/deployment/.gitbook/assets/overview-high_availability%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\).png)

## HA cluster setup

### **Preparing the environment**

* Stop and disable the Storware Backup & Recovery server, node and database as the cluster will manage these resources.

```
systemctl disable vprotect-server vprotect-node mariadb
```

* **Use yum to check if you have any updates pending**

```
# yum update
```

* It is a good idea to check ***/etc/hosts,*** especially if you installed Storware Backup & Recovery using the ***All in one quick installation*** method, as you might find an entry such as:

  ```
  127.0.0.1 <your_hostname_here>
  ```

  **Delete it** as this prevents the cluster from functioning properly (your nodes will not "see" each other).

Now we can proceed with installation of the required packages.

* **On both servers run**

```
# yum install -y pacemaker pcs psmisc policycoreutils-python
```

* **Add a firewall rule to allow HA traffic** - TCP ports 2224, 3121, and 21064, and UDP port 5405 (both servers)

```
# firewall-cmd --permanent --add-service=high-availability
success
# firewall-cmd --reload
success
```

While testing, depending on your environment, you may encounter problems related to network traffic, permissions, etc. While it might be a good idea to temporarily disable the firewall and SELinux, we do not recommend disabling that mechanism in the production environment as it creates significant security issues.\
**If you choose to disable the firewall, bear in mind that Storware will no longer be available on ports 80/443. Instead, connect to ports 8080/8181 respectively.**

```
# setenforce 0
# sed -i.bak "s/SELINUX=enforcing/SELINUX=permissive/g" /etc/selinux/config
# systemctl mask firewalld.service
# systemctl stop firewalld.service
# iptables --flush
```

* **Enable and start PCS daemon**

```
# systemctl enable pcsd.service
# systemctl start pcsd.service
```

**Cluster configuration**

Earlier installation of a pcs package automatically creates a user ***hacluster*** with no password authentication. While this may be good for running locally, we will require a password for this account to perform the rest of the configuration, so let's

* **configure the same password on both nodes**

```
# passwd hacluster
Changing password for user hacluster.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.
```

**Corosync configuration**

* On node 1, issue a command to authenticate as a **hacluster** user:

```
[root@vprotect1 ~]# pcs cluster auth vprotect1 vprotect2
Username: hacluster
Password:
vprotect1: Authorized
vprotect2: Authorized
```

* **Generate and synchronize the corosync configuration**

```
[root@vprotect1 ~]# pcs cluster setup --name mycluster vprotect1 vprotect2
```

​ Take a look at your output, which should look similar to below:

```
Destroying cluster on nodes: vprotect1, vprotect2...
vprotect1: Stopping Cluster (pacemaker)...
vprotect2: Stopping Cluster (pacemaker)...
vprotect1: Successfully destroyed cluster
vprotect2: Successfully destroyed cluster

Sending 'pacemaker_remote authkey' to 'vprotect1', 'vprotect2'
vprotect1: successful distribution of the file 'pacemaker_remote authkey'
vprotect2: successful distribution of the file 'pacemaker_remote authkey'
Sending cluster config files to the nodes...
vprotect1: Succeeded
vprotect2: Succeeded

Synchronizing pcsd certificates on nodes vprotect1, vprotect2...
vprotect1: Success
vprotect2: Success
Restarting pcsd on the nodes in order to reload the certificates...
vprotect1: Success
vprotect2: Success
```

* **Enable and start your new cluster**

```
[root@vprotect1 ~]# pcs cluster start --all && pcs cluster enable --all
vprotect1: Starting Cluster (corosync)...
vprotect2: Starting Cluster (corosync)...
vprotect1: Starting Cluster (pacemaker)...
vprotect2: Starting Cluster (pacemaker)...
vprotect1: Cluster Enabled
vprotect2: Cluster Enabled
```

OK! We have our cluster enabled. We have not created any resources (such as a floating IP) yet, but before we proceed we still have a few settings to modify.

Because we are using only two nodes, we need to

* **disable default quorum policy**

(this command should not return any output)

```
[root@vprotect1 ~]# pcs property set no-quorum-policy=ignore
```

We should also

* **define default failure settings**

```
[root@vprotect1 ~]# pcs resource defaults failure-timeout=30s
[root@vprotect1 ~]# pcs resource defaults migration-threshold=3
```

These two settings combined will define how many failures can occur for a node to be marked as ineligible for hosting a resource and after what time this restriction will be lifted. We define the defaults here, but it may be a good idea to also set these values at the resource level, depending on your experience.

As long we are not using any fencing device in our environment (and here we are not) we need to:

* **disable stonith**

```
[root@vprotect1 ~]# pcs property set stonith-enabled=false && crm_verify -L
```

The second part of this command verifies running-config. These commands normally do not return any output.

**Resource creation**

Finally, we have our cluster configured, so it's time to proceed to

* **resource creation**

First, we will create a resource that represents our ***floating IP*** 10.40.1.100. Adjust your IP and cidr\_netmask, and you're good to go.

**IMPORTANT:** From this moment on we need to use this IP when connecting to our vProtect server.

```
[root@vprotect1 ~]# pcs resource create "Failover_IP" ocf:heartbeat:IPaddr2 ip=10.40.1.100 cidr_netmask=22 op monitor interval=30s
```

Immediately, we should see our IP is up and running on one of the nodes (most likely on the one we issued this command for).

```
[root@vprotect1 ~]# ip a
[..]
2: ens160:  mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:50:56:a6:9f:c6 brd ff:ff:ff:ff:ff:ff
    inet 10.40.1.50/22 brd 10.40.3.255 scope global ens160
       valid_lft forever preferred_lft forever
    inet 10.40.1.100/22 brd 10.40.3.255 scope global secondary ens160
       valid_lft forever preferred_lft forever
    inet6 fe80::250:56ff:fea6:9fc6/64 scope link
       valid_lft forever preferred_lft forever
```

As you can see, our floating IP 10.40.1.100 has been successfully assigned as the second IP of interface ens160. This is what we wanted!

We should also check if the Storware Backup & Recovery web interface is up and running. We can do this by opening the web browser and typing in [https://10.40.1.100](https://10.40.1.100/).

The next step is to

* **define a resource responsible for monitoring network connectivity**

```
[root@vprotect1 ~]# pcs resource create ping ocf:pacemaker:ping dampen=5s multiplier=1000 host_list=10.40.0.1 clone
[root@vprotect1 ~]# pcs constraint location Failover_IP rule score=-INFINITY pingd lt 1 or not_defined pingd
```

Note that you need to use **your gateway IP** in the ***host\_list*** parameter

Finally, we have to define a set of cluster resources responsible for other services crucial for Storware as Storware Node and the Storware server itself. We will logically link these services with our floating IP. Whenever the floating IP disappears from our server, these services will be stopped. We also have to define the proper order for services to start and stop, as for example starting the Storware-server without a running database makes little sense.

* **Resource creation**

```
[root@vprotect1 ~]#  pcs resource create "vProtect-node" systemd:vprotect-node op monitor timeout=300s on-fail="stop" --group vProtect-group
[root@vprotect1 ~]# pcs resource create "vProtect-server" service:vprotect-server op start on-fail="stop" timeout="300s" op stop timeout="300s" on-fail="stop" op monitor timeout="300s" on-fail="stop" --group vProtect-group
```

It is OK for these commands not to return any output.

* **Resource colocation**

```
[root@vprotect1 ~]# pcs constraint colocation add Failover_IP with vProtect-group
```

To finish with, we can set which server is more preferred for running our services

* **Set node preference**

```
[root@vprotect1 ~]# pcs constraint location Failover_IP prefers vprotect1=INFINITY
[root@vprotect1 ~]# pcs constraint location vProtect-group prefers vprotect1=INFINITY
```

We have made it to the end. At this point, our pacemaker HA cluster is functional.

However, there are still two things we need to consider, that is:

1. Creating DB replication
2. Setting up DRBD for /vprotect\_data (optionally with VDO)

#### Setting up VDO+DRBD

In this section, we will prepare our deduplicated and replicated filesystem mounted in /vprotect\_data.

Using a deduplicated FS is optional but highly recommended. If you don't intend to use it, skip the part regarding VDO configuration.

Note: If you are altering existing Stoware Backup & Recovery configuration it is very important to preserve the /vprotect\_data contents and transfer them to the new filesystem. You may also need to re-create your backup\_destination if you previously had one in this directory. Setting up VDO and DRBD will cause all data to be wiped from the configured volume.

Installation is split into the steps below that you need to follow to get the job done.

* **Stop the Storware server and node**

```
# systemctl stop vprotect-server vprotect-node
```

No output means everything went OK.

* **On both nodes install the equired repositories and packages**

```
# rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
# rpm -Uvh https://www.elrepo.org/elrepo-release-7.0-4.el7.elrepo.noarch.rpm
Retrieving https://www.elrepo.org/elrepo-release-7.0-4.el7.elrepo.noarch.rpm
Preparing...                          ################################# [100%]
Updating / installing...
   1:elrepo-release-7.0-4.el7.elrepo  ################################# [100%]
```

The next command can produce quite a few lines, so I've truncated the output, however the idea is simple: install drbd packages:

```
[root@vprotect1 ~]# yum install -y kmod-drbd84 drbd84-utils

Installed:
drbd84-utils.x86_64 0:9.6.0-1.el7.elrepo                                               kmod-drbd84.x86_64 0:8.4.11-1.1.el7_6.elrepo
```

If you have not disabled SELinux and the firewall, remember to

* **configure them on both nodes**

  ```
  # semanage permissive -a drbd_t
  # firewall-cmd --add-port=7788/tcp --permanent
  success
  # firewall-cmd --complete-reload
  success
  ```

  Don't forget to repeat these steps on the second node

Now that we have the necessary software installed, we must prepare an identical size block device on both nodes. A block device can be a hard drive, a hard drive partition, software RAID, LVM Volume, etc. In this scenario, we are going to use a hard drive connected as ***/dev/sdb***.

To add a DRBD resource we create the file ***/etc/drbd.d/vprotect.res*** with the content below. Be sure to change the "address" so that t reflects your network configuration.

Also, the node names (storware1 and storware2) must match your ***uname -n*** output.

```
resource replicate {
protocol C;
    on vprotect1 {
                device /dev/drbd0;
                disk /dev/sdb;
                address 10.40.1.50:7788;
                meta-disk internal;
        }
    on vprotect2 {
                device /dev/drbd0;
                disk /dev/sdb;
                address 10.40.1.52:7788;
                meta-disk internal;
        }
```

We now have config in place and can create and bring our resource online.

* **On both nodes, run**

  ```
  # drbdadm create-md replicate
  initializing activity log
  initializing bitmap (4800 KB) to all zero
  Writing meta data...
  New drbd meta data block successfully created.
  ```

  then bring the volume online

  ```
  # drbdadm up replicate
  ```

  You can verify if the device is up & running by issuing

  ```
  # lsblk
  NAME                    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
  sda                       8:0    0   16G  0 disk
  ├─sda1                    8:1    0    1G  0 part /boot
  └─sda2                    8:2    0   15G  0 part
  ├─vg_vprotect-lv_root 253:0    0 13.4G  0 lvm  /
  └─vg_vprotect-lv_swap 253:1    0  1.6G  0 lvm  [SWAP]
  sdb                       8:16   0  150G  0 disk
  └─drbd0                 147:0    0  150G  1 disk
  ```

  However, if we check

  ```
  [root@vprotect1 ~]# drbdsetup status replicate
  replicate role:Secondary
  disk:Inconsistent
  peer role:Secondary
  replication:Established peer-disk:Inconsistent
  ```

  we will notice we need to start synchronization before we can use our volume.
* **On the first server, run**

  ```
  [root@vprotect1 ~]# drbdadm primary --force replicate
  [root@vprotect1 ~]# drbdsetup status replicate
  replicate role:Primary
  disk:UpToDate
  peer role:Secondary
  replication:SyncSource peer-disk:Inconsistent done:0.22
  ```

  This way we have successfully started the process of replication between servers with vprotect1 as the ynchronization source.

  If you don't want to create a VDO device, then create and mount your filesystem:

  ```
  [root@vprotect1 ~]# mkfs.xfs -K /dev/drbd0
  [root@vprotect1 ~]# mount /dev/mapper/drbd0 /vprotect_data/ && chown -R vprotect:vprotect /vprotect_data
  ```
* **Create VDO volume** (optional)

  By issuing the command below we will create a VDO volume called ***vdo\_data*** and put in at the top our DRBD volume. Afterwards, we format it with XFS and mount it in /vprotect\_data.

  ```
  [root@vprotect1 ~]# vdo create --name=vdo_data --device=/dev/drbd0 --vdoLogicalSize=400G --compression=enabled --deduplication=enabled
  Creating VDO vdo_data
  Starting VDO vdo_data
  Starting compression on VDO vdo_data
  VDO instance 0 volume is ready at /dev/mapper/vdo_data

  [root@vprotect1 ~]# mkfs.xfs -K /dev/mapper/vdo_data
  meta-data=/dev/mapper/vdo_data   isize=512    agcount=4, agsize=26214400 blks
      =                       sectsz=4096  attr=2, projid32bit=1
      =                       crc=1        finobt=0, sparse=0
  data     =                       bsize=4096   blocks=104857600, imaxpct=25
      =                       sunit=0      swidth=0 blks
  naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
  log      =internal log           bsize=4096   blocks=51200, version=2
      =                       sectsz=4096  sunit=1 blks, lazy-count=1
  realtime =none                   extsz=4096   blocks=0, rtextents=0

  [root@vprotect1 ~]# mount /dev/mapper/vdo_data /vprotect_data/ && chown -R vprotect:vprotect /vprotect_data
  ```
* **Copy the VDO config to the second node**

```
[root@vprotect1 ~]# scp /etc/vdoconf.yml root@vprotect2:/etc/vdoconf.yml
```

* **Disable VDO automatic startup**

  As this resource will be managed by the cluster, we need to disable auto startup of this service ***on both nodes.***

  ```
  # systemctl disable vdo
  ```

### Final cluster settings

At this point, we have three components set up. To fully utilize our HAcluster and eliminate the need for manual intervention we should add the resources and settings below to our cluster.

Issue these commands on one node only as it will propagate to the cluster settings.

```
[root@vprotect1 ~]#  pcs cluster cib drbd_cfg
[root@vprotect1 ~]#  pcs -f drbd_cfg resource create replicate ocf:linbit:drbd \
         drbd_resource=replicate op monitor interval=10s --group fs_group

[root@vprotect1 ~]#  pcs -f drbd_cfg resource master replicateClone replicate \
         master-max=1 master-node-max=1 clone-max=2 clone-node-max=1 \
         notify=true --group fs_group

[root@vprotect1 ~]#  pcs -f drbd_cfg resource create vdo_resource ocf:heartbeat:vdo-vol volume=vdo_data --group fs_group
[root@vprotect1 ~]#  pcs -f drbd_cfg resource create fs_resource ocf:heartbeat:Filesystem device=/dev/mapper/vdo_data directory=/vprotect_data fstype=xfs  --group fs_group
[root@vprotect1 ~]#  pcs cluster cib-push drbd_cfg --config

[root@vprotect1 ~]#  pcs constraint colocation add vdo_resource with replicateClone
[root@vprotect1 ~]#  pcs constraint order start vdo_resource then fs_resource
[root@vprotect1 ~]#  pcs constraint order start replicateClone then vdo_resource
[root@vprotect1 ~]#  pcs constraint colocation add vProtect-group with fs_group
[root@vprotect1 ~]#  pcs constraint colocation add vdo_resource with replicateClone INFINITY with-rsc-role=Master
[root@vprotect1 ~]#  pcs constraint order promote replicateClone then start fs_group
```

Here we have created a temporary file ***drbd\_cfg*** and inside this file we have added our drbd\_resource called ***replicate***, plus a Master/Slave set for this resource.

Afterwards, we have the definition of the vdo\_resource and fs\_resource in one fs\_group followed by an update of the cluster configuration.

As a second step, we have put in place several resource colocations and constraints which allow us to control the order and existence of newly created resources.

We need still to

* Make sure that our node is pointed to a localhost address. Check the ***Nodes*** UI section.

If the node's IP is different than 127.0.0.1, delete the node and re-register it using

```
[root@vprotect1 ~]# vprotect node -e <Node_Name> admin http://127.0.0.1:8080/api
```

* copy our license and node information from the first node to the second node:

```
[root@vprotect1 ~]# scp -pr /opt/vprotect/.session.properties 
[root@vprotect1 ~]# scp -pr /opt/vprotect/license.key
```

### MariaDB replication

In this section, we will cover how to setup master<->master MariaDB replication.

* On both nodes, if you have the firewall enabled, allow communication via port **3306**

```
# firewall-cmd --add-port=3306/tcp --permanent
# firewall-cmd --complete-reload
```

**Steps to run on the first storware1 node: 10.40.1.50**

This server will be the source of DB replication.

* **Stop the Storware server, node and database**

```
[root@vprotect1 ~]# systemctl stop vprotect-server vprotect-node mariadb
```

* **Edit the config file**, enable binary logging and start MariaDB again. Depending on your distribution, the config file location may vary, most likely it is /etc/my.cnf or /etc/my.cnf.d/server.cnf

  In the ***\[mysqld]*** section, add the lines:

```
[root@vprotect1 ~]# vi /etc/my.cnf.d/server.cnf
log-bin
server_id=1
replicate-do-db=vprotect
[root@vprotect1 ~]# systemctl start mariadb
```

* Now **log in into your MariaDB**, create a user used for replication and assign appropriate rights to it.

  For the purpose of this task, we will set the username to 'replicator' and the password to 'R3pLic4ti0N'

```
[root@vprotect1 ~]# mysql -u root -p
Enter password:
[..]
MariaDB [(none)]> create user 'replicator'@'%' identified by 'R3pLic4ti0N';
Query OK, 0 rows affected (0.026 sec)

MariaDB [(none)]> grant replication slave on *.* to 'replicator'@'%';
Query OK, 0 rows affected (0.001 sec)

MariaDB [(none)]> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.001 sec)
```

Don't log out just yet, we need to check the master status and

* **write down the log file name and position**, as it is required for proper slave configuration.

```
MariaDB [(none)]> show master status;
+----------------------+----------+--------------+------------------+
| File                 | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+----------------------+----------+--------------+------------------+
| vprotect1-bin.000007 |    46109 |              |                  |
+----------------------+----------+--------------+------------------+
```

* Dump the vprotect database and copy it onto the second server (vprotect2).

```
 [root@vprotect1 ~]# mysqldump -u root -p vprotect > /tmp/vprotect.sql
 [root@vprotect1 ~]# scp /tmp/vprotect_rep.sql root@vprotect2:/tmp/
```

**Steps to run on the 2nd server, storware2: 10.40.1.52**

For the reader's convenience, I have only highlighted the differences in configuration between storware1 and storware2, and omitted the output of some commands if they are the same as on the previous node.

* **Stop the vprotect server, node and database**
* Edit the MariaDB config file. **Assign a different server id**, for example: 2. Then start MariaDB.

```
[root@vprotect2 ~]# vi /etc/my.cnf.d/server.cnf
log-bin
server_id=2
replicate-do-db=vprotect
[root@vprotect2 ~]# systemctl start mariadb
```

* **Load the database dump** copied from storware1.

```
[root@vprotect2 ~]# mysql -u root -p vprotect < /tmp/vprotect.sql
```

At this point, we have two identical databases on our two servers.

* **Log in to the MariaDB instance, create a replication user with a password**. Use the same user as on storware1. Grant the necessary permissions.
* Set the master host. You ***must*** use the user\_master\_log\_file and master\_log\_pos written down earlier. Change the IP of the master host to match your network configuration.

```
MariaDB [(none)]> STOP SLAVE;
MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST = '10.40.10.50', MASTER_USER = 'replicator',MASTER_PASSWORD='R3pLic4ti0N',MASTER_LOG_FILE = 'vprotect1-bin.000007',MASTER_LOG_POS=46109;
Query OK, 0 rows affected (0.004 sec)
```

* Start the slave, check the master status and **write down the file name and position.**

```
MariaDB [(none)]> start slave;
Query OK, 0 rows affected (0.001 sec)

MariaDB [(none)]> SHOW MASTER STATUS;
+----------------------+----------+--------------+------------------+
| File                 | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+----------------------+----------+--------------+------------------+
| vprotect2-bin.000002 |   501051 |              |                  |
+----------------------+----------+--------------+------------------+
1 row in set (0.000 sec)
```

**Go back to the first server (storware1)**

* On **storreaw1**, stop the slave then change the master host using the parameters noted down in the previous step. Also, change the master host IP to match your network configuration.

```
MariaDB [(none)]> stop slave;
MariaDB [(none)]> MariaDB [(none)]>  change master to master_host='10.40.1.52', master_user='replicator', master_password='R3pLic4ti0N',MASTER_LOG_FILE = 'vprotect2-bin.000002', master_log_pos=501051;
Query OK, 0 rows affected (0.004 sec)
MariaDB [(none)]> start slave;
Query OK, 0 rows affected (0.001 sec)
```

At this point, you have successfully configured MariaDB master<->master replication.

#### Testing the setup

**Automatic**

The fastest way to test our setup is to invoke

```
# pcs node standby vprotect1
```

to put storware1 into standby mode, which prevents it from hosting any cluster resources.

After a while, you should see your resources up and running on storware2.

Note that if you perform normal OS shutdown (not a forced one), the pacemaker will wait for a long time for a node to come back online, which in fact will prevent completion of shutdown. As a result, resources ***will not*** switch correctly to the other node.

**Manual**

If you want to dive a little bit deeper, we have prepared instructions on how to manually move a filesystem resource from the first node to the second.

1. Stop vprotect services.

   ```
    systemctl stop vprotect-server && systemctl stop vprotect-node
   ```
2. Unmount the FS used by DRBD/VDO on the primary server (here storware1).

   ```
   [root@vprotect1 ~]# drbdadm role replicate
   Primary/Secondary
   [root@vprotect1 ~]# umount /vprotect_data/
   ```
3. If you are using a VDO device, stop it.

   ```
   [root@vprotect1 ~]# vdo stop -n vdo_data
   Stopping VDO vdo_data
   ```
4. Demote the primary replication server (still storware1) to secondary server.

   ```
   [root@vprotect1 ~]# drbdadm secondary replicate
   ```

**On the second server**

1. Promote the second server (here storware2) to the primary DRBD role.

   ```
   [root@vprotect2 ~]# drbdadm    primary replicate
   ```
2. Start the VDO.

   ```
   [root@vprotect2 ~]# vdo start -n vdo_data
   Starting VDO vdo_data
   Starting compression on VDO vdo_data
   VDO instance 2 volume is ready at /dev/mapper/vdo_data
   ```
3. Mount the filesystem on the second server.

   ```
   [root@vprotect2 ~]# mount /dev/mapper/vdo_data /vprotect_data/
   ```

Now you have your replicated volume mounted on the second node.


# 3 Node Cluster

## Overview

We have prepared 3 machines with RedHat 8 operating system in the same network:

10.1.1.2 vprotect1.local\
10.1.1.3 vprotect2.local\
10.1.1.4 vprotect3.local

We will use IP 10.1.1.5/23 for floating IP of our cluster.

## 1. Storware server installation

Run that steps on all machines under pacemaker cluster:

1. Add Storware repository

   ```
   vi /etc/yum.repos.d/vProtect.repo
   ```

   ```
   # Storware Backup & Recovery - Enterprise backup solution for virtual environments repository
   [vprotect]
   name = vProtect
   baseurl = https://repo.storware.eu/storware/current/el8/
   gpgcheck = 0
   ```
2. Add MariaDB repository

   ```
   vi /etc/yum.repos.d/MariaDB.repo
   ```

   ```
   # MariaDB 10.10 RedHatEnterpriseLinux repository list - created 2023-08-23 08:49 UTC
   # https://mariadb.org/download/
   [mariadb]
   name = MariaDB
   # rpm.mariadb.org is a dynamic mirror if your preferred mirror goes offline. See https://mariadb.org/mirrorbits/ for details.
   # baseurl = https://rpm.mariadb.org/10.10/rhel/$releasever/$basearch
   baseurl = https://mirror.creoline.net/mariadb/yum/10.10/rhel/$releasever/$basearch
   # gpgkey = https://rpm.mariadb.org/RPM-GPG-KEY-MariaDB
   gpgkey = https://mirror.creoline.net/mariadb/yum/RPM-GPG-KEY-MariaDB
   gpgcheck = 1
   ```
3. Install Storware server

   ```
   dnf install -y vprotect-server
   ```
4. Initialize Storware server

   ```
   vprotect-server-configure
   ```
5. Redirect 8181 port to 443 on firewall

   ```
   /opt/vprotect/scripts/ssl_port_forwarding_firewall-cmd.sh
   ```
6. Add redirection to allow local node to communicate with server on cluster IP

   ```
   firewall-cmd --permanent --direct --add-rule ipv4 nat OUTPUT 0 -p tcp -o lo --dport 443 -j REDIRECT --to-ports 8181
   firewall-cmd --complete-reload
   ```
7. Open firewall for MariaDB replication:

   ```
   firewall-cmd --add-port=3306/tcp --permanent
   firewall-cmd --complete-reload
   ```

## 2. Configuration custom SSL certificate

All steps run as root user. All steps execute on first node of cluster.

Follow steps from [enabling HTTPS connectivity for nodes](/70/deployment/common-tasks/enabling-https-connectivity-for-nodes)

## 3. Storware node installation

Execute on all pacemaker nodes, and other Storware node machines.

1. Add Storware repository

   ```
   vi /etc/yum.repos.d/vProtect.repo
   ```

   ```
   # Storware Backup & Recovery - Enterprise backup solution for virtual environments repository
   [vprotect]
   name = vProtect
   baseurl = https://repo.storware.eu/storware/current/el8/
   gpgcheck = 0
   ```
2. Install Storware node

   ```
   dnf install -y vprotect-node
   ```
3. Initialize Storware node

   ```
   vprotect-node-configure
   ```
4. [Configure LVM filter](/70/deployment/common-tasks/lvm-setup-on-storware-backup-and-recovery-node-for-disk-attachment-backup-mode).
5. Only when we want backup Proxmox by export strategy.

```
cd /opt/vprotect/scripts/vma
./setup_vma.sh vprotect-vma-20180128.tar
```

## 4. Backup destination configuration

For multi-node/cluster environment for backup destination we suggest to use NFS, Object Storage, Deduplication appliances. In this example we use NFS.

Execute on all Storware node machines.

1. Add entry in `/etc/fstab` for automount NFS

   ```
   10.1.1.1:/vprotect /vprotect_data nfs defaults 0 0
   ```
2. Create directories for mount NFS share:

   ```
   mkdir /vprotect_data
   ```
3. Mount NFS share

   ```
   mount -a
   ```
4. Create subdirectories for backup destinations (run only on single node)

   ```
   mkdir /vprotect_data/backup
   mkdir /vprotect_data/backup/synthetic
   mkdir /vprotect_data/backup/filesystem
   mkdir /vprotect_data/backup/dbbackup
   ```
5. Add privileges for newly created shares

   ```
   chown vprotect:vprotect -R /vprotect_data
   ```

## 5. Cluster Configuration

Cluster is controlled by pacemaker.

### 5.1 Prepare operating system

All steps run as root user. Run that steps on all machines in pacemaker cluster:

1. Stop all services controlled by cluster, and disable autostart.

   ```
   systemctl stop vprotect-node
   systemctl stop vprotect-server
   systemctl disable vprotect-node
   systemctl disable vprotect-server
   ```

### 5.2 Set MariaDB replication

All steps run as root user. Run on all cluster nodes:

1. Create MariaDB user `replication` with password `vPr0tect` for replication:

   ```mysql
   CREATE USER replicator@'10.1.1.%' IDENTIFIED BY 'vPr0tect';
   GRANT SELECT,REPLICATION SLAVE,REPLICATION CLIENT ON *.* to replicator@'10.1.1.%' IDENTIFIED BY 'vPr0tect';
   ```
2. Add changes to /etc/my.cnf.d/server.cnf in `mysqld` section:

   ```
   [mysqld]
   lower_case_table_names=1
   log-bin=mysql-bin
   relay-log=relay-bin
   log-slave-updates
   max_allowed_packet=500M
   log_bin_trust_function_creators=1
   ```
3. Add changes to /etc/my.cnf.d/server.cnf in `mysqld` section:

   On vprotect1.local:

   ```
   server-id=10
   ```

   On vprotect2.local:

   ```
   server-id=20
   ```

   On vprotect3.local:

   ```
   server-id=30
   ```
4. Restart MariaDB service:

   ```
   systemctl restart mariadb
   ```
5. On each host show output from command:

   ```
   SHOW MASTER STATUS;
   ```

   Output from vprotect3.local:

   ```output
   +------------------+----------+--------------+------------------+
   | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
   +------------------+----------+--------------+------------------+
   | mysql-bin.000006 |      374 |              |                  |
   +------------------+----------+--------------+------------------+
   1 row in set (0.000 sec)
   ```

   Output from vprotect1.local:

   ```output
   +------------------+----------+--------------+------------------+
   | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
   +------------------+----------+--------------+------------------+
   | mysql-bin.000007 |      358 |              |                  |
   +------------------+----------+--------------+------------------+
   1 row in set (0.000 sec)
   ```

   Output from vprotect2.local:

   ```output
   +------------------+----------+--------------+------------------+
   | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
   +------------------+----------+--------------+------------------+
   | mysql-bin.000004 |      358 |              |                  |
   +------------------+----------+--------------+------------------+
   1 row in set (0.000 sec)
   ```
6. Set replication on each MariaDB server:

   Execute on vprotect1.local:

   ```
   CHANGE MASTER TO
   MASTER_HOST='10.1.1.4',
   MASTER_PORT=3306,
   MASTER_USER='replicator',
   MASTER_PASSWORD='vPr0tect',
   MASTER_LOG_FILE='mysql-bin.000006',
   MASTER_LOG_POS=37;
   ```

   Execute on vprotect2.local:

   ```
   CHANGE MASTER TO
   MASTER_HOST='10.1.1.2',
   MASTER_PORT=3306,
   MASTER_USER='replicator',
   MASTER_PASSWORD='vPr0tect',
   MASTER_LOG_FILE='mysql-bin.000007',
   MASTER_LOG_POS=358;
   ```

   Execute on vprotect3.local:

   ```
   CHANGE MASTER TO
   MASTER_HOST='10.1.1.3',
   MASTER_PORT=3306,
   MASTER_USER='replicator',
   MASTER_PASSWORD='vPr0tect',
   MASTER_LOG_FILE='mysql-bin.000004',
   MASTER_LOG_POS=358;
   ```
7. Start replication MariaDB:\
   Execute on vprotect1.local:

   ```
   START SLAVE;
   ```

   Show output from command:

   ```
   SHOW SLAVE STATUS\G
   ```

   Wait until you see in output:

   ```
   Slave_IO_Running: Yes
   Slave_SQL_Running: Yes
   ```

   Repeat last step on host vprotect2.local and vprotect3.local.

#### 5.2.1 Make same passwords for vprotect user in MariaDB

{% hint style="info" %}
Execute only on first node of cluster.
{% endhint %}

1. Copy password from file `/opt/vprotect/payara.properties`

   ```
   eu.storware.vprotect.db.password=SECRETPASSWORD
   ```
2. Log in to MariaDB

   ```
   mysql -u root -p
   ```
3. Set password for vprotect user:

   ```
   SET PASSWORD FOR 'vprotect'@'localhost' = PASSWORD('SECRETPASSWORD');
   quit;
   ```
4. Copy configuration files from vprotect1.local to other cluster hosts

   ```
   cd /opt/vprotect/
   keystore.jks
   log4j2-server.xml
   payara.properties
   vprotect.env
   vprotect-keystore.jks
   license.key
   ```
5. Add permissions for copied files

   ```
   chown vprotect:vprotect -R /opt/vprotect/
   ```

### 5.3 Configure pacemaker

All steps run as root user.

#### 5.3.1 Run on every node in cluster

1. Install pacemaker packages

   ```
   dnf install -y pcs pacemaker fence-agents-all
   ```
2. Create SSH keys, and add them on other hosts to known.
3. Open ports on firewall

   ```
   firewall-cmd --permanent --add-service=high-availability
   firewall-cmd --reload
   ```
4. Start pcsd service

   ```
   systemctl start pcsd.service
   systemctl enable pcsd.service
   ```
5. Set same password for user hacluster

   ```
   passwd hacluster
   ```

#### 5.3.2 Run only on first node of cluster

1. Authenticate nodes of cluster

   ```
   pcs host auth vprotect1.local vprotect2.local vprotect3.local
   ```
2. Create cluster

   ```
   pcs cluster setup vp vprotect1.local vprotect2.local vprotect3.local
   ```
3. Run cluster

   ```
   pcs cluster start --all
   ```
4. Power off stonith

   ```
   pcs property set stonith-enabled=false
   ```
5. Create floating IP in cluster

   ```
   pcs resource create vp-vip1 IPaddr2 ip=10.1.1.4 cidr_netmask=23 --group vpgrp
   ```
6. Add vprotect-server to cluster

   ```
   pcs resource create "vp-vprotect-server.service" systemd:vprotect-server.service op start on-fail="stop" timeout="300s" op stop timeout="300s" op monitor timeout="300s" --group vpgrp
   ```
7. Add vprotect-node to cluster

   ```
   pcs resource create "vp-vprotect-node.service" systemd:vprotect-node.service op start on-fail="stop" timeout="300s" op stop timeout="300s" op monitor timeout="300s" --group vpgrp
   ```

## 6. Register Storware node on server (on all hosts)

1. Add certificate to trusted

   ```
   /opt/vprotect/scripts/node_add_ssl_cert.sh 10.1.1.5 443
   ```
2. Register node on server

   ```
   vprotect node -r ${HOSTNAME%%.*} admin https://10.1.1.5:443/api
   ```

## 7. Useful commands to control cluster:

For update, or service Storware unmanage services from cluster:

```
pcs resource unmanage vpgrp
```

Back to manage:

```
pcs resource manage vpgrp
```

Show status of cluster:

```
pcs status
```

Stop cluster node:

```
pcs cluster stop vprotect1.local
```

Stop all nodes of cluster:

```
pcs cluster stop --all
```

Start all nodes of cluster:

```
pcs cluster start --all

```

Clear old errors in cluster:

```
pcs resource cleanup
```


# Common tasks

This section presents several supplementary tasks that may be needed in Storware Backup & Recovery deployment. This includes tasks such as HTTPS setup, SSH public key authentication with your hypervisors, VMs or libvirt/qemu package installation.

[Staging space configuration](/70/deployment/common-tasks/staging-space-configuration)

[Enabling HTTPS connectivity for nodes](/70/deployment/common-tasks/enabling-https-connectivity-for-nodes)

[LVM setup on Storware Backup & Recovery Node for disk attachment backup mode](/70/deployment/common-tasks/lvm-setup-on-storware-backup-and-recovery-node-for-disk-attachment-backup-mode)

[Full versions of libvirt/qemu packages installation](/70/deployment/common-tasks/full-versions-of-libvirt-qemu-packages-installation)

[SSH public key authentication](/70/deployment/common-tasks/ssh-public-key-authentication)

[Enabling HTTP(S) Proxy for Storware Backup & Recovery](/70/deployment/common-tasks/enabling-proxy)


# Staging space configuration

## General

Storware Backup & Recovery node needs staging space available in `/vprotect_data`by default. It is common to use PowerProtect DD for both the staging and backup destination. This will result in instant "store" processing, without the need to copy data from the staging space to the backup destinations. It is common to just attach an empty drive and mount it.

When using separate storage (usually local disks) for the staging space, consider its requirements. Staging space size depends on the number and size of simultaneous backups - as a rule of thumb make it approximately equal to the number of expected simultaneous backup threads multiplied by the size of your biggest VM.

In any case - make sure the staging space is always mounted in the `/vprotect_data` folder, and that the vprotect user is able to have full permissions to this file system.

### Example - Local filesystem

You also can use a plain file system for staging space (and optionally for backup destination). Here are steps assuming you have a local (physical or virtual) disk.

* List all existing disks, and find your dedicated disk (let's say - `/dev/sdc`):

```
[root@vProtect01 ~]# fdisk -l | grep dev
Disk /dev/sda: 32.2 GB, 32212254720 bytes, 62914560 sectors
/dev/sda1   *        2048     1026047      512000   83  Linux
/dev/sda2         1026048    62914559    30944256   8e  Linux LVM
Disk /dev/sdc: 500 GB, 17179869184 bytes, 33554432 sectors
Disk /dev/sdb: 21.5 GB, 21474836480 bytes, 41943040 sectors
Disk /dev/mapper/centos-root: 28.5 GB, 28462546944 bytes, 55590912 sectors
Disk /dev/mapper/centos-swap: 3221 MB, 3221225472 bytes, 6291456 sectors
```

* If you have a new clean disk prepare a filesystem on it:

```
mkfs.xfs -K /dev/sdc
```

* Test mount your existing filesystem in the created directory:

```
mount /dev/sdc /vprotect_data
```

* Set ownership to `vprotect` user on directory `/vprotect_data`:

```
chown vprotect:vprotect -R /vprotect_data
```

* Add a line to `/etc/fstab`file, to automatically mount new filesystem after reboot:

```
/dev/sdc    /vprotect_data    xfs    defaults 0 0
```

* Mount

```
mount -a
```

* Confirm with `df` that your `/vprotect_data` is mounted
* Restart your `vprotect-node`service:

```
systemctl restart vprotect-node
```


# Enabling HTTPS connectivity for nodes

The default certificate presented by the application server uses `localhost.localdomain`. This works only for local node installations (server and node on a single host).

{% hint style="info" %}
**Note:**

* You can use the default certificate - remember that you may need to use the `./node_add_ssl_cert.sh` script after future updates to refresh the certificate on the node
* Default password for our keystore is `changeit`
* For the default certificate - jump to the Node configuration and use the localhost.localdomain instead of the `storware.local`
* When registering the node locally over HTTPS note that the URL you should use is `localhost.localdomain` - **NOT** `localhost`
* When registering a node via HTTPS, please note that the server must have an FQDN that is different from the IP address (hostname like `10.10.10.10` can be processed incorrectly).
  {% endhint %}

This section presents the steps necessary for generating an SSL certificate, for setup Storware Backup & Recovery to use it and how to register a remote node.

## Storware Backup & Recovery Server (when using own certificate)

This section describes certificate generation and import on the Storware Backup & Recovery Server side. It uses a self-signed certificate. If you would like to use CSR and your own CA instead - check for additional steps described in the next section.

1. SSH to Storware Backup & Recovery Server host
2. Generate the key and certificate (remember to provide a valid Storware Server DNS hostname - in our example it was storware.local):

   ```
   [root@storware.local ~]# openssl req -x509 -newkey rsa:4096 -keyout storware.key -out storware.crt -days 365
   ```

   Example output (you need to input some information, especially passphrase for certificate):

   ```
   Generating a 4096 bit RSA private key
   ...............................................................................++
   .............................................................................................................................................................................................................................................................................................................................................++
   writing new private key to 'storware.key'
   Enter PEM pass phrase:
   Verifying - Enter PEM pass phrase:
   -----
   You are about to be asked to enter information that will be incorporated
   into your certificate request.
   What you are about to enter is what is called a Distinguished Name or a DN.
   There are quite a few fields but you can leave some blank
   For some fields there will be a default value,
   If you enter '.', the field will be left blank.
   -----
   Country Name (2 letter code) [XX]:PL
   State or Province Name (full name) []:
   Locality Name (eg, city) [Default City]:Warsaw
   Organization Name (eg, company) [Default Company Ltd]: your Company
   Organizational Unit Name (eg, section) []:
   Common Name (eg, your name or your server's hostname) []:storware.local
   Email Address []:
   ```
3. Create the PKCS12 bundle from the certificate and the key:

   ```
   [root@localhost ~]# openssl pkcs12 -export -in storware.crt -inkey storware.key -out storware.p12 -name storware
   ```

   You need to input passphrase defined before and define export password:

   ```
   Enter pass phrase for storware.key:
   Enter Export Password:
   Verifying - Enter Export Password:
   ```
4. Create a keystore for the Storware Backup & Recovery Server with the PKCS12 bundle (as a `root`):

   **Note**: Default password for our keystore is `changeit`.

   ```
   [root@localhost ~]# keytool -importkeystore -destkeystore /opt/vprotect/keystore.jks -srckeystore storware.p12 -srcstoretype PKCS12 -alias storware
   Enter destination keystore password: 
   Re-enter new password: 
   Enter source keystore password:
   ```
5. Change ownership on the keystore to the `vprotect` user:

   ```
   chown vprotect:vprotect /opt/vprotect/keystore.jks
   ```
6. Edit `/opt/vprotect/payara.properties`, change the path to the keystore and password (use password generated in step 3 of this instruction, default keystore password is `changeit`):

   ```
   eu.storware.vprotect.ssl.certname=[certificate alias]
   javax.net.ssl.keyStore=/opt/vprotect/keystore.jks
   javax.net.ssl.keyStorePassword=[keystorepassword]
   ```
7. Restart the Server:

   ```
   systemctl stop vprotect-server
   systemctl start vprotect-server
   ```

## Storware Backup & Recovery Node (any SSL certificate)

1. SSH to Storware Backup & Recovery Node host
2. Make sure that your nodes resolve the hostname (FQDN) of the Storware Backup & Recovery Server. You also can add an entry in the `/etc/hosts` like this (example IP: 1.2.3.4):

   ```
   1.2.3.4 storware.local
   ```
3. Check with your browser that `https://STORWARE_HOST:8181` presents the certificate that you have just generated. You also can execute the openssl client from the node to print it (check the hostname that you have provided in the certificate):

   ```
   openssl s_client -connect storware.local:8181 < /dev/null
   ```
4. Import the server certificate using the script under the /opt/vprotect/scripts folder:

   ```
   cd /opt/vprotect/node/scripts
   ./node_add_ssl_cert.sh [SERVER_HOST] [PORT] [KEYSTORE_PASS]
   ```

   * \[SERVER\_HOST] - FQDN name of Storware Backup & Recovery Server
   * \[PORT] - port for SSL communication on Storware Backup & Recovery Server (you need to open it on server `# firewall-cmd --permanent --add-port=[PORT]/tcp && firewall-cmd --reload`)
   * \[KEYSTORE\_PASS] - password which you defined in step 3 of that instruction

   **Note:**

   If you have node on the same host as server, You could use default variables of script (and you can use script without arguments). Default variables are:

   * SERVER\_HOST = `127.0.0.1`
   * PORT = `8181`
   * KEYSTORE\_PASS = `changeit`

   It applies if you would not generated any certificate.
5. Register the node with the NODE\_NAME of your choice, the ADMIN\_USER user name which you would like to use and the URL to Storware Backup & Recovery API, and provide the password when prompted:

   ```
   vprotect node -r NODE_NAME ADMIN_USER http(s)://STORWARE_SERVER:PORT/api
   ```

   **Examples:**

   * Remote server with a generated certificate:

   ```
   vprotect node -r node1 admin https://storware.local:8181/api
   ```

   * Local installation with default certificate:

   ```
   vprotect node -r node1 admin https://localhost.localdomain:8181/api
   ```

## Notes on using your own certificate with CSR and your own CA

When using CSR to get a trusted certificate, you need to replace step 2 in [Storware Backup & Recovery Server (when using own certificate)](#storware-backup--recovery-server-when-using-own-certificate) with several steps including CSR generation, and download the CRT signed by your CA. The steps are as follows:

1. Generate the CSR - answer the same set of questions as above:openssl req -new -newkey rsa:2048 -nodes -keyout storware.key -out storware.csr.
2. Send your CSR and have it signed by your CA.
3. Download your CRT file and save it as storware.crt (note that you should have your working directory set to `/opt/vprotect`).
4. Download your CA certificate chain (for example for a singleca.crt) and import it with the CA\_ALIAS of your choice as follows:

   ```
   keytool -import -trustcacerts -keystore /usr/lib/jvm/jre/lib/security/cacerts -storepass changeit -noprompt -alias CA_ALIAS -file ca.crt
   ```
5. Now continue from PKCS12 bundle generation (step 3 in the section above).


# LVM setup on Storware Backup & Recovery Node for disk attachment backup mode

{% hint style="info" %}
**Note:** This is required for backup of virtual environments when using disk attachment mode, such as Nutanix backups.
{% endhint %}

Storware Backup & Recovery Node attaches VM disks that potentially are clones of its own (for example if Node deployed from the template) - you need to configure LVM on the Node so that it doesn't scan for LVM volumes where disks are being attached.

1. Set the following variables in `/etc/lvm/lvm.conf` in `devices` section - so that only system volumes are being detected by LVM daemon (in this example sda disk with 2 partitions - sda1 and sda2):

   ```
   devices {
            filter = [ "a|^/dev/sda|", "a|^/dev/sda1|", "a|^/dev/sda2|", "r|.*|" ]
            global_filter = [ "a|^/dev/sda|", "a|^/dev/sda1|", "a|^/dev/sda2|", "r|.*|" ]
   }

   ```
2. Check with `vgscan -vvv` that your OS volumes are still being detected:

   ```
        Allocated VG vg_vprotect at 0x55914f19fac0.
        Importing logical volume vg_vprotect/lv_root.
        Importing logical volume vg_vprotect/lv_swap.
   ```
3. Reboot:

   ```
   reboot
   ```


# Full versions of libvirt/qemu packages installation

Make sure that your `libvirt` supports the `virsh blockcommit` operation. CentOS distribution requires you to install the full `libvirt` and `qemu-img` from the `oVirt` repository. This can be done like this:

1\. Install oVirt repo:

```
yum install http://resources.ovirt.org/pub/yum-repo/ovirt-release42.rpm -y
```

2\. Update the packages

```
yum update -y
```

which should replace `qemu` related packages with full versions from the oVirt repo.


# SSH public key authentication

## General

Instead of using password authentication - anywhere where you're able to provide SSH credentials (hypervisors, VMs applications, etc) you also have the public key alternative.\*\*.\
By default, Storware Backup & Recovery uses the `/opt/vprotect/.ssh/id_rsa` path, however, you also can override it with your own path\*.\
***\*(this needs to be owned by `vprotect` user and make sure it has the `0400` permission set.***\
***\*\*You don't have to pass a passphrase, you can leave this parameter blank.***

{% hint style="info" %}
**Note:**

Storware Backup & Recovery does not support keys other than "RSA"
{% endhint %}

### Example

1\. Generate a key or use yours and store it as `/opt/vprotect/.ssh/id_rsa` (make sure that the `vprotect` user and group own the file)

* example key generation:

```
[root@vProtect3 vprotect]# sudo -u vprotect ssh-keygen -t rsa -m PEM
Generating public/private rsa key pair.
Enter file in which to save the key (/opt/vprotect/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /opt/vprotect/.ssh/id_rsa.
Your public key has been saved in /opt/vprotect/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:86HSLKYwl7maDR7U1oIH1Y6VDtRFNJgHgfdjikg3VnQ vprotect@vProtect3
The key's randomart image is:
+---[RSA 2048]----+
|   .o=+XE        |
|   .o X...       |
|  .  O o         |
|  .+=.o +        |
| .o+=o.oS..      |
| ..o.+.o + .     |
|  = + + + .      |
| . O + o         |
|  +.+            |
+----[SHA256]-----+
```

2\. use `ssh-copy-id` to upload your public key (as `vprotect` user) to the KVM host:

```
sudo -u vprotect ssh-copy-id -i /opt/vprotect/.ssh/id_rsa.pub root@HYPERVISOR
```

3\. Check if you're able to log in to the hypervisor using the local `vprotect` user without being asked for the password:

```
[root@vProtect3]# sudo -u vprotect ssh -i /opt/vprotect/.ssh/id_rsa root@dkvm
Last failed login: Mon Jan 29 17:53:01 CET 2018 from 10.50.1.107 on ssh:notty
There was 1 failed login attempt since the last successful login.
Last login: Mon Jan 29 17:52:39 2018 from 10.50.1.107
[root@dKVM ~]# logout
```

4\. Now you should be able to index VMs regardless of the password set for the hypervisor (the key should be used instead)

5\. Provide path to key (default: /opt/vprotect/.ssh/id\_rsa) in Storware Backup & Recovery dashboard

![](/files/Nborm410RMuPOnrjqMDi)


# Enabling HTTP(S) Proxy for Storware Backup & Recovery

You can configure the system to communicate through an HTTP(S) proxy. You can configure the `HTTP_PROXY` and `HTTPS_PROXY` environment variables using the `vprotect.env` file.

1. Edit the vprotect.env file that is located in `/opt/vprotect/vprotect.env`. Uncomment the following lines and specify the correct proxy address:

   ```
   http_proxy="proxy.address:8080"
   https_proxy="proxy.adress:8080"
   no_proxy="localhost,127.0.0.1"
   ```

   <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p>Make sure to change proxy.address to the address of your proxy, it can be either IP address or FQDN.</p></div>
2. Restart the Storware Backup & Recovery Node and Server to apply the changes.

   ```
   systemctl restart vprotect-node vprotect-server
   ```

Repeat above steps for each host where the Server and/or Node is installed.


# Endpoints – how to install

In this section, you will find information about installing and configuring Storware Endpoints server.

We recommend that you start with the [Installation Overview ](/70/deployment/endpoints-how-to-install/installation-overview)to see what general steps are required to install Storware Endpoints server. Choose the method that best suits your needs or experiences.

What's in this chapter:

[Installation overview](/70/deployment/endpoints-how-to-install/installation-overview)

[Administration levels](/70/deployment/endpoints-how-to-install/administration-levels)

[Common tasks](/70/deployment/endpoints-how-to-install/common-tasks)


# Installation overview

1. Select your installation option. You have the following to choose from:
   * ["All-in-One" Installation](/70/deployment/endpoints-how-to-install/installation-overview/all-in-one-installation)
   * [Installation directly](/70/deployment/endpoints-how-to-install/installation-overview/direct-installation) from Storware Backup and Recovery WebUI
   * [Installation with RPMs](/70/deployment/endpoints-how-to-install/installation-overview/installation-with-rpms)
2. If you have chosen the **Installation with RPMs** option you have to configure and connect an external IBM Spectrum Protect server (see [IBM Spectrum Protect server configuration](/70/deployment/endpoints-how-to-install/installation-overview/ibm-spectrum-protect-server-configuration) section). If you'd like to install the IBM Spectrum Protect server on the machine, ask the [Storware support team](mailto:ps@storware.eu) for assistance if needed),
3. Once you've finished the configuration process, you can perform the [Initial configuration](/70/deployment/endpoints-how-to-install/initial-configuration).
4. In the next step, perform [Client deployment](/70/deployment/endpoints-how-to-install/client-deployment) on selected endpoints in your organization.
5. Test basic operations to verify that deployment is completed (go to the [Backup and recovery tests](/70/deployment/endpoints-how-to-install/backup-and-recovery-tests) section)


# "All-in-One" Installation

Storware Endpoints server can be installed on a physical or virtual machine in the "All-in-one" configuration. To do this, the customized script can be executed. It configures the server all required server resources (dedicated disk partitions), installs IBM Spectrum Protect binaries and Storware Backup & Recovery Endpoints server binaries and the service.

The installation script can be found at the address:

<https://repo.storware.eu/storware/endpoints-local-install.sh>

Before you start the installation process please do the following tasks:

1. Install and configure a server according to the requirements of your environment (see the [Sizing Guide](/70/deployment/sizing/storware-endpoints) section).

   <div data-gb-custom-block data-tag="hint" data-style="info" class="hint hint-info"><p>It is recommended to install Storware Endpoints on different machine than Storware Backup &#x26; Recovery.</p></div>

2\. Log in as \*\*root\*\* user over \*\*SSH\*\* protocol to the machine you want to install Storware Endpoint server on. 3. Run \`lsblk\` command to check the system name for the disk you will use as a storage destination. 4. In this example, disk \*\*sdb, sdc, sdd, sde, sdf\*\* were added to the system platform.

````
```
[root@centos8 mapper]# lsblk
NAME                   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                      8:0    0   50G  0 disk
├─sda1                   8:1    0  600M  0 part /boot/efi
├─sda2                   8:2    0    1G  0 part /boot
├─sda3                   8:3    0 14.4G  0 part
│ ├─vg_system-lv--root 253:0    0 46.8G  0 lvm  /
│ └─vg_system-lv_swap  253:1    0  1.6G  0 lvm  [SWAP]
└─sda4                   8:4    0   34G  0 part
  └─vg_system-lv--root 253:0    0 46.8G  0 lvm  /
sdb                      8:16   0  100G  0 disk
sdc                      8:32   0   35G  0 disk 
sdd                      8:48   0   70G  0 disk 
sde                      8:64   0   70G  0 disk 
sdf                      8:80   0    1T  0 disk 
```
````

5\. Prior to installation, make sure you've got access to **repo.storware.eu** site. 6. Now the system platform is ready to deploy Storware Endpoints server. To start server installation, copy and paste this command to the system console and press ENTER:

````
```
bash < <(curl -s https://repo.storware.eu/storware/endpoints-local-install.sh)
```
````

7\. The installation process may take up to 30 minutes, but it depends on your system performance. 8. After the installation process is finished, you can check the Storware Endpoints server service status by using the following command:

````
```
[root@centos8 ~]# systemctl status sbr-endpoints-server
● sbr-endpoints-server.service - Storware Backup and Recovery for Endpoints
Loaded: loaded (/usr/lib/systemd/system/sbr-endpoints-server.service; enabled; vendor preset: disabled)
Active: active (running) since Tue 2022-05-17 10:19:28 CEST; 1 weeks 2 days ago
Process: 1263 ExecStart=/opt/storware/kodo-server/api-core/bin/start.sh (code=exited, status=0/SUCCESS)
    Tasks: 153 (limit: 49440)
Memory: 1.8G
CGroup: /system.slice/sbr-endpoints-server.service
        └─1316 java -XX:+DisableExplicitGC -XX:+UseG1GC -XX:+UseStringDeduplication -XX:MaxGCPauseMillis=500 -Xmx2g -Xms2g -jar ../lib/kodo-server-api.jar --systemproperties ../config/payara.properties

May 17 10:18:26 centos8 systemd[1]: Starting Storware Backup and Recovery for Endpoints...
May 17 10:18:34 centos8 start.sh[1263]: Starting API (pid:1316).
May 17 10:19:28 centos8 systemd[1]: Started Storware Backup and Recovery for Endpoints.
```
````

9\. You can also use the command below to check the version of the installed Storware Endpoints server:

````
```
[root@centos8 /]# curl -k https://localhost:8181/api/version
{"value":"5.0.4"}
```
````

10\. If the Storware Endpoints server is up and running, you can continue with [add endpoints](/70/protecting-endpoints/add-endpoints) to Storware Backup & Recovery


# Direct Installation

Storware Backup and Recovery Endpoints server can be installed on a physical machine or as a virtual machine.

The [sizing guide](/70/deployment/sizing/storware-endpoints) describes requirements for a virtual or physical machine to install Storware Endpoint

{% hint style="info" %}
It is recommended to install Storware Endpoints on different machine than Storware Backup & Recovery.
{% endhint %}

Log into Storware Backup and Recovery WebUI. Go into the Endpoints tab and in "Deployment Type" you can choose Installation Endpoint server without or with IBM Spectrum Protect Server.

![](/files/2VB61uyJjbwvNp4mW27B)

Then You need to provide SSH access to the machine where the Storware Endpoint server is going to be installed.

![](/files/mJ2NlRo74W9LT0gBcEYm)

{% hint style="info" %}
**Note:** When installing Endpoint server, you can overwrite the default password to kodoadmin
{% endhint %}

If you want to customize your installation, clik on **Advanced options**. New window will open. There you can change installation parameters. Comment out the line with the parameter you want to change, edit the vaule and click **Save** button. In the example below, we have changed MariaDB version to 10.6 (default is 10.4).

![](/files/DXBcmTWcTFQjg1Fj4Gaj)

{% hint style="info" %}
**Note:** If you provide a password in the form and in the configuration file, Storware Backup & Recovery will take this from the form into account.
{% endhint %}


# Installation with RPMs

## Prerequisites

1. Install CentOS/RHEL 8 minimal:
   * we recommend having Red Hat's support available if you're going to use RHEL
   * you can use version CentOS/RHEL 7 as well
2. Make sure your OS is up to date (as the `root` user):

   ```
   # dnf -y update
   ```

   If the kernel is updated, then you need to reboot your operating system.
3. Install Storware-endpoints repository:

   * create a file `/etc/yum.repos.d/kodo-endpoints.repo`
   * edit the file and insert the information presented below

   ```
   [kodo-endpoints]
   name=Kodo for Endpoints
   baseurl=https://repo.storware.eu/storware/current/el8/
   enabled=1
   gpgcheck=0
   ```
4. Install MariaDB repository:

   * generate `.repo` file at [MariaDB download](https://downloads.mariadb.org/mariadb/repositories) site
   * copy and paste generated repo file into `/etc/yum.repos.d/MariaDB.repo`, so it looks similar to this (this one for CentOS/RHEL 8):

   ```
   # MariaDB 10.4 CentOS repository list - created 2021-08-08 11:18 UTC
   # http://downloads.mariadb.org/mariadb/repositories/
   [mariadb]
   name = MariaDB
   baseurl = http://yum.mariadb.org/10.4/centos8-amd64
   module_hotfixes=1
   gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
   gpgcheck=1
   ```

{% hint style="info" %}
It is recommended to install Storware Endpoints on different machine than Storware Backup & Recovery.
{% endhint %}

## Storware Endpoints server installation

Storware Endpoints server consists of a server (central management point with WebUI and MariaDB database). To install the server components, do the following steps:

1. Log in as the `root` user.
2. Use the command below to install `sbr-endpoints-server` the package.

```
# yum install sbr-endpoints-server
```

The installation process starts. Select "**y**" when asking about the GPG key:

```
Retrieving key from 
https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
 Importing GPG key 0x1BB943DB: Userid : "MariaDB Package Signing Key 
package-signing-key@mariadb.org
" Fingerprint: 1993 69e5 404b d5fc 7d2f e43b cbcb 082a 1bb9 43db From : 
https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
 Is this ok [y/N]
```

The installation process should take a few minutes.

The installation should be finished with the "**Complete**!" message.

## Storware Endpoints server initialization

Once the Storware Endpoints server is installed, you have to perform the server initialization. Before you start, make sure the MariaDB database service is running. Execute the following command:

```
# systemctl status mariadb
● mariadb.service - MariaDB 10.4.20 database server
   Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/mariadb.service.d
           └─migrated-from-my.cnf-settings.conf
   Active: active (running) since Thu 2021-08-05 09:27:56 CEST; 1 day 7h ago
```

If the service is not running, start it by executing the following command:

```
# systemctl start mariadb
```

As the `root` user run the following script:

```
# /opt/storware/kodo-server/api-core/bin/sbr-init.sh --dbpassword xyz
```

Follow the instructions to complete the configuration.

{% hint style="info" %}
You can use the following parameters with the script:

**--dbpassword password -** password for Storware Endpoints database (default: random value)

\--dbport port - database port number (default: 3306)

\--dbusername username - database username (default: kodo)
{% endhint %}

#### Example:

```
[root@localhost ~]# /opt/storware/kodo-server/api-core/bin/sbr-init.sh --dbrootpassword xxxxx
Storware KODO for Endpoints server initial configuration script (v1.0)
MariaDB host:  localhost
MariaDB port:  3306
MariaDB KODO database user:  kodo
MariaDB KODO user password:  HbhJhrhCfyrpak5nOWgWicEPRs3DgU52
MariaDB root password:  1qazxsw23edc
Creating symlinks
Connecting to database localhost:3306
Checking if database user exists
Checking if database exists
Creating db user
Creating database
Granting privilages
Configuring database
Restarting database
Updateing KODO for Endpoints configuration
Preparing dsmcert database
Start KODO server with: systemctl start sbr-endpoints-server
[root@localhost ~]#
```

Storware Endpoints server initialization script creates the **Storware-Endpoints** service (sbr-endpoints-server), which is the main server process. To start the **Storware-Endpoints** service, execute the following command:

```
# systemctl start sbr-endpoints-server
```

## Configuring firewall

1. You have to open the 8181 port (for HTTPS, HTTP requires port 8080) on the firewall. Here is an example:

   ```
   # firewall-cmd --add-port=8181/tcp --permanent
   # firewall-cmd --complete-reload
   To check open ports:
   # firewall-cmd --list-all
   ```
2. If the Storware Endpoints server is up and running, and firewall ports are open, you should be able to log in to Storware Backup & Recovery using your browser, and in the Endpoints tab add a new installed Storware Endpoints server using `https://IP_OF_YOUR_MACHINE:8181` that you just created.

{% hint style="info" %}

```
**Note:** Storware Endpoints server credentials are presented in chapter [Administration levels](../administration-levels.md)
```

{% endhint %}

1. Storware Endpoints server credentials are presented in chapter [Administration levels](/70/deployment/endpoints-how-to-install/administration-levels)

Go to the [IBM Spectrum Protect server configuration](/70/deployment/endpoints-how-to-install/installation-overview/ibm-spectrum-protect-server-configuration) section to learn how to prepare and configure the IBM Spectrum Protect server for use with the Storware Endpoints server.


# IBM Spectrum Protect server configuration

Storware Endpoints server is using the enterprise IBM Spectrum Protect server as the backup provider. Prior to use, it requires an additional configuration. Create it in accordance with this guideline.

## Creating domain, policy, and management class

Storware Endpoints system requires some special IBM Spectrum Protect configuration. Create a configuration in accordance with this guideline:

1. Log in to the console as the`root`user. Next, you have to log in to the IBM Spectrum Protect server as an administrator with **SYSTEM** level authority. Run the `dsmadmc`command:

   ```
   # dsmadmc
   IBM Tivoli Storage Manager
   Command Line Administrative Interface - Version 7, Release 1, Level 8.8
   (c) Copyright by IBM Corporation and other(s) 1990, 2020. All Rights Reserved.

   Enter your user id:  admin

   Enter your password:

   Session established with server KFE: Linux/x86_64
     Server Version 8, Release 1, Level 12.100
     Server date/time: 07/21/2021 11:45:23  Last access: 07/20/2021 15:44:42


   tsm: SERVER1>
   ```
2. Define new dedicated domain, policy, and management class for Storware Endpoints

   ```
   SERVER1> define domain kodo
   SERVER1> define policy kodo kodo
   SERVER1> define mgmt kodo kodo 30days
   ```
3. Define a new copy group and assign it as default. Remember to change `destination` parameter according to your Spectrum Protect configuration.

   ```
   SERVER1> define copy kodo kodo 30days destination=POOL_NAME rete=30 reto=30 vere=nol verd=nol 
   SERVER1> assign defmgmt kodo kodo 30days
   SERVER1> activate policy kodo kodo
   ```

{% hint style="info" %}
TIP: You can change the retention setting, as well as the name of the management class.
{% endhint %}

## Registering a new node and administrator account

Register a new node and update administrator information. Created node and administrator will be used by Storware Endpoints to manage protected data.

### **IBM Spectrum Protect < 8.1**

{% hint style="info" %}
**Authority class SYSTEM is mandatory.**
{% endhint %}

```
SERVER1> register node kodo.COMPANY_NAME client_password dom=kodo maxnummp=100 dedup=client backdel=yes passexp=0
SERVER1> update admin kodo.COMPANY_NAME passexp=0
SERVER1> grant authority kodo.COMPANY_NAME cl=sys
```

### **IBM Spectrum Protect >= 8.1**

```
SERVER1> register node kodo.COMPANY_NAME client_password dom=kodo maxnummp=100 dedup=client backdel=yes passexp=0
SERVER1> register admin kodo.COMPANY_NAME client_password
SERVER1> update admin kodo.COMPANY_NAME passexp=0
SERVER1> grant authority kodo.COMPANY_NAME cl=sys
```


# Administration levels

Storware Backup & Recovery with Storware Endpoints server was designed in a multi-tenancy architecture. It means that you can define multiple organizations (tenants) within one instance of Storware Backup & Recovery. In each organization instance, you can backup a separate set of endpoints you defined.

To be able to administer the server using different levels of access, the Storware Backup & Recovery was designed to leverage two administration levels:

* **Storware Endpoints Server Management**
* **Storware Endpoints Administrator**

Please find the description for each administration level below.

{% hint style="info" %}
**Note:** default login and password

Username: kodoadmin

Password: k0do\@dmin
{% endhint %}

## **Storware Endpoints Server Management**

Storware Endpoints Server Management level is the highest level of authorization. If you log in to the Web UI as this type of user, you gain the same level of access to Endpoints Management as Storware Backup & recovery Global Admin. You can configure global system settings and other assets as follow:

* Download or upload installer packages
* Manage administrators
* Manage Storware Endpoints organizations
* Configure system settings:
  * General and Customizations
  * E-mail server settings
  * IBM Spectrum Protect server settings
  * Licensing information
  * Logs
  * Billing settings
  * DB backup configuration

## Storware Endpoints Administrator

Storware Backup & Recovery allows your company to create multiple organizations under one Storware server. Every organization is a separate entity with separated data, settings, users, policies, etc. If you log in as the Endpoints Administrator user, you can configure the system assets like:

* Users
* Devices
* Backup SLAs (Policies)
* Client Deployment
* Organization administrators
* LDAP connection
* Users synchronization
* Notifications

The default organization name is “**My organization**”. It is created during Storware Endpoints server deployment.

{% hint style="info" %}
**Note:** You can change the default organization name after logging on to the system as the Endpoints Server Management user or Storware Global Admin. Go to the Organizations menu and click the name of the organization you want to edit.
{% endhint %}


# Initial configuration

Log in to the Storware Backup & Recovery WebUI and in the Endpoints tab enter the default username and password for the global Admin

{% hint style="info" %}
**Note:** Make sure you added an existing Endpoint server or installed a new one using [Direct Installation](/70/deployment/endpoints-how-to-install/installation-overview/direct-installation)
{% endhint %}

If you are asked to accept the temporary certificate, do it by clicking on the link displayed

{% hint style="info" %}
**Note:** Make sure you have added the license to Storware Backup & Recovery
{% endhint %}

1. Go to the **Settings\Endpoints instance settings** menu and in the **General** tab. Enter the **Deployment server name** (it is the Storware Endpoints server IP address with the 8181 port added).

![](/files/SAylXylyQAnosf7i41fv)

. Next, go to the **Email** tab and complete the email settings. Provide the necessary information for the e-mail server configuration:

* **E-mail address** – the address used to send e-mails from the Storware Endpoints server
* **Login** – the user name used to login to the e-mail server (optional if the server requires authentication)
* **Server address** - IP or DNS name of the e-mail server
* **Port** - the e-mail server port
* **Use SSL** - check the box if SSL communication is required
* **SSL Port** - TCP Port number used by the SSL SMTP server
* **Require Authentication** - check the box if the server requires authentication
* **Set Email Server Password**- set the password for the user in the **Login** field

3\. Save the settings and send a test email using **Send Test Email** button.

4\. Go to the **License** tab and upload a valid Storware Endpoints license (the `license.key` file). If you don't have one, you can contact the Storware team.

5\. Go to the **IBM Spectrum Protect** tab. Check if there's a connection with the IBM server (the status should be **Connected**).

![](/files/EFMs8I4iqucZAmNfr2It)

If **IBM Spectrum Protect** is not connected please \*\*\*\* enter the following settings:

* **Server address -** enter the server address (**don't use** `localhost,` \*\*\*\* enter the IP address where \*\*\*\* Storware Endpoints server with IBM Spectrum Protect is located)
* **Port** - set the number at 1502
* **Administrative Port** - set the number at 1503
* **Node name** - it's the node name you've configured in the previous section

6\. In the **SET IBM SPECTRUM PROTECT PASSWORD** field, enter the password you've set in the previous section. Click the **Update Password** button to save it. The **Server Connection Status** should be changed to **Connected** (it may take a while). If the status is **Not connected**, please refresh the web browser site.

7\. Go to the DB Backup, to configure **MariaDB** backup. It can be set to be triggered once a day at a given time. The files in the format "**db\_date\_time*****.*****sql***"* are stored in the folder **/opt/StorwareData/db\_backup**. You can also set the number of stored backups.

![](/files/gAdZzugBWeZj5W2WMmJy)

Go to the [Client deployment section](/70/deployment/endpoints-how-to-install/client-deployment) to get to know how to deploy the Storware Endpoints client application on the endpoints.


# Backup and recovery tests

If the Storware Endpoints client was successfully installed and you can log in to the Storware Endpoints client console the backup process will start automatically. When the backup is finished, you should the following status in the **Overview** menu.

![](/files/0bLFNg3NWaGcyoOBg4sc)

Go to the **Backups** tab and select a file to restore. Click the **Restore** button to start a recovery process.

![](/files/XsYP1YuUlC5YOE5xFyof)

Restore the file to the original location, desktop, or a different location.

![](/files/B7doDJ06CRTWQiKib84t)

Go to the chosen location to check if the file was restored.

You can also create a file manually and restore it afterward using the mouse "right-click" context menu.

To do that, follow the steps:

1. Create a file, enter some information in it and save it.
2. Right-click on the file, go to the Storware Endpoints option and choose a version to restore.

![](/files/YkXi3joQYlSqTVvHO9G4)

3\. Overwrite the existing file or create a copy.


# Client deployment

Storware Endpoints client is an application designed to backup and restore data from client devices (laptops/desktops) running the Windows operating system.

{% hint style="info" %}
**Note:** MacOS client is currently available in technical preview mode only.
{% endhint %}

The application utilizes Continuous Data Protection (CDP) which provides comprehensive protection for all information and is able to provide the most optimal and secure access to corporate/private data.

The Storware Endpoints client application has exceptional and unique features that address the issues that exist in every organization:

* Continuous data protection (CDP)
* Incremental backup
* File versioning
* Deduplication and compression on the source (endpoint)
* "Right-click" approach restore for files
* "Point-in-time" restore
* Privacy policy, integration with the IBM Spectrum Protect server.
* User data encryption

The Storware Endpoints client must be installed and configured on each endpoint to protect its data with CDP functionality, as well as recover data. The Storware Endpoints client can be installed using the following installation method:

1. [Client installer](/70/deployment/endpoints-how-to-install/client-deployment/client-installer) package to deploy it locally on the endpoint.
2. Sending the [Deployment email "Magic Link"](/70/deployment/endpoints-how-to-install/client-deployment/deployment-email) and the links to download the Storware Endpoints client installer.
3. Using [GPO](/70/deployment/endpoints-how-to-install/client-deployment/client-installation-using-gpo) feature or MS SCCM application.


# Deployment packages

To use the Storware Endpoints client, you must upload the Storware Endpoints client packages first.

{% hint style="info" %}
**Note:** You can download the current Storware Endpoints client package (in the ZIP format) from the site <https://repo.storware.eu/storware/current/>. The package name is **Endpoints.Windows.x.x.x.zip**
{% endhint %}

To upload client packages to your Storware Endpoints Server, do as follow:

1. Check if the new Storware Endpoints client package is available (or contact the Storware team).
2. Log in to the Storware Backup & Recovery WebUI.
3. Go to the **Endpoints** -> **Packages** view.
4. Click the **Upload package** button, select download client package, and click the **Open** button.
5. The package will be uploaded. After successful upload, the package will be displayed on the list of available packages.

![](/files/UrxFfSfXRh6UGYOeeoEP)


# Client installer

To download the Storware Endpoints client installer, open Storware Backup & Recovery WebUI, and go to **Endpoints** -> **Packages** view and then click the **Download global installer**.

From the **Download package** window, choose the appropriate installation version of the client installer you want to install. The package will be downloaded locally.

![](/files/bTZYHYhY0AvRGIBcS7Mw)

You can copy the installer to the endpoints where you want to install the software.

To start the installation process and do the following steps:

1. Go to the download directory and run the package. It may take a moment for the installer to start. The application will be installed in the default directory. Click the **Install** button.

![](/files/HIWR7yBlmhAixNWRgYmD)

1. Wait for the installer to finish (it can take a few minutes).

![](/files/ChXrIKLEGiV3r1ZnH1Bk)

3\. Find the Storware Endpoints icon on your desktop and launch it. Enter the server's IP address or name, username, and password (check the "Remember me" box if you want your user to be remembered). Click the **Log in** button.

![](/files/EPQaOjtAshlXDZYHcxJk)

4\. If the authorization is correct, you should see the Storware Endpoints user console.


# Deployment email "Magic Link"

The organization administrator can send the deployment email to selected users. The e-mail a user receives looks like the one below. It contains the download links to the Storware Endpoints client installer packages and the "Magic Link". Allows the user to automatically log in to the Storware Endpoints server without having to enter a password.

![](/files/6xfp5fRTWfBSYIo5oQ4H)

To send the deployment email by e-mail message, open Storware Backup & Recovery WebUI. Go to the **Endpoints** -> **Users** view and select a user you want to send the e-mail to. Choose the **Deploy Client** from the **Action** menu. Alternatively, you can click the **Deploy Client** button.

![](/files/gk5ySTa45cqHE7wE24dl)

{% hint style="info" %}
**Note:** To send a single message containing download links and instructions for multiple users simultaneously, just select the check box next to all selected usernames and then click the **Deploy Client** button in the upper right corner.
{% endhint %}


# Client installation using GPO

The Storware Endpoints client software can be deployed on the endpoint in the organization using the GPO feature. Follow the instruction below to install the Storware Endpoints client remotely in your organization.

{% embed url="<https://docs.microsoft.com/en-us/troubleshoot/windows-server/group-policy/use-group-policy-to-install-software>" %}

{% hint style="info" %}
Before deploying client software, check the prerequisites for the endpoint operating system (see the [Storware Endpoints client support](/70/deployment/platform-requirements#endpoints-client-support) section).
{% endhint %}


# Silent install

You can deploy Storware Endpoints client in silent mode. To do that, follow the steps below:

1. Download the Storware Endpoints client installer and copy it to the endpoint you want to install the software.
2. Run the command line prompt as the administrator and go to the folder the installer has been copied.
3. Type in the command: **msiexec /i Endpoints\_Windows\_x64.msi /quiet** and wait a few minutes.

![](/files/ChYgNe37IKGexODvHxsF)

Once the installation process is complete, close the command prompt and click the Storware Endpoints icon on the user's desktop or use the "**magic link**" from the deployment email to log into the Storware Endpoints server. You can use other options for the **msiexec** command if needed (visit the site <https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/msiexec>).


# Client application components

Once the Storware Endpoints client software was installed, there are some changes made on the user's endpoint. Three application folders are created and the service handles continuous data protection.

## Application folders <a href="#application-folders" id="application-folders"></a>

Storware Endpoints client creates three folders by default on the system drive during the installation process:

* C:\Program Files\Storware\Kodo
* C:\ProgramData\Storware\Kodo
* C:\KodoTemp

The first folder contains all installation components and files required by the Storware Endpoints client.

All application settings, Tivoli Storage Manager settings, and logs from any client components are in `C:\ProgramData\` folder.

The third folder is a part of the Storware Endpoints **Continuous Data Protection** function.

**KodoTemp** folder is configured as hidden by default and located on system drive **C:\KodoTemp**. It is used to copy protected files after any change. This ensures that a backup version of the file is available after every change, even if there is no Internet access. All changes will be uploaded to the backup server when the network connection is restored.

The size of the KodoTemp folder can be set in the backup policy. It is good practice to set a maximum folder size to prevent running out of space on the system disk.

## Continuous Data Protection service <a href="#continuous-data-protection-service" id="continuous-data-protection-service"></a>

A core part of Storware Endpoints is a system service named **KodoService**. KodoService is used for the Continuous Data Protection (CDP) process. It tracks all changes in files and directories included by the backup policy. It should have access to all folders and files so KodoService is running on SYSTEM privileges.

![](/files/BpxRmVw3eL6mEbZOwOhc)


# First time log in

A user can use the Storware Endpoint client console to connect to the Storware Endpoint server using:

* Domain user account
* Local user account
* [Deployment email "Magic Link"](/70/deployment/endpoints-how-to-install/client-deployment/deployment-email)

## **Domain user account**

To use the application, the user must be authenticated on the Storware Endpoint server. To do this, start the application for the first time (using the Storware Endpoint \*\*\*\* icon on the user's desktop) and fill in the following configuration fields:

* **Server-** enter the Storware Endpoint server address in your organization (with 8181 port)
* **Username -enter the user name as "\_domain\username**\_" or "**domain\@username** (it depends on the username format set at the LDAP settings at the **Settings** view)
* **Password-** enter the domain user password.

Optionally, check the "**Remember me**" option (the user password will be saved). Click the **Log in** button.

After successful logging, the device is added to the devices list on the server. The backup process will start immediately and the first full backup will be performed.

## **Local user account**

The local user is created by the organization administrator on the Storware Endpoint server. Provide the following information in the logging window fields:

* **Server-** enter the Storware Endpoint server address in your organization (with 8181 port)
* \*\*Username -\*\*enter the local user name (the defined e-mail address during the user creation process)
* **Password-** enter the user password.

Optionally, check the **Remember me** option (the user password will be saved). Click the **Log in** button.

![](/files/j8tu0G13NpLhhE9VW9fl)

## **Magic Link**

If an organization administrator has sent a deployment email, it contains a "magic link" shortcut with which a user (local or domain) can be authorized on the Storware Endpoint server. The user should click the "magic link" to be automatically logged in to the Storware Endpoint server.

{% hint style="info" %}
**Note:** After installation and successful login, the process of securing files in the selected locations will start automatically according to the assigned policy.
{% endhint %}

{% hint style="info" %}
**Note:** If there was a previous installation of Storware Endpoint, the total content of **C:\ProgramData\Storware\\** should be removed before the installation!
{% endhint %}


# Common tasks

In the next section, there are described the most common tasks that an administrator can perform on the Storware Endpoints server.&#x20;


# OS update

Based on the best practices it's recommended to perform periodic operating system upgrades. To do it, log in as the `root` user and execute the following command:

```
# dnf -y update
```

The update process will start without confirmation of the update package download. It is recommended to restart the server after the update is complete.


# Server upgrade

When the new Storware Endpoints server upgrade package is available it is uploaded to the Storware repository server (`https://repo.storware.eu/storware/current/`).

To do the Storware Endpoints server upgrade, do the following steps:

1. Login to the shell as the `root` user.
2. Use the `dnf clean all` command to clean information about cached packages.
3. To update the Storware Endpoints server, execute the following command:

   ```
   # yum update sbr-endpoints-server
   ```
4. If the command was executed successfully and the process is completed, the Storware Endpoints server has to be restarted. To do this, do as follow:
   1. Switch to the `kodo` user:

      ```
       #su kodo
      ```
   2. Go to the `/opt/storware/kodo-server/api-core/bin/` directory

      ```
       $ cd /opt/storware/kodo-server/api-core/bin/
      ```
   3. Execute the script `stop.sh` and then `start.sh`. You can also check the server status:

      ```
      $ ./stop.sh
      Stopping API (pid:1432)....
      $./start.sh
      Starting API (pid:1373).....
      $./status.sh
      API (pid:1373) running.
      ```
5. Now you can log in again to the Storware Backup & Recovery WebUI and use the Storware Endpoints tab.




---

[Next Page](/llms-full.txt/1)

