Discovery backup to a Windows share or SMB share on a Linux/Samba server fails on verification with unexpected end of stream errors. At different points of the verification, these errors have been observed:
backup.manager: ERROR: Cannot read file jdbcdrivers/oracleSID-12c.jar from archive file /tmp/tmpnqH17L/2018-06-06_113555_addm_backup/60cae23537eff2fcb3300ae6f4893666/addm_data_custom_jdbcdrivers.tgz Unexpected end of stream Cannot read file httpd/conf/ssl.crt/ca-bundle.crt from archive file /tmp/2018-04-03_134747_addm_backup/addm_https_conf.tgz Unexpected end of stream If backup verification is not selected, the failure/corruption would not be noticed. If this is the case, a restore using this backup will fail with similar error messages. The backup .tgz files affected by this issue are not always the same. As an example, the files listed below can also be affected: addm_etc.tgz
addm_product_content_rpms.tgz addm_reports.tgz A 'tar tvf' fails with "Unexpected end of stream" when executed on the files reported as broken. These files appear to be truncated or empty. For example: $ ls -la addm_reports.tgz
-rwxr-xr-x 1 tideway tideway 0 Oct 19 09:30 addm_reports.tgz A manual verification of this file (with tw_restore --verify-only) confirms that it is broken. Typically, a different file is broken each time. This problem has been reported on both a Windows share and an SMB share on a Linux/Samba server (this is a supported configuration). |
Root cause 1: Microsoft defect in the CIFS/SMB implementation.
Solution: Engage Microsoft Customer support to fix the defect Workaround: use documented procedure, section "Windows share (SMB) backups" Suggested procedure to implement the workaround 1 ("Mount the share ... on the appliance"): Run the following commands as user tideway:
1- Create a mount point for the share:
mkdir /usr/tideway/SMB
2- Run the ‘id’ command to get the ID of the directory owner:
id
3- Substitute the uid and gid values from the "id" command into the following command:
sudo mount -t cifs '//servername/sharename' '/usr/tideway/SMB' -o 'defaults,uid=xxx,gid=xxx,username=mywindowsaccount'
Also provide the share name and the Windows account name. For example: sudo mount -t cifs '//mywindowshost/backup' '/usr/tideway/SMB' -o 'defaults,uid=1000,gid=1000,username=Administrator'
Note: The error "mount error(13): Permission denied" may appear if using a Windows domain account. If the permissions are valid, then this is likely due to using the format "domain/user" for the username. Set username without the domain or use "domain=" to specify the domain, for example: sudo mount -t cifs '//mywindowshost/backup' '/usr/tideway/SMB' -o 'defaults,uid=1000,gid=1000,username=mywindowsaccount,domain=mywindowsdomain'
Run this command. When prompted, provide the password for the Windows account. 4- Then run the backup: A- From the UI with the parameter below
Backup Type = SSH
Host = IP address or hostname of the Discovery appliance where the share is mounted Directory = mount point for the share (i.e. /usr/tideway/SMB) Username/Password: for the Discovery appliance B- with the command below:
tw_backup --stop-services --backup-ssh --backup-dir=/usr/tideway/SMB --host=xxx.xxx.xxx.xxx --loglevel=debug --remote-user=tideway --remote-password=tidewaypassword
Please refer following video for more guidance:
Root cause 2: name resolution problem for the Windows host. Workaround: Try performing the backup using the host's IP address instead of the host name.
Root cause 3: Permission issue on the Windows server where the backup is being saved
Workaround: Try moving previously backed up folder to another share in a different Windows server |