Quantcast
Channel: Symantec Connect - Backup and Recovery - Known Issues
Viewing all 178 articles
Browse latest View live

CPU configuration is not preserved following a full virtual machine restore with the Backup Exec Agent for VMware.

$
0
0
Severity: 
Minor functionality
Status: 
Investigating/gathering information
Tech Note: 
198164

Problem

Following a full virtual machine restore using the Backup Exec Agent for VMware, the CPU configuration is not preserved.

The example below shows a virtual machine configured with 4 CPUs (2 virtual sockets, 2 cores per socket). Following a restore back to the original location, this changes to 4 CPUs (4 virtual sockets, 1 core per socket).

Figure 1:

Environment

ESXi 5.0

Solution

The only workaround available is to manually set the correct CPU configuration following the restore.

Symantec Corporation has acknowledged that the above-mentioned issue is present in the current version(s) of the product(s) mentioned at the end of this article. Symantec Corporation is committed to product quality and satisfied customers.
 
This issue is currently under investigation by Symantec Corporation. Pending the outcome of the investigation, this issue may be resolved by way of a patch or hotfix in current or future revisions of the software. However, this particular issue is not currently scheduled for any release.  If you feel this issue has a direct business impact for you and your continued use of the product, please contact your Symantec Sales representative or the Symantec Sales group to discuss these concerns.  For information on how to contact Symantec Sales, please see http://www.symantec.com

Please be sure to refer back to this document periodically as any changes to the status of the issue will be reflected here.


After a successful restore of a SQL Database, the database is left un-attached when the option for "Leave the database nonoperation" is selected.

$
0
0
Severity: 
Non-data threatening / major functionality
Status: 
Investigating/gathering information
Tech Note: 
198181

This issue is currently under investigation.

Manual Disaster Recovery of a Windows 2008 R2 Domain Controller fails with error "0xe000fed7 - A failure occurred performing custom restore”

$
0
0
Severity: 
Data threat/Security vulnerability
Status: 
Investigating/gathering information
Tech Note: 
198214

Manual Disaster Recovery of a Windows 2008 R2 Domain Controller fails error “0xe000fed7 – A failure occurred performing custom restore”. Restore job restores C, D and shadow copy components successfully but fails when trying to restore System State.

For more details please refer to the following article:

http://www.symantec.com/docs/TECH198214

Automatic cleanup of recovery points not working consistently which causes backup destination to run out of disk space.

$
0
0
Severity: 
Non-data threatening / major functionality
Status: 
Investigating/gathering information
Tech Note: 
198360

Problem

Automatic cleanup of recovery points, to remain with the threshold ('Recovery Point Limit') specified, is not working consistently. This causes the backup destination to run out of disk space and subsequent backups to fail.

Consider the following scenario:

5 independent backup jobs targeted to their own specific USB drive. Recovery point limit is set to 2.

Monday backup is targeted to 'Monday' USB drive. Tuesday backup is targeted to 'Tuesday' USB drive and so on.

The issue is seen when 3 recovery point files are stored on the USB drive (i.e. the oldest recovery point should have been automatically removed when the most recent backup was completed).

Error

High Priority Info: Error EBAB03F1: The operation was canceled by the user.
Info 6C8F1C2F: A recovery point operation on drive Tuesday was cancelled by the user.
Error E7D1001F: Unable to write to file.
Error E7D1003C: There is not enough space.
Error EBAB03F1: There is not enough space on the disk. 0x800704C7 (Backup Exec System Recovery)

Solution

The only workaround currently available is to manually delete the oldest recovery point to remain within the limit specified.

Symantec Corporation has acknowledged that the above-mentioned issue is present in the current version(s) of the product(s) mentioned at the end of this article. Symantec Corporation is committed to product quality and satisfied customers.
 
This issue is currently under investigation by Symantec Corporation. Pending the outcome of the investigation, this issue may be resolved by way of a patch or hotfix in current or future revisions of the software. However, this particular issue is not currently scheduled for any release.  If you feel this issue has a direct business impact for you and your continued use of the product, please contact your Symantec Sales representative or the Symantec Sales group to discuss these concerns.  For information on how to contact Symantec Sales, please see http://www.symantec.com

