TrilioVault release 4.1 introduces new features and capabilities including:
Openstack Ussuri support
New File Recovery Process
Increased Openstack independency
Installation Optimization for Kolla Ansible Openstack, Ansible Openstack, and Red Hat Openstack Platform
Support for External MySQL/MariaDB databases
Incremental Backup for nova booted instances
Support of Openstack User Groups
New Quota: Snapshots
S3 Support for Kolla Ansible Openstack
UI enhancement for selective Restore
TrilioVault 4.1.94 is the GA release of TrilioVault 4.1
TrilioVault 4.1 continues to enable Openstack versions and Distributions, allowing TrilioVault customers to stay up to date with Openstack releases.
TrilioVault 4.1 introduces full support for Openstack Ussuri for Kolla Ansible Openstack, Ansible Openstack, and Canonical Openstack. In addition, Triliovault 4.1 does of course support the active long-term releases from Red Hat and Canonical. Openstack users of those releases can continue to use the latest TrilioVault functionalities.
Since TrilioVault was released for the first time was the File Recovery Manager instance in tandem with TrilioVault. The File Recovery Manager instance helped customers to easily and quickly fetch and restore files and folders directly from the backups.
Over the years did more and more customers request to have the File Recovery Manager on their own images or on a specific Linux distribution. We looked into the possibility to create multiple versions of the File Recovery Manager which was identified as not getting to the point of flexibility our customers need.
The result was a revamp of the File Recovery Manager which allows the installation on any CentOS-based or Ubuntu-based instance.
TrilioVault has the goal to become an integrated part of Openstack since its first draft on a whiteboard. Back then were the TrilioVault services defined as sub-services of Nova and TrilioVault tied deeply into the already existing nova services and became an integral part of it.
Over the years did the nova service change and possibilities that were once available have been taken out from nova. This plus the required lengthy qualification of all Openstack Versions and Distributions made it clear that a change is required.
TrilioVault 4.1 is now a complete stand-alone service, which is communicating with nova and other Openstack services through APIs only. The goal of this independence is to speed up future qualification and requalification cycles to provide a broader support matrix again.
TrilioVault's integration into Openstack already starts with the installation process. This process required manual installation steps in the past, which were hard to automize and scale on bigger environments.
TrilioVault 4.1 is therefore introducing Ansible Playbooks for Kolla-Ansible and Ansible Openstack, while the integration with Red Hat Director has been deepened. Further, the TrilioVault configurator does now allow to set the backup target on the TrilioVault Appliance directly based on Distribution.
The TrilioVault Appliance provides its own database. A database that suits the needs of 99% of Trilio's customers. Some customers do have higher requirements. Be it performance, security, or just the general design of the Openstack itself.
For these customers and everyone who wants to use it is TrilioVault 4.1 introducing the possibility to configure TrilioVault with an external database.
Openstack provides the possibility to start an instance from a Cinder Volume or directly using the Glance Image and a nova volume.
TrilioVault always provided incremental forever backups for all cinder volumes. Root-Volumes from nova-booted instances were always taken as a full backup of the Glance image and the actual VM root volume.
TrilioVault 4.1 does introduce incremental backups for nova booted instance root volumes. This allows TrilioVault 4.1 to provide incremental backups to any type of root volume.
TrilioVault is using the Openstack Keystone service to authenticate any user and to verify that the right permissions are set. Openstack Keystone allows to group users and set the permissions to the group.
These Openstack User Groups are now fully supported.
TrilioVault 4.0 introduced the Quota functionality, which allowed to set quotas for the number of workloads, number of VMs and amount of storage used by a single tenant.
Triliovault 4.1 extends this feature by the number of TrilioVault Snapshots that a Tenant is allowed to have.
S3 is becoming the standard to transfer data to and from storage solutions. TrilioVault introduced S3 already in Version 3.0 but had to take it out for Kolla Ansible since Kolla Ansible has been added to the Support Matrix.
TrilioVault 4.1 is now closing that gap to other Openstack Distributions and provides full S3 support for Kolla Ansible Openstack Ussuri.
The Selective Restore is the most powerful and complex restore TrilioVault has to offer. The UI needs to be easy to understand and help the user to fulfill its task.
Several points have been identified to improve this requirement of usability. The selective restore now allows to select or deselect all VMs at once. Further are the VMs now provided in an easy to overview list and the sub-controls can be expanded and collapsed as necessary.
This release contains the following known issues which are tracked for a future update.
Login into the iscsi device is getting rejected for the TrilioVault service
Result is the Snapshot not moving forward until timing out
The workloadmgr Quota feature is still fully supported through CLI.
It has been observed that on non-kolla, non-rhosp setups, such as openstack ansible, nova user id is not same as we consider as default(162).
Another observation is that, the id which is assigned to nova, was conflicting with id of system user in TVM, this created a situation where we had to redeploy Openstack.
Update permissions of /var/triliovault-mounts to 755
VM Volumes stored on Ceph are successfully excluded from backup if desired
Restore does create empty Ceph Volume
created empty Ceph Volume is not attachable or formattable
For every restore will the metadata config_drive be set as blank value
No impact on restored VMs known
delete metadata config_drive
or set desired value
TVault re-configuration while adding nodes to existing TVM cluster fails at "Configuring TrilioVault Cluster"
Reason is that the prev mysql password was not working and mysql root access has be reset.
remove /root/.my.cnf file on already configured TVM and reconfigure it
After TVault re-configuration post addition of 2 more nodes to existing TVM cluster ("import workloads" was not seleted), the databases do not sync against already existing TVM.
It is expected that while adding the 2 new nodes, the db on node1 should get synced up with 2 new nodes and the existing workloads should be available post the reconfig on the new 3 node TVM cluster.
Run workload import from CLI
VM was set with metadata exclude_boot_disk_from_backup set to true
Restored instance showed, that data was backed up and restored
Reinitialize does not keep the already uploaded Openstack Certificates used to communicate with Openstack.
Upload Certificates again
When the import functionality is used via CLI is the scheduler trust changed from enabled to disabled.
Configure/re-configure TVO with import option from UI after reinitialize.
After reinitializing was neither the UI nor CLI showing Node information
Restart wlm-workloads and wlm-cron services on TrilioVault nodes
systemctl restart wlm-workloads
systemctl restart wlm-cron
Running more than 25 workloads at the exact same time leads to error
dmapi service is not responding
Snapshots fail with "object is not subscriptable"
Just changing the backup target in the Kolla Ansible configuration files and redeploying leads to dmapi container stuck in restart
Follow guide to Switch Backup Target on Kolla-Ansible
SSL enabled Openstack
Backup and Restore jobs fail with with missing TLS CA certificate bundle error
Configure the TrilioVault appliance with Openstack CA provided
OR Provide Openstack CA to