You are here: Configuration Considerations > Directory Structure

Directory Structure

The directory structure for the database will be different for each database management system that is used with the SAP system. Please consult the SAP installation guide specific to the database management system for details on the directory structure for the database. All database files must be located on shared disks to be protected by the LifeKeeper Recovery Kit for the database. Consult the database specific LifeKeeper Recovery Kit Documentation for additional information on protecting the database.

See the Directory Structure Diagram below for a graphical depiction of the SAP directories described in this section. 

The following types of directories are created during installation:

Physically shared directories (reside on global host and shared by NFS):

/<sapmnt>/<SAPSID> - Software and data for one SAP system (should be mounted for all hosts belonging to the same SAP system)

/usr/sap/trans - Global transport directory (has to have an export point)

Logically shared directories that are bound to a node such as /usr/sap with the following local directories (reside on the local host with symbolic links to the global host):




Local directories (reside on the local host and shared) that contain the SAP instances such as:

/usr/sap/<SAPSID>/DVEBMGS<No.> -- Primary application server instance directory

/usr/sap/<SAPSID>/D<No.> -- Additional application server instance directory

/usr/sap/<SAPSID>/ASCS<No.> -- ABAP central services instance (ASCS) directory

/usr/sap/<SAPSID>/SCS<No.> -- Java central services instance (SCS) directory

/usr/sap/<SAPSID>/ERS<No.> -- Enqueue replication server instance (ERS) directory for the ASCS and SCS

The SAP directories: /sapmnt/<SAPSID> and /usr/sap/trans are mounted from NFS; however, SAP instance directories (/usr/sap/<SAPSID>/<INSTTYPE><No.>) should always be mounted on the cluster node currently running the instance. Do not mount such directories with NFS. The required directory structure depends on the chosen configuration. There are several issues that dictate the required directory structure.

NFS Mount Points and Inodes

LifeKeeper maintains NFS share information using inodes; therefore, every NFS share is required to have a unique inode. Since every file system root directory has the same inode, NFS shares must be at least one directory level down from root in order to be protected by LifeKeeper. For example, referring to the information above, if the /usr/sap/trans directory is NFS shared on the SAP server, the /trans directory is created on the shared storage device which would require mounting the shared storage device as /usr/sap. It is not necessarily desirable, however, to place all files under /usr/sap on shared storage which would be required with this arrangement. To circumvent this problem, it is recommended that you create an /exports directory tree for mounting all shared file systems containing directories that are NFS shared and then create a soft link between the SAP directories and the /exports directories, or alternately, locally NFS mount the NFS shared directory. (Note: The name of the directory that we refer to as /exports can vary according to user preference; however, for simplicity, we will refer to this directory as /exports throughout this documentation.) For example, the following directories and links/mounts for our example on the SAP Primary Server would be:

For the /usr/sap/trans share




created on shared file system and shared through NFS


mounted to / (on shared file system)


soft linked to  /exports/usr/sap/trans

Likewise, the following directories and links for the <sapmnt>/<SAPSID> share would be:

For the <sapmnt>/<SAPSID> share




created on shared file system and shared through NFS


mounted to / (on shared file system)


NFS mounted to <virtual SAP  server>:/exports/sapmnt/<SAPSID>

Detailed instructions are given for creating all directory structures and links in the configuration steps later in this documentation. See the NFS Server Recovery Kit Documentation for additional information on inode conflicts and for information on using the new features in NFSv4.

Local NFS Mounts

The recommended directory structure for SAP in a LifeKeeper environment requires a locally mounted NFS share for one or more SAP system directories. If the NFS export point for any of the locally mounted NFS shares becomes unavailable, the system may hang while waiting for the export point to become available again. Many system operations will not work correctly, including a system reboot. You should be aware that the NFS server for the SAP cluster should be protected by LifeKeeper and should not be manually taken out of service while local mount points exist.

To avoid accidentally causing your cluster to hang by inadvertently stopping the NFS server, please follow the recommendations listed in the NFS Considerations topic. It is additionally helpful to mount all NFS shares using the 'intr' mount option so that hung processes resulting from inaccessible NFS shares can be killed.

NFS Mounts and su

LifeKeeper accomplishes many database and SAP tasks by executing database and SAP operations using the su - <admin name> -c <command> command syntax. The su command, when called in this way, causes the login scripts in the administrator’s home directory to be executed. These login scripts set environment variables to various SAP paths, some of which may reside on NFS mounted shares. If these NFS shares are not available for some reason, the su calls will hang, waiting for the NFS shares to become available again.

Since hung scripts can prevent LifeKeeper from functioning properly, it is desirable to configure your servers to account for this potential problem. The LifeKeeper scripts that handle SAP resource remove, restore and monitoring operations have a built-in timer that prevents these scripts from hanging indefinitely. No configuration actions are therefore required to handle NFS hangs for the SAP Application Recovery Kit.

Note that there are many manual operations that unavailable NFS shares will still affect. You should always ensure that all NFS shares are available prior to executing manual LifeKeeper operations.

Location of <INST> directories

Since the /usr/sap/<SAPSID> path is not NFS shared, it can be mounted to the root directory of the file system. The /usr/sap/<SAPSID> path contains the SYS subdirectory and an <INST> subdirectory for each SAP instance that can run on the server. For certain configurations, there may only be one <INST> directory, so it is acceptable for it to be located under /usr/sap/<SAPSID> on the shared file system. For other configurations, however, the backup server may also contain a local AS instance whose <INST> directory should not be on a shared file system since it will not always be available. To solve this problem, it is recommended that for certain configurations, the PAS’s, ASCS's or SCS’s /usr/sap/<SAPSID>/<INST>, /usr/sap/<SAPSID>/<ASCS-INST> or /usr/sap/<SAPSID>/<SCS-INST> directories should be mounted to the shared file system instead of /usr/sap/<SAPSID> and the /usr/sap/<SAPSID>/SYS and /usr/sap/<SAPSID>/<AS-INST> for the AS should be located on the local server.

For example, the following directories and mount points should be created for the ABAP+Java Configuration:




mounted to / (on shared file system)


mounted to / (on shared file system)

/usr/sap/<SAPSID>/ERS<No.> mounted to / (on shared file system)

/usr/sap/<SAPSID>/ASCS<Instance No.>

mounted to / (on shared file system)

/usr/sap/<SAPSID>/ERS<No.> mounted to / (on shared file system)

/usr/sap/<SAPSID>/AS<Instance No.>

created for AS on backup server

Directory Structure Diagram

The directory structure required for LifeKeeper protection of ABAP only environments is shown graphically in the figure below. See the Abbreviations and Definitions section for a description of the abbreviations used in the figure.

Directory Structure Example




Directory Structure Options

The configuration steps presented in this documentation are based on the directory structure and diagrams described above. This is the recommended directory structure as tested and certified by SIOS Technology Corp.

There are other directory structure variations that should also work with the SAP Recovery Kit, although not all of them have been tested. For configurations with directory structure variations, you should follow the guidelines below.

© 2012 SIOS Technology Corp., the industry's leading provider of business continuity solutions, data replication for continuous data protection.