Troubleshooting Guide
Introduction
This guide is intended to help you quickly identify and resolve problems and errors during setup, installation and during normal operation of your SEP sesam system. SEP sesam often indicates that there has been a change or event that impacts overall system performance. Changes in SEP sesam backup performance are usually caused by system changes or failures.
First steps
To solve problems quickly and efficiently, make yourself familiar with the general troubleshooting information. Attempt to identify and resolve the problem by yourself. If you cannot find a solution to your problem, report it to SEP sesam support. The support team will then provide you with further instructions.
Identifying the problem
It is important to identify a problem as accurately as possible so that the best solution to the problem can be applied. Answer the following questions to identify the problem you are experiencing:
- What was the message or error?
- When did the error first appear?
- Does the error always occur after a specific action?
- Does the error always occur at the specific time, e.g., in the morning, in the evening, etc.?
- What steps are necessary to duplicate the error?
- Did you make any changes to your SEP sesam environment before the error occurred?
Common problems you can solve by yourself
Below is a list of the most common problems you can solve by yourself. Most of the errors you are likely to encounter can be solved by following these instructions.
- Check with sm_main status to see if all processes are running. If necessary, start the missing process again with sm_main reload.
- View the day log and search for errors.
- Check if the failure was caused by a Newday event. You can prevent Newday from aborting running activities, as described at Newday Event.
- Check if there is a time frame set in the schedule after which the scheduled event is cancelled (option Stop task if it runs longer...). See Creating a Schedule.
- Check specific protocols for backups, restores.
Before contacting support
Before contacting SEP sesam support, make sure that you have exhausted any options that might enable you to solve the problem by yourself. Perform these general checks:
- Check whether your problem is described in the Error Messages Guide or Troubleshooting Guide.
- Browse through the FAQ and check the forum.
- Go through the Common problems you can solve by yourself checklist above.
- Collect all relevant data about the problem and send it to SEP sesam support:
- error output
- message ID
- SEP sesam version (Server, RDS and Client)
- operating system environment
- LOGs (when there is a problem with a backup job, choose in the GUI 'JOB STATE'- 'BACKUPS' - Right click on the affected job and select the bottom menu item 'Download archive with all log files' -> Please send the created LOG archive too.) Proceed in the similar way for restore, migration or replication.
How to interpret SEP sesam's backup module's error messages?
SEP sesam backup modules are designed to produce extended error messages which may return information from 5 layers: SBC – XBSA – FTP – SMS – operating system. SEP sesam scans the protocol files for warnings and errors after backup and restore. In the event of a warning or an error, the first identified message is printed in the summary at the end of the protocol.
Every backup module uses the X/Open Backup Services API (XBSA) standard. SEP sesam XBSA is based on FTP implementation. The backup module connects to SEP sesam's FTPD daemon implementation – Sesam Transfer Protocol Daemon (STPD). Sesam Transfer Protocol Daemon (STPD) is a service that requests and delivers the backup data from or to the SMS Server and manages the data flow between the SEP sesam Server and a client. During a restore STPD receives the data from the SMS Server and sends it to the client, which then restores the data to the target system. Sesam Multiplex Stream (SMS) is a service that receives the backup data from STPD and writes the data to the backup media. During a restore, it reads the data from the backup media and sends it to STPD. Additionally, the SEP sesam backup client (SBC) module executes backup, migration and restore tasks. SBC collects and consolidates backup data on the client system and delivers it to STPD. A list of all SBC messages (C header file) can be found at SBC Messages.
An error message is composed of the messages from the triggering layer up to the upper layers. If an operating system returns an error, the error code and the operating system message are added to the SEP sesam error message. Because of this, error messages can also help troubleshoot problems that are not caused by SEP sesam (for example, OS problems).
Typical backup protocol
The following example shows a typical backup protocol. It is composed of 4 sections: about module, operational parameters, processing, and a summary.
2009-06-26 10:28:16: sbc-3036: Info: # SESAM BACKUP CLIENT FOR Windows NT FILE SYSTEMS, VERSION: 3.2A17 Build Revision: 1.257 (x64), Released: Jun 25 2009 # 2009-06-26 10:28:16: sbc-3063: Info: -------------------- Operation Parameters -------------------- 2009-06-26 10:28:16: sbc-3019: Info: OS info: Microsoft Windows Server 2008, Build: 6001 Service Pack 1 (x64) 2009-06-26 10:28:16: sbc-3100: Info: Program PID: 42900 2009-06-26 10:28:16: sbc-3030: Info: Operation: BACKUP, Level: COPY 2009-06-26 10:28:16: sbc-3031: Info: Storage Host: qsbox3:11001,0-0:SESAM_SECURE_AUTHENTICATION:**** 2009-06-26 10:28:16: sbc-3032: Info: Control Host: qsbox3:11001:SESAM_SECURE_AUTHENTICATION:* 2009-06-26 10:28:16: sbc-3040: Info: Device: SMS:disk1:SHARE:64 2009-06-26 10:28:16: sbc-3064: Info: --------------------- Operation Messages --------------------- 2009-06-26 10:28:16: sbc-3002: Info: Building file list from: [C:\SEPsesam\var\ini] 2009-06-26 10:28:16: sbc-3022: Info: Command line ["sbc" "-b" "-C" "qsbox3:11001" "-S" "qsbox3:11001" "-l" "copy" "-s" "SF20090626102812" "-d" "SMS:disk1" "-t" "weekly00001:1" "-j" "TEST_BACKUP" "-i" "job=TEST_BACKUP,nod=qsbox3,cmd=sbc,src=C/ /SEPsesam /var/ini,ptf=WNT,typ=Path,exc=" "C:/SEPsesam/var/ini" ] 2009-06-26 10:28:16: sbc-3003: Info: Opening saveset: SF20090626102812 2009-06-26 10:28:18: sbc-3104: Info: Saveset info: [SEGMENT=3] 2009-06-26 10:28:18: sbc-3004: Info: Begin writing to saveset... 2009-06-26 10:28:18: sbc-3074: Info: Backup start time [20090626102818] 2009-06-26 10:28:18: sbc-3143: Info: Starting with drive C: 2009-06-26 10:28:18: sbc-3006: Info: Saveset size: 98304 bytes. Throughput: 189.820 MB/Hour. 2009-06-26 10:28:18: sbc-3005: Info: Closing saveset. 2009-06-26 10:28:18: sbc-3052: Info: Items processed correctly: [25]. Not processed or incorrectly processed items: [0]. 2009-06-26 10:28:18: sbc-3007: Info: Operation successful. 2009-06-26 10:28:19: sbc-3001: Info: Exiting.
Backup error summary
The error message summary is prefixed by a short information string. The full error message is composed as follows:
{status}/{amount}/{saveset ID}/{SBCstart}/{message}
The components of this string have the following meanings:
{status} | {amount} | {saveset ID} | {SBCstart} | {message} |
0 - successful |
Amount of data stored on media | Automatically generated saveset ID | Starting time on the client | Message about the error |
The following example shows a backup error summary with all 5 layers prefixed by a short information string.
X/0/SF20060629233007/20060629232907/Error: XBSA Call BSAEndData (closing saveset) failed: System detected error, operation aborted. TRANSIENT or PERMANENT NEGATIVE reply: 553 STOR Failed. 1037: Writing data block on tape failed (23): Data error (cyclic redundancy check). 1039: Writing of Saveset Trailer failed.
The amount of details provided for backup or restore is defined by the log level.
How to set a log level
You can control the reporting (verbose) level to choose the details of messages that SEP sesam reports in various error logs. Running SEP sesam with a higher log level than default (0 for backup and restore) might be useful when you want to get more information about specific events or modules or when asked by support in the course of diagnosing your specific problem.
Note that increasing the log level increases the amount of information being logged and may negatively affect the performance of SEP sesam. Therefore you should only set a higher log level for your own analysis of a specific issue with backup or restore, or when asked by support to provide debugging information in case of troubleshooting. Once you have reproduced the issue, set the log level back to default if you have modified it in the debug.ini file.
You can set the log level in SEP sesam on the following levels:
- For specific backup or restore task in the GUI: Main selection -> Tasks -> By Clients -> double-click the backup or restore task to open the Properties. The log level is set under the Options tab for backup and Expert Options for the restore task. For details, see section Setting log level on a per-task basis in GUI.
- Globally for SEP sesam kernel modules by modifying
<SESAM_VAR>/ini/debug.ini
file on SEP sesam Server. For details, see section Setting log level globally for SEP sesam kernel modules in debug.ini.
The default SEP sesam directory for logs is <SESAM_VAR> (/var/opt/sesam/var
). For more information, see Directory Layout.
SEP sesam log levels
SEP sesam uses different log levels for different modules. The following list represents the reporting level of the backup and restore protocol, which is set in GUI on a per-task basis. Log levels are listed in order of increasing amount of information logged, from lowest to highest:
Setting | Log level details |
---|---|
0 | print only standard and error messages together with summary |
1 | display a line for every item when its processing starts: sbc-3008: Info: Processing item: [xxx]... |
2 | display a line for every item when its processing finishes: sbc-3108: Info: Item processed successfully: [xxx] |
3 | display backup module processing information (with DB_API modules) |
4 | display underlying module processing XBSA and detailed DB_API modules |
5 | display packing data (mtf, cpio, sidf) trace messages |
For details on how to set a log level for specific backup or restore task in the GUI or globally for SEP sesam kernel modules, see Setting Log Level.
Installation and configuration problems
Installation problems
SEP sesam Server installation on Windows failed
Problem
- The SEP sesam Server installation on Windows failed with an error.
Cause
- For SEP sesam Server installation a domain administrator account has been used.
⇒ Solution
- Before starting the SEP sesam installation on Windows, make sure that you are logged in as a local administrator (not domain administrator).
SEP sesam database problems
PostgreSQL startup failure after changing SEP sesam service user (Windows only)
Problem
By default, the SEP sesam service starts under the SYSTEM user account. At installation, postgreSQL database is set to start under this account. However, if the user name of the SEP sesam service is changed from SYSTEM (for example, to Administrator) after installation, PostgreSQL encounters startup issues and fails to start.
Cause
Changing the user name of the SEP sesam service affects the ownership and permissions of the PostgreSQL data directory, typically the db_pg folder. As a result, PostgreSQL is unable to access the necessary files and resources, causing failure to start up.
⇒ Solution
You can revert to the previous SEP sesam service account (SYSTEM), or change the ownership and permissions of the PostgreSQL data directory (db_pg folder) to the used SEP sesam service account user. In this case make sure you change ownership and permissions for subfolders and files as well (use Windows Explorer option Replace owner on subcontainers and objects). PostgreSQL regains the necessary access rights, enabling it to start successfully. Note that this workaround modifies the folder's ownership and permissions, so make sure that the used user account has appropriate privileges for managing the SEP sesam database.
Incorrect timezone setting in PostgreSQL
Problem
Exporting the system-wide environment variable TZ in the system-wide /etc/profile file can override the default system locales, leading to an incorrect timezone setting in the postgresql.conf file. As a result, the time values in the GUI may be incorrect. Mismatch between the system's default timezone and the TZ variable leads to inconsistent time values displayed in the GUI.
⇒ Solution
In the /etc/profile file update the TZ environment variable and set the timezone that matches the desired system default timezone. This will ensure that the timezone setting in the postgresql.conf file is aligned with the system default timezone.
License problems
SEP sesam Server license import fails
Problem
License problems after importing a newly created license
Cause
The license is not correctly imported
⇒ Solution
If you encounter problems after importing a newly created license (strange error messages; expiry message of the license, although the license file actually shows valid values; 'Valid until' shows a different value in the license info than in the license, etc.), switch to demo license and then reimport your new license. Try the following steps:
- From the SEP sesam GUI menu bar, select Help -> License information, and then click Import New License.
- Click File Manager, select the demo LIC file (sm_lic.ini) from
<SEPsesam>/skel
, and then click Apply. - In the License info dialog, click Import New License again.
- Use the File Manager to locate and import your newly issued license.
-> A final check (SEP sesam GUI menu bar -> Help -> License information) should show that the newly created license has been imported correctly and that all errors have disappeared.
License violation caused by exceeding the licensed volume
Problem
Exceeding the licensed volume of backups results in license violation.
Cause
The license violation occurs when there is too much data being considered for licensing purposes, often due to accumulated data that is no longer required.
⇒ Solution
If you encounter a license violation due to exceeding the volume, several steps can be taken:
- Check and expire the EOL of old backups that are no longer required, so they are purged and no longer count towards the license volume.
- Purge and clean up the datastore to remove any backups that should have been deleted but are still present.
- If backups are stored on tapes, they are no longer counted when the tape is reinitialized. In newer SEP sesam versions (≥5.0 Jaglion), backups are no longer counted even if the tape is deleted (including metadata deletion).
Perform a final check in the GUI under HELP - LICENSE INFO to ensure that the license error has been resolved.
Update problems
Client/RDS update does not start or does not work via GUI
Problem
- The direct update of Client/RDS via the GUI does not start.
Cause
- There is still old/wrong client information in the database, which hinders the update process.
⇒ Solution
- In the GUI, under Clients, right-click the client for which the update is not working, and then click the context menu option Reset Version Information.
- Then double-click the client to open its properties and click the trash icon next to the Last SEP sesam message field.
Now the update should start and run without any problems.
SEP sesam Server update failed
Problem
- The SEP sesam Server update failed with an error.
Cause
- SEP sesam services on the system that is being updated could not be started, causing SEP sesam Server update to fail.
⇒ Solution
- Check if SEP sesam Server services are running. If not, start the SEP sesam services manually and then use the same update for the repair installation. For details, see How to Start and Stop SEP sesam.
SEP sesam Windows Client update from v. 4.4.3.64 fails with error
Problem
- The SEP sesam Windows Client update from SEP sesam v. 4.4.3.64 Grolar to a newer version might fail with the following MSI installer error:
Unable to create a temp copy of transform
Cause
- This issue occurs if the transform path specified in the registry points to the wrong folder.
⇒ Solution
- To resolve this issue, you must rename the transform key in the Registry Editor.
Note | |
This procedure modifies the Windows registry; modifying Windows Registry incorrectly might crash your operating system and cause data loss. Ensure that you have a valid SEP sesam and operating system backup before proceeding! |
Proceed as follows:
- Open Registry Editor: use Start and type regedit.
- Navigate to the Products folder:
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products
- Depending on the installed SEP sesam Version find one of the following folders and click it:
SEP sesam Version 5.0.0.X:7737007073521AA4885C03C7AEE4954D
SEP sesam Version 5.1.0.X:7737007073521AA48A24533ED8EBE04E
- In the right pane with registry keys, right-click the Transforms key and rename it to Transforms_.
Automatic remote update from GUI fails with errors
Problem
- On Windows, automatic remote update failed with the following error:
Windows error: (0x800703FA) Illegal operation attempted on a registry key that has been marked for deletion
- The sm_msi.log log file on the client system shows the following:
InstallShield 11:08:04: Initializing Engine InstallShield 11:08:04: Marshalling the , error = 0x800703fa InstallShield 11:08:04: Open Script operation failed, error is 0x800703fa InstallShield 11:08:04: Failed to invoke __ISWIUnInit, error is 0x80070057 InstallShield 11:08:04: Failed to shutdown script engine for script C:\Users\sepshare\AppData\Local\Temp\{A2C12F7B-F8D3-4D99-8E34-61600D67DBCC}\setup.inx, error is 0x80070057 InstallShield 11:08:04: Initialize() Failure, Failed to Initialize script support, Error = 0x800703fa
Cause
- Typically, this error occurs when the sesam service is running under a specific user account instead of the default system account. An administrator uses this service user account to log on to the server (SEP sesam RDS or client) for the session and then logs off. This forcibly unloads the registry keys in the account profile and makes the keys unavailable for future use.
⇒ Solution
You have to enable the Windows User Profile Service which does not unload the registry keys after logging off:
- Open the Group Policy editor (Gpedit.msc) on the respective server.
- Open the UserProfiles folder: go to Computer Configuration -> Administrative Templates -> System -> UserProfiles.
- Look for the Do not forcefully unload the user registry at user logoff setting and select the option Enabled. For details, see Microsoft support article "800703fa Illegal operation attempted on a registry key" error .
Problems with interfaces
Alarm interface fails to send emails
The Alarm interface is designed to send backup logs, stored in the LIS file directory, to specified email recipients. In Apollon, changes have been made to the directory structure for LIS files to improve file management and optimize file system operations. LIS files are now stored in the <SESAM_ROOT>/var/lis directory, with a new sub-directory created for each Sesam day, which prevents accumulation of files in a single directory.
This change has inadvertently caused the Alarm interface to lose track of the required log files. The sm_alarm script is unable to locate the .not file, which leads to the NullPointerException error, and the Alarm interface cannot send emails.
⇒Solution
To resolve this issue, you have to manually modify the sm_alarm script. This will ensure the correct variables are used and the script can locate the required files. Note that the procedure for modifying the sm_alarm script differs slightly between Linux and Windows. For detailed instructions, refer to the sections below.
- On Linux
Open the sm_alarm.sh script and find the following line:
sm_smtp -A "sesam" -s "$mail_subject" -M "$( ls -tr ${gv_rw_lis}/$f*not|tail -1 )" ""
Replace that line with:
sm_smtp -A "sesam" -s "$mail_subject" -M "$3" ""
- On Windows
- Open the sm_alarm.ps1 script in a text editor and find the function send_backup_mail:
function send_backup_mail($type,$msg,$task) { ## Set mail subject $mail_subject = (write "Sesam ALARM: $type $task failed") ## Send Sesam not file as mail body $filename = ((Get-ChildItem "$env:lis\*$task*.not" | sort-object -property LastWriteTime | select-object -last 1).FullName) sm_smtp -A "sesam" -s "$mail_subject" -m "$msg" -a "$filename" }
Replace the function with:
function send_backup_mail($type,$message,$filename) { $task = ($message -replace ":.*","") ## Set mail subject $mail_subject = (write "Sesam ALARM: $type $task failed") ## Send Sesam not file as mail body sm_smtp -A "sesam" -s "$mail_subject" -m "$message" -a "$filename" }
- Find the following line:
{send_backup_mail $args[0] $args[1] $task
Replace that line with:
{send_backup_mail $args[0] $args[1] $args[2]
Alarm interface does not function as expected
The script that defines the functions of the Alarm interface can be modifed to customize the behaviour of the Alarm interface. In release 5.1.0.7, the script was rewritten to address an issue (see Alarm interface fails to send emails). As a result, any modifications made to the script prior to this release have been overwritten and the default behaviour of the interface is reestablished.
⇒Solution
To resolve this issue and restore the desired behavior of the Alarm interface, it is necessary to redo the customizations in the script that modified its behavior. Users should carefully review their previous modifications and apply them again to the updated script.
Uninstallation problems
For uninstallation problems, see Uninstalling SEP sesam.
System limits adjustment problem
Problem
- SEP sesam limits on the system have to be adjusted, however, the settings should not be overwritten by update.
⇒Solution
The best way to adjust SEP sesam limits on the system is to create the Systemd override file. By using this file the settings are not overwritten during the update.
To adjust limits on the system, proceed as follows:
Example
> > root@cefix:~# systemctl show sepsesam.service | grep ^LimitCORE= > LimitCORE=2147483648
- Create the override file and adjust the value:
- Reload the system by using the command:
- Then specify:
> mkdir -p /etc/systemd/system/sepsesam.service.d/ > echo "[Service]" > > /etc/systemd/system/sepsesam.service.d/override.conf echo > "LimitCORE=infinity" >> > /etc/systemd/system/sepsesam.service.d/override.conf
> root@cefix:~# systemctl daemon-reload
> root@cefix:~# systemctl show sepsesam.service | grep ^LimitCORE= > LimitCORE=infinity
Windows installer (MSI) installation error
Problem 1
- You receive the following warning: "An error occurred during the installation of assembly component... HRESULT: 0x80070bc9."
Possible causes
- MSI locks the database to install new software after Windows updates were installed.
⇒ Solution
- Reboot the host to unlock the database.
Note | |
The msi log file contains the line 'Transforming table Error' very often. This does not mean that an error occurred. It rather means that the table which is called Error has been transformed. Hence it is only an information not an error message. |
Problem 2
- Installation failed after uninstallation - you receive the following Popup:
- English: "The SEP sesam server was installed using a server installation package. Please retry the update using a server installation package instead of the server package you are using. Update will be aborted."
- German: "Der SEP sesam server wurde mit einem server Installationspaket installiert. Bitte wiederholen Sie den Update mit einem server Installationspaket statt des verwendeten server Pakets. Das Update wurde abgebrochen."
Possible causes
- The uninstallation did not remove HKLM\SOFTWARE\SEP Elektronik GmbH registry key.
⇒ Solution
- Open the MS Windows registry (e.g. call regedit) and remove HKLM\SOFTWARE\SEP Elektronik GmbH.
SLES
Problem
After upgrading the OS from SLES 11 to a newer version, SEP sesam server cannot read files in an XFS V4 datastore, whether connected directly or over iSCSI.
Cause
Starting from SLES 12, XFS no longer supports file systems in the V4 format. Newer versions, specifically SLES 12 or later, are incompatible with XFS V4, preventing SEP sesam from accessing the datastore. Note that this issue is caused by upgrading the operating system, and not by updates to the SEP sesam Server/RDS.
This may also affect other Linux distributions.
⇒ Solution
To solve this issue, create the file system XFS V5 on the partition containing the datastore:
- Migrate or back up your data from the affected datastore to another location. Make sure to retain the original file structure.
- Reformat the partition with the XFS V5 format, effectively deleting all data on that partition.
- Once the partition has been successfully reformatted with XFS V5, migrate or restore the previously backed-up data back to the datastore.
For more information, see SUSE Storage Administration Guide.
Red Hat Enterprise Linux
Problem
- The following warning occurs on a Windows operating system: "ERROR: SMS0004: The specified device does not exist."
⇒ Solution
- Reinstall the CBMR x.x SEP Sesam Version software package.
Powershell script not executed on a target machine
Problem
- Why is the Powershell script not executed on a target machine?
Possible causes
- By default, Microsoft installs Windows Powershell with the permission set to Restricted. This setting only allows the execution of commands in Powershell but no scripts.
⇒ Solution
- This can be changed with following command in Powershell:
Set-ExecutionPolicy RemoteSigned
For more information, see About Execution Policies.
IBM DB2
Problem
- There are problems with SEP sesam operations.
⇒ Solution
- Check contents of db user's
$HOME/sqllib/db2dump/db2diag.log
log file. - Check the messages on SEP sesam Server.
- Find more information in the sdb2 log. Log filename is set by XBSA LOGFILE=<Full pathname of sdb2.log> and log level by XBSA TRACE=1.
Note | |
All sesam XBSA messages have the prefix XBSA. You can set XBSA TRACE to 2 to show more details, but then the log files can become quite large. |
MacOS
Problem
- There are problems with SEP sesam operations.
⇒ Solution
The Mac installer has its own log messaging system. To view the log files, proceed as follows:
- Execute the installation/update of the client or GUI package step-by-step until you get to the last installer step Summary.
- Go to the Installer Menu and click Window -> Installer Log.
- Select among the following options: Show Errors Only, Show Errors and Progress or Show All Logs.
AIX
Problem
- After SEP sesam installation, an error occurs: STATUS=ERROR MSG=Some daemons offline
⇒ Solution
By default the sesam sshd daemon is not included in the AIX package. Therefore the command:
/opt/sesam/bin/sesam/sm_main status
will report the sshd as offline:
2016-08-27 16:20:05: sshd : offline
- Currently, this error can be ignored as only the CTRL access mode is supported for the AIX systems.
- To disable the sshd daemon, edit the file:
/opt/sesam/var/ini/sm.ini
and change the option:
sshd=on
to
sshd=off
- If any other services are not starting up, contact SEP sesam support.
Debian repository
Problem 1
- After running apt-get update, the following GPG error is shown:
W: GPG error: https://www.sep.de/downloadportal/ jessie InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 68111EBBD273917B
Cause
- The SEP GPG key is missing in the system keyring.
⇒ Solution
- Install the key, as shown in the Debian Repository.
Problem 2
- During package installation the following warning (verification error) occurs:
WARNING: The following packages cannot be authenticated! sesam-<package> Install these packages without verification? [y/N]
Cause
- The SEP GPG key is missing in the system keyring.
⇒ Solution
- Install the key, as shown in the Debian Repository.
Problem 3
- While running apt-get update, the following message appears:
N: Loading the configured file »main/binary-i386/Packages« is skipped because the [...] depot does not support the »i386« architecture.
⇒ Solution
- Insert
[arch=amd64]
between the word deb and the URL of the repository, as follows:
deb [arch=amd64] https://www.sep.de/downloadportal/linux/repositories/debian/ stretch main
Problem 4
- While running the command apt-key add, the following message appears:
E: gnupg, gnupg2 and gnupg1 do not seem to be installed, but one of them is required for this operation
⇒ Solution
- Install the package gnupg to fulfill the dependency via package manger:
apt-get install gnupg
Problem 5
- SEP sesam provides signed Debian repositories for easier package installation, verification and updating of SEP sesam software. When installing SEP sesam Server via the Debian repository, the following message appears:
Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: sesam-srv : Depends: postgresql-9.5 but it is not installable or postgresql-9.6 but it is not installable or postgresql-10 but it is not installable E: Unable to correct problems, you have held broken packages.
Cause
- This problem typically occurs if you have used the wrong version of the Debian distribution in /etc/apt/sources.list.
⇒ Solution
- Correct the version of your Debian distribution, e.g., from stretch to buster, and then run apt-get update to refresh the repository information. For more details on the installation, see Debian Repository.
Troubleshooting SEP sesam authentication
After updating to SEP sesam version 5.0.0.x, no user other than the special user Administrator (Windows) or root (Linux) is elevated to Superuser
Problem
- After updating SEP sesam to version ≥ 5.0.0 Jaglion, the GUI complains that superuser rights are required, but only Administrator rights are listed for this GUI user. The Administrator user is not elevated to Superuser and access to the GUI is not possible without authentication.
Cause
- This is the normal behavior for Java policy authentication. After the initial installation of SEP sesam, no user other than the default Superuser is configured. As the name implies, the permissions of the Superuser account are unrestricted. As of 5.0.0 Jaglion, the Superuser is the only user type with full control over the SEP sesam environment. It is automatically assigned exclusively to the Administrator user when database-based authentication is enabled. If policy-based authentication is enabled, this user type with Superuser rights is assigned to Administrator (on Windows and Linux), root (Linux only) and sesam user. For more details, see User Roles and Permissions and About Authentication and Authorization.
⇒ Solution
If you use policy-based authentication (sm_java.policy) and log in from localhost, you can gain Superuser rights if your username is not listed in sm_java.policy. This is possible if the localFullAccess parameter is enabled (set to true in the <SESAM_ROOT>/var/ini/sm.ini
file). There is no such workaround for database-based authentication, as only Administrator (on Windows and Linux) and root (Linux only) can become Superuser.
Tips for backup troubleshooting
In case of a failed backup, you should follow the tips below:
- Find out when the problem occurred using the day log (.prt) and the status log (.status). The day log shows the causal progression of all SEP sesam activities of the backup day. The files with a file extension ending in .prt.err contain only the error messages from the day log.
- Display the directory files chronologically (with ls -lart on Linux).
- The log files should be read backwards from the end of the file. If a backup failed, you can usually find the indication of errors and their causes at the end of the respective log file.
- Compare failed backups with working backups:
- Check when the last successful backup of this task took place.
- Identify the differences between not and bck logs by comparing two different backups.
- Determine if there were any changes on the network or on the client.
- The values of the database calls in DB_ACCESS have the following explanations:
- result = 1: Database access is OK.
- msg > 0: Amount of result > 0.
- If the data throughput is very low and no backup is running, communication between hardware and RDS may have stopped . Use netstat to check if the connection over the STP ports (11001, 11002, etc.) still exists and check if RDS is still reachable.
- If a process attempts to write to the hardware device and hangs, the kill -9 command on Linux will not help because the process is waiting for I/O and the kernel is unable to stop it. The only solution is to restart the server. These processes usually take only fractions of a second, but get stuck if there are hardware problems.
- SEP sesam does not use kernel functions nor does it access the kernel while processing. All calls are done exclusively via GLIBC (GNU C Library). The command that goes deepest into the system is slu (SCSI Loader Utility). It accesses the SCSI interface directly. Only loader and tape mover commands are affected. When a backup is running, there is no direct access to the kernel or hardware with SEP sesam. For details about this command, see Using slu topology for detecting devices.
Backup Troubleshooting/en
Restore Troubleshooting/en
Disaster Recovery Troubleshooting/en
GUI Troubleshooting/en
Network Troubleshooting/en
MS SQL Troubleshooting/en
MS Exchange Troubleshooting/en
NetWare Troubleshooting/en
Micro Focus GroupWise Troubleshooting/en
Oracle Troubleshooting/en
Informix Troubleshooting/en
Lotus Domino Server Troubleshooting/en
VMware Troubleshooting/en
Citrix XEN Server Troubleshooting/en
SAP HANA Troubleshooting/en
SAP ASE Troubleshooting/en
SAP ERP Troubleshooting/en
NetApp Troubleshooting/en
MySQL Troubleshooting/en
BSR Pro for Windows Troubleshooting/en
NDMP Troubleshooting/en
Hyper-V Troubleshooting/en
KVM QEMU Troubleshooting/en
Si3 Deduplication Troubleshooting/en
Tape and Tape Devices Troubleshooting/en
VSS Troubleshooting/en
HPE StoreOnce Troubleshooting/en
Proxmox VE Troubleshooting/en
See also
Analyzing SEP sesam Log Files – Error Messages Guide – SEP sesam Exit Codes