Why Does the backup_export Command-Line Script Fail While the 'Full Server Backup' Operation Succeeds in TIBCO Data Virtualization Studio?

Why Does the backup_export Command-Line Script Fail While the 'Full Server Backup' Operation Succeeds in TIBCO Data Virtualization Studio?

book

Article ID: KB0137701

calendar_today

Updated On:

Products Versions
TIBCO Data Virtualization All Supported Versions
TIBCO Data Virtualization All Supported Versions
TIBCO Data Virtualization All Supported Versions
TIBCO Data Virtualization All Supported Versions
TIBCO Data Virtualization All Supported Versions
TIBCO Data Virtualization All Supported Versions
TIBCO Data Virtualization All Supported Versions
TIBCO Data Virtualization All Supported Versions
TIBCO Data Virtualization All Supported Versions

Description

This article explains why the backup_export command-line script may fail with the below error while the 'Full Server Backup' operation completes successfully in TDV Studio.

Command:

> ./backup_export.sh -server 10.17.xx.xx -port 9400 -pkgfile /home/backup/tdv_backup.car -user admin -password password -encryptionPassword 123456

Error:

ERROR: Could not login with the following info:
  Host:     10.17.xx.xx
  Port:     9400
  Username: admin
  Password: ********
  Domain:   composite
  Encrypt:  false
Reason: java.rmi.RemoteException: Failed to connect to http://10.17.xx.xx:9400/cdms/webapi; nested exception is: 
    java.rmi.RemoteException: HTTP Status-Code 400: Bad Request; nested exception is: 
    HTTP Status-Code 400: Bad Request; nested exception is: 
    java.rmi.RemoteException: Failed to connect to http://10.17.69.26:9400/cdms/webapi; nested exception is: 
    java.rmi.RemoteException: HTTP Status-Code 400: Bad Request; nested exception is: 
    HTTP Status-Code 400: Bad Request

Resolution

In some cases, monitoring tools installed on Linux servers have been found to interfere with the TDV backup export/import behavior.

To check which monitoring services are actively running on a Linux system, you can use the following command:

systemctl list-units --type=service | grep running

Common examples of monitoring tools that could impact performance include:

  • Dynatrace OneAgent
  • Elastic Agent

If such agents are identified and suspected to be causing issues, the admin can temporarily stop them using systemctl commands and rerun the backup export/import commands:

sudo systemctl stop oneagent         # Stops Dynatrace
sudo systemctl stop elastic-agent    # Stops Elastic Agent

Issue/Introduction

Why Does the backup_export Command-Line Script Fail While the 'Full Server Backup' Operation Succeeds in TDV Studio?