Please be sure to refer back to this document periodically as any changes to the status of the issue will be reflected here.

Local resource enumeration / discovery takes 7-15 minutes when EFI disk partition is in use

$
0
0
Severity: 
Non-data threatening / major functionality
Status: 
Investigating/gathering information
Tech Note: 
198184

When trying to browse the local resources of a Backup Exec media server it may be noticed that there is a delay of 7 to 15 minutes when a EFI partition / disk is being used on the server

File level GRT restore from a backup done with Backup Exec 2010 R3 fails with backup Exec 2012 with the error "Failed to mount one or more virtual disk images"

$
0
0
Severity: 
Minor functionality
Status: 
Investigating/gathering information
Tech Note: 
198382

This issue is currently under investigation.

SQL Redirect Restore fails with error "Unclosed quotation mark after the character string 'X:\SQL_D'"

$
0
0
Severity: 
Minor functionality
Status: 
Investigating/gathering information
Tech Note: 
198367

Backup Exec SQL redirect restore query which gets executed in the background is currently limited to 4096 characters. If the redirect restore query goes beyond 4096 the query will be truncated and would result in the above error. Restore to the same location should be fine.

Symantec DLO 7.0 may still transfer files from clients even if Connection Policy settings are set to block transfer

$
0
0
Severity: 
Non-data threatening / major functionality
Status: 
Investigating/gathering information
Tech Note: 
198424

It has been seen that a DLO client on the network, that is assigned a DLO Profile with Connection Policy configured to block network transfers (i.e. when using an IP address within a VPN range), may still transfer files, if the DLO Profile is changed or if you attempt to force the client to work online.

Any files that are updated on the client will normally queue in the DLO agent console, showing as 'Pending Network' and the client will show as 'Working offline', until connected in a way that allows transfers (i.e. using an IP address on the local LAN).

If you attempt to manually force the DLO client to work online, using the console task bar option or if the associated DLO profile is updated while the Client desktop is connected to the network, file transfers may start, even though they are not supposed to. Only 1-2 files may be transferred, but if the files being sent are large, the transfer of that file will continue until finished.The DLO client will then revert to a 'Working Offline' state.


Backups of specific LVM volume fail ('Error E5D40024: Snap device torn down due to excessive I/O on the Volume.') when using Symantec System Recovery Linux Edition (SSR-L).

$
0
0
Severity: 
Non-data threatening / major functionality
Status: 
Investigating/gathering information
Tech Note: 
198555

Problem

Backups of a specific LVM volume fail with the error listed below. Other LVM volumes backup successfully.

Error

Error E5D40024: Snap device torn down due to excessive I/O on the Volume.
Error E0A20019: Backup Failed.

The messages log shows the following error:

finrod kernel: numSectors in request is not on block boundary, invalidating snap

Environment

Red Hat 5.8 x64

Solution

There is currently no workaround to this issue.

Symantec Corporation has acknowledged that the above-mentioned issue is present in the current version(s) of the product(s) mentioned at the end of this article. Symantec Corporation is committed to product quality and satisfied customers.
 
This issue is currently under investigation by Symantec Corporation. Pending the outcome of the investigation, this issue may be resolved by way of a patch or hotfix in current or future revisions of the software. However, this particular issue is not currently scheduled for any release.  If you feel this issue has a direct business impact for you and your continued use of the product, please contact your Symantec Sales representative or the Symantec Sales group to discuss these concerns.  For information on how to contact Symantec Sales, please see http://www.symantec.com

Please be sure to refer back to this document periodically as any changes to the status of the issue will be reflected here.

During the restore of a SQL database with multiple backup sets the Backup Exec job engine may crash

$
0
0
Severity: 
Non-data threatening / major functionality
Status: 
Investigating/gathering information
Tech Note: 
198587

This issue is currently under investigation.

GRT Restore from a Vmware agent based incremental backup of a Virtual Machine fails with "Failed to mount one or more virtual disk images" error

$
0
0
Severity: 
Non-data threatening / major functionality
Status: 
Investigating/gathering information
Tech Note: 
198569

Restore of individual file or folder from a Vmware agent based incremental backup of a VM fails with error “0xe0009741 - Failed to mount one or more virtual disk images”. Full and incremental Vmware agent GRT backup of the VM completes successfully and restore from Full backup works but the restore from only incremental GRT backup set fails.

For more details please refer to the following article:

http://www.symantec.com/docs/TECH198569

Tapes displaying incorrect media labels

$
0
0
Severity: 
Non-data threatening / major functionality
Status: 
Investigating/gathering information
Tech Note: 
198615

(see tech article referenced above for more detail)

Catalog Meta-Data job that runs after an Exchange Granular Recovery Technology (GRT) enabled backup set hangs and does not complete.

Exchange Granular Recovery Technology (GRT) backup to tape fails with: VFF Open Failure. This can be caused by low memory or disk resources.

$
0
0
Severity: 
Non-data threatening / major functionality
Status: 
Investigating/gathering information
Tech Note: 
198980

Please see http://www.symantec.com/docs/TECH198980 for additional details on this issue.

Backup of a virtual machine may fail with the error virtualmachine.vmdk is corrupt

$
0
0
Severity: 
Non-data threatening / major functionality
Status: 
Investigating/gathering information
Tech Note: 
198982

This issue is currently under investigation


Backup of large VMDK, after Backup Exec 2010 R3 hot fix 194471, fails with "0xe0009578 - Unable to copy the virtual machine disk using the VMware VixDiskLib."

$
0
0
Severity: 
Non-data threatening / major functionality
Status: 
Investigating/gathering information
Tech Note: 
198981

See associated tech note latest update on this issue

Backup job exclude rule ignoring, 'Files not accessed in,' value.

$
0
0
Severity: 
Minor functionality
Status: 
Investigating/gathering information
Tech Note: 
199139

While creating a backup job within Backup Exec 2012, specifying an exclusion rule that uses the, 'File not access in,' X days, where X is the number of days a file has since been last access excludes all files of specified type. This was not an issue in previous versions.

 
 

 

Backup of an virtual machine with Exchange installed may not clear the Exchange Transaction Logs after a full backup with GRT enabled.

$
0
0
Severity: 
Minor functionality
Status: 
Investigating/gathering information
Tech Note: 
199574

This issue is currently under investigation.

Exchange 2010 GRT restore of individual emails fails with error “The resource credentials for the restore job were unable to create a role assignment for ApplicationImpersonation”

$
0
0
Severity: 
Non-data threatening / major functionality
Status: 
Investigating/gathering information
Tech Note: 
199611

Exchange 2010 GRT restore of individual emails fails with error “The resource credentials for the restore job were unable to create a role assignment for ApplicationImpersonation”.

Beremote logs on Client Access Server server shows following error:

[10164]  [fsys\shared]        - EnsureEwsPermissions returned e00003c3
[10164]  [fsys\mb2]           - FATAL: failed to aquire EWS ApplicationImpersonation rights
[10164]  [fsys\shared]        - GetMailboxInfo returned e00003c3 ->
[10164]  [fsys\shared]        - GetMailboxInfo returned e00003c3 ->

For more information please check the following article

http://www.symantec.com/docs/TECH199611

Incremental backup job doesn't run and is set to 'Superseded' status if full backup job with no recurring schedule is suspended after it is performed

$
0
0
Severity: 
Minor functionality
Status: 
Investigating/gathering information
Tech Note: 
199662

 If a full backup job with no recurring schedule is suspended after it is performed, the subsequent incremental/differential backup job does not run and the job status is set to 'Superseded' when the scheduled time comes.

The job can be suspended via BEMCLI with the following commands:

BEMCLI> Get-BEJob "Job-Name-Full" | Start-BEJob -Confirm:$False | Wait-BEJob ; Get-BEJob "Job-Name-Full" | Suspend-BEJob

Please be noted that this issue reproduces only when a full backup job does not have recurring schedule.

This issue is currently under investigation by Symantec Corporation. For more information please check the following article.
http://www.symantec.com/docs/TECH199662
 

Viewing all 178 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>