Source:Troubleshooting Backup: Difference between revisions

From SEPsesam
(Added SBC on Linux issue (proposed by RS).)
(Minor correction.)
(6 intermediate revisions by the same user not shown)
Line 1: Line 1:
__FORCETOC__
__FORCETOC__


<noinclude>{{Copyright SEP AG en}}
<translate><!--T:1-->
<noinclude><languages />
{{Copyright SEP AG en}}


<!--T:2-->
{{Navigation_latest|release=[[Special:MyLanguage/SEP_sesam_Release_Versions|4.4.3/4.4.3 ''Beefalo V2'']]|link=[[Special:MyLanguage/SEP_sesam_Documentation#previous|documentation archive]]}}<br /></noinclude>
{{Navigation_latest|release=[[Special:MyLanguage/SEP_sesam_Release_Versions|4.4.3/4.4.3 ''Beefalo V2'']]|link=[[Special:MyLanguage/SEP_sesam_Documentation#previous|documentation archive]]}}<br /></noinclude>


==Backup problems==  
==Backup problems== <!--T:3--></translate>
<noinclude><div class="boilerplate metadata" id="Additional resources" style="background-color:#ecedf1; color:#8695a7; border: 1px ridge #cdd3db; margin: 0.5em; padding: 0.5em; float: right; width: 35%; "><center><b>
<noinclude><div class="boilerplate metadata" id="Additional resources" style="background-color:#ecedf1; color:#8695a7; border: 1px ridge #cdd3db; margin: 0.5em; padding: 0.5em; float: right; width: 35%; "><center><b><translate><!--T:4--> Additional resources</translate></b></center>
Additional resources</b></center>
{|style="margin: auto; margin-bottom:1em; width:100%; border:0px solid grey;"
{|style="margin: auto; margin-bottom:1em; width:100%; border:0px solid grey;"
| rowspan="2" style="padding:0px 10px 0px;" |  
| rowspan="2" style="padding:0px 10px 0px;" | [[File:SEP_next.png|45px|link=Special:MyLanguage/VSS_Troubleshooting]]
[[File:SEP_next.png|45px|link=Special:MyLanguage/VSS_Troubleshooting]]
| style="padding:0px 40px 0px 10px; color: grey; font-size: 90%; text-align:left;" | <translate><!--T:5--> See also: [[Special:MyLanguage/VSS_Troubleshooting|VSS Troubleshooting]] – [[Special:MyLanguage/Backup|Backup]]</translate>
| style="padding:0px 40px 0px 10px; color: grey; font-size: 90%; text-align:left;" |  
See also: [[Special:MyLanguage/VSS_Troubleshooting|VSS Troubleshooting]] – [[Special:MyLanguage/Backup|Backup]]
|}
|}


{|style="margin: auto; margin-bottom:1em; width:100%; border:0px solid grey;"
{|style="margin: auto; margin-bottom:1em; width:100%; border:0px solid grey;"
| rowspan="2" style="padding:0px 10px 0px;" |  
| rowspan="2" style="padding:0px 10px 0px;" |[[File:SEP Tip.png|45px|link=Special:MyLanguage/FAQ#backup_configuration|FAQ]]
[[File:SEP Tip.png|45px|link=Special:MyLanguage/FAQ#backup_configuration|FAQ]]
| style="padding:0px 40px 0px 10px; color: grey; font-size: 90%; text-align:left;" | <translate><!--T:6--> Check [[Special:MyLanguage/FAQ#backup_configuration|FAQ]] to find the answers to most common questions.</translate>
| style="padding:0px 40px 0px 10px; color: grey; font-size: 90%; text-align:left;" |  
Check [[Special:MyLanguage/FAQ#backup_configuration|FAQ]] to find the answers to most common questions.
|}
|}


{|style="margin: auto; margin-bottom:1em; width:100%; border:0px solid grey;"
{|style="margin: auto; margin-bottom:1em; width:100%; border:0px solid grey;"
| rowspan="2" style="padding:0px 10px 0px;" |  
| rowspan="2" style="padding:0px 10px 0px;" | [[File:SEP Troubleshooting.png|45px|link=Special:MyLanguage/Troubleshooting_Guide|Troubleshooting Guide]]
[[File:SEP Troubleshooting.png|45px|link=Special:MyLanguage/Troubleshooting_Guide|Troubleshooting Guide]]
| style="padding:0px 40px 0px 10px; color: grey; font-size: 90%; text-align:left;" | <translate><!--T:7--> Other problems? Check the [[Special:MyLanguage/Troubleshooting_Guide|Troubleshooting Guide]].</translate>
| style="padding:0px 40px 0px 10px; color: grey; font-size: 90%; text-align:left;" |  
|}</div></noinclude>
Other problems? Check the [[Special:MyLanguage/Troubleshooting_Guide|Troubleshooting Guide]].
<translate>=== Client backup error === <!--T:8--></translate>
|}
</div></noinclude>
==== Client backup error ====


'''Problem'''
'''<translate><!--T:9--> Problem</translate>'''
*A client backup did not function properly. How can I determine where the problem is?
*<translate><!--T:10--> A client backup did not function properly. How can I determine where the problem is?</translate>
&rArr; '''Solution''' <br />
&rArr; '''<translate><!--T:11--> Solution</translate>''' <br />
*Run the following commands to determine the error:
*<translate><!--T:12--> Run the following commands to determine the error:</translate>


{{warning|The following commands produce a high network load.}}
{{<translate><!--T:13--> warning</translate>|<translate><!--T:14--> The following commands produce a high network load.</translate>}}


''BACKUP SERVER UNIX, CLIENT WINDOWS''
''BACKUP SERVER UNIX, CLIENT WINDOWS''
Line 42: Line 37:
   sm_ctrlc -l system  {client name} sbc -b -s -  f:/test  >/dev/null
   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 {{path|/dev/null}} on Unix. To display it, append <tt>-v 1</tt> to the command above. Everything written to {{path|/dev/null}} will be displayed.
<translate><!--T:15--> Data from the F:/ directory on Windows is written over the network to the directory {{path|/dev/null}} on Unix. To display it, append <tt>-v 1</tt> to the command above. Everything written to {{path|/dev/null}} will be displayed.</translate>


   sm_ctrlc -l system  {client name}  sbc  -b -s  -  -v 1      f:/test  >/dev/null
   sm_ctrlc -l system  {client name}  sbc  -b -s  -  -v 1      f:/test  >/dev/null
Line 58: Line 53:
   sm_ctrlc -l root  {client name}  sbc  -b -s -            /usr    > NUL
   sm_ctrlc -l root  {client name}  sbc  -b -s -            /usr    > NUL


With backup data logging:
<translate><!--T:16--> With backup data logging:</translate>


   sm_ctrlc -l root  {client name}  sbc  -b -s -  -v  1  /usr    > NUL
   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:
<translate><!--T:17--> If the test backup is to be run on the target backup client only, execute the following command:</translate>


'''In the Unix directory {{path|<sesam>/bin/sesam/}}:'''
'''<translate><!--T:18--> In the Unix directory {{path|<sesam>/bin/sesam/}}:</translate>'''


   sbc -b -s  -  /usr  >/dev/null
   sbc -b -s  -  /usr  >/dev/null


'''In the Windows directory {{path|<SESAM_ROOT>\bin\sesam\}}:'''
'''<translate><!--T:19--> In the Windows directory {{path|<SESAM_ROOT>\bin\sesam\}}:</translate>'''


   sbc  -b -s  -  f:/test    > NUL
   sbc  -b -s  -  f:/test    > NUL


Enter <tt>-v 1</tt> to show the backed up data on your monitor.
<translate><!--T:20-->
Enter <tt>-v 1</tt> to show the backed up data on your monitor.


==== {{anchor|retain_failed}}Failed backups will be automatically deleted ====
=== {{anchor|retain_failed}}Failed backups will be automatically deleted === <!--T:21-->


'''Problem'''<br />
<!--T:22-->
*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?
'''Problem'''</translate><br />
*<translate><!--T:23--> 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?</translate>


&rArr; '''Solution''' <br />
&rArr; '''<translate><!--T:24--> Solution</translate>''' <br />
* 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 [[Special:MyLanguage/Managing_EOL#manual_extend|Manually extending EOL]]. '''Note:''' As of v. [[Special:MyLanguage/SEP_sesam_Release_Versions|4.4.3 ''Tigon V2'']], 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.
*<translate><!--T:25-->
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 [[Special:MyLanguage/Managing_EOL#manual_extend|Manually extending EOL]]. Note that as of v. [[Special:MyLanguage/SEP_sesam_Release_Versions|4.4.3 ''Tigon V2'']], 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 ====
=== Failed to write the data to media during backup === <!--T:26-->


'''Problem'''
<!--T:27-->
*During backup, operating system error "23 (ERROR_CRC)" is displayed.
'''Problem'''</translate>
'''Possible causes'''
*<translate><!--T:28-->
*The tape drive cannot write proper blocks onto the backup media.
During backup, operating system error "23 (ERROR_CRC)" is displayed.


&rArr; '''Solution'''
<!--T:29-->
*Check the tape drive and backup media.
'''Possible causes'''</translate>
*<translate><!--T:30--> The tape drive cannot write proper blocks onto the backup media.</translate>


==== Incorrect login or password ====
&rArr; '''<translate><!--T:31--> Solution</translate>'''
*<translate><!--T:32-->
Check the tape drive and backup media.


'''Problem'''
=== Incorrect login or password === <!--T:33-->
*During backup, the message ''"Login incorrect. Password incorrect"'' is displayed.


&rArr; '''Solution'''
<!--T:34-->
*Check your name resolution (DNS or <tt>etc/hosts</tt> 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:
'''Problem'''</translate>
# In the SEP sesam GUI, go to '''Main Selection -> Tasks -> By clients''', and select the client with the backup problem.
*<translate><!--T:35--> During backup, the message ''"Login incorrect. Password incorrect"'' is displayed.</translate>
# 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.


=== {{anchor|backup_Windows}}ON WINDOWS ===
&rArr; '''<translate><!--T:36--> Solution</translate>'''
*<translate><!--T:37--> Check your name resolution (DNS or <tt>etc/hosts</tt> 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:</translate>
# <translate><!--T:38--> In the SEP sesam GUI, go to '''Main Selection -> Tasks -> By Clients''', and select the client with the backup problem.</translate>
# <translate><!--T:39--> Open the backup properties and click the '''Options''' tab.</translate>
# <translate><!--T:40--> Type ''-v 4'' at '''Save options'''.</translate>
# <translate><!--T:41--> Start the backup again, then go to '''Main Selection -> Job state -> Backups''' and double-click the backup task to open its properties.</translate>
# <translate><!--T:42-->
Go to '''Logging -> Day log''' and search for the line ''Login incorrect. Password incorrect'' then correct the name resolution.


{{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 [[Special:MyLanguage/VSS_Troubleshooting|VSS Troubleshooting]] or refer to Microsoft's article [https://docs.microsoft.com/en-us/windows/desktop/VSS/volume-shadow-copy-service-portal Volume Shadow Copy Service] for more detailed ionformation on VSS.}}
=== {{anchor|network}}Network connection failure on physical or virtual systems === <!--T:43-->
==== Path backup on Windows is not working ====


'''Problem'''
<!--T:44-->
*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'''</translate>
  Problem while loading dynamic link library: [WIN32 API error: 1114 - A dynamic link library (DLL) <br>initialization routine failed. LoadLibrary() call failed for: [vss.dll]].
<ul><li><translate><!--T:45--> 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:</translate></li>
  10054 An existing connection was forcibly closed by the remote host


'''Possible causes'''
<translate><!--T:46--> or</translate>
*Typically, when <tt>dll</tt> cannot be initialised, a running antivirus solution is preventing it.
*The client's VSS configuration is incorrect.


&rArr; '''Solution'''
Error : Network communication problem: SOCKET error: 10054 - The virtual circuit which reset by the <br>remote side . recv () call failed.
*Disable the antivirus software during backup.
*Check the client's VSS configuration by running the following commands:
**<tt>vssadmin list writers</tt> - check the status of all writers on a daily basis.
**<tt>vssadmin list shadows</tt> - check existing VSS copies.
**<tt>vssadmin list shadowstorage</tt> - check how much space is reserved and available space for VSS.
**<tt>vssadmin resize shadowstorage</tt> - set the reserved space for VSS snapshots to unlimited.


==== WIN32 API error: "1450" ====
<translate><!--T:47--> For more details on Windows error codes, see [https://docs.microsoft.com/en-us/windows/win32/winsock/windows-sockets-error-codes-2?redirectedfrom=MSDN Microsoft Developer Network documentation].</translate>
</ul>
'''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 <br>the requested service.
'''<translate><!--T:48--> Possible causes</translate>'''
Cannot store registry key: [SOFTWARE]. RegSaveKey() call failed in BackupRegistry().].


'''Possible causes'''
'''''<translate><!--T:49--> Cause 1: Virtualization solutions</translate>'''''
*Insufficient size of the registry/paged memory area. This problem affects SEP sesam as well as other backup tools, such as NTBackup.


&rArr; '''Solution'''
<translate><!--T:50-->
*The Microsoft article [http://support.microsoft.com/kb/304101/en-us Backup program is unsuccessful when you back up a large system volume] explains approaches for different versions of Microsoft Windows.
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.


==== {{anchor|system_state}}System state backup is backing up large amount of data due to DFS ====
<!--T:51-->
'''Problem'''
The paravirtual network drivers may cause some problems:</translate>
*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 DFS Replication service too.
&rArr; '''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.}}


<ul><li>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 click ''New backup task''. In the ''New backup task'' window switch to the ''Options'' tab and under ''Additional call arguments'' -> ''Backup options'' exclude the DFS writer as follows:</li>
* <translate><!--T:52--> General CPU load of approx. 30% within a VM without any actions</translate>
-x "VSS:/DFS Replication service writer"
* <translate><!--T:53--> Very poor throughputs, even in disconnected networks or gigabit LANs</translate>
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 [[Special:MyLanguage/4_4_3:Backing_up_System_State|Backing up System State]].
* <translate><!--T:54-->
</ul>
Broken connections


==== System_State backup (RegLoadKey) error ====
<!--T:55-->
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.


'''Problem'''
<!--T:56-->
*What does the warning ''"The system cannot find path. RegLoadKey()..."'' during System_State backup mean?
The problem is at the same time visible on the SEP sesam Server:</translate>
*You may see the following output in NOT-log<!-- What is NOT-log? -->:


C:\Program Files\SEPsesam\var\tmp\usr_wf_S-1-5-21-220523388-1123561945-839522115-1003].
* <translate><!--T:57--> The backup remains in the ''active'' status with a 0 GB/h performance.</translate>
2010-04-13 02:04:20: sbc-2074: Warning: W2KSS Warning: [WIN32 API error: 3 -
* <translate><!--T:58--> There are active <tt>sm_sms_backup</tt> processes.</translate>
The system cannot find path. RegLoadKey() call failed for
* <translate><!--T:59-->
file: [C:\Documents and Settings\nn\ntuser.dat] in BackupUserProfiles().].
There are active <tt>sm_stpd</tt> processes.


'''Possible causes'''
<!--T:60-->
*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.
SEP sesam has no feedback from the client that the backup was aborted. The connection has been ''hard'' reset.


&rArr; '''Solution'''
<!--T:61-->
*Delete the user in question or restore the profile date in the file system.
'''''Cause 2: Network/Port trunking'''''
* 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
<!--T:62-->
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.  


==== Access denied during Microsoft Windows backup via VSS ====
<!--T:63-->
To resolve trunking issues, see [http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&externalId=1004048 Trunking configuration guide].


'''Problem'''
<!--T:64-->
*Why does a Microsoft Windows backup via VSS stop with the message ''"[CVssBaseObject::CreateVssBackupComponents] - Access denied"''?
'''''Cause 3: Firewall'''''


'''Possible causes'''
<!--T:65-->
*SEP sesam is not allowed to create a snapshot with the current user.
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.


&rArr; '''Solution'''
<!--T:66-->
*Check the user running the SEP sesam daemon and make sure that the user has all permissions to access the volume(s).
'''''Cause 4: Virus scanner'''''


==== Stream data length exceeds buffer capacity ====
<!--T:67-->
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 [[Special:MyLanguage/FAQ#antivirus_scanner|FAQ: What effect does an antivirus scanner have on SEP sesam?]].
'''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 causes'''
<!--T:68-->
*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 <tt>icacls</tt> to display the ACL of a file or folder. The output looks like this:
'''''Cause 5: Error on the SEP sesam Server side'''''


C:\>icacls "C:\Documents and Settings\LocalService\Local Settings\Temp"
<!--T:69-->
If a problem with the process <tt>sm_stpd.exe</tt> or <tt>sm_stpd</tt> occurs is recorded in the event viewer or the <tt>dmesg</tt> 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.


C:\Documents and Settings\LocalService\Local Settings\Temp NT AUTHORITY\LOCAL SERVICE:(I)(F)
<!--T:70-->
                                                            NT AUTHORITY\LOCAL SERVICE:(I)(OI)(CI)(IO)(F)
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''.
                                                            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.
<!--T:71-->
To solve this problem, delete and re-add the route as follows:</translate>


&rArr; '''Solution'''
route delete <translate><!--T:72--> <client_network></translate>
*Reset the permissions of the file's respective folder by using the command:
route add -p <translate><!--T:73--> <client_network></translate> mask <translate><!--T:74--> <network_mask_of_the_client_network></translate> <translate><!--T:75-->
<SEP_sesam_Server_IP>


C:\>icacls "C:\Documents and Settings\LocalService\Local Settings\Temp" /reset
<!--T:76-->
'''''Cause 6: Disabling task offloading'''''


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.
<!--T:77-->
''For VMs ''


==== Backup on Windows 7 did not complete successfully ====
<!--T:78-->
Disable the ''TSO'' (TCP Segment Offloading) feature in the VM.


'''Problem'''
<!--T:79-->
*When you perform a Windows 7 backup, the backup might fail with one of the following errors.
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.)
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'''
<!--T:80-->
*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.
''On Windows''
*This error occurs if the snapshot size exceeds the snapshot ''Maximum size'': ''Use limit'' configured for the volume.


&rArr; '''Solution'''
<!--T:81-->
*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'':
To disable this feature on Windows, the key ''DisableTaskOffload'' has to be set in the registry to prevent offloading to the network card, see [http://technet.microsoft.com/en-us/library/cc959732.aspx Microsoft documentation]. After setting this option on the backup client and then restarting, further backups run without any problems.  
** 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 [https://social.technet.microsoft.com/Forums/windows/en-US/e0c8c2d6-3a27-470a-bc32-96499c962240/shadow-copy?forum=w7itprogeneral Microsoft forum answers ''Shadow Copy''].  


=== {{anchor|backup_Linux}}ON LINUX ===
<!--T:82-->
''On Linux ''


==== SEP sesam Linux Client error during backup ====
<!--T:83-->
On Linux, you can activate or deactivate the TSO settings during runtime using the <tt>ethtool</tt> tool as follows:</translate>
ethtool -K eth0 tso off


'''Problem'''
<translate><!--T:84-->
*A SEP sesam Linux Client (SBC) issues an error or warning during backup.
''TCP retransmission''


'''Possible causes'''
<!--T:85-->
Fixing ''TCP retransmission'' errors at the network level fixes the root cause of the problem. To find ''TCP retransmission'' errors, the network analysis tool [http://www.wireshark.org/ Wireshark] is required.


The SBC on Linux backup may complete with an error or warning if:
<!--T:86-->
*the size of a file has changed during backup
You have to start a network analysis with Wireshark on the affected system (''Capture'' -> ''Interfaces'').</translate>
*a file is deleted during the backup (between 'find' and data processing)
*the 'find' function encountered an error


'''Solution'''
{{<translate><!--T:87--> Note</translate>|<translate><!--T:88--> Retransmission error appears as black lines in the Wireshark log.</translate>}}


<ul><li>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:</li>
<translate>=== {{anchor|backup_Windows}}ON WINDOWS === <!--T:89--></translate>
-o ignore_finderr=<regex>|ALL
<li>If you want to avoid all such errors/warnings, specify:</li>
-o ignore_finderr=ALL
</ul>


==== GVFS error during Linux backup ====
{{<translate><!--T:90--> note</translate>|<translate><!--T:91--> 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 [[Special:MyLanguage/VSS_Troubleshooting|VSS Troubleshooting]] or refer to Microsoft's article [https://docs.microsoft.com/en-us/windows/desktop/VSS/volume-shadow-copy-service-portal Volume Shadow Copy Service] for more detailed information on VSS.</translate>}}
<translate>==== Path backup on Windows is not working ==== <!--T:92-->


'''Problem'''  
<!--T:93-->
*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).
'''Problem'''</translate>
*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.
*<translate><!--T:94--> 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:</translate>
Problem while loading dynamic link library: [WIN32 API error: 1114 - A dynamic link library (DLL) <br>initialization routine failed. LoadLibrary() call failed for: [vss.dll]].


'''Solution'''
'''<translate><!--T:95--> Possible causes</translate>'''
*Create a new file named /etc/profile.local with the contents below <tt>/etc/profile.local</tt>:
*<translate><!--T:96--> Typically, when <tt>dll</tt> cannot be initialised, a running antivirus solution is preventing it.</translate>
*<translate><!--T:97--> The client's VSS configuration is incorrect.</translate>


GVFS_DISABLE_FUSE=1
&rArr; '''<translate><!--T:98--> Solution</translate>'''
export GVFS_DISABLE_FUSE
*<translate><!--T:99--> Disable the antivirus software during backup.</translate>
*<translate><!--T:100--> Check the client's VSS configuration by running the following commands:</translate>
**<tt>vssadmin list writers</tt> - <translate><!--T:101--> check the status of all writers on a daily basis</translate>
**<tt>vssadmin list shadows</tt> - <translate><!--T:102--> check existing VSS copies</translate>
**<tt>vssadmin list shadowstorage</tt> - <translate><!--T:103--> check how much space is reserved and available space for VSS</translate>
**<tt>vssadmin resize shadowstorage</tt> - <translate><!--T:104--> set the reserved space for VSS snapshots to unlimited</translate>


*Run the following command for each affected folder
==== WIN32 API error: "1450" ====
**fusermount -u /home/$USER/.gvfs
**test with stat /home/$USER/.gvfs
'''<translate><!--T:105--> Problem</translate>'''
*<translate><!--T:106--> What should I do when a client backup fails with a WIN32 API error: ''"1450 - Not enough system resources to execute the requested service"''?</translate>
*<translate><!--T:107--> The backup of a client may end with the following error message in the backup log:</translate>


==== Error Executing REAR ====
sbc-1148: Error:  W2KSS Error: [WIN32 API error: 1450 - Not enough system resources to execute <br>the requested service.
;Problem
Cannot store registry key: [SOFTWARE]. RegSaveKey() call failed in BackupRegistry().].
SEP sesam Client package was successfully installed and path backups are working. If you have problems executing a ReaR backup check the backup log if there are some missing dependencies.<br>Examples:
<pre>
There are binaries or libraries in the ReaR recovery system that need additional libraries
/opt/sesam/bin/sesam/libvirtmod.so requires additional libraries (fatal error)
libvirt.so.0 => not found
</pre>
<pre>
There are binaries or libraries in the ReaR recovery system that need additional libraries
/opt/sesam/bin/sesam/libvirtmod.so requires additional libraries (fatal error)
libvirt.so.0 => not found
/opt/sesam/bin/sms/libgnutls.so.30 requires additional libraries (fatal error)
libnettle.so.6 => not found
libhogweed.so.4 => not found
/opt/sesam/bin/sms/libgnutls.so.30.0.0 requires additional libraries (fatal error)
libnettle.so.6 => not found
libhogweed.so.4 => not found
/opt/sesam/bin/sms/libhogweed.so.4 requires additional libraries (fatal error)
libnettle.so.6 => not found
/opt/sesam/bin/sms/libhogweed.so.4.0 requires additional libraries (fatal error)
libnettle.so.6 => not found
</pre>
;Solution
See article [[Disaster Recovery for Linux 3.0 en]] how to solve this problem.


<!-- This entire topic (10054) must be reviewed so that it can be properly written. For the most part, it makes no sense.
'''<translate><!--T:108--> Possible causes</translate>'''
==== Network connections failure on physical or virtual systems ====
*<translate><!--T:109--> Insufficient size of the registry/paged memory area. This problem affects SEP sesam as well as other backup tools, such as NTBackup.</translate>


'''Problem'''
&rArr; '''<translate><!--T:110--> Solution</translate>'''
*Network Connections fail on physical or virtual systems. The log files contain one of the following error messages:
*<translate><!--T:111-->
10054 An existing connection was forcibly closed by the remote host
The Microsoft article [http://support.microsoft.com/kb/304101/en-us Backup program is unsuccessful when you back up a large system volume] explains approaches for different versions of Microsoft Windows.


or
==== {{anchor|system_state}}System state backup is backing up large amount of data due to DFS ==== <!--T:112-->


Error : Network communication problem: SOCKET error: 10054 - The virtual circuit which reset by the <br>remote side . recv () call failed.
<!--T:113-->
'''Problem'''</translate>
*<translate><!--T:114--> 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.</translate>
'''<translate><!--T:115--> Possible cause</translate>'''
*<translate><!--T:116--> If the DFS replication is enabled, the system state backup may include all the data from the DFS Replication service too.</translate>
&rArr; '''<translate><!--T:117--> Solution</translate>'''
{{<translate><!--T:118--> Note</translate>|<translate><!--T:119--> 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.</translate>}}


'''Possible causes'''
<ul><li><translate><!--T:120--> 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 click ''New backup task''. In the ''New backup task'' window switch to the ''Options'' tab and under ''Additional call arguments'' -> ''Backup options'' exclude the DFS writer as follows:</translate></li>
*;Virtualization Solutions
-x "VSS:/DFS Replication service writer"
Citrix XenTools and Installing VMware Tools may also create your own network card driver in the virtual machine, which will then be used instead of the regular Windows system drivers.
<translate><!--T:121--> 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 [[Special:MyLanguage/4_4_3:Backing_up_System_State|Backing up System State]].</translate>
</ul>


The Paravirtual network drivers can sometimes cause the following problems to occur :
<translate>==== System_State backup (RegLoadKey) error ==== <!--T:122-->


* General CPU load of about 30% within a VM when idle
<!--T:123-->
* Very poor transfer rates, even on 10 Gigabit networks or 1 Gigabit LAN
'''Problem'''</translate>
* Disconnections
*<translate><!--T:124--> What does the warning ''"The system cannot find path. RegLoadKey()..."'' during System_State backup mean?</translate>
*<translate><!--T:125--> You may see the following output in NOT-log</translate><!-- What is NOT-log? -->:


According to Microsoft documentation, the above error message says that the connection was reset by the client, so the tcp RST comes from the client system.
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().].


On the SEP sesam Server, the problem can be visible  as follows :
'''<translate><!--T:126--> Possible causes</translate>'''
*<translate><!--T:127--> 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.</translate>


* The backup remains in the status "active" with a 0 GB/h performance.
&rArr; '''<translate><!--T:128--> Solution</translate>'''
* There are active <tt>sm_sms_backup</tt> processes.
*<translate><!--T:129--> Delete the user in question or restore the profile date in the file system.</translate>
* There are active <tt>sm_stpd</tt> processes.
*<translate><!--T:130--> Check the following in your registry to see whether it still includes references to usernames which no longer exist:</translate>


SEP sesam has no feedback from the client that the backup was aborted. The connection was "hard" reset.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList


*;Network/Port trunking
<translate>==== Access denied during Microsoft Windows backup via VSS ==== <!--T:131-->
In several customer environments, port trunking has been identified to either side of the system to be backed up or to the backup server side. After the trunk has been dissolved, the actions were able to be performed without problems. Ordinarily, this type of disconnection happens in less than 5 minutes but can happen randomly. This is almost always related to a trunking problem but could be the result of TSO corruption on virtual machines or even physical machines with first revision 10/100 network cards.


Use this trunking configuration guide to resolve trunking issues http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&externalId=1004048
<!--T:132-->
'''Problem'''</translate>
*<translate><!--T:133-->
Why does a Microsoft Windows backup via VSS stop with the message ''"[CVssBaseObject::CreateVssBackupComponents] - Access denied"''?


*;Firewall
<!--T:134-->
Firewalls reach through stateful inspection measures active in the transport of data and can therefore be a cause of the problem. If the disconnection occurs in less than 5 minutes, it is likely a TSO/trunking issue. If the disconnect happens at almost exactly 5 or 60 or 120 minutes, it is a KeepAlive problem on NAT/PAT router or firewall issue.
'''Possible causes'''</translate>
*<translate><!--T:135--> SEP sesam is not allowed to create a snapshot with the current user.</translate>


*;Virus scanner
&rArr; '''<translate><!--T:136--> Solution</translate>'''
Virus scanners intervene actively in the data transmission and related processes and may thus be the cause of the problem. A false positive from an antivirus application will cause intermittent and random failures.
*<translate><!--T:137-->
Check the user running the SEP sesam daemon and make sure that the user has all permissions to access the volume(s).


Exclude virus scanner recommendation for SEP sesam
==== Stream data length exceeds buffer capacity ==== <!--T:138-->
It is recommended to use the antivirus exclusions for SEP sesam as they can have adverse effects on backup and restore operations, for example:
*GUI is very slow or hangs for several seconds
'''Problem'''</translate>
*Sudden discontinuation of backup or restore jobs
*<translate><!--T:139-->
*Reduced throughput and speed
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]"'' ?


The following objects must be excluded from any virus scanner activities:
<!--T:140-->
*All SEP sesam installation directories on the backup server, client and Remote Device Server:
'''Possible causes'''</translate>
*<tt>SESAM_BIN</tt> directory including all subdirectories
*<translate><!--T:141--> 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 <tt>icacls</tt> to display the ACL of a file or folder. The output looks like this:</translate>
*<tt>SESAM_VAR</tt> directory including all subdirectories
* DataStore on the backup server and Remote Device Server
**each volume on which a DataStore is filed, must be excluded from virus scanning
*All SEP sesam processes on the backup server, client and Remote Device Server. Close all executable files from the following directories from:
***<SESAM_ROOT> / Bin / sesam / *. *
**<SESAM_ROOT> / Bin / sms / *. *


Alternatively, the "child process monitoring" option can be disabled with some virus scanners to the exclude rule settings.
C:\>icacls "C:\Documents and Settings\LocalService\Local Settings\Temp"
Then only need the following September islets excluded sesam processes:
'''1. Windows''':
*sm_main.exe
*sm_ctrld_main.exe
*sm_db_main.exe
*sm_passd.exe
*sm_rmi_main.exe
*sm_sepuler.exe
*sm_sms_main.exe
*sm_data_server.exe
*sm_stpd_main.exe
*sbc.exe


'''2. Linux''':
C:\Documents and Settings\LocalService\Local Settings\Temp NT AUTHORITY\LOCAL SERVICE:(I)(F)
*sm_qm_main
                                                            NT AUTHORITY\LOCAL SERVICE:(I)(OI)(CI)(IO)(F)
*SM_CTRLD_MAIN
                                                            NT AUTHORITY\SYSTEM:(I)(F)
*sm_db_main
                                                            NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
*sm_passd
                                                            BUILTIN\Administrators:(I)(F)
*sm_rmi_main
                                                            BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
*sm_sepuler
Successfully processed 1 files; Failed processing 0 files
*sm_sms_main
*sm_data_server
*sm_stpd_main
*sbc


*;Error on SEP sesam Server side
<translate><!--T:142--> If you get several hundred or thousand lines, there is something wrong with the ACL.</translate>
*
* If there is a <tt>sm_stpd.exe</tt> or <tt>sm_stpd</tt> problem when a backup in the event viewer is abandoned or during the <tt>dmesg</tt> output of a SEP sesam Server, the problem must be analysed on the SEP sesam Server side.???Originally:  If the time of abandonment of the backup in the event viewer or the <tt>dmesg</tt> output of a SEP sesam Server a problem with the process <tt>sm_stpd.exe</tt> or <tt>sm_stpd</tt> on, so the problem of sesam server side to be analyzed.???
* 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 the other way around.


In the case described in the SEP sesam Server was the ''Permanent'' set route in the network of clients, but she was not part of the ''active'' routes. ???What this means???<br>
&rArr; '''<translate><!--T:143--> Solution</translate>'''
To solve this problem, delete and re-add the route:
*<translate><!--T:144--> Reset the permissions of the file's respective folder by using the command:</translate>


  route delete <NetzwerkdesClients>
  C:\>icacls "C:\Documents and Settings\LocalService\Local Settings\Temp" /reset
route add -p <NetzwerkdesClients> mask <NetzmaskedesClientnetzwerkes> <IPdesSesamServers>


&rArr; '''Solution'''
<translate><!--T:145-->
*;Turn ''Task offloading'' off
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.


''' VMs '''
==== Backup on Windows 7 did not complete successfully ==== <!--T:146-->


Turn off the TSO (TCP segment offloading) feature in the VM. Both Citrix XenServer and VMware ESXi are available in the network, the existing types "TSO" (TCP segment offloading).
<!--T:147-->
'''Problem'''</translate>
*<translate><!--T:148--> When you perform a Windows 7 backup, the backup might fail with one of the following errors.</translate>
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]
*<translate><!--T:149--> 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:</translate>
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.


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).
<translate><!--T:150--> '''Possible causes'''</translate>
*<translate><!--T:151--> 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.</translate>
*<translate><!--T:152--> This error occurs if the snapshot size exceeds the snapshot ''Maximum size'': ''Use limit'' configured for the volume.</translate>


Sense, it is the CPU load thereby reduce because the actual calculation is then performed on the network card.
&rArr; '''<translate><!--T:153--> Solution</translate>'''
*<translate><!--T:154--> 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'':</translate>
** <translate><!--T:155--> 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.</translate>
**<translate><!--T:156-->
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 [https://social.technet.microsoft.com/Forums/windows/en-US/e0c8c2d6-3a27-470a-bc32-96499c962240/shadow-copy?forum=w7itprogeneral Microsoft forum answers ''Shadow Copy''].  


The XenServer NIC drivers are more affected by this problem.
=== {{anchor|backup_Linux}}ON LINUX === <!--T:157-->


''' Windows '''
==== SEP sesam Linux Client error during backup ==== <!--T:158-->


The following Microsoft article describes how this feature can be disabled on Windows Server 2003 systems:
<!--T:159-->
'''Problem'''</translate>
*<translate><!--T:160-->
A SEP sesam Linux Client (SBC) issues an error or warning during backup.


http://support.microsoft.com/?scid=kb % 3ben -us % 3B904946 & x = 12 & y = 10
<!--T:161-->
'''Possible causes'''


In the end, is in the registry of the key set "is DisableTaskOffload '' '' " to prevent the " offloading " on the network card :
<!--T:162-->
Backup on Linux may finish with an error or warning if:</translate>
*<translate><!--T:163--> the size of a file has changed during the backup</translate>
*<translate><!--T:164--> a file is deleted during the backup (between 'find' and data processing)</translate>
*<translate><!--T:165--> the 'find' function encountered an error</translate>


http://technet.microsoft.com/en-us/library/cc959732.aspx
&rArr; <translate><!--T:166--> '''Solution'''</translate>


Under this option set on the backup client and rebooting additional backups are running smoothly.
<ul><li><translate><!--T:167--> 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:</translate></li>
-o ignore_finderr=<regex>|ALL
<li><translate><!--T:168--> If you want to avoid all such errors/warnings, specify:</translate></li>
-o ignore_finderr=ALL
</ul>


''' Linux '''
<translate>==== GVFS error during Linux backup ==== <!--T:169-->


On Linux, you can enable or disable the TSO settings via the Tools <tt> ethtool </tt> at run time:
<!--T:170-->
ethtool -K eth0 tso off
'''Problem'''</translate>
*<translate><!--T:171--> 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).</translate>
*<translate><!--T:172--> 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.</translate>


*TCP Retransmission
&rArr; <translate><!--T:173--> '''Solution'''</translate>
The remedy of "TCP Retransmission" errors on the network level removes the root cause of the problem. <br>
*<translate><!--T:174--> Create a new file named /etc/profile.local with the contents below <tt>/etc/profile.local</tt>:</translate>


To find " TCP Retransmission " error , the network analysis tool [ http://www.wireshark.org/ Wireshark ] is needed.
GVFS_DISABLE_FUSE=1
export GVFS_DISABLE_FUSE


Start with Wireshark network analysis on the affected system : " Capture - > Interfaces "
*<translate><!--T:175--> Run the following command for each affected folder</translate>
**fusermount -u /home/$USER/.gvfs
**test with stat /home/$USER/.gvfs


'''Note :''' Retransmission error appear as black lines in the Wireshark log.
<translate><!--T:176-->
-->
<noinclude>== See also ==
<noinclude>== See also ==
[[Special:MyLanguage/VSS_Troubleshooting|VSS Troubleshooting]] – [[Special:MyLanguage/Backup|Backup]]</noinclude>
[[Special:MyLanguage/VSS_Troubleshooting|VSS Troubleshooting]] – [[Special:MyLanguage/Backup|Backup]]</noinclude></translate>

Revision as of 14:20, 12 February 2021


Other languages:

Template:Copyright SEP AG en

Docs latest icon.png Welcome to the latest SEP sesam documentation version 4.4.3/4.4.3 Beefalo V2. For previous documentation version(s), check documentation archive.


Backup problems

Client backup error

Problem

  • A client backup did not function properly. How can I determine where the problem is?

Solution

  • Run the following commands to determine the error:
SEP Warning.png 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?

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 as of v. 4.4.3 Tigon V2, 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 causes

  • The tape drive cannot write proper blocks onto the backup media.

Solution

  • Check the tape drive and backup media.

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:
  1. In the SEP sesam GUI, go to Main Selection -> Tasks -> By Clients, and select the client with the backup problem.
  2. Open the backup properties and click the Options tab.
  3. Type -v 4 at Save options.
  4. Start the backup again, then go to Main Selection -> Job state -> Backups and double-click the backup task to open its properties.
  5. Go to Logging -> Day log and search for the line Login incorrect. Password incorrect then correct the name resolution.

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 FAQ: What effect does an antivirus scanner have on 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).

Information sign.png Note
Retransmission error appears as black lines in the Wireshark log.

ON WINDOWS

Information sign.png 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 causes

  • Insufficient size of the registry/paged memory area. This problem affects SEP sesam as well as other backup tools, such as NTBackup.

Solution

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

Information sign.png 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 click New backup task. In the New backup task 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 causes

  • 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 causes

  • 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 causes

  • 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 command for each affected folder
    • fusermount -u /home/$USER/.gvfs
    • test with stat /home/$USER/.gvfs

See also

VSS TroubleshootingBackup