Blog - Shortcut IT

Direkt zum Seiteninhalt

Saving system specific tables using R3trans

Shortcut IT
Veröffentlicht von in Sc4SAP · 19 März 2020
Tags: R3trans
Here is a short description how to back up system specific tables with Sc4SAP (and how to restore them in case you need it).

We take the RFC connections for this example. In case they get lost you are in big trouble. Outgoing data can not be sent any longer, functions using RFC connections are not working any longer. Maybe in a very short time your system produces thousands of short dumps.

You don't have the possibility to get back this data from another system as every system has its own individual RFC connections. There is no way to import the data via transport request or similar. Without having a backup of the specific tables the only chance would be to set up a new system via system copy using a full backup of the concerned system. A huge effort, and very time consuming - time during which your SAP system is not working properly!
BTW, indeed we noticed complaints that during an SAP Upgrade the RFC connections got lost :-(  Thus, in front of an SAP upgrade saving the RFC connections might be a good idea.  

The procedure described here might also be a solution when you have to do a system copy (e.g. from a productive system to a quality or test system to get recent data on them) and there is no "PCA tool" (see below). Just export the RFC connections of the quality or test system in front of the system copy and restore them afterwards.

Ok, let's start:

1.: Determine the tables that are relevant. In general it is not really easy to get the knowledge about the related tables of a specific area, but here - for system specific tables - we have some help from the "PCA tool" (Post Copy Automation). Have a look into the function module SCTC_GET_WHITELIST. This function module gives information about the components managed by the PCA tool and their related tables, all listed in the source code of the function module.

BTW, you might get more ideas related to system copies and saving of system specific tables by viewing the components and their related tables in this function module. Beside RFC connection data there are also other suitable tables for restoring them, especially with regard to the preparation and post-processing of a system copy: ALE configuration, the SAP license, ECATT, logical files / paths, TMS configuration, variants, web services etc. etc. etc...
You can also execute program SCTC_LIST_TABLES to show tables of a component. However, due to license issues (the use of the PCA tool requires some prerequesites) the program might deny your request. In that case you can try this program which is a modified copy of it, showing all components managed by the PCA tool and their related tables in one big list. And here is the output of the program taken from my local SAP system (NW AS ABAP 7.52).


2.: Use the "Process table data using R3trans" function to create a data file with all contents of all tables related to RFC connections. Some of the given tables are client-dependent (other than most of the RFC tables), therefore you have to specify a client. Sc4SAP allows us to specify '*' in the client field, which means all clients. Of course you can also specify a specific client. Regarding the RFC tables saving the data for all clients is to be recommended (see footnote #1).
Depending on the release of your SAP systems maybe not all of them exist in your system. Sc4SAP checks this and indicates missing tables. Just leave them out.


As our purpose in this example is to create a backup of table contents we place the backup file on the application server. Of course you can also use the frontend for storing the data. In that case you have to use an SAP connection using a user with dialog capabilities because of the download of the data file to your computer. In this example storing the data on the application server seems to be a good idea, and DIR_HOME seems to be a suitable directory, but you can use any directory that is accessible by the server. If the user used in the connection is a system user, you have to remove the flag in the "With SAPGUI" field.
Now let's start the export. As there is (usually) a small amount of data in the RFC tables it takes a few seconds only and the Messages / log area indicates finishing the task:

3.: Looking into the log file should definitely be done, especially when you do this a first time. If we would have used the Frontend as the location it would of the data file this could be done by a mouse click only, but in this case we used the server. So we use transaction AL11 for viewing the log file. Selecting DIR_HOME we can see the 2 files created:


The log file contains the information about the written data:


That's all for the moment. It took only some minutes to create a backup file of the RFC connections - and hopefully we don't need it, but in case the RFC connections would get lost (shit happens!) we can use this backup file to create them again. When there is a change regarding the RFC connections of course also the backup file should be refreshed.

Let's assume we get into the trouble of lost RFC connection data and want to restore the RFC connections. Or we made the backup in advance of a system copy and want to get back the original data in our refreshed system.

Use the "Process table data using R3trans" again for restoring the data. In case the current RFC data in your system is corrupt you should use the "Remove / Clientremove" option first. Specify the tables to be deleted and it will be done. You don't have to use all tables that were written into the data file. In case you have to restore only few or a single table you can specify them / it in the text field and data of other tables will not be processed.
In our example we don't know if only one or few tables are concerned, therefore we take all RFC tables and import the data back into the system:


In DIR_HOME we now see also the log file for the import:




The data is imported, the RFC connections are restored and work properly. The operability of our system is given again, and it took only few minutes!



Footnote #1: There is one special table here: RSECTAB ("Secure Storage: Memory for Encrypted Data"). There is a special issue regarding the "Secure storage": its data is stored using a special value '___' for the client.
In the R3trans log file shown above we can see 12 entries of that table exported and also imported lateron. It is not possible to view the entries using SE16 or similar tools (SE16 shows a message "You can not display RSECTAB with the standard tools"). But with transaction SECSTORE you can see the records:


These are the 12 entries mentioned in the R3trans log files, and you can see that nearly all of these entries have this strange value '___' in the client field. They contain passwords (in an encrypted form) for users used in RFC connections as well as in some other areas (e.g. for the database connection - at the left side in transaction SECSTORE you see some applications using the secure storage), and the intention for using this value is to achieve more security regarding sensitive password information in an "invisible" client. Well, for the regular users SAP did it not like this and stored the hashed values for the passwords beside all other client related data in the same client. I guess the reason for implementing the "Secure storage" with this "invisible" client is that the passwords are encrypted instead of hashed like the usual passwords, and of course the SAP system needs to decrypt the value back to the password for using the credentials in the RFC connection. This offers a wider attack surface for hackers than a hashed value (which offers no approach to get back to the original value except time consuming brute-force attacks), and this probably explains this additional hurdle.
BTW, if you are interested in SAP's password security, this blog article might also be worthwhile for you.

But this is really an extraordinary and special case - you don't have to expect similar stumbling blocks with other tables than those related to the "Secure storage". But for the RFC connections this table likely has to be considered, and that is the reason why we specified client '*' when we exported the RFC data. Otherwise we would not catch the entries with client '___' and there would be no possibility to restore also the passwords of the users in the RFC connections in case these entries would get lost. SAP note 1532825 describes some trouble with the Secure storage after a system refresh and offers some workarounds - but it seems to me that the better solution would be to avoid the hassle and effort of repairing invalid data by making a backup of that data and restoring it after the system copy...



Kein Kommentar
Shortcut IT GmbH
Kreuzberger Straße 8
31226 Peine
Tel.: 0170/9377125
Zurück zum Seiteninhalt