In this situation, the Azure VM needs to be re-deployed.
I need a bit of guidance please.
I’m in the process of moving our Symantec Endpoint Protection Management installation from one server to another.
I have done a backup and saved the recovery file.
I need to know how to proceed with the installation of the new server etc.
– Do I choose to do a new/First Site Install with the previosuly saved Recovery Configuration file along with choosing same site name as the one on the old system and enter the Admin and DBA password to be the same as the old system and then when the installation is finished do a restore from backup.
But then how do I make sure the Clients only talk to the new server … Change server priorities?
– Do I do an Additional Site install, with the previosuly saved Recovery Configuration file, along with choosing a different site name than the old one( it wont let me choose the same site name), enter the replication server details (of the old system) along with Admin and DBA passwords the same and when finished do a restore from back up and then change the Priority of the old and new server so that the new server takes over control of the clients?
This last option seems best but I got an error during the installation (database creation and initialization) where it said that it could not finish aggregating data for replication.
Can anyone please advise?
This article aims to describe File Level Recovery (FLR) for Hyper-V VM backups done with NMM. FLR can be used to recover individual files/folders from a VM backup without having to restore the entire VM.
FLR can be performed using a browser from any windows host on the network that has access to the Networker server and the Hyper-V server. Following are the pre-requisites for performing FLR:
1. The user used for the FLR login needs to be a member of the NMC administrators console group:
2. The user does not need to have any other NetWorker user group membership, i.e no need to have membership of the ‘operators’ group or any other group. At the OS level the user will need to have write permissions to do the restore. So either member of backup operator group or local administrators group will suffice.
3. Host from where the restore is done, needs to have a client resource created on the NetWorker server.
4. The host from where FLR is done does not require NMM or NWC (NetWorker client) to be installed.
1. Login to a windows server with a user that meets the above criteria and launch a browser with the following URL:
2. The GUI detects Hyper-V clients that have been backed up to the NetWorker server. Select the Hyper-V client. In our case its the Hyper-V cluster name:
3. The GUI will list all the VM backups found for the Hyper-V client. Select the VM to perform FLR on and click ‘Next’.
4. The GUI will display the backups found for the selected VM. Select the desired backup and click ‘Next’
5. The GUI displays all disk partitions in the VM. Note if the VM contains ‘Dynamic’ disk, it will not be shown here as dynamic disks are not supported for FLR or GLR.
6. Select the file/folder to restore. Drag and drop it to the bottom pane. After selecting the required files, click ‘Next’
7. Here you get a choice to restore to a browser location or restore to a VM. We will keep the default of ‘Recover to a browser download location’. Select ‘Next’
8. Click on the green check mark
9. Click on the ‘downloads’
10. Save to the desired download path and then unzip the zip file for the recovered files.
This concludes this article on how to perform FLR for Hyper-V backups done with NMM
NMM offers the option of flat file restore of a Virtual Machine (Full VM restore) from command line. There is no support of performing flat file restore from GUI. Below are some of the scenarios where flat file restore could be useful:
- Image Level recovery from the GUI is failing. It’s possible a flat file restore may not give you any different result, but as flat file restore eliminates the use of VSS framework during restore, it simplifies the restore. Flat file restore can be used in this case as a troubleshooting mechanism.
- Flat file restore can be performed from a non-Hyper-V host that’s not part of the same domain as the Hyper-V host. The host would need NMM to be installed.
- As flat file restore does not interact with Hyper-V, it can be used to recover the VM’s without any dependency on Hyper-V version. i.e potentially a backup from a HyperV 2016 host can be recovered to a Hyper-V 2012 host.
After performing flat file restore, the VM will need to be imported in Hyper-V manager.
Pre-requisites for performing flat file restore:
- The user performing the restore needs to be member of the Network operators group.
- The user needs to either to be a member of the local administrators group or have enough rights to perform recovers on the host.
- The recover host OS ideally should be same version as the source Hyper-V host.
Step 1. Get the backup that you need to restore with mminfo command. E.g: (If the command is run from the client add the ‘-s <nwserver>’ switch.)
mminfo -avot -q client=thor.bronte.local -r “client,nsavetime,savetime(25),sumsize,sumflags,level,name”
thor.bronte.local 1548449822 1/25/2019 3:57:02 PM 58 MB cb full APPLICATIONS:Microsoft Hyper-VAd1ConfigFiles
thor.bronte.local 1548449823 1/25/2019 3:57:03 PM 7967 MB cb full APPLICATIONS:Microsoft Hyper-VAd1DF9EBEC6-63A2-43FC-9180-17C5BC720DCF
thor.bronte.local 1548449828 1/25/2019 3:57:08 PM 5120 KB cb full APPLICATIONS:Microsoft Hyper-VAd1D4BF4D6E-F82D-4875-9E10-800DD93F05A6
thor.bronte.local 1548450034 1/25/2019 4:00:34 PM 10 KB cb incr APPLICATIONS:Microsoft Hyper-VAd1
Choose the ‘nsavetime’ of the ‘meta data/cover save set’ e.g “APPLICATIONS:Microsoft Hyper-VAd1” in the above.
Issue the restore command as below:
nsrnmmrc -s ad2016 -c thor.bronte.local -A NSR_SNAP_TYPE=rct -x c:restore -t 1548450034“APPLICATIONS:Microsoft Hyper-VAd1\”
The above command requires the parameter NSR_SNAP_TYPE. As the backup was done using rct, this value needs to be specified with this parameter.
Also note this command is sensitive to the order of operands. Use the order operands as shown above. See below the correct command:
nsrnmmrc -s ad2016 -c thor.bronte.local -A NSR_SNAP_TYPE=rct -x c:restore -t 1548450034“APPLICATIONS:Microsoft Hyper-VAd1\”
e.g of Incorrect command (same command as above, except the order of the operands is changed i.e –A is used after –x)
nsrnmmrc -s ad2016 -c thor.bronte.local -x c:restore -t 1548450034 -A NSR_SNAP_TYPE=rct “APPLICATIONS:Microsoft Hyper-VAd1\”
This command fails with the following error:
“Recovery process has failed to locate correct logical savetime for requested selections — error 0x80004005..”
Also the ‘\’ in the saveset name is required. Its not a typo. This is mandatory otherwise the restore will fail.
The operant ‘-x’ specifies the destination directory for the restore. Make sure this has enough space for the restore. The restore command does not check for this ahead of time.
When the restore is successful, its reported as below:
For RCT backups, flat file restore, restores the vhd/vhdx files in the VM. It does not restore the configuration files (the VMCX, VMRS files). The VM cannot be imported into Hyper-V manager. However a VM can be created and the recovered vhd/vhdx file can be associated with the VM to rebuild the VM. Because the config files are not recovered, VM information like, memory, CPU’s, Network etc is not recovered.
When the backup type is VSS, flat file restore restores all the files including the configuration files and this can be used to import the VM
This concludes the procedure of performing flat file restore of a VM from a NMM Hyper-V backup
This article describes the procedure to perform Image Level Restore (Full VM restore) of Hyper-V VMs backed up with NMM 18.1. Image level restore is used to recover from situations of loss/corruption of virtual machine. This article demonstrates this restore procedure for Hyper-V 2016 server backups with NMM 18.1.
The following are pre-requisites to perform this restore successfully. Restore can be done from the source Hyper-V node or from any node in the Hyper-V cluster. Restore can also be done from a non-Hyper-V host:
1. If restore is done from a host that is not part of the Hyper-V cluster, then ensure it has the same OS as the source Hyper-V cluster node. e.g if the source node is Hyper-V 2016, do the restore from a Windows Server 2016 rather than a Windows Server 2012 host.
2. The restore host (host from where the restore is performed) needs to be in the same domain as the Hyper-V host
3. The restore host needs to have a client resource on the NetWorker server.
4. The user needs to be a member of the ‘operators’ group on the Networker server or have be listed under ‘Remote access’ attribute of the source Hyper-V client.
5. The user should be a domain user that is part of the local administrators group of the target Hyper-V node and the host from where the restore is initiated. Note for SMB VM restores, you will need additional rights on the SMB Share, if the restore is being done to the original location. The additional rights will include rights to delete any user’s files and folders on the share and rights to create files/folders on the share. If the restore is being done to an empty folder on the share, these rights may not be required. If the restore fails due to lack of permissions, the error message in the failure will indicate so.
- Start the NMM GUI and select the cluster client. For standalone server, select the host name of the source Hyper-V client.
2. Select ‘Hyper-V Recover Session’ -> ‘Image Recovery’
3 . Browse for the desired backup time and select the desired VM
4. Click ‘Recover…’ and additional recover choices are seen as below:
The default is to recover to the original location using the current cluster owner Hyper-V node. In the above the host to recover is ‘Hypv2016N2’. NMM picked this node by default as it was the cluster owner node at the time of restore.
Note: Restore to the original location will overwrite the source virtual machine.
5. When you click next, the restore summary is shown. Notice the ‘warning’. Proceed if you need to replace the existing VM from a backup copy.
Relocating the Virtual Machine during Restore.
- Select the VM from the desired backup time. Click ‘Recover..’ and choose ‘Recover the virtual machine to an alternate location’: (Note: NMM does not support relocation of SMB VMs)
2. After you click next, specify new path for the VM location. Here we are moving the VM from its original path on ‘Volume2’ to ‘Volume1’. Change the path for the ‘VHD’ files and also the path for the ‘Configuration’ files for the VM. Click ‘Next’
3. The message below indicates ‘Restore and registration completed successfully.’ Note when the VM is relocated to the different path, the VM files (vhd’s and config files) in the original path are not deleted. If these are no longer required after relocating the VM to a new path with the restore, then delete these files manually.
If the VM is not seen as a highly available VM in failover cluster manager ( this happens when a VM is relocated to a different path during restore), follow the steps below to configure the VM as a highly available VM:
Step 1. Start the Failover Cluster Manger. Right click ‘Roles’ and select ‘Configure Role.’
Step 2: Click ‘Next’, on the informational page:
Step 3. Select ‘Virtual Machine’ , under ‘Select Role’. Click ‘Next’
Step 4. Pick the virtual machine just recovered. Click ‘Next’
Step 5. Failover cluster configures the VM as highly available. Note if the VM was recovered to a local path and not to a CSV or SMB path, the VM cannot be configured as highly available.
This concludes the procedure for Image Level Restore of Hyper-V.
For Hyper-V Granular Level Restore refer to article:
This article aims to provide a simple and detailed instructions on configuration NMM 18 to backup Hyper-V Server 2016 VMs.
Hyper-V 2016 introduced a feature called RCT (Resilient Change Tracking). It’s a native change tracking system build in Hyper-V. It keeps track of the change blocks in a virtual hard disk. It keeps in memory bitmap and on disk bitmap. This helps keep track of changes even through power failures, when a memory only bit map would be lost.
RCT backups do not use VSS frame work. It’s more scalable and reliable than VSS. NMM 18.1 introduced support for RCT. When backing Hyper-V Server 2016 VMs with NMM 18.1, it’s recommended to use RCT. Support to backup using VSS is still available.
Refer to the Networker compatibility guide for the latest compatibility information between NMM and Hyper-V at https://elabnavigator.emc.com/eln/modernHomeAutomatedTiles?page=NetWorker
Pre-requisites for backups using RCT:
1. NMM 18.1 or higher. NMM 9.x does not support RCT.
2. Hyper-V server 2016. Hyper-V server 2012 does not support RCT.
3. VM configuration version higher than 6.2
I have used NMM 18.1 on Hyper-V Server 2016 with NetWorker server 184.108.40.206 for this article.
Below are the steps:
1. The first step is to install NetWorker client software and NMM on each of the Hyper-V nodes. No instructions are provided for this step as its a pretty simple process.
2. Configure the Client resources for the backup. Start the Client Wizard from the NMC GUI.
3. To backup Virtual Machines on a HyperV Cluster residing on CSV volume or SMB Share, use the Cluster name with the client configuration wizard. For standalone Hyper-V server use the Hyper-V server hostname or FQDN.
4. Select ‘Hyper-V Server’ under applications:
5. On the next page, keep the defaults
6. Select the Virtual Machines to backup. To exclude any Virtual Machine from the backup deselect the Virtual machine and select ‘Use Exclude Component List’ at the bottom of the screen.
7. Specify the backup options.
The account used for backups in ‘Remote Username’ should have the following group membership.
a. Should be a domain user. i.e member of the ‘Domain users’ AD group.
b. Member of the local ‘Administrators’ group on each HyperV host in the cluster
c. Have FULL access to the HyperV cluster. Run the following Powershell command to provide this access:
Grant-clusteraccess –cluster <clustername> -user <username> -FULL.
Grant-ClusterAccess -cluster thor -user brontenmmadmin –FULL
To verify if the account has FULL cluster access, run the following command:
Note: While the above permissions are sufficient for backups, when restoring SMB VMs to the original location, additional permissions are required to perform restore to original VM location. The above permissions do not provide admin level read rights to the SMB share. There are 2 ways to workaround this:
a. When performing a restore login to the Hyper-V host with a account that has FULL rights to the SMB-share.
b. If performing the restore with the same account as backup account, first delete/rename the original VM folder or provide this user account all rights to the SMB share.
8. Review summary and click ‘Create’:
The client wizard will proceed to create client resource for the Hyper-V cluster and a client resource for every node in the cluster.
9. Once the client resources are created proceed to create a Group, Workflow in an existing policy or create a new Policy.
a. Create a group and add the cluster client to it. Note only the cluster client will be used for the backup.
b. Create a new workflow and add the Hyper-V group to this workflow
c. Create a New ‘Action’, by clicking the ‘Add’ button in the above window. Specify the schedule and backup levels (Only level ‘FULL’ and ‘Incr’ are supported)
d. Specify storage node, pool, retention as appropriate:
e. Set the ‘Retries’ to ‘0’ and the ‘Inactivity timeout’ to ‘0’
f. Review summary and click ‘Configure’ (not shown in the screen shot)
10. Add the ‘backup user’ to the Networkers ‘Operators’ group. From NMC GUI, click ‘Server’. Select ‘User Groups’ and then do properties on the ‘Operators’ group. In the ‘Users’ box add the entries similar to below:
There is one entry for each node in the cluster.
This completes the backup configuration for a HyperV 2016 Federated backup using RCT. Note when using RCT backups, SMB and CSV VMs can be backed up together, unlike when using VSS SMB and CSV VMs had to be backed up separately.
Also for SMB VMs, as RCT does not use VSS, there is no need to install the “File Server VSS agent service” on the File Server. Also the backup user does not need any additional rights to backup VMs on SMB share.
Save sets created for a FULL level backup
HyperVPool.003 Data Domain thor.bronte.local 1/22/2019 3:08:11 PM 15 GB 2370271269 cb full APPLICATIONS:Microsoft Hyper-VEx1E9D2B2FD-B4B7-4A4A-87DC-0DD89D89FAC6
HyperVPool.003 Data Domain thor.bronte.local 1/22/2019 3:08:12 PM 58 MB 2353494053 cb full APPLICATIONS:Microsoft Hyper-VEx1ConfigFiles
HyperVPool.003 Data Domain thor.bronte.local 1/22/2019 3:13:46 PM 8 KB 2303162745 cb full APPLICATIONS:Microsoft Hyper-VEx1
For each VM following save sets are created:
- One save set for each disk in the VM. This is represented by a long hex number in the save set name. (e.g APPLICATIONS:Microsoft Hyper-VEx1E9D2B2FD-B4B7-4A4A-87DC-0DD89D89FAC6)
- One save set for ‘ConfigFiles’
- One metadata save set. This save set ends with the VM name (e.g APPLICATIONS:Microsoft Hyper-VEx1)
For a VM with one disk, there are 3 save sets. For a VM with 2 disks there are 4 save sets.
Save sets created for a Incremental backup
HyperVPool.003 Data Domain thor.bronte.local 1/22/2019 9:04:36 PM 15 GB 2068302767 cb full APPLICATIONS:Microsoft Hyper-VEx1E9D2B2FD-B4B7-4A4A-87DC-0DD89D89FAC6
HyperVPool.003 Data Domain thor.bronte.local 1/22/2019 9:04:37 PM 58 MB 2051525551 cb full APPLICATIONS:Microsoft Hyper-VEx1ConfigFiles
HyperVPool.003 Data Domain thor.bronte.local 1/22/2019 9:05:52 PM 8 KB 2001193984 cb incr APPLICATIONS:Microsoft Hyper-VEx1
Since a synthetic FULL is performed on Data Domain, all save sets are registered at level FULL in media DB, except for the metadata save set (From the above example, its “APPLICATIONS:Microsoft Hyper-VEx1”), that reflects the actual backup level for that backup.
The most recent Data Domain release, DD OS 6.1.2, enhanced both the efficiency and cloud readiness of the Data Domain platform. This blog will focus on the efficiency improvements of this release, specifically when it comes to Data Domains Instant Access and Restore. So what is Instant Access? Instant Access is the ability to boot a VM directly from the Data Domain appliance. You simply find the VM you would like to access, power it on and connect to it. By doing this, you can decrease the downtime. If you need to perform a full restore, … READ MORE
|Update your feed preferences|