Hello All,
We're exploring a proof of concept for Backup and Restoring an SAP systems on Windows system with Oracle database and we're on VMware ESX.
SCENARIO: a patching for a certain maintenance went wrong and crashed the Windows server that the SAP Production application resides on.
The Leveraged Backup does not provide methods nor support restores using base VM image file (for VMWare ESX/ESXi, file format extensions used are .vmdk and .vmx) backup.
- The scope of HPE Data Protector provides volume data level backup only and the steps do not provide a fully detailed recovery execution process for any Windows platform.
Current Solution
- The essential steps are for recovering a single failed Windows Server VM instance.
0.) Pre-cursor: Source VM is inaccessible or offline.
1.) Install new Windows VM template aligning to source server sizing in vCenter.
2.) Install base Windows OS using Alpharetta HPE Gold Disk deployment source
2.1) Using existing source hostname and primary IP address
3.) Install HPE tools onto base Windows OS including Data Protector agent (configured using source BUR IP address).
4.) Perform HPE Data Protector data recovery on per Windows mounted volume basis.
4.1) Use last available full data backup as initial data recovery. This includes OS volume application as "data".
4.2) Apply incremental data backups to volume as final data recovery step
5.) Perform HPE Data Protector system state file recovery to recovery server
5.1) Apply system state recovery files to recovery server
6.) Restart recovery server and perform Health Checks.
QUESTION:
Can we use LOW LEVEL RESTORE method if no snapshots have been created? If not, what other choices do we have?
Restoring Virtual Disk Data As in the section
Low Level Restore Procedures,
VixDiskLib functions provide interfaces for writing the data to virtual disk, either locally or remotely.
Raw Device Mapping (RDM) Disks
To create an RDM disk using
CreateVM_Task, use a LUN that is not occupied and thus is still available. Developers sometimes use the same LUN
uuid that is available in the
configInfo object, which can cause errors because the LUN
uuid is datastore specific.
Call
QueryConfigTarget to fetch the
ConfigTarget.ScsiDisk.Disk.CanonicalName property, set in
VirtualDiskRawDiskMappingVer1BackInfo.deviceName. Also call
QueryConfigTarget to fetch
ConfigTarget.ScsiDisk.Disk.uuid, set in
VirtualDiskRawDiskMappingVer1BackInfo.lunUuid. When creating the virtual machine, avoid host-specific properties of
configInfo, which should be set according to host configuration where the virtual machine is
restored. Restore of Incremental Backup Data At some point you might need to
restore a virtual disk from the backup data that you gathered as described in
Changed Block Tracking on Virtual Disks. The essential procedure is as follows:
1 | Power off the virtual machine, if powered on. |
2 | Using VirtualMachineConfigInfo that corresponds to the last known good state of the guest operating system, re-create the virtual machine as described in Using the VirtualMachineConfigInfo. |
3 | Completely reload the base virtual disk using the full backup that started the most recent series of incremental backups. |
4 | Create a snapshot. This is mandatory for SAN mode restore. |
5 | For SAN mode restore, disable changed block tracking. SAN writes are not possible with it enabled. |
6 | Sequentially restore the incremental backup data. You can do this either forwards or backwards. If you work forwards, the restore might write some sectors more than once. If you work backwards, you must keep track of which sectors were restored so as to avoid restoring them again from older data. |
a | From your backup records, get the change ID of the incremental backup to be restored. Your software must also store the changed-block information, so it knows which sectors of virtual disk to restore. Once you start restoring virtual disk, the change tracking mechanism will misreport. |
b | Restore only changed areas to the virtual disks referred to by the snapshot. This ensures that you do not write the data to the redo log created by the snapshot. When restoring a thin provisioned (sparse) disk, use the star "*" change ID to avoid writing zeroes to the unallocated blocks. |
c | Repeat Step a and Step b as necessary by applying incremental backup data sets in order. |
7 | If applicable, revert to the base virtual disk, thus eliminating the snapshot. |