Please enter search query.
Search <book_title>...
Veritas NetBackup™ Flex Scale Release Notes
Last Published:
2023-03-01
Product(s):
Appliances (2.1)
Platform: NetBackup Flex Scale OS
- Getting help
- Features, enhancements, and changes
- What's new in this release
- Support for immutability
- Deploying external certificates
- Support for Universal Shares and Instant Access
- Recovering the catalog file system using GUI
- Deploying a NetBackup Flex Scale cluster as a scale-out media server
- Enabling lockdown mode and providing WORM storage during initial configuration
- Improved diagnostic support
- Support for Security-Enhanced Linux (SELinux)
- Setting login banners
- Managing password policies
- Terminology changes
- Registering the appliance
- Performing disaster recovery using GUI
- Support for NetBackup Client
- What's new in this release
- Limitations
- Known issues
- Cluster configuration issues
- Cluster configuration fails with error docker createOneFile failed for file /mnt/nblogs/.tpconfig_cred in container nb_media
- Cluster configuration fails if there is a conflict between the cluster private network and any other network
- Cluster configuration process may hang due to an ssh connection failure
- DNS servers that are added after initial configuration are not present in the /etc/resolv.conf file
- Initial configuration of the cluster fails if multiple DNS servers are specified in the YML configuration file
- Empty log directories are created in the downloaded log file
- For the private network, if you use the default IPv4 IP address but specify an IPv6 IP other than the default, the specified IPv6 IP address is ignored
- Node discovery fails during initial configuration if the default password is changed
- Disaster recovery issues
- Backup data present on the primary site before the time Storage Lifecycle Policies (SLP) was applied is not replicated to the secondary site
- When disaster recovery gets configured on the secondary site, the catalog storage usage may be displayed as zero
- Catalog backup policy may fail or use the remote media server for backup
- Takeover to a secondary cluster fails even after the primary cluster is completely powered off
- Catalog replication may fail to resume automatically after recovering from node fault that exceeds fault tolerance limit
- Unable to configure and create AD/LDAP users on the secondary cluster if disaster recovery is configured
- If the replication link is down on a node, the replication IP does not fail over to another node
- During upgrade on a cluster on which disaster recovery is configured, the upgrade task may be triggered again
- After upgrade is performed, the 'Executing the full discovery' task appears as ongoing under Recent Activity
- After you upgrade to NetBackup Flex Scale 2.1 from 1.3.1 version, the replication is in paused state
- If both primary and secondary clusters are down and are brought online again, it may happen that the replication is in error state
- Disaster recovery configuration fails if the lockdown mode on the secondary cluster is enterprise or compliance
- Unable to perform a takeover operation from the new site acting as the secondary
- Enabling compliance mode for the first time on the secondary cluster may fail if disaster recovery is configured
- If disaster recovery is configured and an upgrade is performed, an alert appears that the master server is offline on the secondary cluster
- Infrastructure management issues
- Storage-related logs are not written to the designated log files
- Unable to start a node that is shut down
- Arrival or recovery of the volume does not bring the file system back into online state making the file system unusable
- Unable to replace a stopped node
- An NVMe disk is wrongly selected as a target disk while replacing a SAS SSD
- Disk replacement might fail in certain situations
- Replacing an NVMe disk fails with a data movement from source disk to destination disk error
- Unable to detect a faulted disk that is brought online after some time
- When NetBackup Flex Scale is configured, the size of NetBackup logs might exceed the /log partition size
- Nodes may go into an irrecoverable state if shut down and reboot operations are performed using IPMI-based commands
- Add node fails because of memory fragmentation
- Replace node may fail if the new node is not reachable
- NetBackup certificates tab and the External certificates tab in the Certificate management page on the NetBackup UI show different hosts list
- The NetBackup web GUI does not list media or storage hosts in Security > Hosts page
- Media hosts do not appear in the search icon for Recovery host/target host during Nutanix AHV agentless files and folders restore
- On the NetBackup media server, the ECA health check shows the warning, 'hostname missing'
- The backup host pool is not visible while configuring the Dynamic NAS (DNAS) policy on a NetBackup Flex Scale cluster.
- Node is displayed as unhealthy if the node on which the management console is running is stopped
- Unable to collect logs from the node if the node where the management console is running is stopped
- Self test fails in a media server only deployment
- Log rotation does not work for files and directories in /log/VRTSnas/log
- After replacing a node, the AutoSupport settings are not synchronized to the replacement node
- Unable to start or stop a cluster node
- Miscellaneous issues
- If NetBackup Flex Scale is configured, the storage paths are not displayed under MSDP storage
- Failure may be observed on STU if the Only use the following media servers is selected for Media server under Storage > Storage unit
- Red Hat Virtualization (RHV) VM discovery and backup and restore jobs fail if the Media server node that is selected as the discovery host, backup host, or recovery host is replaced
- Primary server services fail if an nfs share is mounted at /mnt mount path inside the primary server container
- NetBackup fails to discover VMware workloads in an IPv6 environment
- The file systems offline operation gets stuck for more than 2hrs after a reboot all operation
- cvmvoldg agent causes resource faults because the database not updated
- SQLite, MySQL, MariaDB, PostgreSQL database backups fail in pure IPv6 network configuration
- Exchange GRT browse of Exchange-aware VMware policy backups may fail with a database error
- Call Home test fails if a proxy server is configured without specifying a user
- Replicated images do not have retention lock after the lockdown mode is changed from normal to any other mode
- NetBackup primary container goes into unhealthy state
- Unable to switch the lockdown mode from normal to enterprise or compliance for a cluster that is deployed with only media servers and with lockdown mode set to normal
- Networking issues
- DNS of container does not get updated when the DNS on the network is changed
- Cluster configuration workflow may get stuck
- Bond modify operation fails when you modify some bond mode options such as xmit_hash_policy
- Node panics when eth4 and eth6 network interfaces are disconnected
- AD/LDAP configuration may fail for IPv6 addresses
- Upgrade issues
- After an upgrade, if checkpoint is restored, backup and restore jobs may stop working
- Upgrade fails during pre-flight in VCS service group checks even if the failover service group is ONLINE on a node, but FAULTED on another node
- During EEB installation, a hang is observed during the installation of the fourth EEB and the proxy log reports "Internal Server Error"
- EEB installation may fail if some of the NetBackup services are busy
- During an upgrade the NetBackup Flex Scale UI shows incorrect status for some of the components
- After upgrading from version 1.3.1 to 2.1, Call Home does not work
- After an upgrade, the proxy server configured for Call Home is disabled but is displayed as enabled in the UI
- Unable to view the login banner after an upgrade
- After an upgrade to NetBackup Flex Scale 2.1, the metadata format in cloud storage of MSDP cloud volume is changed
- Rollback fails after a failed upgrade
- Add node operation hangs on the secondary site after an upgrade
- UI issues
- In-progress user creation tasks disappear from the infrastructure UI if the management console node restarts abruptly
- During the replace node operation, the UI wrongly shows that the replace operation failed because the data rebuild operation failed
- Changes in the local user operations are not reflected correctly in the NetBackup GUI when the failover of the management console and the NetBackup primary occurs at the same time
- Mozilla Firefox browser may display a security issue while accessing the infrastructure UI
- Recent operations that were completed successfully are not reflected in the UI if the NetBackup Flex Scale management console fails over to another cluster node
- Previously generated log packages are not displayed if the infrastructure management console fails over to another node.
- Cluster configuration issues
- Fixed issues
Takeover to a secondary cluster fails even after the primary cluster is completely powered off
The takeover to a secondary cluster fails even after primary cluster is completely powered off with the following error:
<cluster_name> cluster is either running or not completely down. Takeover of replication role is not permitted
In a rare scenario, the status of a remote cluster cannot be determined. The remote cluster status can be obtained from the console using the following command.
# haclus -display <remote_cluster_name> | grep ClusState
The takeover operation is permitted only when the remote cluster status is faulted or exited. But due to a bug, the remote cluster status shows the status as unknown even after the remote cluster is powered off. Also, if the remote cluster is powered off when the local cluster is down, the remote cluster status shows init. The takeover is not permitted in these scenarios. (4012004)
Workaround:
If the user can confirm that the remote cluster is down, then the takeover can be forced by running the following commands manually from the console.
Run the following command:
# /opt/VRTSnas/pysnas/bin/nso_replication.py --command update_master_server_etc_hosts --data '{"fqdn": "<master_fqdn>", "new_ip": "<new_master_ip>","old_ip": "<old_master_ip>"}'Update the DNS entry of master server FQDNs to the IPs of the new primary.
Run the following command:
# hagrp -online -propagate -force NBUMasterBrain -any
Run the following command:
# /opt/VRTSnas/scripts/rep/nso_replication.sh prepare primary
Run the following command:
# /opt/VRTSnas/pysnas/bin/nso_replication.py --command clear_host_cache
Verify that the master server (nbu_master) is online and healthy and all media servers are healthy.