Disaster Recovery Option
The following issues relating to the Disaster Recovery Option are known to exist in this release:
- After Disaster Recovery is completed, the size of the last partition recovered can be expanded from the original size by as much as 8 MB. The problem occurs if free space is available at the end of the last partition on the disk being recovered.
- For Microsoft SQL-hosted Arcserve Backup databases, the operating system will record numerous application errors of MSSQL$ARCSERVE_DB to the Event Log during recovery of the database, such as:
- 8355
- 17204
- 17207
- Since these events are recorded by the recovery of the database, they pose no problem.
- When Arcserve Backup Server (Primary or Member) is configured in Cluster with the Disaster Recovery Option installed, the "Alternate Location for DR Information" setting may not be stored when the cluster is ready after installation. Reconfigure this setting by running the DR Boot Kit Wizard Utility from Active Node and re-enter it.
- The database engine will not start automatically after successful recovery of the Arcserve Backup database. Upon the first reboot after performing Disaster Recovery of the Arcserve Backup Server hosting the Arcserve database, you must restart the database engine through the Arcserve Backup Manager Console.
- When performing Disaster Recovery on Microsoft Windows 2008 systems, the Create Folder button may not work when attempting to save logs. To save logs, create a new folder using the mkdir command with the Open Console button or save logs into an existing folder.
- If your system is configured with a number of volumes mounted via mount points, Disaster Recovery cannot be performed correctly. You must format and restore data manually.
- If an iSCSI LUN is being used as a shared disk by a failover cluster, that LUN cannot be restored while performing Disaster Recovery of the cluster.
- Consider the following situation:
- Arcserve Backup is installed on Server A. On Server B, two shared folders exist and are configured on Server A as remote File System or Data Deduplication devices using different Windows accounts. When using the Disaster Recovery option to restore backup data from these devices, Arcserve Backup will be able to connect to only one. Connection to the second device fails with Windows error 1219 because multiple connections to shared resources by the same user, using more than one user name, are not allowed.
- You cannot log into Arcserve Backup with a blue screen (error code: 000000FC) when performing disaster recovery from a Physical Machine (DELL 270) to a Virtual Hyper-V environment. To resolve this issue, log into Arcserve Backup by performing the following steps:
- Press F8 when the startup menu appears, use the arrow keys to select the safe mode option, and then press ENTER.
- Click Start, Run, and type 'cmd', and then click OK.
- At command prompt, type the following and then press ENTER:
- bootcfg/raw "/noexecute=alwaysoff /fastdetect" /id 1
- When performing disaster recovery on a cluster environment that has Arcserve Backup installed on an iSCSI connected shared disk, the Arcserve Backup database recovery utility fails to launch automatically after the disaster recovery completes and the machine reboots. The reason being the iSCSI Initiator which needs time to re-establish the connection.
- As a workaround, you can manually run the Arcserve Backup database recovery utility after logging into Windows and connecting to the cluster shared disk.
- You cannot open the online help for the iSCSI Initiator Properties screen on a WinPE Disaster Recovery environment.
- During the Disaster Recovery process, if the cluster shared disk is not ready when the client Agent begins, the cluster volumes on the shared disk will become inaccessible, the disk quota cannot be restored, and the diskquota.inf file cannot be deleted.
- As a workaround, once all shared disks become available, you can perform the following operations to restore the disk quota:
- Add a DWORD key: IsResDskQuota to the following registry:
- HKEY_LOCAL_MACHINE\SOFTWARE\ComputerAssociates\CA ARCServeBackup\ClientAgent\Parameters
- Set parameter to 1
- Restart the Universal Agent Service
- Due to Windows limitation, Windows Server 2008 R2 fails to reboot after running WinPE Disaster Recovery on uEFI systems with MBR (Master Boot Record) disks attached and logical volume that exists on an extended partition.
- It is a known issue for a staging backup job to be marked as "Crashed" in the Job Queue after the Disaster Recovery process completes from the staging device.
- When you perform a remote backup from one primary Server (A) to another primary Server (B) with Arcserve Backup Database (ASDB) locally installed and then perform disaster recovery, the ASDB will not restore automatically.
- As a workaround, you need to manually perform the following in order to restore the Server containing ASDB:
- From Server A, submit a restore job to recover the SQL Disaster Recovery Element Session.
- This ensures that the SQL Service operates successfully on Server B.
- From Server B, manually start the SQL Service.
- From Server A, submit a restore job to recover the ASDB session from Server B.
- With Global Dashboard configured and Disaster Recovery is run, the Global Dashboard becomes unavailable. The reason being is that the Global Dashboard maintains its own database called "asdb_central" where Disaster Recovery does not recover.
- To recover the Global Dashboard, you need to restore the "asdb_central" database from the Arcserve Backup Restore Manager after Disaster Recovery completes.
- When Disaster Recovery completes and the system restarts, if the Disk Quota is not applied to the volumes correctly or the file "diskquota_info.inf" exists then it is required that you set the following registry key and restart the Arcserve Universal Agent service.
- Key Name: HKEY_LOCAL_MACHINE\SOFTWARE\ComputerAssociates\Arcserve Backup\ClientAgent\Parameters
- Create a new key (IsResDskquota) of type DWORD and set the value to 1.
- Name: IsResDskquota
- Type: DWORD
- Value: 1