Show TOC

Data Backup (Online) and RestoreLocate this document in the navigation structure


You back up TREX indexes and queues online using Python scripts without stopping TREX and while the TREX search continues to be available. You then restore the saved data offline. This is the usual way to back up TREX data. It is a good idea to back up the TREX indexes if the original index creation process took a long time and you want to avoid having to reindex if the full-text information is lost. SAP also recommends that you back up your data if a large number of documents have been added to an index since the original indexing process.


Backup and restore of TREX during live operation is only possible under certain circumstances. It is absolutely necessary to observe these prerequisites, because otherwise inconsistencies and corrupt indexes or queues occur, with subsequent data loss.

  • You require a Python version that is delivered and installed with the TREX installation.

  • You require the following Python scripts for the backup:



      These scripts are located in the /usr/sap/<SAPSID>/TRX<instance_number>/exe/python_support directory.

  • SAP recommends that you make sure that no write accesses of the following types take place during the backup procedure:

    • Creation, deletion, or resetting

    • Changing attributes

    • Indexing

    • Changing taxonomies

    You cannot automatically suppress all write access to TREX from within TREX. You can only take administrative action (manual monitoring) to check that no write access of these types takes place.

    The application using TREX (for example, Knowledge Management in the Enterprise Portal) should also not carry out any TREX-related write operations. For example, you must check that no crawler process is running and that the KM repositories are set to read only. This restriction is to prevent data inconsistencies and data loss between TREX and the application using the TREX data.

    Data backup can only be carried out with active write access. Each index is backed up consistently on its own. If, from an application perspective, multiple indexes constitute a logical index, it is possible that these indexes might be saved with statuses that do not match.

  • The TREX search is available during the data backup procedure.

  • The TREX search is not available during the restoration of the TREX data.

  • You can also back up TREX queues.

  • Only TREX indexes and queues and their configuration are backed up. The configuration of the TREX landscape is not backed up.

  • During the import procedure, the system attempts to restore index distribution as it was in the system from which you exported the indexes.

  • You can import indexes even if you have not exported them previously.

  • You can make the directory from which you import the data into the index directory.

  • During the backup, the system takes into account all documents with the statuses preprocessing, to be indexed, indexing, to be optimized, optimizing, and optimized. The system does not take into account all documents with the statues failed and to be preprocessed.

  • You can also use the scripts in distributed TREX landscapes.

  • Following the import, you can use index replication to distribute the indexes on the slaves. In the case of a distributed installation, you only need to back up the index on the TREX master index server.


    We recommend starting the backup on the host that the TREX master index server runs on. In this way, you can avoid overloading the network.


Use the and Python scripts to carry out the following activities: