Troubleshooting Guide: Difference between revisions
m (fixing links) |
(fixing transclusions) |
||
| Line 24: | Line 24: | ||
{{anchor|GUI}}{{Source:Troubleshooting_GUI}} | {{anchor|GUI}}{{Source:Troubleshooting_GUI}} | ||
{{anchor|network}}{{Source:Troubleshooting_Network}} | {{anchor|network}}{{Source:Troubleshooting_Network}} | ||
{{anchor|MS_SQL}} | {{anchor|MS_SQL}}{{Source:Troubleshooting_MS_SQL}} | ||
{{anchor|Exchange}} | {{anchor|Exchange}}{{Source:Troubleshooting_MS_Exchange}} | ||
{{anchor|NetWare}} | {{anchor|NetWare}}{{Source:Troubleshooting_NetWare}} | ||
{{anchor|GroupWise}}<translate><!--T:41--> {{:Micro Focus GroupWise Troubleshooting/en}}</translate> | {{anchor|GroupWise}}<translate><!--T:41--> {{:Micro Focus GroupWise Troubleshooting/en}}</translate> | ||
{{anchor|Oracle}}<translate><!--T:19--> {{:Oracle Troubleshooting/en}}</translate> | {{anchor|Oracle}}<translate><!--T:19--> {{:Oracle Troubleshooting/en}}</translate> | ||
Revision as of 15:09, 31 March 2023
Introduction
|
Visit SEP sesam YouTube Channel for latest videos and webinars. |
|
Check FAQ to find the answers to most common questions. |
|
Problems? See the Troubleshooting Guide. |
|
If you are using an older SEP sesam version, refer to Documentation archive. |
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.inifile 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] $taskReplace 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.loglog 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 problems
Client backup error
Problem 1
Backup of a Windows or Linux client fails with the following error:
"E020-HOSTS [..] : Error: Network communication problem: SOCKET error: 10060
Possible causes
The cause of this problem is most likely:
- The active firewall on the SEP sesam backup Client. In this case, check the firewall settings and if ports 11322 or 11301 are blocked.
On Linux also check if the sesam SSHD daemon is running
ps axw | grep sm_sshd
and if port 11322 is open and in state LISTEN
lsof -i TCP | grep 11322
- An active antivirus program is blocking access or running its own firewall and blocking access.
- Third party firewall between the backup server and the backup client blocking access.
- The SEP sesam Client agent is not running on the system.**Other network related errors.
Problem 2
A client backup did not function properly. How can I determine where the problem is?
⇒ Solution
Run the following commands to determine the error:
|
Warning |
| The following commands produce a high network load. |
BACKUP SERVER UNIX, CLIENT WINDOWS
sm_ctrlc -l system {client name} sbc -b -s - f:/test >/dev/null
Data from the F:/ directory on Windows is written over the network to the directory /dev/null on Unix. To display it, append -v 1 to the command above. Everything written to /dev/null will be displayed.
sm_ctrlc -l system {client name} sbc -b -s - -v 1 f:/test >/dev/null
BACKUP SERVER UNIX, CLIENT UNIX
sm_ctrlc -l root {client name} sbc -b -s - /usr >/dev/null
To display the read data:
sm_ctrlc -l root {client name} sbc -b -s - -v 1 /usr >/dev/null
BACKUP SERVER WINDOWS, CLIENT UNIX
sm_ctrlc -l root {client name} sbc -b -s - /usr > NUL
With backup data logging:
sm_ctrlc -l root {client name} sbc -b -s - -v 1 /usr > NUL
If the test backup is to be run on the target backup client only, execute the following command:
In the Unix directory <sesam>/bin/sesam/:
sbc -b -s - /usr >/dev/null
In the Windows directory <SESAM_ROOT>\bin\sesam\:
sbc -b -s - f:/test > NUL
Enter -v 1 to show the backed up data on your monitor.
Failed backups will be automatically deleted
Problem
By default, SEP sesam deletes all failed backups after 3 days automatically to release the storage space. How can I keep such backups for a longer time? (< version 4.3.3)
⇒ Solution
If you want to keep your failed backups for more than 3 days, you may manually extend the backup EOL (expiration date) of this particular saveset. For details, see Manually extending EOL. Note that SEP sesam automatically retains the last successful backup saveset when the next backup fails. This means that SEP sesam extends the EOL of the previous 'successful' or 'with warnings' backup, thus ensuring that at least one successful backup is retained.
Failed to write the data to media during backup
Problem
During backup, operating system error "23 (ERROR_CRC)" is displayed.
Possible cause
The tape drive cannot write proper blocks onto the backup media.
⇒ Solution
Check the tape drive and backup media.
Backup to data store fails
Problem
Backup (or migration) to data store fails with the error message All available space of media is used, stop writing to media.
Possible cause
SEP sesam aborts a data transfer because less than 1 GB is available on the data store (disk storage). A disk failure can also cause this problem.
⇒ Solution The following points may help to resolve the problem:
- Check the system messages on Linux or the event log on Windows for any hardware problems.
- Remove orphaned savesets from the data stores by using the Clean up option, see Data Store.
- Delete some savesets or backups on this datastore or start a purge process for the data store to delete the obsolete (EOL-free) savesets and to get enough free space. For details, see Purging a Data Store.
- Increase the disk space.
- Run FSCK on the disk storage.
If you cannot solve this issue, report it to SEP sesam support. The support team will then provide you further instructions.
Incorrect login or password
Problem
During backup, the message "Login incorrect. Password incorrect" is displayed.
⇒ Solution
Check your name resolution (DNS or etc/hosts file). The SEP sesam Server and SEP sesam Client must be reachable with or without FQDN and should be able to resolve each other correctly, including the reverse lookup. If the resolution is correct, do the following:
- In the SEP sesam GUI, go to Main Selection -> Tasks -> By Clients, and select the client with the backup problem.
- Open the backup properties and click the Options tab.
- Type -v 4 at Save options.
- Start the backup again, then go to Main Selection -> Job state -> Backups and double-click the backup task to open its properties.
- Go to Logging -> Day log and search for the line Login incorrect. Password incorrect then correct the name resolution.
Data transfer via FTP fails with XBSA Initialisation error
Problem
At the beginning of a backup data transfer via FTP, the following error message appears:
- XBSA Initialisation error. Access to the requested object is not possible. NEGATIVE reply: 425 Can't open data connection. WINSOCK: Connection timed out. (0x274c,10060)
Possible causes
This problem can be caused by the following:
- Active firewall on the system that is supposed to transfer the backup data between SEP sesam Server and Client.
- Routing or Network Address Translation (NAT) between the systems involved.
⇒ Solution
The following steps can help to solve the problem:
- In the case of a firewall problem:
- Disable the firewall.
- Adjust the firewall application-based. This needs to be done on system, which should transfer the data. SEP sesam uses active FTP. When starting regular file backups on Windows add binary sbc.exe to the firewall exclude list. In case of BSR on Windows also add binary oodiag.exe to the firewall exclude list.
- Customize the firewall port-based. Make sure that all required ports are available on the system and are not blocked by a firewall. If a port range is open, it is important that you configure that port range in the STPD options for the client. For details, see Port numbers for SEP sesam Client.
- In case of a router/NAT, adjust the rules to allow SEP sesam RDS and Client to transfer data.
Network connection failure on physical or virtual systems
Problem
SEP sesam backup of physical or virtual systems fails due to network connection error (10054). The log files contain one of the following error messages:
10054 An existing connection was forcibly closed by the remote host
or
Error : Network communication problem: SOCKET error: 10054 - The virtual circuit which reset by the
remote side . recv () call failed.
For more details on Windows error codes, see Microsoft Developer Network documentation.
Possible causes
Cause 1: Virtualization solutions
Citrix XenTools and VMware Tools may create their own network card driver on a virtual machine, which will be used instead of the regular Windows system drivers.
The paravirtual network drivers may cause some problems:
- General CPU load of approx. 30% within a VM without any actions
- Very poor throughputs, even in disconnected networks or gigabit LANs
- Broken connections
According to Microsoft documentation, the above error message shows that the connection was reset by the client, i.e., the system to be backed up.
The problem is at the same time visible on the SEP sesam Server:
- The backup remains in the active status with a 0 GB/h performance.
- There are active sm_sms_backup processes.
- There are active sm_stpd processes.
SEP sesam has no feedback from the client that the backup was aborted. The connection has been hard reset.
Cause 2: Network/Port trunking
In several customer environments, port trunking was disabled either on the system to be backed up or on the backup server side. After the trunks were resolved, the backups could be performed without problems.
To resolve trunking issues, see Trunking configuration guide.
Cause 3: Firewall
If network disconnection occurs in less than 5 minutes, is most likely a TSO/trunking issue described above. If the network disconnects after 5, 60 or 120 minutes, there is a KeepAlive problem with the NAT/PAT router or a firewall.
Cause 4: Virus scanner
Virus scanners intervene actively in the data transmission and related processes and may thus be the cause of the problem. It is recommended to use the antivirus exclusions for SEP sesam as they can have adverse effects on backup and restore operations, as described in Antivirus Exclusions for SEP sesam.
Cause 5: Error on the SEP sesam Server side
If a problem with the process sm_stpd.exe or sm_stpd occurs is recorded in the event viewer or the dmesg output of a SEP sesam Server at the time the backup is aborted, the problem must be analysed from the SEP sesam Sever side. Note that incorrect routing can also be the cause of this problem.
For example, the SEP sesam Server and SEP sesam Client are on two different networks. Routing is not controlled by one central router but via static routes on the other network. A ping from the SEP sesam Server to the client works, but not vice versa. In such case, the permanent route to the client's network was set on the SEP sesam Server, but it was not part of the active routes.
To solve this problem, delete and re-add the route as follows:
route delete <client_network> route add -p <client_network> mask <network_mask_of_the_client_network> <SEP_sesam_Server_IP>
Cause 6: Disabling task offloading
For VMs
Disable the TSO (TCP Segment Offloading) feature in the VM.
Both Citrix XenServer and VMware ESXi use the existing TSO in the network cards. This feature allows you to swap out different operations that must be performed during the fragmentation of network packets to the network interface card (checksum calculation). The purpose of this is to reduce the CPU load. (The XenServer network card drivers (NIC) are more affected by this problem.)
On Windows
To disable this feature on Windows, the key DisableTaskOffload has to be set in the registry to prevent offloading to the network card, see Microsoft documentation. After setting this option on the backup client and then restarting, further backups run without any problems.
On Linux
On Linux, you can activate or deactivate the TSO settings during runtime using the ethtool tool as follows:
ethtool -K eth0 tso off
TCP retransmission
Fixing TCP retransmission errors at the network level fixes the root cause of the problem. To find TCP retransmission errors, the network analysis tool Wireshark is required.
You have to start a network analysis with Wireshark on the affected system (Capture -> Interfaces).
|
|
Note |
| Retransmission error appears as black lines in the Wireshark log. |
ON WINDOWS
|
|
Note |
| SEP sesam uses Microsoft’s Volume Shadow Copy Service (VSS) to perform backup for various task types. VSS failures are typically caused by system configuration and not by SEP sesam; this section may provide some instructions on how to troubleshoot such issues. If you cannot find your issue here, check also VSS Troubleshooting or refer to Microsoft's article Volume Shadow Copy Service for more detailed information on VSS. |
Path backup on Windows is not working
Problem
SEP sesam Server failed to execute a path backup of a Windows client (however, a path backup without VSS is working). The following error is displayed:
Problem while loading dynamic link library: [WIN32 API error: 1114 - A dynamic link library (DLL)
initialization routine failed. LoadLibrary() call failed for: [vss.dll]].
Possible causes
- Typically, when dll cannot be initialised, a running antivirus solution is preventing it.
- The client's VSS configuration is incorrect.
⇒ Solution
- Disable the antivirus software during backup.
- Check the client's VSS configuration by running the following commands:
- vssadmin list writers - check the status of all writers on a daily basis
- vssadmin list shadows - check existing VSS copies
- vssadmin list shadowstorage - check how much space is reserved and available space for VSS
- vssadmin resize shadowstorage - set the reserved space for VSS snapshots to unlimited
WIN32 API error: "1450"
Problem
- What should I do when a client backup fails with a WIN32 API error: "1450 - Not enough system resources to execute the requested service"?
- The backup of a client may end with the following error message in the backup log:
sbc-1148: Error: W2KSS Error: [WIN32 API error: 1450 - Not enough system resources to execute
the requested service. Cannot store registry key: [SOFTWARE]. RegSaveKey() call failed in BackupRegistry().].
Possible cause
Insufficient size of the registry/paged memory area. This problem affects SEP sesam as well as other backup tools, such as NTBackup.
⇒ Solution
The Microsoft article Backup program is unsuccessful when you back up a large system volume explains approaches for different versions of Microsoft Windows.
Unsuccessful backup of OneDrive files
Problem
SEP sesam is unable to access files in OneDrive remote storage. When attempting to back up files stored in OneDrive, SEP sesam log file displays the following warning:
Warning: Unable to open item - Access to the cloud file is denied.
Cause
OneDrive is a cloud-based service provided by Microsoft for storing, synchronizing, and sharing files. It has some unique characteristics that are specific to Microsoft's ecosystem and access to files is implemented differently than standard cloud solutions. SEP sesam may encounter difficulties in accessing and backing up the files that are stored in OneDrive cloud-like remote storage.
⇒ Solution
To resolve this issue, consider using the "offline mode" and syncing the files from OneDrive to local storage on the client device. This enables SEP sesam to bypass the issues with access and files are backed up from the local storage rather than the cloud. Ensure that you regularly update the local copy to reflect the changes in the cloud storage.
System state backup is backing up large amount of data due to DFS
Problem
When performing a Windows system state backup on the server that runs DFS (Distributed File System), large amount of data is backed up and the backup is slow.
Possible cause
If the DFS replication is enabled, the system state backup may include all the data from the DFS Replication service too.
⇒ Solution
|
|
Note |
| On a Domain Controller (DC) the DFS is used to replicate the SYSVOL, therefore it should be included in the system state backup. Use the following procedure only as a workaround if your system state backups are slow due to large amount of DFSR data. |
Exclude the DFS writer from the system state backup task in the SEP sesam GUI: from the Main Selection -> Tasks -> By clients, select your Windows client then double click on your system state backup task. In the properties window switch to the Options tab, and under Additional call arguments -> Backup options exclude the DFS writer as follows:
-x "VSS:/DFS Replication service writer"
Next, you have to back up the file system data, served by the DFS, separately by performing a regular Path backup (create a Path task type instead of a System_state backup task). For details, see Backing up System State.
System_State backup (RegLoadKey) error
Problem
- What does the warning "The system cannot find path. RegLoadKey()..." during System_State backup mean?
- You may see the following output in NOT-log:
C:\Program Files\SEPsesam\var\tmp\usr_wf_S-1-5-21-220523388-1123561945-839522115-1003]. 2020-04-13 02:04:20: sbc-2074: Warning: W2KSS Warning: [WIN32 API error: 3 - The system cannot find path. RegLoadKey() call failed for file: [C:\Documents and Settings\nn\ntuser.dat] in BackupUserProfiles().].
Possible cause
There are inconsistencies in the OS configuration. The reason is that a user profile has been deleted but the user account still exists. System_State backup is looking for files corresponding to the user in the file system but the files no longer exist.
⇒ Solution
- Delete the user in question or restore the profile date in the file system.
- Check the following in your registry to see whether it still includes references to usernames which no longer exist:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
Access denied during Microsoft Windows backup via VSS
Problem
Why does a Microsoft Windows backup via VSS stop with the message "[CVssBaseObject::CreateVssBackupComponents] - Access denied"?
Possible cause
SEP sesam is not allowed to create a snapshot with the current user.
⇒ Solution
Check the user running the SEP sesam daemon and make sure that the user has all permissions to access the volume(s).
Stream data length exceeds buffer capacity
Problem
What does the warning "Stream data length bigger than buffer can accept. Input buffer length = [65536], Stream data size = (High part)[0] (Low part)[65564]" ?
Possible cause
SEP sesam uses 64 kB to back up Windows ACL files and folders and one object exceeds this buffer. You can use the Windows command icacls to display the ACL of a file or folder. The output looks like this:
C:\>icacls "C:\Documents and Settings\LocalService\Local Settings\Temp"
C:\Documents and Settings\LocalService\Local Settings\Temp NT AUTHORITY\LOCAL SERVICE:(I)(F)
NT AUTHORITY\LOCAL SERVICE:(I)(OI)(CI)(IO)(F)
NT AUTHORITY\SYSTEM:(I)(F)
NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
Successfully processed 1 files; Failed processing 0 files
If you get several hundred or thousand lines, there is something wrong with the ACL.
⇒ Solution
Reset the permissions of the file's respective folder by using the command:
C:\>icacls "C:\Documents and Settings\LocalService\Local Settings\Temp" /reset
This command inherits the permissions of the parent object. You may have to adjust the permissions after running this command if manual settings have been applied for this object.
Backup on Windows 7 did not complete successfully
Problem
When you perform a Windows 7 backup, the backup might fail with one of the following errors.
sbc-1146: Error: DB Module: [WIN32 API error: 55 - The specified network resource or device is no longer available. sbc-2040: Warning: Cannot read item [\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy730\Windows\winsxs\x86_microsoft-windows-sort_31bf3856ad364e35_6.1.7600.16385_none_ab9479767ad67fd7\sort.exe: (2) WIN32 API error]:[ 2 - The system cannot find the file specified. ]. Padding remaining bytes... smk-3506: Info: Backup finished. Status: ERROR Error: Item generator returns [WIN32 API error: 2 - The system cannot find the file specified. ] for item [\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy136\Windows\winsxs\FileMaps\] smk-3506: Info: Backup finished. Status: ERROR Error: DB Module: [Not all items have been processed]
To see more detailed error, view the Event Log on your Windows client: Event Viewer -> Windows Logs -> System. The Event Id 33, volsnap shows the following message:
The oldest shadow copy of volume C: was deleted to keep disk space usage for shadow copies of volume C: below the user defined limit.
Possible causes
- There was not enough disk space for the Volume Shadow Service to take a snapshot; consequently, the operating system automatically deleted the snapshot due to the lack of space.
- This error occurs if the snapshot size exceeds the snapshot Maximum size: Use limit configured for the volume.
⇒ Solution
Check the Maximum size: Use limit on your Windows 7 client: Open a Windows Explorer on the client and right-click the drive letter to open the drive properties. Select the Shadow copies tab -> Settings -> check the Maximum size: Use limit:
- If you select No limit, Windows will not delete the snapshot regardless of how much space it consumes. Note, however, that in case of a large snapshot the process might be failing to create the snapshot because there is not enough disk space left on the respective drive.
- If you specify Use limit, change the maximum size limit to a large enough value to contain the snapshot with room to spare. According to Microsoft, it is recommended to set the maximum size limit to a value that equals 10% of the volume size. For example, if the C:\ drive has 100 GB of data, the limit should be set to 10 GB. Or, you can store the shadow copy data on another disk. For details, see Microsoft forum answers Shadow Copy.
ON LINUX
SEP sesam Linux Client error during backup
Problem
A SEP sesam Linux Client (SBC) issues an error or warning during backup.
Possible causes
Backup on Linux may finish with an error or warning if:
- the size of a file has changed during the backup
- a file is deleted during the backup (between 'find' and data processing)
- the 'find' function encountered an error
⇒ Solution
- To avoid these warnings and resolve the above errors, double-click the backup task to open its properties and under the Options tab in the Backup options field enter the following command:
-o ignore_finderr=<regex>|ALL
- If you want to avoid all such errors/warnings, specify:
-o ignore_finderr=ALL
GVFS error during Linux backup
Problem
- If a user is logged on to the gnome or kde session and makes use of the GVFS layer, the directory ~/.gvfs is created. This directory cannot be entered by any other user (even root).
- Additionally, the system call "stat" also errors out on this directory. The directory cannot be excluded, because while creating the file list and looking at the excludes, sbc_find once does a "stat()" call on the directory and receives an error.
⇒ Solution
- Create a new file named /etc/profile.local with the contents below /etc/profile.local:
GVFS_DISABLE_FUSE=1 export GVFS_DISABLE_FUSE
- Run the following commands for each affected folder:
fusermount -u /home/$USER/.gvfstest with stat /home/$USER/.gvfs
Restore problems
Error mounting a saveset on SLES 15 SP4
Problem
- On SLES 15 SP4, when running guestfs tool to mount a saveset, the mount fails with the following error message:
error while loading shared libraries: libgcrypt.so.20: cannot open shared object file: No such file or directory
⇒ Solution
- Run the following commands on the affected SEP sesam Server:
echo '/usr/lib64/libgcrypt.so*' > /usr/lib64/guestfs/supermin.d/zz-libgcryptecho '/usr/lib64/libgpg-error.so*' > /usr/lib64/guestfs/supermin.d/zz-libgpg-error
Disaster recovery on Linux
Problem with a ReaR backup execution on SEP sesam Client
Problem
- ReaR backups on the SEP sesam Client are experiencing issues, but path backups are functioning correctly. The backup log may contain errors such as sbc_vadp requires additional libraries (fatal error). Example:
opt/sesam/bin/sesam/sbc_vadp requires additional libraries (fatal error) libpython2.7.so.1.0 => not found
Cause
- This issue is caused by the sbc_vadp binary, which was included in the 5.0.0.15 Service Pack 1 update, but is not required on the Client.
⇒ Solution
Delete the sbc_vadp binary. You can use the following command:
rm /opt/sesam/bin/sesam/sbc_vadp
The workflow mkrescue is not supported in the ReaR system
Problem
- The workflow mkrescue is not supported in the ReaR rescue/recovery system.
⇒ Solution
- Delete the file /etc/rear-release.
ReaR image hangs during bootup
Problem
- The system hangs during bootup like shown in the following image:
⇒ Solution
- Boot the system with the ACPI=OFF option (this option can be specified on the command line in the boot menu prompt, after the options BACKUP=SESAM OUTPUT=ISO).
The recovered system does not boot
Problem 1
- The system does not boot because /root/dev/console cannot be found.
Possible causes
- Certain distributions rely on the existence of the directory /dev/ while booting
- Certain static devices must exist before the udev daemon creates them.
⇒ Solution
- Include the /dev/ file system in your backup.
- If the restore cannot restore /dev/:
- Boot from the SEP sesam LIVE CD.
- Mount the ROOT partition of the restored system.
- Manually create the /dev/ directory.
- Manually create the /dev/console entry with:
mknod /path/to/target/mount//dev/console c 0 0
Problem 2
- The system does not boot because of missing libblkid.so.1.
Possible cause
- This is most likely caused by SELinux which is activated by default.
⇒ Solution
- Especially on RHEL6 or CentOS6 systems, follow these steps after rebooting from the ReaR recovery:
- Press a key when prompted by the boot loader (GRUB):
- Select the appropriate boot loader entry:
- Press e to modify the commands for the selected entry:
- Add selinux=0 to the commands:
- Press Enter to confirm the changes and b to boot up the machine with SELinux disabled.
- When having access to the system, change the option SELinux of /etc/selinux/config to the following: SELINUX=permissive
Afterwards, reboot the system and feel free to set the SELinux value back to enforcing if needed.
No bootable operating system can be found
Problem
- The system is not able to find a bootable OS instance after the restore.
Possible causes
- There may have been problems during the installation of the GRUB boot loader.
⇒ Solution
- The restore protocol includes a statement whether or not the installation of the boot loader was successful:
2009-12-14 14:48:27: sbc-3500: Info: Reinstall boot manager [/sesam/bin/sesam//sbc_grub_auto /mnt/disk/ AUTO]
- It is also possible to boot the system again from the live-CD, mount the target partitions and use grub-install to install the boot loader correctly.
The device does not have a corresponding BIOS drive
Problem
- During the restore, the following error occurs:
/dev/sda1 does not have any corresponding BIOS drive
Possible causes
- Check the file /boot/grub/device.map on the target system. If there are entries referring to the disk through /dev/by-disk/... as shown in the example below, the entry is most likely the reference to the hard disk partition of the broken system. GRUB will not find the proper device:
hd(0) /dev/disk/by-id/ata-SAMSUNG_SP2504C_S09QJ1GLA14263-part1
⇒ Solution
- Reboot from the live-CD
- Mount the root and boot partitions to /mnt/disk (and /mnt/disk/boot, if necessary)
- Restart grub-install with the following options:
grub-install --root-directory=/mnt/disk --recheck hd0
Output:
grub-probe: error: Cannot open `/boot/grub/device.map' /usr/sbin/grub-install: line 374: [: =: unary operator expected Installation finished. No error reported. This is the contents of the device map /mnt/disk/boot/grub/device.map. Check if this is correct or not. If any of the lines is incorrect, fix it and re-run the script `grub-install'. (hd0) /dev/hda (hd1) /dev/hdb
You can ignore the error line 374: [: =: unary operator expected.
More important is the result Installation finished. No error reported.
No corresponding BIOS drive for /dev/cciss/c0d0p2
Problem
- You receive the message: /dev/cciss/c0d0p2 does not have any corresponding BIOS drive in restore log.
⇒ Solution
- Please see: Novell support
fsck.ext3: File system has unsupported features
Problem
- During a restore of a system with kernel version 2.4 the system may not boot because the Live-CD creates a file system with features which are not supported by kernel 2.4.
Possible causes
- Most likely the file system options resize_inode,dir_index,large_file,ext_attr are causing the problem and making the system unbootable.
⇒ Solution
- Reboot from the Live-CD image, which includes the tool debugfs.
- Show the file system features with debugfs:
root@recover#: debugfs -w /dev/sda2 debugfs 1.41.1 (01-Sep-2008) debugfs: features Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file quit
Replace /dev/sda2 with the corresponding partition names on your system.
- To remove file system features:
root@recover#: debugfs -w /dev/sda2 debugfs: features -resize_inode -ext_attr -dir_index -large_file -needs_recovery -sparse_super Filesystem features: has_journal filetype quit
After removing the options, the system should boot correctly.
Incorrect inode size (256)
Problem
- After a successful restore the boot process stops with incorrect inode size (256).
Possible causes
- Older kernel versions (2.4) may use a different inode size than the one the file system's created through the Live-CD (which includes kernel 2.6). For example, this happens during the restore of SLES8 based systems which use an inode size of 128k.
⇒ Solution
- This can only be solved by formatting the devices manually from the Live-CD, using the proper mkfs options:
mkfs.ext3 -I 128 /dev/sda1
After this step, remount the partition to /mnt/disk and repeat the restore operations. Changing the inode size is only possible by reformatting the devices.
Missing root file system
Problem
- The restored system can't find a root file system and fails during resume.
Possible causes
- The /etc/fstab file was configured with the root file system as UUID.
⇒ Solution
- Specify the root file system device name in conventional device names if you are using a different physical disk. After booting, use YAST to reconfigure your boot loader or edit your /boot/grub/menu.lst manually:
root=/dev/sda2
Missing network cards
Problem
- The restored system does not find any network cards.
Possible causes
- If the restore was done to dissimilar hardware, SLES-based distributions may not configure the network devices correctly. SLES-based systems save their network configuration by using the system's MAC address. Most likely the system will not use eht0 as a device name, but eth1, as it has another MAC address.
⇒ Solution
- Use YaST and reconfigure your network interfaces.
Client does not start on the RHEL6/Debian9 recovery image
Problem
- The SEP sesam Client does not start automatically on RHEL6 and Debian9-based recovery images.
Cause
- The file /etc/init.d/functions is missing within the recovery image.
⇒ Solution
- The client can be started manually via:
/opt/sesam/bin/sesam/sm_main start
RHEL7 backup fails with an error
Error 1
- The RHEL backup fails with the following error:
ERROR: The LSB package is not installed.
⇒ Solution
- Install the lsb package as follows:
yum install redhat-lsb-core mkisofs syslinux
Error 2
- The RHEL backup fails with:
ERROR: Cannot find required programs: mingetty
For more details, see Rear dependencies on RHEL7.
⇒ Solution
To solve this problem, proceed as follows:
- Edit
- Run the backup again.
/var/opt/sesam/var/lib/rear/usr/share/rear/conf/default.conf
and from the line:
# required programs. Same as above, but if they are missing, we abort. REQUIRED_PROGS=( "$SCRIPT_FILE"
remove the line:
mingetty
ReaR error occurred during grub2-mkimage of bootx64.efi
|
|
Note |
| In order to be able to create an UEFI/EFI bootable ISO image, the additional tool ebiso has to be installed on the client system as described in the section Installing ebiso for creating UEFI aware ISO images. |
Problem
- The ReaR error occurrs during grub2-mkimage of bootx64.efi.
⇒ Solution
- To solve the problem, install the grub2-efi-x64-modules package.
SM_SSH does not work on SLES11 recovery image
⇒ Solution
- In this case, execute
mount -t tmpfs none /dev/shm/ -o rw,nosuid,nodev,noexec
- before starting the recovery process.
Client is unreachable after booting the rescue image
Problem
- After booting the rescue image the client is not reachable.
⇒ Solution
- Start the client manually using the following command on the rescue command line:
sh /etc/scripts/system-setup.d/59-start-sesam-client.sh
EFI bootable image cannot be created on SLES11
Problem
- EFI bootable image of GRUB2 cannot be created on SLES11.
Cause
- SEP sesam v. 4.4.3.64 Grolar is the last version that supports SLES11 with UEFI.
⇒ Solution
- To continue using SLES with UEFI, you should not upgrade to a later version of SEP sesam.
Installing ebiso for creating UEFI aware ISO images
In order to be able to create an UEFI/EFI bootable ISO image the, the additional tool ebiso has to be installed on the client system. This package is not part of a regular SLES12/SLES15 installation and can be downloaded at the following URL:
http://download.opensuse.org/repositories/Archiving:/Backup:/Rear/SLE_12/x86_64/
or
http://download.sep.de/utils/bsr-linux/
For other Linux distributions contact SEP support at support@sep.de for assistance.
Install ebiso as follows:
rpm -i ebiso-<version>.rpm
Note that in ReaR v. < 1.19, the generated ISO image mount migt be too small for storing all needed information and need to be adjusted.
In this case, under
/var/opt/sesam/var/lib/rear/usr/share/rear/lib/uefi-functions.sh (line 64)
change
(shim.efi|elilo.efi) size=128000 ;;
to
(shim.efi|elilo.efi) size=228000 ;;
Graphical User Interface (GUI) problems
After updating SEP sesam on Windows, GUI cannot be opened
Problem
After updating SEP sesam to version ≥ 4.4.3.82 Beefalo V2 on Windows, GUI cannot be opened when the group policy option Prevent access to registry editing tools is applied.
Possible cause
This issue seems to be related to the group policy (GPO) setting: if Prevent access to registry editing tools is applied for a specific user or group, opening the GUI does not work for the users which are prevented from accessing the Registry. In most cases, users with admin privileges will still be able to run the GUI as they are typically exempt for a GPO (and are able to access the Registry). If this policy is disabled (or not configured), the users may access the GUI regardless of their privileges.
⇒ Solution
To enable access to the GUI for the affected users (typically non-admin users), disable the group policy option Prevent access to registry editing tools.
|
|
Warning |
| Only experts should edit the registry; modifying Windows Registry incorrectly might crash your Windows operating system causing data loss. |
- Press the Windows key + R to open the Run window.
- Type gpedit.msc and press Enter.
- In the Group Policy Editor -> User Configuration -> Administrative Templates -> System, double-click on Prevent access to registry editing tools setting in the right panel and select Disable. Then click Apply.
GUI Server not accessible
Problem
SEP sesam cannot access the GUI Server.
Possible causes
- The network connection to SEP sesam is broken.
- The GUI Server process is not running.
⇒ Solutions
- Make sure that the computer is running.
- Start the GUI server process by running the command sm main reload rmi.
Database connection failure
Problem
SEP sesam cannot connect to the database.
Possible cause
The DB or RMI servers are not running.
⇒ Solution
Run the commands sm main reload db or sm main reload rmi to restart the servers.
GUI does not start
Problem
The Graphical User Interface (GUI) fails to start.
Possible causes
- There is a problem with Java rights.
- A problem with the screen resolution.
⇒ Solution
In case of the screen resolution problem, set a resolution to at least 1920x1080 (full HD).
Wrong time values in the GUI
Problem
In GUI, the displayed time values may not correspond with the system's default timezone.
Possible causes
- This can be caused by exporting the system-wide environment variable TZ in the system-wide /etc/profile file, which can override the default system locales, leading to an incorrect timezone setting in the postgresql.conf file.
- On Debian, the timezone settings are stored in the /etc/timezone file. If the timezone on the system is changed using the timedatectl set-timezone command, only the /etc/localtime file is updated. The /etc/timezone file remains unchanged.
⇒ 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.
- On Debian, update the settings in /etc/timezone file to set the correct timezone.
Online guide not available
Problem
The online guide cannot be accessed.
Possible causes
- Adobe Acrobat Reader is not installed.
- Adobe Acrobat Reader is installed but not configured in the GUI.
- The PDF file is not configured in the GUI.
⇒ Solution
Download Adobe Acrobat Reader from http://www.adobe.com.
Online help not available
Problem
The online help cannot be accessed.
Possible causes
- There is no browser installed on the system.
- The browser is installed but not configured in the GUI.
⇒ Solution
Install a browser.
Network problems
Network check
Problem
- Network connection is not working.
⇒ Solution
- Perform the network check. Use the commands ping, nslookup, address resolution etc. Check the connection with the corresponding SEP sesam access program (CTRL/SSH). The address resolution must be consistent, i.e., if for a TCP/IP name the resolution gives an IP-address, then the resolution for that IP-address must give the same TCP/IP name!
Example
# nslookup decunix Server: seplinux2.sep.de Address: 193.28.59.40
Name: decunix.sep.de Address: 193.28.59.94
# nslookup 193.28.59.94 Server: seplinux2.sep.de Address: 193.28.59.40
Name: decunix.sep.de Address: 193.28.59.94
Microsoft SQL Server
Incorrect login
Problem
- If a backup or restore ends with errors and you find the following information in the log files, an attempt has been made to address a SQL Server instance on a client that is not entered locally on this system. The selected Trusteed Connection only allows the registration on a SQL Server where the instance is locally active:
DB Module: [DB-Library: Login failed for user '(null)'. Reason: Not associated with a trusted SQL Server connection.] DB Module: [DB-Library message: Login incorrect.]
⇒ Solution
- The backup client or end node on the active SQL Server must be changed.
Microsoft SQL Server backup failure
Problem
- Backup fails with the message "The server principal "NT AUTHORITY\SYSTEM" is not able to access the database "<database>" under the current security context."
Possible causes
- The user SYSTEM is not allowed to connect to the MS-SQL database because the SEP sesam daemon runs as the user SYSTEM by default.
⇒ Solution
- Change the SEP sesam daemon to a user account that has permission to connect to the database(s). Open the Windows service management console on your MS-SQL server, edit the properties of the SEP sesam service, switch to Log on tab and use valid credentials, then restart the SEP sesam daemon.
MS SQL Server backup shows message "The Transaction Log For Database Is Full"
Problem
- During backup of MicroSoft SQL Server the backup log can show the message: "The transaction log for database '<DATABASE>' is full due to 'LOG_BACKUP'".
Possible causes
- This error message indicates that the LOG area is full. This can happen when no INC backup are made, only FULL backups.
⇒ Solution
- Increase the size of the LOG area and perform a FULL and INC backup so that the LOGs can be truncated correctly. Then, set up regular INC backups so that the LOG area does not fill up again.
For more information on resolving this error see here.
Restoring a database from AlwaysOn Availability Group fails with RESTORE cannot operate on database 'Test1' because it is configured for database mirroring or has joined an availability group
|
|
Note |
| MS AlwaysOn is only supported by SEP sesam with the assistance of SEP sesam support. |
Problem
- The MS SQL AlwaysOn Availability Group database restore fails with an error:
DB Module: [UNKNOWN error: 4294967295 -. Got error: [SQL Server]RESTORE cannot operate on database 'Test1' because it is configured for database mirroring or has joined an availability group. If you intend to restore the database, use ALTER DATABASE to remove mirroring or to remove the database from its availability group.]
Cause
- It is not possible to restore the MS SQL database which is part of AlwaysOn Availability Group.
⇒Solution
To restore a database which is part of AlwaysOn Availability Group successfully, proceed as follows:
- Remove the database from the AlwaysOn Availability Group.
- Restore the database to the primary replica in the AlwaysOn Availability Group.
- Add the restored database to the AlwaysOn Availability Group again by using Full as a data synchronization option.
Afterwards the database will be replicated to the secondary replicas.
Restore fails with The system cannot find the path specified
Problem
- If the original database was removed or the database should be restored to a different location, then the path for the database must be created before the restore. If the path for the database does not exist, the following message appears:
Directory lookup for the file "C:\Programme\Microsoft SQL Server\MSSQL$ZWEITE_DB\data\sesamdb_Data.MDF" failed with the operating system error 3(The system cannot find the path specified.). File 'sesamdb_Data' cannot be restored to 'C:\Programme\Microsoft SQL Server\MSSQL$ZWEITE_DB\data\sesamdb_Data.MDF'. Use WITH MOVE to identify a valid location for the file.
Cause
- The system cannot find the database path if the original database was removed or the database path wasn't created before restoring to a different location.
⇒Solution
- In this case you have to restore the database to a new location, as described in Restoring a database to a new location by using GUI relocation or move option.
Restore fails with Directory lookup for the file '...' failed...
Problem
- You receive the following warning:
DB Module: [DB-Library: Directory lookup for the file "e:\Database\SQL Server 2000 SE
\MSSQL\Data\sesam.mdf"failed with the operating system error 21(The device is not ready.).] DB Module: [DB-Library: File 'sesam_db' cannot be restored to 'e:\Database\SQL Server 2000 SE
\MSSQL\Data\sesam.mdf'. Use WITH MOVE to identify a valid location for the file.]
Possible causes
- The existing path where the database files were located is not on the target system or an entry was made in the "Move" option that used a non-existing path name.
⇒ Solution
- A path name must be created or the correct path must be entered in the Move option. Entering the correct path name is the easier solution. Using a long path name in the Move option may cause problems, in which case the input can be shortened.
Restore failure due to SQL Server connection
Problem
- The restore fails with the following error:
DB Module: [DB-Library message: Unable to connect: SQL Server is unavailable or does not exist. Unable to connect: SQL Server does not exist or network access denied.; Net-Library message: ConnectionOpen (Connect()).; ]
Possible causes
- The selected server does not exist. It is possible that an instance was incorrectly entered without the server name.
⇒ Solution
- Check the server name. If necessary, enter the restore target fully qualified as follows:
<HOSTNAME>/<Instance>/<DB Name>
Restore with Move option fails
Problem 1
- Restore using the Move option fails with the warning The physical file name '...' may be incorrect. The following error occurs:
DB Module: [DB-Library: A file activation error occurred. The physical file name
'c:/temp/sesam_log.ldf' may be incorrect. Diagnose and correct additional errors, and retry the operation.] DB Module: [DB-Library: File 'sesam_db_log' cannot be restored to 'c:/temp/sesam_log.ldf'. Use WITH MOVE to identify a valid location for the file.]
Possible causes
- The wrong syntax was used in the file name, e.g., / instead of \.
⇒ Solution
- Enter the path with the correct syntax.
|
|
Note |
| If the SEP sesam Server is using a Postgres database, e.g., with Linux x64, then the character '\' must be entered twice '\\', otherwise it will disappear. For example:
-a move=Mgmt_data:"e:\\SQL Server 2000 SE\\MSSQL\\Data\\Mgmt.mdf" -a move=Mgmt_log:"e:\\SQL Server 2000 SE\\MSSQL\\Data\\Mgmt_log.ldf" |
Problem 2
- Restore with Move option fails with Logical file '...' is not part of database. The following error occurs:
DB Module: [DB-Library: Logical file 'Mgmt_data' is not part of database 'sesam_db2'. Use RESTORE FILELISTONLY to list the logical file names.]
Possible causes
- The wrong logical name was entered in the Move option.
⇒ Solution
- Enter the logical filename correctly. This can be found in the backup log file (NOT-file). For example, in the backup log file, you see the following lines:
DB Module: [DB-Library: Processed 256 pages for database 'sesam_db', file 'sesam_db' on file 1.] DB Module: [DB-Library: Processed 1 pages for database 'sesam_db', file 'sesam_db_log' on file 1.]
The logical file names in this case are sesam_db and sesam_db_log. These should be entered in the Move option.
Restored database remains in the state Restoring
Problem
- A database remains in state Restoring... after the restore finishes.
Possible causes
- This happens if the option Auto recover was not selected in the restore wizard.
⇒ Solution
- Select option the option Auto recover in the restore wizard or execute sbc in the CLI with the option -a recover for the particular database. For example:
- Call the sbc in the command line with:
sbc -r -a recover sbcmsql:"/MIRACULIX/SECOND/msdb"
|
|
Note |
| During the restore of a database with additional transaction log files (generation restore), the database remains in the state "Restoring..." until the last restore (with the option -a recover) ends. |
Disaster recovery fails with ODBC SQL Server Driver][DBMSLPCN]SQL Server does not exist or access denied.
Problem
- The MS SQL disaster recovery fails with an error:
ODBC SQL Server Driver][DBMSLPCN]SQL Server does not exist or access denied.
Cause
- This error typically indicates either network or installation-related issues; the SQL Server does not exist, is not available or is not found.
⇒Solution 1:
- If possible, restore the system databases from the latest path backup. If no such backup exists, check solutions 2 and 3.
⇒Solution 2:
- Create a new MS SQL instance. For this, you will need the MS SQL install files. For details, see How to manually create the Microsoft SQL Server 2014 ACT7 Instance. Then restore the MS SQL databases to the new instance with the target path <server_name>/<instance_name>.
⇒Solution 3:
You can also rebulid MS SQL system databases. The procedure differs slightly if you rebuild the databases from CD or DVD drive (MS SQL Server 2005) or from the installation folder on your local computer in \Binn\Templates\ (MS SQL Server ≥ 2008), for example, C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Binn\Templates. You have to run the setup.exe command from the command prompt, then proceed as follows:
- Click Start -> Run, type cmd, and click OK.
- Depending on your MS SQL version, run the relevant command to rebuild the system databases:
- To rebuild the system databases from CD or DVD drive (MS SQL Server 2005), run the following command:
- To rebuild the system databases from \Binn\Templates\ (MS SQL Server ≥ 2008), run the following command:
start /wait <CD_or_DVD_drive>\setup.exe /qn INSTANCENAME=<instance_name> REINSTALL=SQL_Engine REBUILDDATABASE=1 SAPWD=<strong_password>
For example:
start /wait D:\setup.exe /qn INSTANCENAME=MSSQLSERVER REINSTALL=SQL_Engine REBUILDDATABASE=1 SAPWD=p@ssw0rd
For details, see How to Rebuild System Databases in SQL Server 2005.
setup /ACTION=REBUILDDATABASE /QUIET /INSTANCENAME=<instance_name> /SQLSYSADMINACCOUNTS=<accounts> /SAPWD=<strong_password>
For details and troubleshooting, see How to Rebuild System Databases in SQL Server 2008.
Microsoft Exchange Server
Exchange backup fails with VSS API error due to missing Microsoft Exchange VSS writer
Problem
When backing up Exchange, the backup fails because the Microsoft Exchange VSS writer required for backup is missing. The following error occurs:
sbc-1178: Error: VSS API error: CVssServer::CreateSnapshot: No volume could be determined. sbc-1146: Error: DB Module: [BackupProcessing: For the specified backup source no volumes could be determined. Sources - \Microsoft Exchange Writer] sbc-3052: Info: Items processed correctly: [0]. Not processed or incorrectly processed items: [0]. (SF20160503083743700@BLljg0gnWAa) sbc-1156: Error: Operation failed! sbc-3001: Info: Exiting.
This error occurs when one or more writers required for backup are missing or not available. Note that this is not the same as VSS error or failed VSS. In the latter case, check Common VSS problems.
A writer is consider missing, if running (as administrator) the Microsoft command-line tool vssadmin list writers shows no available Microsoft Exchange VSS writer. If a VSS writer is missing, all backups that use that writer to perform VSS snapshots will fail. A missing writer is a failure of the Windows operating system. To fix this issue, Windows registry needs to be edited. SEP sesam cannot back up any data until the required VSS writers are available.
Solution
|
|
Note |
| SEP sesam is not responsible for any issue caused by Windows registry editing. Note that only experts should edit the registry, as using Windows registry editor incorrectly can cause serious problems, such as Windows to stop working. For more information on editing Windows registry, see Windows registry information for advanced users. It is advised to back up the registry before making any change to it. It is also recommended to perform the following procedure outside of working hours as it requires restarting the Microsoft Exchange Information Store service. |
To enable Microsoft Exchange VSS writer, on the Exchange server open and edit the registry with the following key value:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\ "Disable Exchange Writer" DWORD=0
If the key already exists with a value of 1, change the value to 0. (Value 1 disables the Microsoft Exchange Writer.) For more information on enabling VSS Exchange writer, refer to How to turn on the Exchange writer for the Volume Shadow Copy service (it is marked as relevant for Windows Small Business Server 2003, but the procedure can also be applied to later versions).
Then restart the Microsoft Exchange Information Store service:
- Log in to the Exchange server and click Start.
- Enter services.msc in the search box, and press Enter. The Services window opens.
- From the list of services, right-click the Microsoft Exchange Information Store service (MSExchangeIS), and then click Restart. Note that during restart the users will be disconnected from Exchange.
After restarting Exchange, in the command prompt enter vssadmin list writers and verify that the VSS writers are listed. Then run your Exchange backup again.
Exchange logs truncation errors
Problem
The Exchange logs are not truncated or the log files are missing.
Cause
Exchange database log truncation is part of Exchange services. SEP sesam notifies Exchange Writer of each successful backup of Exchange Server and Exchange DAG nodes. SEP sesam does not manage or delete Exchange logs and is therefore not responsible for truncating logs, Microsoft Exchange Writer is. SEP sesam only notifies Exchange of the backup status and then:
- In configurations without DAG, Exchange Writer truncates the transaction log files after a successful full or incremental backup.
- In DAG replicated configurations, log truncation is delayed by the replication service until all required log files have been replayed into all other copies. The replication service deletes the backed-up log files from both the active and the copy log file paths after verifying that the log files have been successfully applied to the copy database and that both the active database and the database copies checkpoint have passed the log files to be deleted.
⇒ Solution
To verify that Exchange log truncation has been called, check the Applications and Services Logs and look for errors related to the Exchange VSS or Replica writer.
Check ESE events with ID:
- 224: This event indicates that logs are being deleted and denotes the associated database.
- 225: This event indicates that there are no logs available for truncation (either ESE cannot determine whether the transaction log files have been committed to the Exchange Server database, there are not enough logs or Circular Logging is enabled).
- 299: The replication service truncates the log stream and removes transaction logs that are no longer needed (or reports that there is not a minimum amount of logs for truncation).
If the Exchange configuration uses DAG, the replication process between the different nodes can prevent log truncation in case of errors. These errors are indicated with the event source MSExchangeRepl.
Below are some entries from the application log in the Event Viewer (for a list of errors, see the Microsoft article MSExchangeRepl Errors and Events):
· Event ID 224 (ESE) MDB01 deleting log files C:\ExchVols\MDB01\Log Files\E0000000001.log to C:\ExchVols\MDB01\Log Files\E000000002B.log. · Event ID 225 (ESE) MDB01—no log files can be truncated; will be logged instead of Event ID 224 when circular logging is used. · Event ID 2046 (MSExchangeRepl) VSS writer has successfully completed the backup of database MDB01. · Event ID 2006 (ESE) MDB01 shadow copy completed successfully. · Event ID 2033 (MSExchangeRepl) VSS writer has successfully processed the backup completion event. · Event ID 2037 (MSExchangeRepl) VSS writer backup has been successfully shut down.
If errors occur in connection with the Exchange VSS or Replica Writer, check the Exchange configuration to determine the cause and resolve the errors. Such errors cannot be caused by SEP sesam, but until they are resolved, Exchange cannot truncate the log files, resulting in filling up the volume or disk where they reside.
Also check the current status of the VSS writer by running the following at an administrative prompt on the Exchange server:
vssadmin list writers
If the writer is missing or is in a failed state, reboot the Exchange server and verify that it is now listed and showing as stable. Then restart the SEP sesam Exchange backup task and check the log truncation.
Exchange Recovery Pro asks for License
If you have started Exchange Recovery Pro the first time you get prompted to install the license. If you use several different Windows users, you get this prompt for every user.
NetWare
Checking the reachability of the TSA services
Problem 1
- Determining all available TSAs of a NetWare/OES Server.
⇒ Solution
- On a NetWare Server (the sbc_smdr command must be executed on a OES Linux machine with the sesam-novell-client package installed (up to OES2015) or on a OES2018 server (the sesam-novell-client is already included in the SEP Sesam SLES12 Linux Client package):
#> /opt/sesam/bin/sesam/sbc_smdr -D -N "nw1:::admin.admins.mydomain:novell:0" "/NetWare" 2007-03-21 16:42:50: sbc-3500: Info: ::/NetWare 2007-03-21 16:42:50: sbc-3036: Info: # @(#)SESAM BACKUP CLIENT FOR NETWARE FILE SYSTEMS, VERSION: 1.8R3 Build: 1.161 20070320 17:31:00 Linux i386 abas # 2007-03-21 16:42:50: sbc-3074: Info: Backup start time [20070321164250] 2007-03-21 16:42:50: sbc-3500: Info: Starting Session "SESAM SBC_NLM Session" ... 2007-03-21 16:42:52: sbc-3500: Info: NW1.NetWare File System "NW1.NetWare File System" d_ 2000.01.01 00:00:00 2000.01.01 00:00:00 4096 - , 2007-03-21 16:42:52: sbc-3500: Info: NW1.Novell Directory "NW1.Novell Directory" d_ 2000.01.01 00:00:00 2000.01.01 00:00:00 4096 - ,
In this case, the TSAFS (NW1.NetWare File System) and TSANDS (NW1.Novell Directory) are loaded.
- On an OES(2)-Linux server:
#> /opt/sesam/bin/sesam/sbc_smdr -D -N "oesnix1::oesnix1:backup:novell:0" "/NetWare" 2007-03-21 15:55:01: sbc-3500: Info: ::/NetWare 2007-03-21 15:55:01: sbc-3036: Info: # @(#)SESAM BACKUP CLIENT FOR NETWARE FILE SYSTEMS, VERSION: 1.8R3 Build: 1.161 20070320 17:31:00 Linux i386 abas # 2007-03-21 15:55:01: sbc-3074: Info: Backup start time [20070321155501] 2007-03-21 15:55:01: sbc-3500: Info: Starting Session "SESAM SBC_NLM Session" ... 2007-03-21 15:55:01: sbc-3500: Info: OESNIX1.GroupWise System "OESNIX1.GroupWise System" d_ 2000.01.01 00:00:00 2000.01.01 00:00:00 4096 - , 2007-03-21 15:55:01: sbc-3500: Info: OESNIX1.Linux File System "OESNIX1.Linux File System" d_ 2000.01.01 00:00:00 2000.01.01 00:00:00 4096 - ,
The TSAFSGW (OESNIX1.GroupWise System) and TSAFS (OESNIX1.Linux File System) are loaded.
Problem 2
- Determining the sources (resources) of a Target Service File System.
⇒ Solution
- Depending on your installed services, these TSA's are visible:
- NetWare File System
- Linux File System
- GroupWise System
- Novell Directory
- iFolder Store
- Linux Cluster File System
- NetWare Cluster File System
|
|
Tip |
| To enable debug mode for TSA, see Enabling the Debug Options in TSAFS on OES Linux. |
Unable to browse or backup a NetWare Server
Problem
- It is not possible to browse or back up a NetWare Server.
Possible causes
- No TSA is loaded, or
- The wrong data mover was inserted.
⇒ Solution
- Restart the NetWare file system with unload TSAFS and load TSAFS.
- Edit the properties of the NetWare Server in SEP sesam and adjust the data mover in the NetWare Access tab.
When using OES 2018 SP2 with SMDR/TSA, the TSA backup may fail
Problem
- When using OES 2018 SP2 with SMDR/TSA, the following problem occurs: If two TSA modules (e.g., tsafs and tsands) are loaded via smdr.conf, one of them does not work. Consequently, the TSA backup may fail under certain circumstances.
⇒ Workaround
- Start only one TSA module via smdr.conf, the other module should be loaded manually later. As this is a Micro Focus bug, see the Micro Focus community issue smdr on OES2018SP2 not working for more details.
Sesam Error: Client returns no data
Problem
- The following error message appears in /var/log/messages on OES Linux client:
nds_nss_GetGroupsbyMember: failed to init socket, status = 0 nds_nss_GetPwdbyName: init sock returned 0 nds_nss_GetPwdbyName: init sock returned 0 nds_nss_GetPwdbyName: init sock returned 0
Possible causes
- Incomplete or wrong eDirectory LUM configuration.
- eDirectory Server certificate is invalid/expired.
⇒ Solution
- Fix the lum setup so that eDirectory authentication can complete.
- Use iManager and check and/or recreate the server certificates.
Error messages during a backup
Message 1
(0XFFFDFFD7) "Login denied".
Possible causes
- Invalid username or password.
- eDirectory Server certificate is invalid/expired.
⇒ Solution
- Edit the properties of the client in SEP sesam and adjust the login data in the NetWare Access and Novell SMS tabs.
- Use iManager and check and/or recreate the server certificates.
Message 2
(0XFFFDFFCD) "A data stream cannot be opened." "Unable to open a data stream."
Possible causes
- The user does not have permission to access all data.
⇒ Solution
- Change the user name or adjust the permissions.
Message 3
(0XFFFEFFCC) "Could not write an object to NDS or write to a stream"
or
(0XFFFEFFB1) "Connection to remote host is lost. Remote host might have disconnected."
Possible causes
- The TSA or the smdr deamon is not running.
⇒ Solution
- Check TSA with opt/novell/sms/bin/smsconfig -t.
Message 4
(0XFFFDFFDC) "An invalid path was used."
Possible causes
- A wrong backup path was used or the TSAFS was loaded in an incorrect mode.
⇒ Solution
- In the event of --tsamode=dual, it is possible to simply use a Linux path.
- The source NetWare server backs up all existing volumes respectively.
- "VOL-NAME:" backs up a specific volume when using --tsamode=netware.
- The option --tsamode=linux supports path to the volumes/volumename only.
- In the event of a restore, insufficient access rights could be a reason for this message.
Files are locked after backup, server freezes
Problem
- Files are locked for several minutes after a backup and the server freezes spontaneously, requiring a reset.
⇒ Solution
- Update the sesam-novell-client to a higher version to solve this problem.
File-based backup is faster than Novell volume backup
Problem
- The file-based backup is faster than the Novell volume backup.
⇒ Solution
- Disabling the TSA-cache will increase the performance of a Novell-based backup and also decrease the system load.
- Edit the file /etc/opt/novell/sms/tsafs.conf, change the line "cachingmode=enable" to "cachingmode=disable" and apply the settings with rcnovell-smdrd restart.
Checking the performance and availability of a NSS volume via tsatest on OES2
- Back up the resource '/' using the supplied credentials.
tsatest -u root -p unsecure
- Back up the resource /home using the supplied credentials.
tsatest --path=/home -u root -p unsecure
- Back up the NetWare target SYS:\SYSTEM on ACME_SERVER using the supplied credentials.
tsatest -s ACME_SERVER -v SYS: --path=SYSTEM -u root -p unsecure
- Back up the '/' resource using the supplied credentials and a buffer size of 131072 bytes.
tsatest -b 131072 -u root -p unsecure
- Back up the resource '/' on server ACME_SERVER using the supplied credentials. This will perform a remote backup if ACME_SERVER is not the server on which tsatest is loaded/executed.
tsatest -s ACME_SERVER -u root -p unsecure
To check the performance on a NetWare Server, use these instructions: http://support.novell.com/docs/Tids/Solutions/10092890.html
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 – Interpreting Error Messages - Error Messages Guide – SEP sesam Exit Codes