Zerto Virtual

Manager
Administration
Guide
Microsoft Azure Environment

Version 5.5 Update 3

ZVR-ADVAZ-5.5U3 Rev01 Dec2017

Copyright © 2017, Zerto Ltd. All rights reserved.
Information in this document is confidential and subject to change without notice and does not represent a commitment on the part of Zerto Ltd. Zerto Ltd.
does not assume responsibility for any printing errors that may appear in this document. No part of this document may be reproduced or transmitted in any
form or by any means, electronic or mechanical, including photocopying, recording, or information storage and retrieval systems, for any purpose other than
the purchaser's personal use, without the prior written permission of Zerto Ltd.
All other marks and names mentioned herein may be trademarks of their respective companies.

The scripts are provided by example only and are not supported under any Zerto support program or service.
All examples and scripts are provided "as-is" without warranty of any kind. The author and Zerto further disclaim all implied warranties including, without
limitation, any implied warranties of merchantability or of fitness for a particular purpose.
In no event shall Zerto, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever
(including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of
the use of or inability to use the sample scripts or documentation, even if the author or Zerto has been advised of the possibility of such damages. The entire
risk arising out of the use or performance of the sample scripts and documentation remains with you.

ZVR-ADVAZ-5.5U3 Rev01 Dec2017

2
 TABLE OF CONTENTS

About This Guide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

Intended Audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Overview of Content in This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Support and Feedback. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

CHAPTER 1: INTRODUCTION TO ZERTO VIRTUAL REPLICATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

What is Zerto Virtual Replication?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Zerto Virtual Replication Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
How Zerto Virtual Replication Recovery Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Benefits of Using Zerto Virtual Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

CHAPTER 2: ACCESSING THE ZERTO USER INTERFACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Using the Zerto Virtual Manager Web Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Adding a Security Certificate for the Zerto User Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Working With the Zerto User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
Sub tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Views. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

CHAPTER 3: OVERVIEW OF RECOVERY FLOWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Flows for a Disaster Recovery Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Flow for a Disaster Recovery Operation to Azure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Flow for a Test Failover Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Flow for a File or Folder Level Restore Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Flow for an Offsite Backup and Restore Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

CHAPTER 4: INTRODUCTION TO PROTECTING VIRTUAL MACHINES . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Configuring Virtual Protection Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Requirements for Microsoft Azure Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
The Role of the Journal During Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
What Happens After the VPG is Defined. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
File and Folder Recovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Offsite Backups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

CHAPTER 5: PROTECTING VIRTUAL MACHINES FROM AZURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Requirements for Microsoft Azure Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Protecting Azure Virtual Machines to a vCenter Server Recovery Site. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Protecting Azure Virtual Machines to a Hyper-V Recovery Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Protecting Azure Virtual Machines to a vCloud Director Recovery Site. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

CHAPTER 6: MONITORING ZERTO VIRTUAL REPLICATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

The DASHBOARD Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Monitoring VPGs – The VPGs Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
List View - GENERAL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
List View - PERFORMANCE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
List View - BACKUP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Additional Fields and Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

3
 Grid View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Monitoring a Single VPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Monitoring Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Monitoring Protected Virtual Machines – The VMs Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Monitoring Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
The SITES Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Monitoring Repositories for Offsite Backups – The SETUP Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Monitoring Offsite Backups – The OFFSITE BACKUP Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
VPGs Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
VMs Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

CHAPTER 7: MANAGING VPGS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Editing a VPG. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Modifying the Journal Size Hard Limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Modifying the Retention Period for Offsite Backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Modifying Protected Virtual Machine Disks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Adding Virtual Machines to a VPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Removing Virtual Machines from a VPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Removing a Protected Virtual Machine from Azure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Pausing and Resuming the Protection of a VPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Forcing the Synchronization of a VPG. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Deleting a VPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Deleting a VPG When the Status is Deleting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Running an Unscheduled Offsite Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Ensuring Application Consistency – Checkpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Adding a Checkpoint to Identify a Key Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Ensuring Transaction Consistency in Microsoft Windows Server Environments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Running Scripts Before or After Recovering a VPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Creating a Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Example Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Exporting and Importing VPG Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
VPG Statuses and Synchronization Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
VPG Statuses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
VPG Synchronization Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

CHAPTER 8: MANAGING A ZERTO VIRTUAL MANAGER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Check Connectivity Between Zerto Virtual Replication Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Reconfiguring the Zerto Virtual Manager Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Reconfiguring the Microsoft SQL Server Database Used by the Zerto Virtual Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .110
Pair to Another Site and Unpairing Sites. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .110
Pair to Another Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Unpairing Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

CHAPTER 9: OVERVIEW OF DISASTER RECOVERY OPERATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112

The Failover Test Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112
The Move Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
The Failover Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114
The Restore File Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115
The Clone Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115

CHAPTER 10: ADVANCED SITE CONFIGURATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117

Site Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117
Editing Information About a Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118

4
 Defining Site Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119
Configuring Email Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Defining the Resource Report Sampling Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121
Seeing What is Licensed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
About the Zerto Virtual Replication Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

CHAPTER 11: TESTING RECOVERY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

The Test Failover Process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Starting and Stopping Failover Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
After Starting a Test, What Happens? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Viewing Test Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Live Disaster Recovery Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Basic Verification – User Traffic Is Not Run against the Recovered VMs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

CHAPTER 12: MIGRATING A VPG TO AZURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

The Move Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Moving Protected Virtual Machines to a Remote Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Reverse Protection For a Moved VPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Reverse Protection Specified . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Reverse Protection Not Specified . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

CHAPTER 13: MIGRATING A VPG FROM AZURE TO AN ON-PREMISE SITE. . . . . . . . . . . . . . . . . . . . . . 140

The Move Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Moving Protected Virtual Machines to a Remote Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141
Reverse Protection For a Moved VPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Reverse Protection Specified . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Reverse Protection Not Specified . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

CHAPTER 14: MANAGING FAILOVER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

The Failover Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Initiating a Failover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Reverse Protection for a Failed Over VPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Reverse Protection with One-to-Many . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
What Happens When the Protected Site is Down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Initiating a Failover During a Test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

CHAPTER 15: CLONING A VPG TO AZURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

The Clone Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Cloning Protected Virtual Machines to the Remote Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

CHAPTER 16: RECOVERING FILES AND FOLDERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

The File and Folder Recovery Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Recovering Files and Folders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Mounting the Disk that Contains the Required Files and Folders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Downloading the Files and Folders from the Disk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

CHAPTER 17: FAILING BACK (MOVING) FROM AZURE TO AN ON-PREMISE SITE . . . . . . . . . . . . . . . 166
The Failback (Move) Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Initiating a Failback (Move) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Reverse Protection For a Moved VPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Reverse Protection Specified . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

5
 Reverse Protection Not Specified . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

CHAPTER 18: OFFSITE BACKUP CONFIGURATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Creating an Offsite Backup Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Editing an Offsite Backup Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

CHAPTER 19: ZERTO VIRTUAL REPLICATION REPORTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

Outbound Protection Over Time Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Recovery Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Resources Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Using a REST API to Generate a Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181
Details Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .181
VPG Performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Backup Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

CHAPTER 20: TROUBLESHOOTING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

Ensuring the Zerto Virtual Manager is Running . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Troubleshooting: “Needs Configuration” Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Troubleshooting VRA Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Zerto Virtual Replication Diagnostics Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Collecting Zerto Virtual Replication Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Using Remote Log Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Using the Zerto Diagnostics application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Understanding the Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

CHAPTER 21: THE ZERTO VIRTUAL MANAGER USER INTERFACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

Add Checkpoint Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Add Site Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Pair sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Add Static Route Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Advanced Journal Settings Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Advanced Journal Settings Dialog (vCD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Advanced VM Recovery Settings Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200
Advanced VM Replication Settings Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Advanced VM Replication Settings Dialog (vCD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .202
Advanced VM Settings for Cloud Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
ALERTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Boot Order Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .204
Browse for File Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .205
Change Host Password VRA Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .205
Change VM Recovery VRA Dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .206
Checkpoints Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .207
Configure and Install VRA Dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .208
Configure Paired Site Routing Dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .209
Configure Provider vDCs Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Configure VM Settings Dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .211
Configure Volume Dialog (vCD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .211
Edit NIC Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Edit Selected Volumes Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Edit VM Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Edit VM Dialog (vCD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Edit VM Settings Dialog (Azure) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Edit vNIC Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

6
Edit vNIC Dialog (vCD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Edit Volumes Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Edit Volumes Dialog (vCD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Edit VRA Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .220
Manage Static Routes Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
New Repository Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Offsite Clone Dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Open Support Ticket Dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Remote Support Dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Site Settings Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Site Information Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Policies Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Email Settings Dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Reports Dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
License Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
About Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Stop Failover Test Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
TASKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232

CHAPTER 22: GLOSSARY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

7
 ABOUT THIS GUIDE

Zerto Virtual Replication provides a business continuity (BC) and disaster recovery (DR) solution in a virtual environment,
providing near real-time replication, with write-order fidelity, with minimal impact on product workloads. Fully automated
orchestration delivers failover and failback in one click. Non-disruptive disaster recovery testing gives you confidence that your
DR solution will work predictably and consistently. Protection groups ensure that all virtual machines that comprise an
application are protected in the exact same manner no matter where they are in the environment.
With support for different hypervisors, such as vSphere or Hyper-V, workloads can be protected, migrated, and recovered,
either within the same hypervisor environment or across hypervisor environments.
This guide describes how to configure and manage Zerto Virtual Replication to implement business continuity and disaster
recovery (DR) solutions in VMware, Hyper-V, Azure, or mixed environments.

Intended Audience
This guide is for the use of experienced hypervisor and Azure administrators.

Overview of Content in This Guide

This guide contains the following sections:
CHAPTER TITLE DESCRIPTION
1 Introduction to Zerto Virtual Replication Describes the underlying concepts and architecture of Zerto Virtual
Replication.
2 Accessing the Zerto User Interface Describes how to access the Zerto User Interface.
3 Overview of Recovery Flows Describes disaster recovery and offsite backup flows from the initial
protection to the recovery of virtual machines. It also describes, at a
high level, the file level recovery process.
4 Introduction to Protecting Virtual Machines Describes how to set up protection for virtual machines.
6 Monitoring Zerto Virtual Replication Describes how to monitor the protected virtual machines and the
protected and Azure sites.
7 Managing VPGs Describes how to manage VPGs using Zerto Virtual Replication.
8 Managing a Zerto Virtual Manager Describes the processes available to manage the Zerto Virtual
Manager.
9 Overview of Disaster Recovery Operations Describes the available recovery procedures and when they are used.
10 Advanced Site Configuration Describes the processes available to manage protected and recovery
sites using Zerto Virtual Replication.
11 Testing Recovery Describes how to test recovery to ensure the results you want.
12 Migrating a VPG to Azure Describes the process of migrating protected virtual machines from
the protected site to Azure.
13 Migrating a VPG From Azure to an On- Describes the process of migrating protected virtual machines from
Premise Site Azure to an on-premise site.
14 Managing Failover Describes the process of recovery from the protected site to the
recovery site.
15 Cloning a VPG to Azure Describes the process of cloning protected virtual machines from the
protected site to the recovery site in Azure.

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
About This Guide 8
Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
About This Guide

CHAPTER TITLE DESCRIPTION

16 Recovering Files and Folders Describes the process of restoring files and folders from the recovery
site.
17 Failing Back (Moving) from Azure to an On- Describes how to fail back recovered virtual machines from Azure to
Premise Site on-premise sites.
18 Offsite Backup configuration Describes the process of restoring an offsite backup from a repository
to an on-premise site.
19 Zerto Virtual Replication Reports Describes the reporting and monitoring capabilities available with
Zerto Virtual Replication.
20 Troubleshooting Describes how to resolve problems, including generating logs.
21 The Zerto Virtual Manager User Interface Describes the screens and dialogs in the Zerto User Interface
22 Glossary A glossary of terms used throughout Zerto Virtual Replication.

Support and Feedback

Please send suggestions to improve the documentation to Zerto support.

Support and Feedback 9

 CHAPTER 1: INTRODUCTION TO
ZERTO VIRTUAL REPLICATION

Disaster recovery is the process of preparing for recovery or continuation of IT processing tasks that support critical business
processes in the event of a threat to the IT infrastructure. Zerto Offsite Backup is the additional process of enabling recovery of
IT processing tasks after an extended period. This section describes Zerto Virtual Replication general concepts to enable
replication and recovery in a virtual environment.
The following topics are described in this section:
■ “What is Zerto Virtual Replication?”, below
■ “Zerto Virtual Replication Architecture”, on page 10
■ “How Zerto Virtual Replication Recovery Works”, on page 11
■ “Benefits of Using Zerto Virtual Replication”, on page 12

What is Zerto Virtual Replication?

With support for different hypervisors such as vSphere or Hyper-V, and public cloud sites such as Azure, workloads can be
protected, migrated, and recovered, either within the same hypervisor environment or across hypervisor environments.
Zerto Virtual Replication is installed in both the protected and the recovery sites. The disaster recovery across these sites is
managed by a browser-based user interface. Managing Zerto Virtual Replication is also possible programmatically, either via a
set of RESTful APIs or PowerShell cmdlets.
Recovery that does rely on native replication functionality, such as recovery available with Microsoft Active Directory or SQL
Server, can also be replicated using Zerto Virtual Replication, and whether the native replication functionality is used or not is
determined by site considerations, such as increased complexity of having multiple points of control and possible additional
costs incurred when using vendor native replication.
You configure replication by first pairing the site with virtual machines to be protected with a recovery site. You then define
what virtual machines you want replicated in consistency groups, where the virtual machines in a group comprise the
application and data you want to protect. You can group different virtual machines together or keep them separate. By creating
different replication groups, you can customize the replication requirements for each group to better optimize the recovery
plan.
Disaster recovery is based on the premise that you will want to recover with a minimum RPO. The minimum RPO for recovery
from Azure is 1 minute. The minimum RPO for recovery to Azure is measured in seconds. However, to enable full recovery in
cases such as virus attacks, Zerto Virtual Replication provides the ability to recover to a point in time up to 30 days prior to the
disaster. When recovery earlier than 30days is required, Zerto Virtual Replication provides an extended recovery, using an
offsite backup mechanism that enables you to recover to a recovery site based on a daily or weekly backup going as far back as
a year. The majority of the processing for both disaster recovery and extended recovery is done at the recovery site, minimizing
the impact on the production site.

Zerto Virtual Replication Architecture

Zerto Virtual Replication provides disaster recovery between hypervisors such as VMware ESX/ESXi hosts managed by
vCenter Servers and Microsoft Hyper-V hosts managed by SCVMM. In addition, you can protect virtual machines in these
environments to a public cloud, such as Amazon Web Services or Microsoft Azure.
When Zerto Virtual Replication is installed to work with a hypervisor it comprises the following components:
Zerto Virtual Manager (ZVM) – A Windows service that manages everything required for the replication between the
protection and recovery sites, except for the actual replication of data. The ZVM interacts with the hypervisor management
user interface, such as vCenter Server or Microsoft SCVMM, to get the inventory of VMs, disks, networks, hosts, etc. and then
the Zerto User Interface manages this protection. The ZVM also monitors changes in the hypervisor environment and

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Introduction to Zerto Virtual Replication 10
Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Introduction to Zerto Virtual Replication

responds accordingly. For example, a VMware vMotion operation, or Microsoft Live Migration of a protected VM from one
host to another is intercepted by the ZVM and the Zerto User Interface is updated accordingly.
A Zerto Virtual Manager can manage up to 5000 virtual machines, either being protected by, or recovered to, the Zerto Virtual
Manager.
Virtual Replication Appliance (VRA) – A Windows service that manages the replication of data from protected virtual
machines to Azure. A VRA can manage a maximum of 1500 volumes, whether these are volumes being protected or recovered.
Virtual Backup Appliance (VBA) – A VBA is a Windows service, which manages back-ups within Zerto Virtual Replication. The
VBA service runs on the same machine as the Zerto Virtual Manager service and is responsible for the repositories where
offsite backups are stored. These repositories can be local or on a shared network.
Zerto User Interface – Recovery using Zerto Virtual Replication is managed in a browser.
The following diagram shows how the main Zerto Virtual Replication components are deployed across hypervisor-based
enterprise sites to provide disaster recovery across these sites.

When you plan to recover the enterprise site to a public cloud, Zerto Virtual Replication is installed in the cloud environment.
Zerto Virtual Replication comprises the same components but the VRA runs as a service, so that the ZVM, VRA, and VBA all
run as services on a single virtual machine instance in the public cloud.
Note: For the architecture diagrams when one of the sites is a cloud service provider, see the Zerto Cloud Manager
Administration Guide.

How Zerto Virtual Replication Recovery Works

Installing Zerto Virtual Replication installs the Zerto Virtual Manager, which sits in the hypervisor layer on the protected site
and the Zerto Cloud Appliance which sits in Azure on the recovery site. You manage disaster recovery using the Zerto User
Interface.
Zerto also provides a set of RESTful APIs and PowerShell cmdlets to enable incorporating some of the disaster recovery
functionality within scripts or programs.
In the protected site you define the virtual machines that you want to replicate, either individually or together, as a virtual
protection group (VPG). The virtual machines that you include in the VPG can come from one or more hypervisor hosts. In this
way, you can protect applications that run on multiple virtual machines and disks as a single unit – a VPG. An example of an
application that runs on multiple virtual machines includes software that requires a web server and database, both of which run
on virtual machines different than the virtual machine where the application software runs.
A virtual machine can be included in several VPGs so that you can recover it to several sites, depending on the needs of the
organization. For example the same workload can be protected to a local or a remote location as well as to the cloud. Using
several recovery sites also enables migrating disaster recovery datacenters from one location to another.

How Zerto Virtual Replication Recovery Works 11

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Introduction to Zerto Virtual Replication

Every write is copied by Zerto Virtual Replication and sent, asynchronously, to the recovery site, while the write continues to be
processed on the protected site. For greater efficiency and performance, the write can be compressed before being sent to the
recovery site with throttling techniques being used to prioritize network traffic.
On the recovery site the write is written to a journal managed by a Virtual Replication Appliance (VRA). Each protected virtual
machine has its own journal. Every few seconds, a checkpoint is also written to each journal. These checkpoints ensure write
order fidelity and crash-consistency to each checkpoint. During recovery you pick one of these crash-consistent checkpoints
and recover to this point. Additionally, checkpoints can be manually added by the administrator, with a description of the
checkpoint. For example, when an event is going to take place that might result in the need to perform a recovery, you can
pinpoint when this event occurs as a checkpoint written to each journal.
The VRA manages the journals for every virtual machine that will be recovered to the hypervisor hosting that VRA. It also
manages images of the protected volumes for these virtual machines. During a failover, you can specify that you want to
recover the virtual machines in the VPG using the last checkpoint or you can specify an earlier checkpoint, in which case the
recovery of the mirror images under the VRA are synchronized to this checkpoint. Thus, you can recover the environment to
the point before any corruption and ignore later writes in the journal that were corrupted, regardless of the cause of the
corruption, such as a crash in the protected site or a virus attack.
When recovery to a point is required that is further in the past than the time saved in the journal, an offsite backup can be
restored. Offsite backups are an extension of disaster recovery, with the virtual machine files, such as the configuration and
virtual disk files, saved to a repository for up to one year. These files are then used to restore the virtual machines to the point
of the stored offsite backup at the recovery site.

Benefits of Using Zerto Virtual Replication

Datacenter optimization and virtualization technologies have matured and are now commonly used in IT infrastructure. As
more applications are deployed in a virtualized infrastructure, there is a growing need for recovery mechanisms that support
mission critical application deployments while providing complete BC and DR.
Traditional replication and disaster recovery solutions were not conceived to deal with the demands created by the
virtualization paradigm. For example, most replication solutions are not managed in the hypervisor layer, considering the
virtual machines and disks, but at the physical disk level. Hence they are not truly virtualization aware.
The lack of virtualization awareness creates a huge operational and administrative burden. It also results in operational
inflexibility. Zerto Virtual Replication has been designed to resolve these issues by being fully virtualization aware.
See the following topics:
■ “Hardware Agnostic”, on page 12
■ “Focus is on the Application, Not the Physical Storage”, on page 13
■ “Compatibility Across Virtual Environments – Cross-Hypervisor Platform and Version Agnostic”, on page 13
■ “Efficient Asynchronous Replication”, on page 13
■ “One-Click Failover and Control of the Recovery Process”, on page 13
■ “One-Click Migration”, on page 13
■ “File and Folder Recovery”, on page 14
■ “Offsite Backup”, on page 14
■ “Policy-based”, on page 14
■ “Minimal RPO”, on page 14
■ “WAN Optimization Between Protected and Recovery Sites”, on page 14
■ “WAN Resilience on Both the Protected and Recovery Sites”, on page 14
■ “DR Management Anywhere”, on page 14

Hardware Agnostic
Because Zerto Virtual Replication software manages recovery of virtual machines and virtual disks only, it does not matter
what hardware is used in either the protected or recovery sites; it can be from the same vendor or different vendors. With Zerto

Benefits of Using Zerto Virtual Replication 12

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Introduction to Zerto Virtual Replication

Virtual Replication the logical storage is separated from the physical storage so that the vendor and actual type of storage
hardware do not need to be considered.
Zerto Virtual Replication provides a workload mobility and protection layer providing seamless connectivity, portability,
protection, orchestration, and application encapsulation of workloads across clouds without vendor lock-in. High scale, mission
critical applications, and data are encapsulated, as well as features, specifications, and configurations, and can be seamlessly
migrated across different servers, storage, hypervisors, and clouds without any disruption to business services.
With Zerto Virtual Replication, IT managers can choose the right infrastructure for the right use case for the right price. One
application can leverage several different environments for disaster recovery, bursting, production, backup, testing, and
development. With Zerto Virtual Replication there is no vendor lock-in to a cloud, technology, or vendor. Any choice, any cloud,
any technology, any price, any service level is available in minutes for any workload.

Focus is on the Application, Not the Physical Storage

By considering the physical disk level and not the virtual disk level, traditional replication is not truly application aware. Even
virtual replication recovers block writes at the SCSI level and not at the application level. Zerto Virtual Replication is truly
application focused, replicating the writes from the application in a consistent manner.

Compatibility Across Virtual Environments – Cross-Hypervisor Platform and Version Agnostic

Zerto Virtual Replication enables replication across multiple hypervisor managers, such as VMware vCenter Server and
Microsoft SCVMM, and to public clouds such as Amazon Web Services (AWS) or Microsoft Azure. You can protect virtual
machines in one hypervisor platform and recover to a different hypervisor platform. This feature can also be used to migrate
virtual machines to a different hypervisor platform.
Also, virtual machines running in one version a hypervisor can be recovered in a different version of the same type of
hypervisor, as long as Zerto Virtual Replication supports the hypervisor versions, virtual machines can be protected across
versions.

Efficient Asynchronous Replication

Writes are captured by the Zerto Virtual Replication software in the hypervisor level, before they are written to the physical
disk at the protected site. These writes are sent to the recovery site asynchronously, thus avoiding long distance replication
latency for the production applications.
Also, because these writes are captured and sent to the recovery site, it is only the delta changes and not the whole file or disk
that is sent to the recovery site, reducing the amount of network traffic, which reduces WAN requirements and significantly
improves the ability to meet both RPO and RTO targets.

One-Click Failover and Control of the Recovery Process

When recovery is required, the administrator clicks on a button in the Zerto User Interface to initiate failover. This means that
controlling the start of a recovery remains in the hands of the administrator, who can decide when to initiate the recovery and,
by selecting a checkpoint, to what point-in-time to recover to.

One-Click Migration
Application migrations can be resource intensive projects that take weeks of planning, execution, and downtime. With Zerto
Virtual Replication migrations are greatly simplified and can be completed without extended outages or maintenance windows
and across different types of hardware and even different hypervisors, such as VMware ESXi or Microsoft Hyper-V. Migrations
across different versions within a type of hypervisor, such as from a VMware vCenter environment to a vCloud environment or
even cross hypervisor migration, such as migration from a vCenter environment to a Hyper-V environment is as easy as a
migration from one site to another using the same hypervisor infrastructure.

Benefits of Using Zerto Virtual Replication 13

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Introduction to Zerto Virtual Replication

File and Folder Recovery

You can recover specific files and folders from the recovery site for virtual machines that are being protected by Zerto Virtual
Replication and running Windows or Linux operating systems. You can recover the files and folders from a specific point-in-
time.
You can choose to recover one or several files or folders from the recovery site.

Offsite Backup
Zerto Virtual Replication provides an offsite back up option that enables saving the protected virtual machines offsite for up to
one year in a state where they can be easily deployed. Because the backups use the same mechanism used for disaster
recovery, there is no performance impact on the production site, since the processing is performed on the recovery site. The
offsite backups are fixed points saved daily, weekly or monthly.
Note: Zerto recommends weekly backups.

Policy-based
In the protected site you define the virtual machines that you want to recover, either individually or as groups, as a virtual
protection group (VPG). The virtual machines that you include in the VPG can come from one or more hypervisor hosts. In this
way, you can protect applications that run on multiple virtual machines and disks as a single unit, in a single VPG.

Minimal RPO
Zerto Virtual Replication utilizes continuous data protection, sending a record of every write in the virtual protection group to
the recovery site. The transfer of this information is done over an optimized WAN asynchronously. If recovery is required, all
the data that was transferred to the recovery site is available resulting in recovery within the requested RPO.

WAN Optimization Between Protected and Recovery Sites

Using compression to minimize bandwidth and other techniques such as throttling to prioritize network traffic to reduce the
impact on day-to-day operations, you can make sure that the communication between the protected and recovery sites is fully
optimized.
Zerto Virtual Replication also uses signature matching to reduce the amount of data sent across the WAN. During
synchronization of the protected site and recovery site for every virtual machine in a VPG, Zerto Virtual Replication maintains a
map of disk sectors so that if there is a need to resynchronize sites, the map signatures can be used to ensure that only data
where changes occurred are passed over the WAN.

WAN Resilience on Both the Protected and Recovery Sites

Zerto Virtual Replication is highly resilient to WAN interruptions. In order to reduce storage overhead used for replication
purposes, on WAN failure or when the load over the WAN is too great for the WAN to handle, Zerto Virtual Replication starts
to maintain a smart bitmap in memory, in which it tracks and records the storage areas that changed. Since the bitmap is kept
in memory, Zerto Virtual Replication does not require any LUN or volume per VPG at the protected side. The bitmap is small
and scales dynamically, but does not contain any actual IO data, just references to the areas of the protected disk that have
changed. The bitmap is stored locally on the VRA within the available resources. Once the WAN connection resumes or the
load returns to normal traffic, Zerto Virtual Replication uses this bitmap to check whether there were updates to the protected
disks and if there were updates to the disks, these updates are sent to the recovery site.

DR Management Anywhere
With Zerto Virtual Replication everything is managed from a standalone browser-base user interface, enabling disaster
recovery management from anywhere using any device.

Benefits of Using Zerto Virtual Replication 14

 CHAPTER 2: ACCESSING THE ZERTO
USER INTERFACE

You manage the protection and replication of virtual machines between the protected site and Azure using the Zerto User
Interface. On first access to the Zerto User Interface, you might have to add a security certificate to set up secure
communication. Zerto also provides a set of RESTful APIs and PowerShell cmdlets to enable incorporating some of the disaster
recovery functionality within scripts or programs.

Note: Microsoft Windows Explorer 9 is not supported and version 10 does not work well with the user interface. Zerto
recommends using Chrome, Firefox, or later versions of Internet Explorer.
Note: It is required to exclude the Zerto Virtual Replication folder from antivirus scanning. Failure to do so may lead to the ZVR
folder being incorrectly identified as a threat and in some circumstances corrupt the ZVR folder.
Note:
Note: For a full list of requirements and limitations when protecting virtual machines to and from Azure see “Requirements for
Microsoft Azure Environments” on page 28
The following topics are described in this section:
■ “Using the Zerto Virtual Manager Web Client”, below
■ “Adding a Security Certificate for the Zerto User Interface”, on page 15
■ “Working With the Zerto User Interface”, on page 17

Using the Zerto Virtual Manager Web Client

To use the Zerto Virtual Manager Web Client:
1. In a browser, enter the following URL:
https://zvm_IP:9669
where zvm_IP is the IP address of the Zerto Virtual Manager for the site you want to manage.
2. Log on using the user name and password of the virtual machine on which you installed the Zerto Cloud Appliance.

Adding a Security Certificate for the Zerto User Interface

Communication between the Zerto Virtual Manager and the user interface uses HTTPS. On the first login to the Zerto User
Interface, you must install a security certificate in order to be able to continue working without each login requiring acceptance
of the security.

To install a security certificate for the Zerto User Interface:

On first access to the Zerto User Interface, if you haven’t installed the security certificate, a security alert is issued.
Note the following:
■ To run this procedure run Microsoft Internet Explorer as administrator. The procedure is similar for Google Chrome and for
Mozilla Firefox.
■ Access the Zerto User Interface using the IP and not the name of the machine where Zerto Virtual Replication is installed.
1. Click View Certificate.
The Certificate dialog is displayed.
2. Click Install Certificate.
The Certificate Import wizard dialog is displayed.

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Accessing the Zerto User Interface 15
Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Accessing the Zerto User Interface

3. Follow the wizard: Place all the certificates in the Trusted Root Certification Authorities store: Select the Place all
certificates in the following store option and browse to select the Trusted Root Certification Authorities store.

4. Continue to the end of the wizard. Click Yes when the Security Warning is displayed.

5. Click OK that the installation was successful.

6. Click OK when prompted and then Yes in the Security Alert dialog to continue.

Adding a Security Certificate for the Zerto User Interface 16

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Accessing the Zerto User Interface

Working With the Zerto User Interface

After logging on to the Zerto User Interface for the first time, the dashboard is displayed. The dashboard provides summary
information about the status of the site, as shown in the following diagram:

Use the tabs to access the specific information you want:

DASHBOARD – General information about the site, including the status of the VPGs being protected or recovered to the site.
VPGs – All the VPGs from both the local and remote sites and provides summary details of each VPG.
VMs – All the protected virtual machines from both the local and remote sites and provides summary details of each virtual
machine.
SITES – Details of the paired sites. This tab lists all the paired sites to the local site and provides summary details of each paired
site.
SETUP – Details about repositories.
OFFSITE BACKUP – Details of the offsite backup jobs either by VPG or virtual machine. This tab lists all the defined offsite
backups and their statuses.
MONITORING – Details about the alerts, events and tasks for the site.
REPORTS – General reports.

Working With the Zerto User Interface 17

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Accessing the Zerto User Interface

Sub tabs
The SETUP, OFFSITE BACKUP and MONITORING tabs and details of a specific VPG can be viewed from different perspectives
via subtables. For example, under SETUP you can manage repositories.

Views
Lists can be displayed with different views. For each view you can filter the information in columns via the filter icon next to
each column title. Clicking the column title enables sorting the column in ascending to descending order.
You can customize the default views or add a new view by clicking the view configuration button.
Customize a default view by selecting Show/Hide Columns and then checking the columns you want displayed. Create a new
view by selecting Create View.

Working With the Zerto User Interface 18

 CHAPTER 3: OVERVIEW OF
RECOVERY FLOWS

Zerto Virtual Replication enables protecting virtual machines, for both disaster recovery or for extended, longer term recovery
from an offsite backup, by protecting the relevant virtual machines in virtual protection groups. A virtual protection group
(VPG) is a group comprised of virtual machines that are grouped together for recovery purposes. For example, the virtual
machines that comprise an application like Microsoft Exchange, where one virtual machine is used for the software, one for the
database, and a third for the Web Server require that all three virtual machines be replicated to maintain data integrity.
The following topics are described in this section:
■ “Flows for a Disaster Recovery Operations”, below
■ “Flow for a File or Folder Level Restore Operation”, on page 20
■ “Flow for an Offsite Backup and Restore Operation”, on page 20

Flows for a Disaster Recovery Operations

Disaster recovery using Zerto Virtual Replication enables recovering from a disaster to any point between the moment just
before the disaster and a specified amount of time in the past up to 30 days. The recovery is done in real time at the recovery
site with a minimal RTO.
A recovery operation is one of the following:
■ A failover.
■ A planned move of the protected virtual machines from the protected site to the recovery site.
■ A clone of the protected virtual machine to the recovery site.

Flow for a Disaster Recovery Operation to Azure

Virtual machines are protected in VPGs, which are defined in the protected site. Once a VPG is created, Zerto Virtual
Replication creates a copy of the protected virtual machines under the management of a Virtual Replication Appliance, VRA,
on the Azure recovery site. The data managed by the VRA is saved in a storage account.
When a recovery operation is performed, the Zerto Virtual Manager (ZVM) creates the following:
■ A copy of the virtual machine disks in a dedicated container under the same storage account.
■ A virtual machine in Azure, under a newly created Resource Group, with the copied disks attached to it.
■ Network Interfaces Cards (NICs) for each NIC of the protected virtual machine.
Once this is done, the ZVM promotes the data from the journal to the virtual machine disks.
For information on disaster recovery flows from Azure to on-premise platforms see:
■ Flow for a Disaster Recovery Operation - vSphere
■ Flow for a Disaster Recovery Operation - Hyper-V
The following references the procedures to recover virtual machines protected in a VPG:
■ “Overview of Disaster Recovery Operations”, on page 73
■ “Managing Failover”, on page 147
■ “Migrating a VPG to Azure”, on page 132
■ “Cloning a VPG to Azure”, on page 155

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Overview of Recovery Flows 19
Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Overview of Recovery Flows

Flow for a Test Failover Operation

When testing that the recovery works as planned, the Zerto Virtual Manager (ZVM) creates the virtual machines defined in
the VPG in a dedicated resource group in Azure. The following references the procedure to recover virtual machines:
■ “Overview of Disaster Recovery Operations”, on page 73
■ “Testing Recovery”, on page 124

Flow for a File or Folder Level Restore Operation

You can recover specific files and folders from the recovery site for virtual machines that are being protected by Zerto Virtual
Replication and running Windows operating systems. You can recover the files and folders from a specific point-in-time.
1. Select the virtual machine that contains the file or folder to be recovered.
2. Select the checkpoint that contains the appropriate version of the file or folder.
3. Select the specific files or folders to be recovered.
4. Download the specific files or folders.
For more information, see “Recovering Files and Folders”, on page 159.

Flow for an Offsite Backup and Restore Operation

If there is a requirement to extend the recovery ability to more than the 30 days that are available with disaster recovery, Zerto
Virtual Replication provides an offsite backup option that enables saving the protected virtual machines offsite for up to one
year in a state where they can easily be deployed. The recovery virtual machines are saved in a repository of offsite backups
that can extend as far back as a year. These offsite backups are fixed points saved either daily or weekly. To save space the
offsite backups can be compressed before they are stored in the repository.
To set up repositories to protect virtual machines in a VPG with offsite backup, see “Creating an Offsite Backup Repository”, on
page 174.
Setting up offsite backups is part of defining a VPG.
After initializing the VPG, Zerto Virtual Replication periodically checks that the time to run an offsite backup has not passed. At
the scheduled backup time, the offsite backup is run and the offsite backup file stored in the specified repository.
Offsite backups are kept for the retention period specified in the VPG. Over time the number of stored offsite backups is
reduced to save space.
Note: You cannot restore a backup in Azure. Use Windows Azure Backup to restore a backup.

Flows for a Disaster Recovery Operations 20

 CHAPTER 4: INTRODUCTION TO
PROTECTING VIRTUAL MACHINES

Virtual machines are protected in virtual protection groups (VPGs). A VPG is a group of virtual machines that you group
together for recovery purposes. For example, the virtual machines that comprise an application like Microsoft Exchange, where
one virtual machine is used for the software, one for the database, and a third for the Web Server require that all three virtual
machines be replicated to maintain data integrity.
Any virtual machine whose operating system is supported in both the protected site and recovery site can be protected in a
VPG.
Once a virtual machine is protected, all changes made on the machine are replicated in the remote site. The replicated virtual
machines in the remote site can be recovered to any point in time defined for the VPG or if a period further in the past is
required, an offsite backup can be restored.
When a VPG is created, a replica of each virtual machine disk in the VPG is created under a VRA on the recovery site. These
replica virtual disks must be populated with the data in the protected virtual machines, which is done by synchronizing the
protected virtual machines with the recovery site replicas. The time taken for synchronization between the protected and
recovery sites will depend on the size of the virtual machines.
After the initial synchronization completes, only the writes to disk from the virtual machines in the protected site are sent to
Azure. These writes are stored by the Virtual Replication Appliance (VRA) in the journals in a storage account for a specified
period, after which they are promoted to the replica virtual disks managed by the VRA, which are also in storage account.
The number of VPGs that can be defined on a site is limited only by the number of virtual machines that can be protected. Each
site can manage a maximum of 300 virtual machines.
Note: If the total number of protected virtual machines on the paired sites is 300, then any additional machines are not
protected.
Note: For Linux machines, Azure Linux Agent must be installed.
The following topics are described in this section:
■ “Configuring Virtual Protection Groups”, below
■ “Requirements for Microsoft Azure Environments”, below
■ “The Role of the Journal During Protection”, on page 24
■ “What Happens After the VPG is Defined”, on page 25

Configuring Virtual Protection Groups

You protect one or more virtual machines in a VPG. The VPG must include at least one virtual machine.
After creating a VPG, you can add or remove virtual machines as required.
When protecting VMs from Azure, you can only protect a virtual machine in a VPG when the virtual machine has no more than
60 disks.
When protecting VMs to Azure, the number of disks attached to the virtual machines should not exceed the quota defined by
the instance size set in the VPG and VM settings.
VPGs can be created at the protected site or the recovery site.
Configuring a VPG consists of defining the following:
■ General: A name to identify the VPG and the priority to assign to the VPG.
■ Virtual machines: The list of virtual machines being protected as well as the boot order and boot delay to apply to the
virtual protection groups during recovery.
■ Replication: The recovery site settings and the VPG SLA. SLA information includes the default journal history settings and
how often tests should be performed on the VPG. These settings are applied to every virtual machine in the VPG but can
be overridden per virtual machine, as required.

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Introduction to Protecting Virtual Machines 21
Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Introduction to Protecting Virtual Machines

■ Storage: The default storage volume to use for the recovered virtual machine files and for their data volumes. The storage
used for the virtual machine definition is also used for the virtual machine data and can be overridden per virtual machine,
as required. If a cluster is selected for the host, only storage accessible by every host in the cluster is displayed
■ Recovery: Recovery details include the networks to use for recovered virtual machines, such as the virtual networks,
subnets, network security groups, instance families, and instance size to use for failover/move and failover test
procedures, and the scripts, if any, that should run at the start or end of a recovery operation.
■ Backup: The backup properties that govern the VPG backup, including the repository where the backups are saved. Offsite
backup is relevant only when creating VPGs that will be recovered to Azure. When creating VPGs to be recovered from
Azure this tab is not shown.
■ Summary: The details of the VPG configuration defined in the previous components.
For information about protecting VMs created in Azure see “Protecting Virtual Machines From Azure” on page 28.

Requirements for Microsoft Azure Environments

■ Azure ZCA can be installed only on Windows Server 2012 R2 and higher.
■ Only virtual machines that are supported by Azure can be protected by Zerto Virtual Replication. All Windows operating
systems are supported.
Note: Microsoft does not support operating systems that are past the End of Support date, without a Custom Support
Agreement (CSA). For more information about Microsoft operating systems support for Microsoft Azure, refer to https://
support.microsoft.com/en-us/kb/2721672.
■ To replicate between Azure and your site, you must have a virtual machine in Azure with a Zerto Cloud Appliance installed
on it. This ZCA must be paired with your site.
■ For Linux distribution, refer to Azure documentation:
■ Linux on Azure-endorsed distributions: https://azure.microsoft.com/en-us/documentation/articles/virtual-
machines-linux-endorsed-distributions/
■ Information for non-endorsed distributions: https://azure.microsoft.com/en-us/documentation/articles/virtual-
machines-linux-create-upload-vhd-generic/

Requirements for Replication From Azure

■ For Virtual Machines to be protected from Azure, the VM volumes must reside in the Standard storage account defined
during ZCA installation.
A Standard storage account is created or selected upon ZCA installation.
■ Type: Standard storage
■ Recovery and journal volumes reside on this Zerto Storage Account
■ Azure VMs with all disks on this Zerto Storage Account can be protected by Zerto.
■ VMs which are not deployed via the Azure Resource Manager cannot be protected from Azure.

Requirements for Replication To Azure

■ Protected volumes are recovered in Azure as VHD disks in a page blob. Virtual machines with disks that are less than 1GB
are recovered with disks of 1GB.
Note: For some instance sizes, the Azure virtual machine is created with a Local SSD disk which is a temporary disk. This
disk is in addition to the disks associated with each protected virtual machine.
■ The following limitations apply when protecting to Azure
■ Virtual machines with UEFI Firmware cannot be protected.
■ You cannot protect machines that have a disk larger than 4 TB.
■ The protected virtual machines needs to have at least one NIC.
■ Reserve at least 2 CPUs and 4GB RAM for the machine using a subnet accessible by other Zerto Virtual Replication
sites.
■ The supported number of data disks and NICS per virtual machine is dependent on the selected instance size. For
example, instance size D3_v2 allows up to eight data disks per virtual machine.

Requirements for Microsoft Azure Environments 22

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Introduction to Protecting Virtual Machines

Additional Azure Considerations

For additional considerations, see Azure subscription and service limits, quotas and constraints: https://docs.microsoft.com/
en-us/azure/azure-subscription-service-limits.
For example from the link, see the following default values:
■ There can be multiple Zerto Cloud Appliances per Azure subscription and region.
■ 20 cores per subscription
■ 200 Storage accounts per subscription
■ 20 VMs per region per subscription
■ 20 VMs per series (Dv2, F, etc.) cores per subscription per Region
Additionally, see the following example for maximum values:
■ A Standard storage account has a maximum total request rate of 20,000 IOPS. The total IOPS across all of your virtual
machine disks in a Standard storage account should not exceed this limit.
VM TIER BASIC TIER VM STANDARD TIER VM
Disk size 1023 GB 1023 GB
Max 8 KB IOPS per persistent disk 300 500
Max number of disks performing max IOPS 66 50

See also “Azure Limitations Which Affect Installation and Recoverability”, on page 23.

Azure Limitations Which Affect Installation and Recoverability

Below are the default Azure limitations which affect installation and recovery.

Default Azure limitations which Affect Installation

■ Storage Limitations:
■ Number of storage accounts: 200 per subscription (note: max is 250)

Default Azure Limitations which Affect Recovery

Virtual Machines VMs per subscription per region: 20 (max: 10K)

Limitations VM total cores per subscription per 20
region:
Instance sizes: Limited per region.
Many of them are 20 cores per region per subscription
Resource groups per subscription: 800

Requirements for Microsoft Azure Environments 23

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Introduction to Protecting Virtual Machines

Networking Network interfaces per region: 350

NICs per instance: Depends on instance size:
■ Windows: https://docs.microsoft.com/en-us/
azure/virtual-machines/virtual-machines-
windows-sizes
■ Linux: https://docs.microsoft.com/en-us/azure/
virtual-machines/virtual-machines-linux-
sizes?toc=%2fazure%2fvirtual-
machines%2flinux%2ftoc.json
Private IP Addresses per VNET per 4096
subscription per region:
Cloning of IP addresses during recovery A different static IP should not be configured for virtual
operations: machines with a Linux operating system. Configuring a
different static IP for these machines will cause them
not to boot.
Storage Storage account total size limitation: 500 TB
(# of entities (blobs, containers etc) within a storage
account: unlimited)
Max size of a page blob (vhd): 4 TB
Min size of a page blob (vhd): 20 MB
Max number of data disks: Depends on instance size
■ Windows: https://docs.microsoft.com/en-us/
azure/virtual-machines/virtual-machines-
windows-sizes
■ Linux: https://docs.microsoft.com/en-us/azure/
virtual-machines/virtual-machines-linux-
sizes?toc=%2fazure%2fvirtual-
machines%2flinux%2ftoc.json

The Role of the Journal During Protection

After defining a VPG, the protected virtual machine disks are synced with the recovery site. After initial synchronization, every
write to a protected virtual machine is copied by Zerto Virtual Replication to the recovery site. The write continues to be
processed normally on the protected site and the copy is sent asynchronously to the recovery site and written to a journal in a
storage account managed by a Virtual Replication Appliance (VRA). Each protected virtual machine has its own journal.
In addition to the writes, every few seconds all journals are updated with a checkpoint time-stamp. Checkpoints are used to
ensure write order fidelity and crash-consistency. A recovery can be done to the last checkpoint or to a user-selected, crash-
consistent checkpoint. This enables recovering the virtual machines, either to the last crash-consistent point-in-time or, for
example, when the virtual machine is attacked by a virus, to a point-in-time before the virus attack.
Data and checkpoints are written to the journal until the specified journal history size is reached, which is the optimum
situation. At this point, as new writes and checkpoints are written to a journal, the older writes are written to the virtual
machine recovery virtual disks. When specifying a checkpoint to recover to, the checkpoint must still be in the journal. For
example, if the value specified is 24 hours then recovery can be specified to any checkpoint up to 24 hours. After the time
specified, the mirror virtual disk volumes maintained by the VRA are updated.
During recovery, the virtual machines at the recovery site are created and the recovery disks for each instance, managed by the
VRA, are copied to the recovered virtual machine. Information in the journal is promoted to the virtual instances to bring them
up to the date and time of the selected checkpoint.

The Role of the Journal During Protection 24

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Introduction to Protecting Virtual Machines

Each protected virtual machine has its own dedicated journal.

What Happens After the VPG is Defined

After defining a VPG, the VPG is created. For the creation to be successful, the storage used for the recovery, in the case of
recovery from Azure, must have either 30GB free space or 15% of the size free. This requirement ensures that during
protection the VRA, which manages the virtual machine journal and data, cannot completely fill the storage, which would result
in the VRA freezing and stopping to protect all virtual machines using that VRA. The VRA in Microsoft Azure is updated with
information about the VPG and its protected virtual machines. Until a recovery operation to Azure is performed, all data
managed by the VRA is stored in a storage account.
The synchronization process can take some time, depending on the size of the virtual machines, the amount of data in its
volumes, and the bandwidth between the sites. During this synchronization, you cannot perform any replication task, such as
adding a checkpoint.
For synchronization to work, the protected virtual machines must be powered on. The VRA requires an active IO stack to
access the virtual machine data to be synchronized across the sites. If the virtual machine is not powered on, there is no IO
stack to use to access the protected data to replicate to the target disks, and an alert is issued.
Once synchronized, the VRA in Azure includes a complete copy of every virtual machine in the VPG. After synchronization the
virtual machines in the VPG are fully protected, meeting their SLA, and the delta changes to these virtual machines are sent to
the recovery site.

For details of the screen, see “Monitoring a Single VPG”, on page 69.

What Happens After the VPG is Defined 25

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Introduction to Protecting Virtual Machines

Recovery
After initializing the VPG, all writes to the protected virtual machines are sent by the VRA on the relevant host for each virtual
machine on the protected site to the VRA. The information is saved in the journal for the virtual machine with a timestamp,
ensuring write-fidelity. Every few seconds the Zerto Virtual Manager writes a checkpoint to every journal on Azure for every
virtual machine in the VPG, ensuring crash-consistency.
The data remains in the journal, in a storage account, for the time defined by the journal history configuration, after which it is
moved to the relevant mirror disks, also in the storage account, for each virtual machine. Both the journal and the mirror disks
are managed by the VRA
When recovering, either a failover or move, or testing failover or cloning protected virtual machines in the recovery site, you
specify the checkpoint to which you want the recovered virtual machines to be recovered. The mirror disks and journal are used
to recover the virtual machines to this point-in-time. When recovering to Azure, the recovered virtual machines are created as
new virtual machines in a dedicated, new, resource group.

File and Folder Recovery

After initializing the VPG, instead of recovering a virtual machine, you can recover specific files and folders in the protected
virtual machines from a checkpoint.

Offsite Backups
After initializing the VPG, Zerto Virtual Replication periodically checks that the schedule to run an offsite backup has not been
passed, either a daily or weekly. At the scheduled backup time, the offsite backup is run and the offsite backup file stored in the
specified repository.
Offsite backups are kept on a ZCA configured repository for the retention period specified in the VPG. However, over time the
number of stored offsite backups is reduced to save space.
Offsite backup is relevant only when creating VPGs that will be recovered to Azure. Offsite backup is not supported for VPGs,
created in, and that will be recovered from Azure.
The number of stored offsite backups for daily backups is as follows:
RETENTION PERIOD DAILY WEEKLY MONTHLY NUMBER OF MAXIMUM NUMBER OF
BACKUPS DAYS TO OLDEST BACKUP
1 week 7 0 0 7 7
1 month 7 4 0 11 35
3 months 7 4 2 13 91
6 months 7 4 5 16 175
9 months 7 4 8 19 259
12 months 7 4 11 22 343

That is, an offsite backup is kept for each day for the current week and then the oldest offsite backup for the previous week is
kept for the previous four weeks and then the oldest monthly backup is kept for the rest of the retention period.
The number of stored offsite backups for weekly backups is as follows:
RETENTION PERIOD WEEKLY MONTHLY NUMBER OF MAXIMUM NUMBER OF
BACKUPS DAYS TO OLDEST BACKUP
1 week 1 0 1 7
1 month 4 1 5 58
3 months 4 3 7 121
6 months 4 6 10 205

What Happens After the VPG is Defined 26

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Introduction to Protecting Virtual Machines

RETENTION PERIOD WEEKLY MONTHLY NUMBER OF MAXIMUM NUMBER OF

BACKUPS DAYS TO OLDEST BACKUP
9 months 4 9 13 289
12 months 4 12 16 373
That is, an offsite backup is kept for each week for the current month and then the oldest backup for the month is kept and then
the oldest monthly backup is kept for the rest of the retention period.

What Happens After the VPG is Defined 27

 CHAPTER 5: PROTECTING VIRTUAL
MACHINES FROM AZURE

Virtual Machines created in Azure can be protected to the following original on-premise platforms:
■ VMware vSphere - See Protecting Azure Virtual Machines to a vCenter Server Recovery Site
■ Microsoft Hyper-V - See Protecting Azure Virtual Machines to a Hyper-V Recovery Site
■ vCloud Director (VCD) - See Protecting Azure Virtual Machines to a vCloud Director Recovery Site
Before protecting your virtual machines, review the Requirements for Microsoft Azure Environments

Requirements for Microsoft Azure Environments

■ Azure ZCA can be installed only on Windows Server 2012 R2 and higher.
■ Only virtual machines that are supported by Azure can be protected by Zerto Virtual Replication. All Windows operating
systems are supported.
Note: Microsoft does not support operating systems that are past the End of Support date, without a Custom Support
Agreement (CSA). For more information about Microsoft operating systems support for Microsoft Azure, refer to https://
support.microsoft.com/en-us/kb/2721672.
■ To replicate between Azure and your site, you must have a virtual machine in Azure with a Zerto Cloud Appliance installed
on it. This ZCA must be paired with your site.
■ For Linux distribution, refer to Azure documentation:
■ Linux on Azure-endorsed distributions: https://azure.microsoft.com/en-us/documentation/articles/virtual-
machines-linux-endorsed-distributions/
■ Information for non-endorsed distributions: https://azure.microsoft.com/en-us/documentation/articles/virtual-
machines-linux-create-upload-vhd-generic/

Requirements for Replication From Azure

■ For Virtual Machines to be protected from Azure, the VM volumes must reside in the Standard storage account defined
during ZCA installation.
A Standard storage account is created or selected upon ZCA installation.
■ Type: Standard storage
■ Recovery and journal volumes reside on this Zerto Storage Account
■ Azure VMs with all disks on this Zerto Storage Account can be protected by Zerto.
■ VMs which are not deployed via the Azure Resource Manager cannot be protected from Azure.

Requirements for Replication To Azure

■ Protected volumes are recovered in Azure as VHD disks in a page blob. Virtual machines with disks that are less than 1GB
are recovered with disks of 1GB.
Note: For some instance sizes, the Azure virtual machine is created with a Local SSD disk which is a temporary disk. This
disk is in addition to the disks associated with each protected virtual machine.
■ The following limitations apply when protecting to Azure
■ Virtual machines with UEFI Firmware cannot be protected.
■ You cannot protect machines that have a disk larger than 4 TB.
■ The protected virtual machines needs to have at least one NIC.
■ Reserve at least 2 CPUs and 4GB RAM for the machine using a subnet accessible by other Zerto Virtual Replication
sites.
■ The supported number of data disks and NICS per virtual machine is dependent on the selected instance size. For
example, instance size D3_v2 allows up to eight data disks per virtual machine.

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure 28
Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure

Additional Azure Considerations

For additional considerations, see Azure subscription and service limits, quotas and constraints: https://docs.microsoft.com/
en-us/azure/azure-subscription-service-limits.
For example from the link, see the following default values:
■ There can be multiple Zerto Cloud Appliances per Azure subscription and region.
■ 20 cores per subscription
■ 200 Storage accounts per subscription
■ 20 VMs per region per subscription
■ 20 VMs per series (Dv2, F, etc.) cores per subscription per Region
Additionally, see the following example for maximum values:
■ A Standard storage account has a maximum total request rate of 20,000 IOPS. The total IOPS across all of your virtual
machine disks in a Standard storage account should not exceed this limit.
VM TIER BASIC TIER VM STANDARD TIER VM
Disk size 1023 GB 1023 GB
Max 8 KB IOPS per persistent disk 300 500
Max number of disks performing max IOPS 66 50

See also “Azure Limitations Which Affect Installation and Recoverability”, on page 29.

Azure Limitations Which Affect Installation and Recoverability

Below are the default Azure limitations which affect installation and recovery.

Default Azure limitations which Affect Installation

■ Storage Limitations:
■ Number of storage accounts: 200 per subscription (note: max is 250)

Default Azure Limitations which Affect Recovery

Virtual Machines VMs per subscription per region: 20 (max: 10K)

Limitations VM total cores per subscription per 20
region:
Instance sizes: Limited per region.
Many of them are 20 cores per region per subscription
Resource groups per subscription: 800

Requirements for Microsoft Azure Environments 29

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure

Networking Network interfaces per region: 350

NICs per instance: Depends on instance size:
■ Windows: https://docs.microsoft.com/en-us/
azure/virtual-machines/virtual-machines-
windows-sizes
■ Linux: https://docs.microsoft.com/en-us/azure/
virtual-machines/virtual-machines-linux-
sizes?toc=%2fazure%2fvirtual-
machines%2flinux%2ftoc.json
Private IP Addresses per VNET per 4096
subscription per region:
Cloning of IP addresses during recovery A different static IP should not be configured for virtual
operations: machines with a Linux operating system. Configuring a
different static IP for these machines will cause them
not to boot.
Storage Storage account total size limitation: 500 TB
(# of entities (blobs, containers etc) within a storage
account: unlimited)
Max size of a page blob (vhd): 4 TB
Min size of a page blob (vhd): 20 MB
Max number of data disks: Depends on instance size
■ Windows: https://docs.microsoft.com/en-us/
azure/virtual-machines/virtual-machines-
windows-sizes
■ Linux: https://docs.microsoft.com/en-us/azure/
virtual-machines/virtual-machines-linux-
sizes?toc=%2fazure%2fvirtual-
machines%2flinux%2ftoc.json
The following are not supported:
■ Volumes residing in premium storage accounts.
■ Virtual machines with managed disks attached.
■ Azure temp drives.
■ Local replication - Azure to Azure.
■ Backup is not supported for “From Azure” VPGs
■ Offsite Backup not supported (back up tab removed from “From Azure” VPGs)
■ Resizing of protected disks on Azure is not supported and will not result in an auto-resized recovery disk. After resizing, the
protected disk from Azure, the VRA will not crash but the VPG will be stuck in a Needs Configuration state until the resized
disk, VM, or VPG is removed.
Notes:
■ Recovery operations from Azure configured with Reverse Protection back to Azure result in Initial Sync at the Azure site
because preseeded disks are not supported in Azure.
■ When Reverse Protection is configured, in the Recovery step of the wizard the VPG and VM default network settings are
configured as if a new VPG to Azure was created. The original VM network settings of the on-premise VPG are not
reproduced in the VPG network settings in reverse protection configuration.
■ When creating or editing a VPG from Azure to vSphere or Hyper-V, re-IP of the NIC configuration is supported only if
VMware Tools (vSphere) or Microsoft Integration Services (Hyper-V) are available for each virtual machine in the VPG, in
which case the IP address of the originally protected virtual machine is used.
■ Protection can be set up to enable recovery to a point in time, up to 30 days prior to a disaster.
■ Azure local SSD disks, which are created with the virtual machine but not provisioned to the virtual machine, are not
protected.
■ Boot order configuration for virtual machines recovered from Azure to on-premise sites is supported.

Requirements for Microsoft Azure Environments 30

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure

■ Both the protected and recovery sites must be running Zerto Virtual Replication version 5.5.
When the protected site is Azure, the following protection is available:
■ “Protecting Azure Virtual Machines to a vCenter Server Recovery Site”, below
■ “Protecting Azure Virtual Machines to a Hyper-V Recovery Site”, on page 44
■ “Protecting Azure Virtual Machines to a vCloud Director Recovery Site”, on page 53

Requirements for Microsoft Azure Environments 31

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure

Protecting Azure Virtual Machines to a vCenter Server Recovery Site

You can protect virtual machines to a recovery site vCenter Server. The procedure is the same whether you intend to protect
one virtual machine or multiple virtual machines.
When creating a VPG from Azure to a vCenter Server, all recovery operations bring up the recovered machines on VMware
vCenter Server hosts.
Zerto Virtual Replication uses SCSI for vCenter Server virtual machine disks.
When protecting virtual machines from Azure to vCenter Server, the operating systems of the protected machines must be
supported by vCenter Server. Refer to the VMware documentation for a list of supported operating systems.
The following conversions are done to a protected virtual machine when it is recovered in vSphere:
■ The SCSI controller type is operating system dependent.
■ In Azure VMs, each data disk has a Logical Unit Number (LUN) whereas in the recovered VMs there are no LUNs.
■ All disks are thin provisioned.
■ Recovered virtual machines use the VMware Virtual E1000 network adapter.
■ Operating systems will be either Windows 2012 (64-bit) or Linux Other (64-bit)
■ Memory and CPU properties will be extracted from the instance type in Azure.

To create a virtual protection group (VPG):

1. In the Zerto User Interface, select ACTIONS > CREATE VPG.
The GENERAL step of the Create VPG wizard is displayed.

2. Specify the name of the VPG and the priority of the VPG.
VPG Name – The VPG name must be unique. The name cannot be more than 80 characters.
Priority – Determine the priority for transferring data from the protected site to the recovery site when there is limited
bandwidth and more than one VPG is defined on the protected site. When there are updates to virtual machines protected
in VPGs with different priorities, first the updates from the VPG with the highest priority are passed over the WAN.
Medium priority VPGs will only be able to use whatever bandwidth is left after the high priority VPGs have used it. This is
also true between medium and low priorities. Note that updates to the protected virtual machines are always sent across
the WAN before synchronization data, such as during a bitmap or delta sync. During a synchronization, only after updates
to the virtual machines are sent over the WAN, based on the VPG priority, is synchronization data from the VPG sent, and
the synchronization data from the VPG with the highest priority is passed over the WAN before data from medium and
low priority VPGs.
3. Click NEXT.

Protecting Azure Virtual Machines to a vCenter Server Recovery Site 32

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure

The VMs step is displayed.

4. Unprotected VMs with all its disks in the storage account specified during the installation, are included in the list and can
be selected for protection. Select the VMs that will be part of this VPG and click the right-pointing arrow to include these
VMs in the VPG.
The hardware version of the virtual machine must be the same or less than the hardware version supported by the vDC in
vCloud Director (vCD) otherwise recovery of the virtual machine in vCD is not permitted. Set the supported hardware level
in the Provider vDC Properties for the vDC in the vCloud Director console.
The Select VMs dialog is displayed.

Note: Virtual machines can be protected in a maximum of three VPGs. These VPGs cannot be recovered to the same site.
Virtual machines protected in the maximum number of VPGs are not displayed in the Select VMs dialog.
Protecting virtual machines in several VPGs is enabled only if both the protected site and the recovery site, as well as the
VRAs installed on these sites, are of version 5.0 and higher.
5. If you want to define the boot order of the virtual machines in the VPG, click DEFINE BOOT ORDER, otherwise go to the
next step.
When virtual machines in a VPG are started in the recovery site, by default these machines are not started up in a
particular order. If you want specific virtual machines to start before other machines, you can specify a boot order. The

Protecting Azure Virtual Machines to a vCenter Server Recovery Site 33

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure

virtual machines are defined in groups and the boot order applies to the groups and not to individual virtual machines in the
groups. You can specify a delay between groups during startup.
Note: Up to five virtual machines may boot on a host simultaneously. Following the boot, a 300 second (default) delay
occurs until the next boot batch.
Initially, virtual machines in the VPG are displayed together under the Default group. If you want specific machines to start
before other virtual machines, define new groups with one or more virtual machines in each group.

6. Click ADD to add a new group. Then, do the following:

a) To change the name of a group, click the Pencil icon next to the group.
b) To delete a group, click the delete icon on the right side. You cannot delete the Default group nor a group that
contains a virtual machine.
c) Drag virtual machines to move them from one group to another.
d) Drag groups to change the order the groups are started.
e) Optionally, in Boot Delay, specify a time delay between starting up the virtual machines in the group and starting up
the virtual machines in the next group.
For example, assume three groups, Default, Server, and Client, defined in this order. The boot delay defined for the
Default group is 10, for the Server group is 100, and for the Client group 0. The virtual machines in the Default group
are started together and after 10 seconds the virtual machines in the Server group are started. After 100 seconds the
virtual machines in the Client group are started.
f) Click OK to save the boot order.
Click NEXT.
The REPLICATION step is displayed.

Protecting Azure Virtual Machines to a vCenter Server Recovery Site 34

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure

Note: If the protected site is paired with only one recovery site, the recovery step is displayed with the Recovery Site field
automatically filled in and defaults set for the SLA and Advanced settings, as shown below.
7. Specify the recovery site.
Recovery Site – The site to which you want to recover the virtual machines. After specifying the recovery site, other fields
are displayed including the host and datastore to use for replication.

Note: You cannot select a recovery site if any of the virtual machines you selected are already in VPGs that recover to that
site.
ZORG – If the site is defined in Zerto Cloud Manager, you specify the name used by the cloud service provider to identify
you as a Zerto Organization, ZORG. For details about Zerto Cloud Manager, refer to Zerto Cloud Manager Administration
Guide.
Host – The default cluster, resource pool or host in the recovery site that handles the replicated data. If the site is defined in
Zerto Cloud Manager, only a resource pool can be specified and the resource pool must also have been specified as a
resource in Zerto Cloud Manager.
Note: If Zerto Cloud Manager is used, vSphere Standard edition cannot be used.
For details about Zerto Cloud Manager, refer to Zerto Cloud Manager Administration Guide.
When a resource pool is specified, Zerto Virtual Replication checks that the resource pool capacity is enough for any
virtual machines specified in the VPG.
All resource pool checks are made at the level of the VPG and do not take into account multiple VPGs using the same
resource pool. If the resource pool CPU resources are specified as unlimited, the actual limit is inherited from the parent
but if this inherited value is too small, failover, move, and failover test operations can fail, even without a warning alert
being issued by Zerto Virtual Manager.
Note: If a resource pool is specified and DRS is disabled for the site later on, all the resource pools are removed by VMware
and recovery will be to any one of the hosts in the recovery site with a VRA installed on it.
Datastore – The default datastore to use for recovered virtual machine files and for their data volumes. Every datastore for
the selected recovery host is included in the drop-down list. If a cluster or resource pool is selected for the host, only
datastores that are accessible by every host in the cluster or resource pool are displayed.
8. When the Zerto Cloud Manager is used select the service profile.
Service Profile – The name of the service profile to use which determines the VPG SLA settings for the group, which apply
to every virtual machine in the group. To change the VPG SLA settings, select the Custom Service Profile.
9. If the VPG SLA settings are editable, when the Zerto Cloud Manager is not used or when a Custom service profile is
available, specify these settings for the group, which apply to every virtual machine in the group.
Journal History - The time that all write commands are saved in the journal.
The longer the information is saved in the journal, the more space is required for each journal in the VPG.
You can select the number of hours from 1 to 24 or the number of days from 2 to 30.

Protecting Azure Virtual Machines to a vCenter Server Recovery Site 35

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure

For additional journal-related fields, click ADVANCED.

The Advanced Journal Settings dialog is displayed.

Select the journal settings.

■ (for Hyper-V environments) Default Journal Storage:
-or-
■ (for vSphere environments) Default Journal Datastore:
The storage/datastore used for the journal data for each virtual machine in the VPG.
Select the storage/datastore accessible to the host.
When you select a specific journal storage/datastore, the journals for each virtual machine in the VPG are stored in this
storage/datastore, regardless of where the recovery storage/datastore is for each virtual machine. In this case, all
protected virtual machines must be recovered to the hosts that can access the specified journal storage/datastore.

Journal Size Hard Limit: The maximum size that the journal can grow, either as a percentage or a fixed amount.
The journal is always thin-provisioned.
■ Unlimited: The size of the journal is unlimited and it can grow to the size of the recovery datastore.
Note: If Unlimited is selected, the Size and Percentage options are not displayed.
■ Size (GB): The maximum journal size in GB.
■ The minimum journal size, set by Zerto Virtual Replication, is 8 GB, for Hyper-V and vSphere environments, and
10GB for Microsoft Azure environments.
■ Percentage: The percentage of the virtual machine volume size to which the journal can grow.
■ This value can be configured to more than 100% of the protected VM's volume size.
Journal Size Warning Threshold: The size of the journal that triggers a warning that the journal is nearing its hard limit.
■ Unlimited: The size of the journal is unlimited and it can grow to the size of the recovery datastore.
Note: If Unlimited is selected, the Size and Percentage options are not displayed.
■ Size (GB): The size in GB that will generate a warning.
■ Percentage: The percentage of the virtual machine volume size that will generate a warning.
Both the values of Size and Percentage must be less than the configured Hard Limit so that the warning will be generated
when needed. In addition to the warning threshold, Zerto Virtual Replication will issue a message when the free space
available for the journal is almost full.
Target RPO Alert – The maximum desired time between each automatic checkpoint write to the journal before an alert is
issued. To increase the value, move the slider right; to decrease the value, move the slider left.
Test Reminder – The time recommended between testing the integrity of the VPG. A warning is issued if a test is not done
within this time frame.
10. If you want to change the replication settings per virtual machine, click VM SETTINGS.

Protecting Azure Virtual Machines to a vCenter Server Recovery Site 36

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure

The Advanced VM Replication Settings dialog is displayed.

In this dialog, you can edit the values of one or more of the virtual machines in the VPG.
11. If you want to edit information in one field, click the field and update the information. If you want to edit information for
several virtual machines at the same time, select the virtual machines and click EDIT SELECTED.
The Edit VM dialog is displayed.

Recovery Host: The cluster, resource pool, or host that will host the recovered virtual machine. If the site is defined in
Zerto Cloud Manager, only a resource pool can be specified and the resource pool must also have been defined in Zerto
Cloud Manager. For details about Zerto Cloud Manager, see Zerto Cloud Manager Administration Guide.
When a resource pool is specified, Zerto Virtual Replication checks that the resource pool capacity is enough for all the
virtual machines specified in the VPG.
If a resource pool is specified and DRS is disabled for the site later on, all the resource pools are removed by VMware and
recovery is to any one of the hosts in the recovery site with a VRA installed on it.
All resource pool checks are made at the level of the VPG and do not take into account multiple VPGs using the same
resource pool. If the resource pool CPU resources are defined as unlimited, the actual limit is inherited from the parent but
if this inherited value is too small, failover, move, and failover test operations can fail, even without a warning alert being
issued by Zerto Virtual Manager.
Recovery Datastore: The datastore where the VMware metadata files for the virtual machine are stored, such as the vmx
file. If a cluster or resource pool is selected for the host, only datastores that are accessible by every ESX/ESXi host in the
cluster or resource pool are displayed. This is also the datastore where RDM backing files for recovery volumes are
located.
Journal Size Hard Limit: The maximum size that the journal can grow, either as a percentage or a fixed amount.
The journal is always thin-provisioned.
■ Unlimited: The size of the journal is unlimited and it can grow to the size of the recovery datastore.
Note: If Unlimited is selected, the Size and Percentage options are not displayed.

Protecting Azure Virtual Machines to a vCenter Server Recovery Site 37

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure

■ Size (GB): The maximum journal size in GB.

■ The minimum journal size, set by Zerto Virtual Replication, is 8 GB, for Hyper-V and vSphere environments, and
10GB for Microsoft Azure environments.
■ Percentage: The percentage of the virtual machine volume size to which the journal can grow.
■ This value can be configured to more than 100% of the protected VM's volume size.
Journal Size Warning Threshold: The size of the journal that triggers a warning that the journal is nearing its hard limit.
■ Unlimited: The size of the journal is unlimited and it can grow to the size of the recovery datastore.
Note: If Unlimited is selected, the Size and Percentage options are not displayed.
■ Size (GB): The size in GB that will generate a warning.
■ Percentage: The percentage of the virtual machine volume size that will generate a warning.
Both the values of Size and Percentage must be less than the configured Hard Limit so that the warning will be generated
when needed. In addition to the warning threshold, Zerto Virtual Replication will issue a message when the free space
available for the journal is almost full.
Journal Datastore: The datastore used for the journal data for each virtual machine in the VPG.
To change the default, specify a host and then select one of the datastores accessible by this host to be used as the journal
datastore.
When you select specific journal datastore, the journals for each virtual machine in the VPG are stored in this datastore,
regardless of where the recovery datastores are for each virtual machine.
In this case, all the protected virtual machines must be recovered to hosts that can access the specified journal datastore.
12. Click OK.
13. In the Advanced VM Replication Settings dialog, click OK.
14. Click NEXT.
The STORAGE step is displayed. By default the storage used for the virtual machine definition is also used for the virtual
machine data. For each virtual machine in the VPG, Zerto Virtual Replication displays its storage-related information.

Note: Steps that do not require input are marked with a check mark. You can jump directly to a step that has been marked
with a check mark to edit the values for that step. Every step must be marked with a check mark before you can click DONE
to create the VPG.
Thin – If the recovery volumes are thin-provisioned or not.
IMPORTANT: Changing the VPG recovery volume from thin-provisioned to thick-provisioned or vice versa, results in
volume initial synchronization.
Temp Data – If the virtual machine to be replicated includes a temp data disk as part of its configuration, mark the recovery
disk for this disk as a temp data disk. In this case, data is not replicated to the temp data disk after initial synchronization.
If you want to edit storage information for one of the virtual machines, select the virtual machine and click EDIT SELECTED.

Protecting Azure Virtual Machines to a vCenter Server Recovery Site 38

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure

The Edit Volumes dialog is displayed.

15. Specify the volume source for recovery from one of the following options.
Datastore – A new volume is used for replicated data. Specify the datastore to use to create disks for the replicated data. If
the source disk is thin provisioned, the default for the recovery volume is that it is also thin provisioned.
The datastore specified for replication must have at least the same amount of space as the protected volume and an
additional amount for the journal. The amount of additional space needed for the journal can be fixed by specifying a
maximum size for the journal, or can be calculated as the average change rate for the virtual machines in the VPG,
multiplied by the length of time specified for the journal history.
Zerto Virtual Replication supports the SCSI protocol. Only disks that support this protocol can be specified.
Preseeded volume – Whether to copy the protected data to a virtual disk in the recovery site. Zerto recommends using this
option particularly for large disks so that the initial synchronization will be faster since a Delta Sync can be used to
synchronize any changes written to the recovery site after the creation of the preseeded disk. When not using a preseeded
disk, the initial synchronization phase must copy the whole disk over the WAN. When using a preseeded virtual disk, you
select the datastore and exact location, folder, and name of the preseeded disk, which cannot be an IDE disk. Zerto Virtual
Replication takes ownership of the preseeded disk, moving it from its source folder to the folder used by the VRA. Only
disks with the same size as the protected disk can be selected when browsing for a preseeded disk. The datastore where
the preseeded disk is placed is also used as the recovery datastore for the replicated data.

If the preseeded disk is greater than 1TB on NFS storage, the VPG creation might fail. This is a known VMware problem
when the NFS client does not wait for sufficient time for the NFS storage array to initialize the virtual disk after the RPC
parameter of the NFS client times out. The timeout default value is 10 seconds. See the VMware documentation, http://
kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1027919, which
describes the configuration option to tune the RPC timeout parameter using the esxcfg-advcfg -s <Timeout> /NFS/
SetAttrRPCTimeout command.
Datastore – The datastore where the preseeded disk is located.
Path – The full path to the preseeded disk.
Note the following conditions:
■ If the protected disks are non-default geometry, configure the VPG using preseeded volumes.
■ If the protected disk is an RDM disk, it can be used to preseed to a recovery VMDK disk. Zerto Virtual Replication
makes sure that the VMDK disk size is a correct match for the RDM disk.
■ If the VPG is being defined for a Zerto Organization, ZORG, the location of the preseeded disk must be defined in the
Zerto Cloud Manager. For details, see Zerto Cloud Manager Administration Guide.
16. Specify the other volume options.
Temp Data disk – If the virtual machine to be replicated includes a temp data disk as part of its configuration, mark the
recovery disk for this disk as a temp data disk. In this case, data is not replicated to the temp data disk after initial
synchronization.
Thin provisioning – If the recovery volumes are thin-provisioned or not. If the source disk is thin provisioned, the default for
the recovery volume is that it is also thin provisioned.

Protecting Azure Virtual Machines to a vCenter Server Recovery Site 39

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure

17. Click OK.

18. Click NEXT.
The RECOVERY step is displayed. Recovery details include the networks to use for failover, move, and for testing failover,
and whether scripts should run as part of the recovery operation.

19. Select the default recovery settings. These are applied to every virtual machine in the VPG.
Failover/Move Network – The network to use during a failover or move operation in which the recovered virtual machines
will run.
Failover Test Network – The network to use when testing the failover of virtual machines in the recovery site. Zerto
recommends using a fenced-out network so as not to impact the production network at this site.
Recovery Folder – The folder to which the virtual machines are recovered.
20. To specify a recovery folder for each virtual machine in the VPG, click VM SETTINGS.
The Advanced VM Recovery Settings dialog is displayed.

In this dialog, you can edit the values of one or more of the virtual machines in the VPG.
21. If you want to edit information in a field, click the field and update the information. If you want to edit information for
several virtual machines at the same time, select the virtual machines and click EDIT SELECTED.

Protecting Azure Virtual Machines to a vCenter Server Recovery Site 40

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure

The Edit VM dialog is displayed.

Recovery Folder – The folder to which the virtual machine is recovered.

22. Click SAVE.
23. In the Advanced VM Recovery Settings dialog, click OK.
24. Enter the name of the script to run in the Command to run text box. You can then enter details about the script.
Pre-recovery Script – The information about a script that should run at the beginning of the recovery process.
Post-recovery Script – The information about a script that should run at the end of the recovery process.
For both types of scripts, enter the following information:
TEXT BOX DESCRIPTION
Command to run The full path of the script. The script must be located on the same machine as the Zerto Virtual
Manager for the recovery site.
Params The parameters to pass to the script. Separate parameters with a space.
Timeout The time-out, in seconds, for the script to run. If the script runs before executing a failover, move,
or test failover, and the script fails or the timeout value is reached, an alert is generated and the
failover, move, or test failover is not performed. If the script runs after executing a failover, move,
or test failover, and the timeout value is reached, an alert is generated. The default time-out value
is specified in Performance and Throttling tab in the Site Settings dialog.
25. Click NEXT.
The NICs step is displayed. In this step, you can specify the NIC details to use for the recovered virtual machines after a
failover, a test failover, or migration.

26. If you want to edit information in one field, click the field and update the information. If you want to edit information for
several virtual machines at the same time, select the virtual machines and click EDIT SELECTED. Otherwise, go to step 29.

Protecting Azure Virtual Machines to a vCenter Server Recovery Site 41

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure

The Edit vNIC dialog is displayed.

27. Specify the network details to use for the recovered virtual machines after a failover or move operation, in the Failover/
Move column, and for the recovered virtual machines when testing replication, in the Test column.
In each column, specify the following:
Network: The network to use for this virtual machine.
Create New MAC Address: Whether the Media Access Control address (MAC address) used on the protected site should
be replicated on the recovery site. The default is to use the same MAC address on both sites. Note that if you check this
option, to create a new MAC address, and the current IP address is not specified, the protected virtual machine static IP
address might not be used for the recovered virtual machine.
Change vNIC IP Configuration: Whether or not to keep the default virtual NIC (vNIC) IP configuration. The vNIC IP is only
changed after recovery for virtual machines with VMware Tools running.
Refer to the Zerto Virtual Replication Interoperability Matrix for the list of operating systems for which Zerto supports Re-
IPing.
To change the vNIC IP, select Yes in the Failover/Move or Test column. If you select to use a static IP connection, set the IP
address, subnet mask, and default gateway. Optionally, change the preferred and alternate DNS server IPs and the DNS
suffix. If you leave the DNS server and suffix entries empty, or select to use DHCP, the IP configuration and DNS server
configurations are assigned automatically, to match the protected virtual machine. You can change the DNS suffix.
If the virtual machine has multiple NICs but is configured to only have a single default gateway, fill in a 0 for each octet in
the Default gateway field for the NICs with no default gateway.
During a failover, move, or test failover, if the recovered virtual machine is assigned a different IP than the original IP, after
the virtual machine has started it is automatically rebooted so that it starts up with the correct IP. If the same network is
used for both production and test failovers, Zerto recommends changing the IP address for the virtual machines started for
the test, so that there is no IP clash between the test machines and the production machines.
Copy to failover test – Copies the settings in the Failover/Move column to the Test column.
Copy to failover/move – Copies the settings in the Test column to the Failover/Move column.
28. Click OK.
29. Click NEXT.

Protecting Azure Virtual Machines to a vCenter Server Recovery Site 42

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure

The SUMMARY step is displayed. It shows the VPG configuration that you defined in previous tabs.

30. Click DONE.

The VPG is created.
For details of what happens after saving the VPG, see “What Happens After the VPG is Defined”, on page 23.

Protecting Azure Virtual Machines to a vCenter Server Recovery Site 43

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure

Protecting Azure Virtual Machines to a Hyper-V Recovery Site

You can protect virtual machines to recovery Hyper-V hosts. The procedure is the same whether you intend to protect one
virtual machine or multiple virtual machines.
When creating a VPG from Azure to Hyper-V all recovery operations bring up the recovered machines on Microsoft Hyper-V
hosts in SCVMM.
Zerto Virtual Replication uses SCSI for Hyper-V Server virtual machine disks.
When protecting virtual machines from a Azure to Hyper-V, the operating systems of the protected machines must be
supported by Hyper-V. Refer to Hyper-V documentation for the list of supported operating systems. Virtual machine names
cannot include any of the following special characters: *?:<>/|\".
■ The following conversions are done to a protected virtual machine in when it is recovered in Hyper-V:The SCSI controller
type is operating system dependent.
■ In Azure VMs, each data disk has a Logical Unit Number (LUN) whereas in the recovered VMs there are no LUNs.
■ All disks are thin provisioned.
■ Recovered virtual machines use the VMware Virtual E1000 network adapter.
■ Operating systems will be either Windows 2012 (64-bit) or Linux Other (64-bit)
■ Memory and CPU properties will be extracted from the instance type in Azure.

■ To create a virtual protection group to recover in Hyper-V:

1. In the Zerto User Interface, select ACTIONS > CREATE VPG.
The NEW VPG step of the Create VPG wizard is displayed.

2. Specify the name of the VPG and the priority of the VPG.
VPG Name – The VPG name must be unique. The name cannot be more than 80 characters.
Priority – Determine the priority for transferring data from the protected site to the recovery site when there is limited
bandwidth and more than one VPG is defined on the protected site. When there are updates to virtual machines protected
in VPGs with different priorities, first the updates from the VPG with the highest priority are passed over the WAN.
Medium priority VPGs will only be able to use whatever bandwidth is left after the high priority VPGs have used it. This is
also true between medium and low priorities. Note that updates to the protected virtual machines are always sent across
the WAN before synchronization data, such as during a bitmap or delta sync. During a synchronization, only after updates
to the virtual machines are sent over the WAN, based on the VPG priority, is synchronization data from the VPG sent, and
the synchronization data from the VPG with the highest priority is passed over the WAN before data from medium and
low priority VPGs.
3. Click NEXT.

Protecting Azure Virtual Machines to a Hyper-V Recovery Site 44

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure

The VMs step is displayed.

4. Unprotected VMs with all its disks in the storage account specified during installation, are included in the list and can be
selected for protection. Select the VMs that will be part of this VPG and click the right-pointing arrow to include these VMs
in the VPG.
Note: Virtual machines can be protected in a maximum of three VPGs. These VPGs cannot be recovered to the same site.
Virtual machines protected in the maximum number of VPGs are not displayed in the Select VMs dialog.
Protecting virtual machines in several VPGs is enabled only if both the protected site and the recovery site, as well as the
VRAs installed on these sites, are of version 5.0 and higher.
5. If you want to define the boot order of the virtual machines in the VPG, click DEFINE BOOT ORDER, otherwise go to the
next step.
When virtual machines in a VPG are started in the recovery site, by default these machines are not started up in a
particular order. If you want specific virtual machines to start before other machines, you can specify a boot order. The
virtual machines are defined in groups and the boot order applies to the groups and not to individual virtual machines in the
groups. You can specify a delay between groups during startup.
Note: Up to five virtual machines may boot on a host simultaneously. Following the boot, a 300 second (default) delay
occurs until the next boot batch.
Initially, virtual machines in the VPG are displayed together under the Default group. If you want specific machines to start
before other virtual machines, define new groups with one or more virtual machines in each group.

6. Click ADD to add a new group. Then, do the following:

g) To change the name of a group, click the Pencil icon next to the group.
h) To delete a group, click the delete icon on the right side. You cannot delete the Default group nor a group that
contains a virtual machine.

Protecting Azure Virtual Machines to a Hyper-V Recovery Site 45

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure

i) Drag virtual machines to move them from one group to another.

j) Drag groups to change the order the groups are started.
k) Optionally, in Boot Delay, specify a time delay between starting up the virtual machines in the group and starting up
the virtual machines in the next group.
For example, assume three groups, Default, Server, and Client, defined in this order. The boot delay defined for the
Default group is 10, for the Server group is 100, and for the Client group 0. The virtual machines in the Default group
are started together and after 10 seconds the virtual machines in the Server group are started. After 100 seconds the
virtual machines in the Client group are started.
l) Click OK to save the boot order.
Click NEXT.
The REPLICATION step is displayed.

Note: If the protected site is paired with only one recovery site, the recovery step is displayed with the Recovery Site
field automatically filled in and defaults set for the SLA and Advanced settings, as shown below.
7. Specify the recovery site and default values to use for the replication to this site.
Recovery Site – The site to which you want to recover the virtual machines. After specifying the Microsoft SCVMM
recovery site, the host and storage on the site to use for the replication can be specified.

CreateVPG_4_replication_HV
Note: You cannot select a recovery site if any of the virtual machines you selected are already in VPGs that recover to that
site.

Protecting Azure Virtual Machines to a Hyper-V Recovery Site 46

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure

Host – The default cluster or host, in the recovery site that handles the replicated data.
Storage – The default storage volume to use for the recovered virtual machine files and for their data volumes. Every
storage for the recovery host is included in the drop-down list. If a cluster is selected for the host, only storage accessible
by every host in the cluster are displayed.
8. Optionally, change the VPG SLA settings, which apply to every virtual machine in the group.
■ Journal History: The time that all write commands are saved in the journal.
The longer the information is saved in the journal, the more space is required for each journal in the VPG.
You can select the number of hours from 1 to 24 or the number of days from 2 to 30.
For additional journal-related fields, click ADVANCED.
The Advanced Journal Settings dialog is displayed.

Select the journal settings.

■ (for Hyper-V environments) Default Journal Storage:
-or-
■ (for vSphere environments) Default Journal Datastore:
The storage/datastore used for the journal data for each virtual machine in the VPG.
Select the storage/datastore accessible to the host.
When you select a specific journal storage/datastore, the journals for each virtual machine in the VPG are stored in this
storage/datastore, regardless of where the recovery storage/datastore is for each virtual machine. In this case, all
protected virtual machines must be recovered to the hosts that can access the specified journal storage/datastore.

Journal Size Hard Limit: The maximum size that the journal can grow, either as a percentage or a fixed amount.
The journal is always thin-provisioned.
■ Unlimited: The size of the journal is unlimited and it can grow to the size of the recovery datastore.
Note: If Unlimited is selected, the Size and Percentage options are not displayed.
■ Size (GB): The maximum journal size in GB.
■ The minimum journal size, set by Zerto Virtual Replication, is 8 GB, for Hyper-V and vSphere environments, and
10GB for Microsoft Azure environments.
■ Percentage: The percentage of the virtual machine volume size to which the journal can grow.
■ This value can be configured to more than 100% of the protected VM's volume size.
Journal Size Warning Threshold: The size of the journal that triggers a warning that the journal is nearing its hard limit.
■ Unlimited: The size of the journal is unlimited and it can grow to the size of the recovery datastore.
Note: If Unlimited is selected, the Size and Percentage options are not displayed.
■ Size (GB): The size in GB that will generate a warning.
■ Percentage: The percentage of the virtual machine volume size that will generate a warning.
Both the values of Size and Percentage must be less than the configured Hard Limit so that the warning will be generated
when needed. In addition to the warning threshold, Zerto Virtual Replication will issue a message when the free space
available for the journal is almost full.
Target RPO Alert – The maximum desired time between each automatic checkpoint write to the journal before an alert is
issued. To increase the value, move the slider right; to decrease the value, move the slider left.
Test Reminder – The time recommended between testing the integrity of the VPG. A warning is issued if a test is not done
within this time frame.
9. If you want to change the replication settings per virtual machine, click VM SETTINGS.

Protecting Azure Virtual Machines to a Hyper-V Recovery Site 47

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure

The Advanced VM Replication Settings dialog is displayed.

In this dialog, you can edit the values of one or more of the virtual machines in the VPG.
10. If you want to edit information in one field, click the field and update the information. If you want to edit information for
several virtual machines at the same time, select the virtual machines and click EDIT SELECTED.
The Edit VM dialog is displayed.

Recovery Host: The cluster, resource pool, or host that will host the recovered virtual machine. If the site is defined in
Zerto Cloud Manager, only a resource pool can be specified and the resource pool must also have been defined in Zerto
Cloud Manager. For details about Zerto Cloud Manager, see Zerto Cloud Manager Administration Guide.
When a resource pool is specified, Zerto Virtual Replication checks that the resource pool capacity is enough for all the
virtual machines specified in the VPG.
Recovery Storage: The location where the metadata files for the virtual machine are stored, such as the vhdx file. If a
cluster is selected for the host, only storage that are accessible by every host in the cluster are displayed.
Journal Size Hard Limit: The maximum size that the journal can grow, either as a percentage or a fixed amount.
The journal is always thin-provisioned.
■ Unlimited: The size of the journal is unlimited and it can grow to the size of the recovery datastore.
Note: If Unlimited is selected, the Size and Percentage options are not displayed.
■ Size (GB): The maximum journal size in GB.
■ The minimum journal size, set by Zerto Virtual Replication, is 8 GB, for Hyper-V and vSphere environments, and
10GB for Microsoft Azure environments.
■ Percentage: The percentage of the virtual machine volume size to which the journal can grow.
■ This value can be configured to more than 100% of the protected VM's volume size.
Journal Size Warning Threshold: The size of the journal that triggers a warning that the journal is nearing its hard limit.
■ Unlimited: The size of the journal is unlimited and it can grow to the size of the recovery datastore.
Note: If Unlimited is selected, the Size and Percentage options are not displayed.
■ Size (GB): The size in GB that will generate a warning.

Protecting Azure Virtual Machines to a Hyper-V Recovery Site 48

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure

■ Percentage: The percentage of the virtual machine volume size that will generate a warning.
Both the values of Size and Percentage must be less than the configured Hard Limit so that the warning will be generated
when needed. In addition to the warning threshold, Zerto Virtual Replication will issue a message when the free space
available for the journal is almost full.
Journal Storage: The storage used for the journal data for each virtual machine in the VPG. To change the default, specify
a host and then select the storage location accessible by this host to be used as the journal storage. When you select
specific journal storage, the journals for each virtual machine in the VPG are stored in this storage, regardless of where the
recovery storage is for each virtual machine. In this case, all the protected virtual machines must be recovered to hosts that
can access the specified journal storage.
Click OK.
11. In the Advanced VM Replication Settings dialog, click OK.
12. Click NEXT.
The STORAGE step is displayed. By default the storage used for the virtual machine definition is also used for the virtual
machine data. For each virtual machine in the VPG, Zerto Virtual Replication displays its storage-related information.

Note: Steps that do not require input are marked with a check mark. You can jump directly to a step that has been marked
with a check mark to edit the values for that step. Every step must be marked with a check mark before you can click DONE
to create the VPG.
Temp Data – If the virtual machine to be replicated includes a temp data disk as part of its configuration, mark the recovery
disk for this disk as a temp data disk. In this case, data is not replicated to the temp data disk after initial synchronization.
13. If you want to edit storage information for one of the virtual machines, select the machine and click EDIT SELECTED.
The Edit Volumes dialog is displayed.

14. Specify the volume source for recovery from one of the options.
Storage – A new volume is used for replicated data. Specify the storage to use to create disks for the replicated data.
The storage specified for the replication must have at least the same amount of space as the protected volume and then an
additional amount for the journal. The amount of additional space needed for the journal can be fixed by specifying a
maximum size for the journal, or can be calculated as the average change rate for the virtual machines in the VPG,
multiplied by the length of time specified for the journal history.

Protecting Azure Virtual Machines to a Hyper-V Recovery Site 49

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure

Preseeded volume – Whether to copy the protected data to a virtual disk in the recovery site. Zerto recommends using this
option particularly for large disks so that the initial synchronization will be faster since a Delta Sync can be used to
synchronize any changes written to the recovery site after the creation of the preseeded disk. When not using a preseeded
disk, the initial synchronization phase must copy the whole disk over the WAN. When using a preseeded virtual disk, you
select the storage and exact location, folder, and name of the preseeded disk. Zerto Virtual Replication takes ownership of
the preseeded disk, moving it from its source folder to the folder used by the VRA. Only disks with the same size as the
protected disk can be selected when browsing for a preseeded disk. The storage where the preseeded disk is placed is also
used as the recovery storage for the replicated data.
15. Specify the other volume options.
Temp Data disk – If the virtual machine to be replicated includes a temp data disk as part of its configuration, specify a
mirror disk for replication that is marked as a temp data disk. In this case, data is not replicated to the temp data disk after
initial synchronization.
16. Click OK.
17. Click NEXT.
The RECOVERY step is displayed. Recovery details include the networks to use for failover, move, and for testing failover,
and whether scripts should run as part of the recovery operation.

18. Select the default recovery settings.

Failover/Move Network – The network to use during a failover or move operation in which the recovered virtual machines
will run.
Failover Test Network – The network to use when testing the failover of virtual machines in the recovery site. Zerto
recommends using a fenced-out network so as not to impact the production network at this site.
19. Enter the name of the script to run in the Command to run text box. You can then enter details about the script.
Pre-recovery Script – The information about a script that should run at the beginning of the recovery process.
Post-recovery Script – The information about a script that should run at the end of the recovery process.
For both types of scripts, enter the following information:
TEXT BOX DESCRIPTION
Command to run The full path of the script. The script must be located on the same machine as the Zerto Virtual
Manager for the recovery site.
Params The parameters to pass to the script. Separate parameters with a space.
Timeout The time-out, in seconds, for the script to run. If the script runs before executing a failover, move,
or test failover, and the script fails or the timeout value is reached, an alert is generated and the
failover, move, or test failover is not performed. If the script runs after executing a failover, move,
or test failover, and the timeout value is reached, an alert is generated. The default time-out value
is specified in Performance and Throttling tab in the Site Settings dialog.

Protecting Azure Virtual Machines to a Hyper-V Recovery Site 50

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure

20. Click NEXT.

The NICs step is displayed. In this step, you can specify the NIC details to use for the recovered virtual machines after a
failover, a test failover, or migration.

21. If you want to edit information in one field, click the field and update the information. If you want to edit information for
several virtual machines at the same time, select the virtual machines and click EDIT SELECTED. Otherwise, go to step 24.
The Edit VNIC dialog is displayed.

22. Specify the network details to use for the recovered virtual machines after a failover or move operation, in the Failover/
Move column, and for the recovered virtual machines when testing replication, in the Test column.
In each column, specify the following:
Network: The network to use for this virtual machine.
Create New MAC Address: Whether the Media Access Control address (MAC address) used on the protected site should
be replicated on the recovery site. The default is to use the same MAC address on both sites. Note that if you check this
option, to create a new MAC address, and the current IP address is not specified, the protected virtual machine static IP
address might not be used for the recovered virtual machine.
Change vNIC IP Configuration: Whether or not to keep the default virtual NIC (vNIC) IP configuration. Configuration is
possible only when the guest operating system is defined in the hypervisor manager and Integration Services or VMware

Protecting Azure Virtual Machines to a Hyper-V Recovery Site 51

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure

Tools are detected. The vNIC IP address is only changed after recovery for virtual machines with VMware Tools and
Microsoft Integration Services running.
Note: VMware Tools must also be installed on the virtual machine in vCenter server, so that a failback can utilize Re-IPing.
Refer to the Zerto Virtual Replication Interoperability Matrix for the list of operating systems for which Zerto supports Re-
To change the vNIC IP configuration, select Yes in the Failover/Move or Test column. If you select to use a statically-
assigned IP address, set the IP address, subnet mask, and default gateway. Optionally, change the preferred and alternate
DNS server IP addresses and the DNS suffix. If you leave the DNS server and suffix entries empty, or select to use DHCP,
the IP address and DNS server configurations are assigned automatically, to match the protected virtual machine. You can
change the DNS suffix.
If the virtual machine has multiple NICs but is configured to only have a single default gateway, fill in a 0 for each octet in
the Default gateway field for the NICs with no default gateway.
Note: During a failover, move, or test failover, if the recovered virtual machine is assigned a different IP address than the
original IP address, after the virtual machine has started it is injected with the correct IP address. If the same network is
used for both production and test failovers, Zerto recommends changing the IP address for the virtual machines started for
the test, so that there is no IP address clash between the test machines and the production machines.
Copy to failover test – Copies the settings in the Failover/Move column to the Test column.
Copy to failover/move – Copies the settings in the Test column to the Failover/Move column.
23. Click OK.
24. Click NEXT.
The SUMMARY step is displayed. It shows the VPG configuration that you defined in previous tabs.

25. Click DONE.

The VPG is created.
For details of what happens after saving the VPG, see “What Happens After the VPG is Defined”, on page 25.

Protecting Azure Virtual Machines to a Hyper-V Recovery Site 52

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure

Protecting Azure Virtual Machines to a vCloud Director Recovery Site

You can protect virtual machines to a recovery site vCenter Server. The procedure is the same whether you intend to protect
one virtual machine or multiple virtual machines.
When creating a VPG from Azure to a vCenter Server, all recovery operations bring up the recovered machines on VMware
vCenter Server hosts.
Zerto Virtual Replication uses SCSI for vCenter Server virtual machine disks.
When protecting virtual machines from Azure to vCenter Server, the operating systems of the protected machines must be
supported by vCenter Server. Refer to the VMware documentation for a list of supported operating systems.
■ The following conversions are done to a protected virtual machine in when it is recovered in vCD:The SCSI controller type
is operating system dependent.
■ In Azure VMs, each data disk has a Logical Unit Number (LUN) whereas in the recovered VMs there are no LUNs.
■ All disks are thin provisioned.
■ Recovered virtual machines use the VMware Virtual E1000 network adapter.
■ Operating systems will be either Windows 2012 (64-bit) or Linux Other (64-bit)
■ Memory and CPU properties will be extracted from the instance type in Azure.

■ To create a virtual protection group (VPG) to recover in vCloud Director:

1. In the Zerto User Interface, select ACTIONS > CREATE VPG.
The NEW VPG step of the Create VPG wizard is displayed.

2. Specify the name of the VPG and the priority of the VPG.
VPG Name – The VPG name must be unique. The name cannot be more than 80 characters.
Priority – Determine the priority for transferring data from the protected site to the recovery site when there is limited
bandwidth and more than one VPG is defined on the protected site. When there are updates to virtual machines protected
in VPGs with different priorities, first the updates from the VPG with the highest priority are passed over the WAN.
Medium priority VPGs will only be able to use whatever bandwidth is left after the high priority VPGs have used it. This is
also true between medium and low priorities. Note that updates to the protected virtual machines are always sent across
the WAN before synchronization data, such as during a bitmap or delta sync. During a synchronization, only after updates
to the virtual machines are sent over the WAN, based on the VPG priority, is synchronization data from the VPG sent, and
the synchronization data from the VPG with the highest priority is passed over the WAN before data from medium and
low priority VPGs.
3. Click NEXT.
Note: If vCloud Director is also on the protected site, choose vCenter. For details of protecting from vCD, refer to.

Protecting Azure Virtual Machines to a vCloud Director Recovery Site 53

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure

The VMs step is displayed.

4. Unprotected VMs with all its disk in the storage account specified during installation, are included in the list and can be
selected for protection. Select the VMs that will be part of this VPG and click the right-pointing arrow to include these VMs
in the VPG.
The hardware version of the virtual machine must be the same or less than the hardware version supported by the vDC in
vCloud Director (vCD) otherwise recovery of the virtual machine in vCD is not permitted. Set the supported hardware level
in the Provider vDC Properties for the vDC in the vCloud Director console.
The Select VMs dialog is displayed.

Note: Virtual machines can be protected in a maximum of three VPGs. These VPGs cannot be recovered to the same site.
Virtual machines protected in the maximum number of VPGs are not displayed in the Select VMs dialog.
Protecting virtual machines in several VPGs is enabled only if both the protected site and the recovery site, as well as the
VRAs installed on these sites, are of version 5.0 and higher.
Note: You define the boot order for the recovered vCD vApp in the vCloud Director console.
5. If you want to define the boot order of the virtual machines in the VPG, click DEFINE BOOT ORDER, otherwise go to the
next step.
When virtual machines in a VPG are started in the recovery site, by default these machines are not started up in a
particular order. If you want specific virtual machines to start before other machines, you can specify a boot order. The

Protecting Azure Virtual Machines to a vCloud Director Recovery Site 54

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure

virtual machines are defined in groups and the boot order applies to the groups and not to individual virtual machines in the
groups. You can specify a delay between groups during startup.
Note: Up to five virtual machines may boot on a host simultaneously. Following the boot, a 300 second (default) delay
occurs until the next boot batch.
Initially, virtual machines in the VPG are displayed together under the Default group. If you want specific machines to start
before other virtual machines, define new groups with one or more virtual machines in each group.

6. Click ADD to add a new group. Then, do the following:

m) To change the name of a group, click the Pencil icon next to the group.
n) To delete a group, click the delete icon on the right side. You cannot delete the Default group nor a group that
contains a virtual machine.
o) Drag virtual machines to move them from one group to another.
p) Drag groups to change the order the groups are started.
q) Optionally, in Boot Delay, specify a time delay between starting up the virtual machines in the group and starting up
the virtual machines in the next group.
For example, assume three groups, Default, Server, and Client, defined in this order. The boot delay defined for the
Default group is 10, for the Server group is 100, and for the Client group 0. The virtual machines in the Default group
are started together and after 10 seconds the virtual machines in the Server group are started. After 100 seconds the
virtual machines in the Client group are started.
r) Click OK to save the boot order.
7. Click NEXT.
The REPLICATION step is displayed.

8. Choose the recovery site and whether recovery will be to VC or vCD.

Protecting Azure Virtual Machines to a vCloud Director Recovery Site 55

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure

The REPLICATION step is re-displayed, with additional fields that are relevant for VC or vCD. If you chose vCD, this screen
is displayed.

When VCD is selected, specify the Recovery Org vDC to use in the recovery site.
ZORG – If the site is defined in Zerto Cloud Manager, you specify the name used by the cloud service provider to identify
you as a Zerto Organization, ZORG. For details about Zerto Cloud Manager, refer to Zerto Cloud Manager Administration
Guide
You cannot select a recovery site if any of the virtual machines you selected are already in VPGs that recover to that site.
9. When the Zerto Cloud Manager is used select the service profile.
Service Profile – The name of the service profile to use which determines the VPG SLA settings for the group, which apply
to every virtual machine in the group. To change the VPG SLA settings, select the Custom Service Profile.
10. If the VPG SLA settings are editable, when the Zerto Cloud Manager is not used or when a Custom service profile is
available, specify these settings for the group, which apply to every virtual machine in the group.
■ Journal History: The time that all write commands are saved in the journal.
The longer the information is saved in the journal, the more space is required for each journal in the VPG.
You can select the number of hours from 1 to 24 or the number of days from 2 to 30.
For additional journal-related fields, click ADVANCED.
The Advanced Journal Settings dialog is displayed.

JJournal Size Hard Limit: The maximum size that the journal can grow, either as a percentage or a fixed amount.
The journal is always thin-provisioned.
■ Unlimited: The size of the journal is unlimited and it can grow to the size of the recovery datastore.
Note: If Unlimited is selected, the Size and Percentage options are not displayed.
■ Size (GB): The maximum journal size in GB.
■ The minimum journal size, set by Zerto Virtual Replication, is 8 GB, for Hyper-V and vSphere environments, and
10GB for Microsoft Azure environments.
■ Percentage: The percentage of the virtual machine volume size to which the journal can grow.
■ This value can be configured to more than 100% of the protected VM's volume size.
Journal Size Warning Threshold: The size of the journal that triggers a warning that the journal is nearing its hard limit.

Protecting Azure Virtual Machines to a vCloud Director Recovery Site 56

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure

■ Unlimited: The size of the journal is unlimited and it can grow to the size of the recovery datastore.
Note: If Unlimited is selected, the Size and Percentage options are not displayed.
■ Size (GB): The size in GB that will generate a warning.
■ Percentage: The percentage of the virtual machine volume size that will generate a warning.
Both the values of Size and Percentage must be less than the configured Hard Limit so that the warning will be generated
when needed. In addition to the warning threshold, Zerto Virtual Replication will issue a message when the free space
available for the journal is almost full.
Target RPO Alert: The maximum desired time between each automatic checkpoint write to the journal before an alert is
issued. To increase the value, move the slider right; to decrease the value, move the slider left.
Test Reminder: The time recommended between testing the integrity of the VPG. A warning is issued if a test is not done
within this time frame.
11. If you want to change the replication settings per virtual machine, click VM SETTINGS.
The Advanced VM Replication Settings dialog is displayed.

In this dialog, you can edit the values of one or more of the virtual machines in the VPG.
12. If you want to edit information in one field, click the field and update the information. If you want to edit information for
several virtual machines at the same time, select the virtual machines and click EDIT SELECTED.
The Edit VM dialog is displayed.

Storage Profile – Storage profiles enable mapping virtual machines to storage levels according to predefined service levels,
storage availability, performance requirements or cost. You can define and label storage tiers and then specify the tier to
use as a storage profile, for each virtual machine in the VPG. The default storage profile is the default for the Recovery Org
vDC.
Zerto will place all the volumes of each virtual machine in a datastore, according to the following considerations:
■ The datastore is part of the selected storage profile.
■ The datastore is configured as recovery datastore target in the Configure PVDC dialog.
■ The datastore has enough space to contain all of the virtual machine volumes.

Protecting Azure Virtual Machines to a vCloud Director Recovery Site 57

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure

If Zerto Virtual Replication cannot find a storage profile that can be used as target storage, the value is set to Zerto_Any.
In this case, any of the datastores configured in the Configure Provider vDCs dialog can be selected as recovery datastores,
provided they are exposed to the relevant recovery hosts. Upon recovery, Zerto Virtual Replication chooses a storage
profile available to the Org vDC, for the recovered vApp, that contains all of the datastores on which recovery volumes of
the VPG reside. If there is no such storage profile, the recovery operation cannot start. The storage profile can be set to
Zerto_Any for a number of reasons, such as adding a virtual machine to the VPG which does not have a storage profile
that can be used as the target.
Journal Size Hard Limit: The maximum size that the journal can grow, either as a percentage or a fixed amount.
The journal is always thin-provisioned.
■ Unlimited: The size of the journal is unlimited and it can grow to the size of the recovery datastore.
Note: If Unlimited is selected, the Size and Percentage options are not displayed.
■ Size (GB): The maximum journal size in GB.
■ The minimum journal size, set by Zerto Virtual Replication, is 8 GB, for Hyper-V and vSphere environments, and
10GB for Microsoft Azure environments.
■ Percentage: The percentage of the virtual machine volume size to which the journal can grow.
■ This value can be configured to more than 100% of the protected VM's volume size.
Journal Size Warning Threshold: The size of the journal that triggers a warning that the journal is nearing its hard limit.
■ Unlimited: The size of the journal is unlimited and it can grow to the size of the recovery datastore.
Note: If Unlimited is selected, the Size and Percentage options are not displayed.
■ Size (GB): The size in GB that will generate a warning.
■ Percentage: The percentage of the virtual machine volume size that will generate a warning.
Both the values of Size and Percentage must be less than the configured Hard Limit so that the warning will be generated
when needed. In addition to the warning threshold, Zerto Virtual Replication will issue a message when the free space
available for the journal is almost full.
13. Click OK.
14. In the Advanced VM Replication Settings dialog, click OK.
15. Click NEXT.
The STORAGE step is displayed. By default the storage used for the virtual machine definition is also used for the virtual
machine data. For each virtual machine in the VPG, Zerto Virtual Replication displays its storage-related information.

Note: Steps that do not require input are marked with a check mark. You can jump directly to a step that has been marked
with a check mark to edit the values for that step. Every step must be marked with a check mark before you can click DONE
to create the VPG.
Thin – If the recovery volumes are thin-provisioned or not.
IMPORTANT: Changing the VPG recovery volume from thin-provisioned to thick-provisioned or vice versa, results in
volume initial synchronization.

Protecting Azure Virtual Machines to a vCloud Director Recovery Site 58

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure

Temp Data – If the virtual machine to be replicated includes a temp data disk as part of its configuration, mark the recovery
disk for this disk as a temp data disk. In this case, data is not replicated to the temp data disk after initial synchronization.
16. If you want to edit storage information for one of the virtual machines, select the machine and click EDIT SELECTED.
The Edit Volumes dialog is displayed.

17. Specify the volume source for recovery from one of the options.
vCD managed storage profile – The datastore is allocated based on the available free space. You can specify whether the
recovery volume is thin-provisioned or not. If the Org vDC only supports thin-provisioned volumes, you cannot change the
setting.
Preseeded volume – A virtual disk (the VMDK flat file and descriptor) in the recovery site that has been prepared with a
copy of the protected data. Zerto recommends using this option particularly for large disks so that the initial
synchronization is much faster since a Delta Sync is used to synchronize any changes written to the recovery site after the
creation of the preseeded disk. When not using a preseeded disk the initial synchronization phase has to copy the whole
disk over the WAN. Browse to the preseed folder configured for the customer and the disk name, of the preseeded disk. In
order to use a preseeded VMDK, do the following:
■ Create a folder in vCD to use for the preseeded disks in the datastore you want to use for the customer.
■ Specify this datastore as a provider datastore for preseeded disks in the Configure Provider vDCs dialog, from the
Advanced Settings dialog, as described in Zerto Cloud Manager Administration Guide.
■ In the Zerto Cloud Manager specify the Preseed Folder Name for the ZORG, in the Manage ZORG tab.
Zerto Virtual Replication searches for the preseeded folder in the available datastores in the Org vDCs specified in the vCD
Cloud Resources for the ZORG in the Zerto Cloud Manager and takes ownership of the preseeded disk, moving it from its
source folder to the folder used by the VRA. Note that if the virtual machine has more than one preseeded disk, these disks
must reside on the same datastore. If the preseeded disk is greater than 1TB on NFS storage, the VPG creation might fail.
This is a known VMware problem when the NFS client does not wait for sufficient time for the NFS storage array to
initialize the virtual disk after the RPC parameter of the NFS client times out. The timeout default value is 10 seconds. Refer
to the VMware documentation, http://kb.vmware.com/selfservice/microsites/
search.do?language=en_US&cmd=displayKC&externalId=1027919, which describes the configuration option to tune the
RPC timeout parameter using the esxcfg-advcfg -s <Timeout> /NFS/SetAttrRPCTimeout command.
If the VPG is being defined for a Zerto Organization, ZORG, the location of the preseeded disk must be defined in the Zerto
Cloud Manager. For details, refer to Zerto Cloud Manager Administration Guide.
Zerto Virtual Replication supports the SCSI protocol. Only disks that support this protocol can be specified. Virtual
machine RDMs in a vCenter Server are replicated as VMDKs in a vCD environment.
18. Specify the other volume options.
Temp Data disk – If the virtual machine to be replicated includes a temp data disk as part of its configuration, mark the
recovery disk for this disk as a temp data disk. In this case, data is not replicated to the temp data disk after initial
synchronization.
Thin provisioning – If the recovery volumes are thin-provisioned or not.
19. Click OK.
20. Click NEXT.

Protecting Azure Virtual Machines to a vCloud Director Recovery Site 59

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure

The RECOVERY step is displayed. Recovery details include the scripts that should be run either at the start or end of a
recovery operation.

21. Select the default recovery settings.

vCD Guest Customization – When checked, VMware Guest OS Customization is enabled for the virtual machine in vCloud
Director. Enabling guest customization means that the computer name and network settings configured for this virtual
machine are applied to its Guest OS when the virtual machine is powered on. vCD Guest Customization must be checked to
enable re-IPing the recovered virtual machines.
Copy NAT Rules– When checked, NAT rules on source vCD vApp networks are copied to the recovery vCD vApp during
recovery. One of the following options can be selected:
Use automatically allocated IP - Allow the recovery site to automatically assign an external IP.
Use source external IP - Copy the rule’s external IP as the external IP on the recovery sitevApp Network Mapping – The
networks to use for failover and move operations, for failover test operations, and for test failover operations after a
failover or move when reverse protection is configured. The list of current Org Networks is displayed and you can specify
what network to use in each of the situations. <Isolated> means that the network is an internal only vApp network.
22. Enter the name of the script to run in the Command to run text box. You can then enter details about the script.
Pre-recovery Script – The information about a script that should run at the beginning of the recovery process.
Post-recovery Script – The information about a script that should run at the end of the recovery process.
For both types of scripts, enter the following information:
TEXT BOX DESCRIPTION
Command to run The full path of the script. The script must be located on the same machine as the Zerto Virtual
Manager for the recovery site.
Params The parameters to pass to the script. Separate parameters with a space.
Timeout The time-out, in seconds, for the script to run. If the script runs before executing a failover, move,
or test failover, and the script fails or the timeout value is reached, an alert is generated and the
failover, move, or test failover is not performed. If the script runs after executing a failover, move,
or test failover, and the timeout value is reached, an alert is generated. The default time-out value
is specified in Performance and Throttling tab in the Site Settings dialog.
23. Click NEXT.

Protecting Azure Virtual Machines to a vCloud Director Recovery Site 60

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure

The NICs step is displayed. In this step, you can specify the NIC details to use for the recovered virtual machines after a
failover, a test failover, or migration.

24. If you want to edit information in one field, click the field and update the information. If you want to edit information for
several virtual machines at the same time, select the virtual machines and click EDIT SELECTED. Otherwise, go to step 26.
The Edit VNIC dialog is displayed.

25. Specify the network details to use for the recovered virtual machines after a failover or move operation, in the Failover/
Move column, and for the recovered virtual machines when testing replication, in the Test column.
In each column, specify the following:
Network: The network to use for this virtual machine.
MAC Address – Whether the Media Access Control address (MAC address) used on the protected site should be
replicated on the recovery site. The default is to use the same MAC address on both sites.
vNIC IP Mode – Which IP mode to use. Specify the IP address if you choose static IP pool.
Refer to the Zerto Virtual Replication Interoperability Matrix for the list of operating systems for which Zerto supports Re-
IPing.
Note: During a failover, move, or test failover, if the recovered virtual machine is assigned a different IP than the original IP,
after the virtual machine has started it is automatically rebooted so that it starts up with the correct IP. If the same network
is used for both production and test failovers, Zerto recommends changing the IP address for the virtual machines started
for the test, so that there is no IP clash between the test machines and the production machines.
Copy to failover test – Copies the settings in the Failover/Move column to the Test column.
Copy to failover/move – Copies the settings in the Test column to the Failover/Move column.
26. Click OK.

Protecting Azure Virtual Machines to a vCloud Director Recovery Site 61

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Protecting Virtual Machines From Azure

27. Click NEXT.

The SUMMARY step is displayed. It shows the VPG configuration that you defined in previous steps.

28. Click DONE.

The VPG is created.
For details of what happens after saving the VPG, see “What Happens After the VPG is Defined”, on page 25.
The virtual machines in the VPG are protected as a vCD vApp in the recovery site. When recovering the VPG, reverse
protection is configured back the virtual machines.

Protecting Azure Virtual Machines to a vCloud Director Recovery Site 62

 CHAPTER 6: MONITORING ZERTO
VIRTUAL REPLICATION

You can monitor information about all the VPGs either protected at the local site or recovered to the local site in the VPGs tab.
You can also drill-down to monitor information about a specific VPG displayed in the VPGs tab or about the virtual machines
being protected by VPGs. You can also view summary details of the protected and recovery sites in either the protected or
recovery site as well as monitor the status of each virtual protection group and any of the virtual machines being protected in
either site.
The following general monitoring options are described in this section:
■ “The DASHBOARD Tab”, below
■ “Monitoring VPGs – The VPGs Tab”, on page 65
■ “Monitoring a Single VPG”, on page 69
■ “Monitoring Tasks”, on page 72
■ “Monitoring Protected Virtual Machines – The VMs Tab”, on page 74
The following site monitoring option is described in this section:
■ “Monitoring Sites”, on page 76
The following offsite backup monitoring options are described in this section:
■ “Monitoring Repositories for Offsite Backups – The SETUP Tab”, on page 77
■ “Monitoring Offsite Backups – The OFFSITE BACKUP Tab”, on page 78
For details about monitoring Zerto Virtual Manager alerts and events, refer to Zerto Virtual Replication Guide to Alarms, Alerts
and Events.

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Monitoring Zerto Virtual Replication 63
Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Monitoring Zerto Virtual Replication

The DASHBOARD Tab

The DASHBOARD provides an overview of the sites and VPGs being protected at the site, or recovered to the site.

The following information is displayed:

VPG HEALTH
The VPGs being protected to or recovered from Azure, along with the health of each VPG, are represented by colored blocks,
where the color represents the following:
Green – The VPG is being replicated, including syncing the VPG between the sites.
Orange – The VPG is being replicated but there are problems, such as an RPO value larger than the target RPO value
specified for the VPG.
Red – The VPG is not being replicated, for example because communication with Azure is down.
Positioning the mouse over a block displays the VPG name as a tooltip. Clicking the block opens the details tab for the VPG.

STATUS
The status of the site, including the following:
■ The number of VPGs and virtual machines being protected or recovered.
■ The amount of storage being protected.
■ The average RPO.
■ The percentage compression of data passed between the site and peer sites.

The DASHBOARD Tab 64

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Monitoring Zerto Virtual Replication

Performance Graphs
The current site performance, which includes the following information:
IOPS (IO per second) – The IO between all the applications running on the virtual machines being protected and the VRA that
sends a copy to the remote site for replication.
Throughput (MB/sec): The MBs for all the applications running on the virtual machines being protected. There can be a high
IO rate with lots of small writes resulting in a small throughput as well as a small IO with a large throughput. Thus, both the
IOPS and Throughput values together provide a more accurate indication of performance.
WAN Traffic (MB/sec): The VPG related outgoing traffic between the sites.
A listing of the currently active alerts and running tasks, and the events run during the last few hours.
User input, for example, stopping a failover test or committing or rolling back a Move or Failover operation, can be initiated
from the relevant task displayed in the RUNNING TASKS section.

ACTIVE ALERTS, RUNNING TASKS, and EVENTS

A listing of the currently active alerts and running tasks, and the events run during the last few hours.
User input, for example, stopping a failover test or committing or rolling back a Move or Failover operation, can be initiated
from the relevant task displayed in the RUNNING TASKS section.

Monitoring VPGs – The VPGs Tab

View details of all VPGs in the VPGs tab. This tab lists all the VPGs from both the local and remote sites and provides summary
details of each VPG.

Monitoring VPGs – The VPGs Tab 65

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Monitoring Zerto Virtual Replication

You can create a query using the view buttons ( )to display VPG information in a list or as a grid. In both list and grid
views you can filter the VPGs that will be displayed according to their status by checking the checkboxes alongside the VPG
status icons ( ). The query can be customized by adding and removing filters.
The QUERY option allows you to save or run a personal query, or set the VPG tab back to its default view.

List View - GENERAL

The following information is displayed in the GENERAL view:
Alert status indicator: The color indicates the status of the VPG. Hovering over the alert displays a popup of all active alerts
with descriptions:
Green: The VPG is being replicated, including syncing the VPG between the sites.
Orange: The VPG is being replicated but there are problems, such as an RPO value larger than the Target RPO Alert value
specified for the VPG.
Red: The VPG is not being replicated, for example, because communication with the remote site is down.
Move the cursor over the Alert status indicator to display details of the alert.

VPG Name (#VMs): The name of the VPG. The name is a link: Click the VPG name to drill-down to more specific details about
the VPG that are displayed in a dynamic tab. The number of VMs protected in the VPG is displayed in parentheses.
Direction: The direction of the replication, from this site to the remote site or from the remote site to this site.
Peer Site: The name of the site with which this site is paired: the site where the VPG is protected or will be recovered to.
Priority: The priority of the VPG.
Protection Status: The current status of the VPG, such as Meeting SLA. Where appropriate, the percentage of the operation
completed, such as syncing, is displayed.
State: The current substatus of the VPG, such as Delta syncing. Where appropriate, the percentage of the operation
completed, such as syncing, is displayed.
Actual RPO: The time since the last checkpoint was written to the journal. This should be less than the Target RPO Alert value
specified for the VPG.
Operation: The operation, such as Move, that is currently being performed.

List View - PERFORMANCE

The following information is displayed in the PERFORMANCE view:
Alert status indicator – The color indicates the status of the VPG. Hovering over the alert displays a popup of all active alerts
with descriptions:
Green – The VPG is being replicated, including syncing the VPG between the sites.

Monitoring VPGs – The VPGs Tab 66

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Monitoring Zerto Virtual Replication

Orange – The VPG is being replicated but there are problems, such as an RPO value larger than the Target RPO Alert
value specified for the VPG.
Red – The VPG is not being replicated, for example, because communication with the remote site is down.
Move the cursor over the Alert status indicator to display details of the alert.

VPG Name (#VMs) – The name of the VPG. The name is a link: Click the VPG name to drill-down to more specific details
about the VPG that are displayed in a dynamic tab. The number of virtual machines protected in the VPG is displayed in
parentheses.
IO – The IO per second between all the applications running on the virtual machines in the VPG and the VRA that sends a copy
to the remote site for replication.
Throughput – The MB per second for all the applications running on the virtual machines being protected. There can be a high
IO rate with lots of small writes resulting in a small throughput as well as a small IO with a large throughput. Thus, both the
IOPS and Throughput values together provide a more accurate indication of performance.
Network – The amount of WAN traffic.
Provisioned Storage (not shown by default) – The provisioned storage for all the virtual machines in the VPG. Thus, a virtual
machine with 1GB hard disk and 4GB memory will show 5GB provisioned storage.
Used Storage – The storage used by all of the virtual machines in the VPG.

List View - BACKUP

The following information is displayed in the BACKUP view:
Alert status indicator: The color indicates the status of the VPG. Hovering over the alert displays a popup of all active alerts
with descriptions:
Green: The VPG is being replicated, including syncing the VPG between the sites.
Orange: The VPG is being replicated but there are problems, such as an RPO value larger than the Target RPO Alert value
specified for the VPG.
Red: The VPG is not being replicated, for example, because communication with the remote site is down.
Move the cursor over the Alert status indicator to display details of the alert.

VPG Name (#VMs): The name of the VPG. The name is a link: Click the VPG name to drill-down to more specific details about
the VPG that are displayed in a dynamic tab.
Retention Policy: Whether the VPG is protected against a disaster only with the ability to recover to a point in time up to 30
days before the disaster, or protection is extended to include offsite backups of the virtual machines, going back for a maximum
of one year.
Backup Status: The status of the backup.
Backup Repository: The name of the repository where the jobs are stored.
Restore Point Range: The restore points for the backup jobs out of the total backup jobs run for the VPG.
Backup Scheduling: The schedule for offsite backups.

Monitoring VPGs – The VPGs Tab 67

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Monitoring Zerto Virtual Replication

Additional Fields and Options

In the GENERAL, PERFORMANCE, and BACKUP views you can:
■ Show/Hide Columns, Create View and Reset Columns using the settings ( ) menu.
■ Sort the list by a column by clicking in the column title.
■ Filter information in the columns by clicking the filter button ( ) that is displayed when the mouse cursor is moved into
the column title. Active filters are displayed with a yellow background.

Grid View
In the grid view each VPG is displayed as a card.

The default view is of all the VPG cards, un-grouped and sorted by VPG name.

The cards displayed can be filtered by clicking the filter button( ). The default filters are Direction and Protection Status. You
can click the ADD button to open the filters drop-down, and select additional filters. Active filters are displayed with a yellow
background.
Each card contains the following:
Alert status indicator: The color indicates the status of the VPG. Hovering over the alert displays a popup of all active alerts
with descriptions:
Green:The VPG is being replicated, including syncing the VPG between the sites.
Orange: The VPG is being replicated but there are problems, such as an RPO value larger than the Target RPO Alert value
specified for the VPG.
Red: The VPG is not being replicated, for example, because communication with the remote site is down.
Move the cursor over the Alert status indicator to display details of the alert.

VPG Name (#VMs): The name of the VPG. The name is a link: Click the VPG name to drill-down to more specific details about
the VPG that are displayed in a dynamic tab. The number of VMs protected in the VPG is displayed in parentheses.
Direction: The direction of the replication, from this site to the remote site or from the remote site to this site.
Peer Site: The name of the site with which this site is paired: the site where the VPG is protected or will be recovered to.

Monitoring VPGs – The VPGs Tab 68

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Monitoring Zerto Virtual Replication

State: The current substatus of the VPG, such as Delta syncing. Where appropriate, the percentage of the operation completed,
such as syncing, is displayed.
Actual RPO: The time since the last checkpoint was written to the journal. This should be less than the Target RPO Alert
value specified for the VPG.
Operation: The operation, such as Move, that is currently being performed.

Saving Details of Virtual Protection Groups to a File

You can save details of every VPG displayed in the VPGs tab to a CSV file, which can be opened using programs such as
Microsoft Excel.
In the VPGs tab, click EXPORT and specify where to save the VPG details.

Monitoring a Single VPG

You can monitor the status of a specific VPG by clicking the VPG name in the VPGs tab or clicking the VPG name in the VMs
tab. The VPG details are displayed in a dynamic tab.

General Tab
The tab on the left side shows the status of the VPG. The following information is displayed in this tab:

Performance Graphs
The current VPG performance, which includes the following information:
RPO (sec): The time since the last checkpoint was written to the journal. This should be less than the Target RPO Alert
value specified for the VPG.
IOPS: The IO per second between all the applications running on the virtual machines in the VPG and the VRA that sends a
copy to the remote site for replication.

Monitoring a Single VPG 69

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Monitoring Zerto Virtual Replication

Throughput (MB/sec): The MB per second for all the applications running on the virtual machines being protected. There can
be a high IO rate with lots of small writes resulting in a small throughput as well as a small IO with a large throughput. Thus,
both the IOPS and Throughput values together provide a more accurate indication of performance.
WAN TRAFFIC (MB/sec): The outgoing traffic between the sites.

JOURNAL HISTORY
The journal history shows:
■ The SLA defined for the VPG.
■ The amount of time currently covered by information in the journal.
■ The earliest—oldest—checkpoint currently in the journal that can be used for a recovery operation.

OFFSITE BACKUP
If backup is enabled, the following backup details are displayed:
Retention Policy: Whether the VPG is protected against a disaster only with the ability to recover to a point in time up to 30
days before the disaster, or protection is extended to include offsite backups of the virtual machines, going back for a maximum
of one year.
Backup Status: The status of the backup.
Backup Repository: The name of the repository where the jobs are stored.
Restore Point Range: The restore points for the backup jobs out of the total backup jobs run for the VPG.
Backup Scheduling: The schedule for offsite backups.

ACTIVE ALERTS, RUNNING TASKS, and EVENTS

A listing of the currently active alerts and running tasks, and the events run during the last few hours.
User input, for example, stopping a failover test or committing or rolling back a Move or Failover operation, can be initiated
from the relevant task displayed in the RUNNING TASKS section.

PROTECTED VMs Tab

The PROTECTED VMs tab shows details about the protected virtual machines. This includes:
■ The name of the virtual machine.
■ The boot order group to which the virtual machine belongs.

Monitoring a Single VPG 70

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Monitoring Zerto Virtual Replication

■ The protected virtual machine host.

■ The protected virtual machine storage.
■ The protected virtual machine provisioned storage.
■ The protected virtual machine used storage.
■ The amount of data used on the recovery site for this virtual machine.
■ The failover and move networks that will be used for this virtual machine.
■ The failover and move subnets that will be used for this virtual machine.
■ The failover and move network security group that will be used for this virtual machine.
■ The test network that will be sued for this virtual machine.
■ The test subnet that will be sued for this virtual machine.
■ The test network security group that will be used for this virtual machine.

SITES Tab

The SITES tab shows the topology of the VPG, including both the protected and recovery sites.

Monitoring a Single VPG 71

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Monitoring Zerto Virtual Replication

SETTINGS Tab

The SETTINGS tab shows details about the VPG settings, divided into general, replication, recovery, and backup categories.

Monitoring Tasks
Recent tasks can also be reviewed for a site by clicking the TASKS area in the status bar at the bottom of the user interface.

The following information is displayed for each task:

Status: The task status.
Name: The name of the task.
Description: A description of the task.
Action: The ability to perform an action directly. For example, stop a failover test, or commit or rollback a move or failover
operation.

Monitoring Tasks 72
Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Monitoring Zerto Virtual Replication

The full details of the tasks can be monitored in the TASKS subtab under the MONITORING tab.

The following information is displayed for each task:

Task status indicator: The color indicates the status of the task. The following statuses exist for each task:
Green: The task was completed successfully.
Red: The task failed.
Task: The task name.
Status: The task status.
Related Entities: The sites which were effected by the task.
User: The user who initiated the task.
Started: The date and time the task started.
Completed: The date and time the task completed.
Notes: Notes added at the completion of a failover test.

Monitoring Tasks 73
Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Monitoring Zerto Virtual Replication

Monitoring Protected Virtual Machines – The VMs Tab

View details of the protected VMs in the VMs tab. This tab lists all the protected virtual machines from both the local and
remote sites and provides summary details of each virtual machine.

You can filter information in columns via the filter icon next to each column title. You can also sort the list by each column.

GENERAL View
The following information is displayed in the GENERAL view:
Alert status indicator: The color indicates the status of the VPG:
Green: The VPG is being replicated, including syncing the VPG between the sites.
Orange: The VPG is being replicated but there are problems, such as an RPO value larger than the Target RPO Alert
value specified for the VPG.
Red: The VPG is not being replicated, for example, because communication with the remote site is down.
VM Name: The name of the virtual machine. The name is a link.
VPG Name: The name of the VPG. The name is a link: Click the VPG name to drill-down to more specific details about the VPG
that are displayed in a dynamic tab.
Direction: The direction of the replication, from this site to the remote site or from the remote site to this site.
Peer Site: The name of the site with which this site is paired: the site where the VPG is protected or will be recovered to.
Priority: The priority of the VPG.
Protection Status: The current status of the virtual machine, such as Meeting SLA. Where appropriate, the percentage of the
operation completed, such as syncing, is displayed.
State: The current substatus of the VPG, such as Delta syncing. Where appropriate, the percentage of the operation completed,
such as syncing, is displayed.
Actual RPO: The time since the last checkpoint was written to the journal. This should be less than the Target RPO Alert value
specified for the VPG.
Operation: The operation, such as Move, that is currently being performed.

Monitoring Protected Virtual Machines – The VMs Tab 74

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Monitoring Zerto Virtual Replication

PERFORMANCE View
The following information is displayed in the PERFORMANCE view:
Alert status indicator – The color indicates the status of the VPG:
Green – The VPG is being replicated, including syncing the VPG between the sites.
Orange – The VPG is being replicated but there are problems, such as an RPO value larger than the Target RPO Alert
value specified for the VPG.
Red – The VPG is not being replicated, for example, because communication with the remote site is down.
VM Name – The name of the virtual machine. The name is a link.
VPG Name – The name of the VPG. The name is a link: Click the VPG name to drill-down to more specific details about the VPG
that are displayed in a dynamic tab.
IO – The IO per second between all the applications running on the virtual machine and the VRA that sends a copy to Azure.
Throughput: The MB per second for all the applications running on the virtual machines being protected. There can be a high
IO rate with lots of small writes resulting in a small throughput as well as a small IO with a large throughput. Thus, both the
IOPS and Throughput values together provide a more accurate indication of performance.
Network: The amount of WAN traffic.
Provisioned Storage – The provisioned storage for the virtual machine in the recovery site. Thus, a virtual machine with 1GB
hard disk and 4GB memory will show 5GB provisioned storage.
Used Storage – The storage used by the virtual machine in the recovery site.

BACKUP View
The following information is displayed in the BACKUP view:
Alert status indicator: The color indicates the status of the VPG. Hovering over the alert displays a popup of all active alerts
with descriptions:
Green: The VPG is being replicated, including syncing the VPG between the sites.
Orange: The VPG is being replicated but there are problems, such as an RPO value larger than the Target RPO Alert value
specified for the VPG.
Red: The VPG is not being replicated, for example, because communication with the remote site is down.
Move the cursor over the Alert status indicator to display details of the alert.

VPG Name (#VMs): The name of the VPG. The name is a link: Click the VPG name to drill-down to more specific details about
the VPG that are displayed in a dynamic tab.
Retention Policy: Whether the VPG is protected against a disaster only with the ability to recover to a point in time up to 30
days before the disaster, or protection is extended to include offsite backups of the virtual machines, going back for a maximum
of one year.
Backup Status: The status of the backup.
Backup Repository: The name of the repository where the jobs are stored.
Restore Point Range: The restore points for the backup jobs out of the total backup jobs run for the VPG.
Backup Scheduling: The schedule for offsite backups.

Monitoring Protected Virtual Machines – The VMs Tab 75

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Monitoring Zerto Virtual Replication

Additional Fields
There are additional fields that you can display that are listed when you select Show/Hide Columns from the dropdown list
shown by clicking the configuration icon ( ):
Protected Site – The name of the protected site.
Recovery Site – The name of the recovery site.
ZORG – A name given to an organization by a cloud service provider. For details refer to Zerto Cloud Manager Administration
Guide.
Last Test – The time and date of the last backup performed by Zerto Virtual Manager.

Monitoring Sites
You can display information about the peer sites of the local site via the SITES tab.

The SITES Tab

View details of the paired sites in the SITES tab. This tab lists all the sites paired to the local site and provides summary details
of each paired site.

You can filter information in columns via the filter icon next to each column title. You can also sort the list by each column.

GENERAL View
The following information is displayed in the GENERAL view:
Alert status indicator – The color indicates the alert status of the site:
Green – The Zerto Virtual Manager for the site is running without problems.
Orange – The Zerto Virtual Manager for the site has a problem that does not stop the protection of virtual machines, such
as an RPO value larger than the Target RPO Alert value for a VPG.
Red – The Zerto Virtual Manager for the site is not running correctly, for example, because communication with the site is
down.
Site Name – The name specified for the paired site during installation or in the Site Settings dialog.
Location – The location specified for the paired site during installation or in the Site Settings dialog.
Site IP – The IP of the peer site.
Network – The amount of WAN traffic.

Monitoring Sites 76
Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Monitoring Zerto Virtual Replication

IOPS – The IO per second between all the applications running on the virtual machine in the VPG and the VRA that sends a
copy to the remote site for replication.
Incoming Throughput – The MBs for all the applications running on the virtual machine being protected. There can be a high IO
rate with lots of small writes resulting in a small throughput as well as a small IO with a large throughput. Thus, both the IO and
Incoming Throughput values together provide a more accurate indication of performance.
Provisioned Storage (GB) – The maximum storage that can be protected.
# VPGs – The total number of VPGs being protected by the site and replicated to the site.
# VMs – The total number of virtual machines being protected by the site and replicated to the site.

Additional Fields
There are additional fields that you can display that are listed when you select Show/Hide Columns from the dropdown list
shown by clicking the configuration icon ( ):
Used Storage (GB) – The name of the protected site.
ZORG – A name given to the organization by a cloud service provider. For details refer to Zerto Cloud Manager Administration
Guide.
Version – The Zerto Virtual Replication version installed at this site.

Monitoring Repositories for Offsite Backups – The SETUP Tab

View details of the repositories that can be used for offsite backup jobs in the REPOSITORIES subtab, under the SETUP tab. This
tab lists all the repositories created for the site.
You can filter information in columns via the filter icon next to each column title. You can also sort the list by each column.

GENERAL View
In this view, the number of repositories is displayed in the REPOSITORIES tab. The following information is displayed in this
view:
Delete Repository – Links to edit or delete a repository.
Repository Name – The name of the repository.
Repository Type – The type of repository. The options are Local or Network Share (SMB).
Connectivity – Whether the repository is connected or not.
Path – The path to the repository.
Capacity – The overall capacity of the repository.
Free Space – The amount of free space currently available for the repository.
Active Backups – The number of backup jobs currently active that are stored in the repository.
Restore Points – The restore points for the backup jobs out of the total backup jobs saved to the repository.
Compression – A value in this field denotes that the backups stored in the repository are compressed.
Click NEW REPOSITORY to display the New Repository dialog used to create a new repository.

Monitoring Repositories for Offsite Backups – The SETUP Tab 77

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Monitoring Zerto Virtual Replication

Monitoring Offsite Backups – The OFFSITE BACKUP Tab

View details of the offsite backup jobs in the OFFSITE BACKUP tab either by VPG or virtual machine. This tab lists all the defined
offsite backups and their statuses.

VPGs Tab
View details of the offsite backup jobs by VPG.
You can filter information in columns via the filter icon next to each column title. You can also sort the list by each column.

GENERAL View
The following information is displayed in the GENERAL view:
VPG Name: The name of the VPG.
Backup Site: The site where the VPG is backed up. The backup jobs are stored either locally at this site or on a network shared
drive which is accessible from this site.
Status: The status of the job: Running or Scheduled.
Repository Name: The name of the repository where the job is stored.
VPG Size: The size of the VPG in the last run stored on disk.
Result of Last Run: The result of the last run: Full success, Partial success, or Failed.
Restore Points: The restore points for the backup jobs out of the total backup jobs run for the VPG.

RUN DETAILS View

The following information is displayed in the RUN DETAILS view:
VM Name: The name of the Virtual machine.
VPG Name: The name of the VPG.
Result of Last Run: The result of the last run: Full success, Partial success, or Failed.
Time of Last Run: The time of the last run.
Next Scheduled Run: The time of the next scheduled run.
Last Full Backup: The date and time of the last full backup.

Additional Fields
There are additional fields that you can display that are listed when you select Show/Hide Columns from the dropdown list
shown by clicking the configuration icon ( ):
Protected Site – The name of the site.
Last Backup Size – The size of the last backup performed by Zerto Virtual Manager.
ZORG – A name given to an organization by a cloud service provider. For details refer to Zerto Cloud Manager Administration
Guide.
# VMs – The total number of virtual machines protected by the VPG.
# of Volumes – The number of volumes protected by the VPG.

Monitoring Offsite Backups – The OFFSITE BACKUP Tab 78

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Monitoring Zerto Virtual Replication

VMs Tab
View details of the offsite backup jobs by virtual machine.
You can filter information in columns via the filter icon next to each column title. You can also sort the list by each column.

GENERAL View
The following information is displayed in the GENERAL view:
VM Name – The name of the virtual machine.
VPG Name – The name of the VPG.
Protected Site – The name of the site where the VPG is protected.
Backup Site – The site where the virtual machines are backed up. The backup jobs are stored either locally at this site or on a
network shared drive which is accessible from this site.
Status – The status of the job.
Repository Name – The name of the repository where the job is stored.
VM Size – The size of the VMs stored on disk.
Result of Last Run – The result of the last run: Full success, Partial success, or Failed.
Restore Points – The restore points for the backup jobs out of the total backup jobs run for the VPG.

RUN DETAILS View

The following information is displayed in the RUN DETAILS view:
VM Name – The name of the Virtual machine.
VPG Name – The name of the VPG.
Result of Last Run – The result of the last run: Full success, Partial success, or Failed.
Time of Last Run – The time of the last run.
Next Scheduled Run – The time of the next scheduled run.
Last Full Backup – The date and time of the last full backup.

MORE Options
Click MORE > Edit to edit the backup parameters of the VPG.
Click MORE > Abort Backup to abort a running job. Any virtual machine volumes already stored in the repository are not
removed and the job status is partial if there are any stored volumes.
Click MORE > Run Backup to start a job for a selected VPG, outside of the schedule for that VPG.
Click EXPORT to export the backup list as a Microsoft Excel worksheet.

Additional Fields
There are additional fields that you can display that are listed when you select Show/Hide Columns from the dropdown list
shown by clicking the configuration icon ( ):

Monitoring Offsite Backups – The OFFSITE BACKUP Tab 79

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Monitoring Zerto Virtual Replication

Last Backup Size – The size of the last backup performed by Zerto Virtual Manager.
ZORG – A name given to an organization by a cloud service provider. For details refer to Zerto Cloud Manager Administration
Guide.
# of Volumes – The number of volumes associated with the VM.

Monitoring Offsite Backups – The OFFSITE BACKUP Tab 80

 CHAPTER 7: MANAGING VPGS

After defining virtual protection groups (VPGs) the virtual machines specified as part of each VPG are protected. There are a
number of ongoing management tasks that you can perform on a VPG, such as specifying a checkpoint to enable recovery to
that specific point or you can modify the configurations of existing VPGs.
The following VPG management options are described in this section:
■ “Editing a VPG”, below
■ “Adding Virtual Machines to a VPG”, on page 82
■ “Removing Virtual Machines from a VPG”, on page 84
■ “Removing a Protected Virtual Machine from Azure”, on page 84
■ “Modifying Protected Virtual Machine Disks”, on page 82
■ “Pausing and Resuming the Protection of a VPG”, on page 84
■ “Pausing and Resuming the Protection of a VPG”, on page 84
■ “Forcing the Synchronization of a VPG”, on page 85
■ “Deleting a VPG”, on page 85
■ “Running an Unscheduled Offsite Backup”, on page 86
■ “Ensuring Application Consistency – Checkpoints”, on page 86
■ “Running Scripts Before or After Recovering a VPG”, on page 94
■ “Exporting and Importing VPG Definitions”, on page 97
■ “VPG Statuses and Synchronization Triggers”, on page 98
Monitoring VPGs and the VMs that are protected is described in “Monitoring Zerto Virtual Replication”, on page 63.

Editing a VPG
You can edit a VPG definition, including adding virtual machines to the VPG, as described in “Modifying Protected Virtual
Machine Disks”, on page 82, deleting virtual machines from the VPG, or changing the information about how virtual machines
are recovered, such as adding or removing disks from the virtual machine.
Note: You cannot edit the VPG while a backup job is running.
After modifying the VPG, the definition is updated.
While the VPG definition is being updated, you cannot perform any operations on the VPG, such as adding a checkpoint,
editing the VPG properties, or failing the VPG.
After the definition is updated, the VPG is synchronized with the recovery site.

To modify a VPG:
1. In the VPGs tab in the Zerto User Interface, select the VPG to be edited and click MORE > Edit VPG. You can also select the
VPG, display the VPG details, and click EDIT VPG.
The Edit VPG wizard is displayed, enabling editing the VPG, including adding and removing virtual machines from the VPG.
Note: If the VPG was previously viewed, and the tab for this VPG is still displayed, you can access the details by selecting
the tab.
2. Make any required changes to the VPG definition. You can jump directly to a step to make a change in that step, for
example, the REPLICATION step or the RECOVERY step, by clicking the step. Steps that have been completed are marked
with a check.
3. Click DONE.
Note: The changed values are not applied to existing virtual machines but only to new virtual machines added to the VPG.
When a virtual machine is removed from a VPG, a warning is displayed. Another message is displayed when trying to save
the VPG, if a virtual machine is added to the VPG.

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing VPGs 81
Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing VPGs

The VPG is updated and then synchronized with the recovery site, if required, for example when the host was changed.
Note: Synchronization after deleting a virtual machine from a VPG results in all checkpoints being removed and the checkpoint
mechanism restarts after synchronization completes.

Modifying the Journal Size Hard Limit

If the journal size hard limit is reduced, and if the current size is greater than the newly defined size, the journal remains at the
current size. When the amount of the journal used falls below the hard limit value it will not grow greater than the new hard
limit. Unused journal volumes from the added volumes are marked for removal and removed after the time equivalent to three
times the amount specified for the journal history, or twenty-four hours, whichever is more.
Note: If the Journal Size Hard Limit or Journal Size Warning Threshold in the VPG SLA settings are changed, the
changed values are not applied to existing virtual machines but only to new virtual machines added to the VPG.

Modifying the Retention Period for Offsite Backups

If the retention period was shortened, the number of backup jobs older than the new retention period are deleted from the
repository.

Modifying Protected Virtual Machine Disks

Adding or deleting disks for a virtual machine protected in a VPG, are automatically reflected in the disks used for the mirror
virtual machine, managed by the VRA in the recovery site.

Adding Virtual Machines to a VPG

You can add virtual machines that are not already included in a VPG, to an existing VPG. A virtual machine can be protected in
a maximum of three existing VPGs, provided that the VPGs are recovered to different sites.
Protecting virtual machines in several VPGs is enabled only if both the protected site and the recovery site, as well as the VRAs
installed on these sites, are of version 5.0 and higher.
Note: You cannot edit the VPG to add a virtual machine while a backup job is running.

To add a virtual machine to an existing VPG:

1. In the VPGs tab in the Zerto User Interface, select the VPG and click MORE > Edit VPG. You can also select the VPG to
display the VPG details and click EDIT VPG.
The Edit VPG wizard is displayed, enabling you to edit the VPG, including adding and removing virtual machines from the
VPG.
In the VMs step, select the virtual machines to add and click the arrow pointing right to include these machines in the VPG.
A VPG can include virtual machines that are not yet protected and virtual machines that are already protected. You can
view protected virtual machines by clicking Select VMs in the Advanced (Multi Target) section.
Virtual machines protected in the maximum number of VPGs are not displayed in the Select VMs dialog.
Note: Protecting virtual machines in several VPGs is enabled only if both the protected site and the recovery site, as well as
the VRAs installed on these sites, are of version 5.0 and higher.
If you want to define the boot order of the VPGs, click DEFINE BOOT ORDER.
Note: Defining boot order is only relevant when replicating from Azure to on-premise sites.

Adding Virtual Machines to a VPG 82

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing VPGs

2. Configure the settings for the new virtual machines in the same way that you configured the other virtual machines in the
VPG, when you created the VPG.
3. Click DONE.
The virtual machines are added to the VPG. This process may take a few minutes. While the VPG definition is being updated,
you cannot perform any operation on the VPG, such as adding a checkpoint, editing its properties, or recovering it.
After the VPG definition has been updated, the protected and recovery sites are then synchronized. During the synchronization
period, the Protection Status displayed in the VPGs tab of the Zerto User Interface is: Meeting SLA n/m VMs
where n is the number of virtual machines that were originally in the VPG, and m is the total number of virtual machines in the
VPG, including the virtual machines that are currently being synced. While the virtual machines that were added are being
synced, the VPG can be failed over but the failover only includes the original virtual machines in the VPG.
For example, in the following screen shot, two virtual machines were added to the VPG, Operations, that originally contained 2
other virtual machines.

When the sync process for a virtual machine is complete, Zerto Virtual Manager tags the first checkpoint that includes a new
virtual machine with: VM ’XXX’ is fully synced
where XXX is the name of the virtual machine that was synced.
When you perform a recovery operation using one of these checkpoints, or any later checkpoint, all the virtual machines that
have completed syncing will be recovered.
For example, in the following screen shot, two virtual machines were added to the VPG Operations. When the sync process for
each machine completed, a checkpoint was added to show this. If you use the checkpoint written on Dec 20, 2015 at 15:39:48,
the recovery will include the virtual machine Clients but not FX history.
If you select the checkpoint at 15:40:03 or a later checkpoint, a recovery operation will also include the virtual machine FX
history.

Adding Virtual Machines to a VPG 83

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing VPGs

If the virtual machine is added to a VPG replicating to a resource pool in VMware vSphere environments, Zerto Virtual
Replication checks that the additional virtual machine doesn’t exceed the resource pool capacity, such that the sum of the
virtual machine reservation is less than or equal to the resource pool CPU and storage settings.

Removing Virtual Machines from a VPG

If a user removes a virtual machine from a VPG, the checkpoints of the VPG are retained.
Note: Once a virtual machine is removed, it is no longer possible to recover it.

Removing a Protected Virtual Machine from Azure

If a user removes a protected virtual machine from Azure, the checkpoints of the VPG are retained.
For more information about removing an Azure virtual machine, see the relevant Microsoft Azure documentation.
Note: Once a virtual machine is removed, it is no longer possible to recover it.

Pausing and Resuming the Protection of a VPG

During periods when the WAN bandwidth is utilized to its maximum, you can pause the protection of a VPG, to free up some of
this bandwidth. After pausing the protection, the VPG can still be recovered to the last checkpoint written to the journal before
the pause operation.
Note:
■ Zerto recommends adding a checkpoint to the VPG immediately before pausing protection, if you might want to recover
the VPG to the latest point in time before the pause.
■ You cannot pause a VPG while a backup job is running.

Removing Virtual Machines from a VPG 84

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing VPGs

To pause the protection of VPGs:

1. In the Zerto User Interface, click the VPGs or VMs tab and select one or more VPGs to pause protection.
2. Click MORE > PAUSE.
A warning is displayed. If you click PROCEED in this warning, the VPG protection is paused.
Note: If the VPG was previously viewed, and the tab for this VPG is still displayed, you can access the details by selecting
the tab.
The VPG protection is paused until you click Resume VPGs.

To resume the protection of VPGs:

1. In the Zerto User Interface, click the VPGs or VMs tab and select one or more VPGs to resume protection.
2. Click MORE > Resume.
After resuming protection, a Bitmap Sync will most probably be performed to synchronize the protection and recovery
sites.

Forcing the Synchronization of a VPG

If the protected virtual machines are updated such that they are no longer synchronized with their mirror machines in the
recovery site, you can force the resynchronization of the machines. An example of when the machines can be out-of-sync is
when there is a rollback of a virtual machine to a VMware snapshot. In this case, the recovery virtual machine will include
changes that have been rolled back in the protected machine, so that they are no longer synchronized.
You can force the synchronization of the machines in a VPG to remedy this type of situation.
Note: You cannot force the synchronization of a VPG while a backup job is running.

To forcibly synchronize a VPG:

1. In the Zerto User Interface, select the VPGs or VMs tab and click the VPG to display the VPG details.
2. Click MORE > Force Sync.
Note: If the VPG was previously viewed, and the tab for this VPG is still displayed, you can access the details by selecting
the tab.
The VPG starts to synchronize with the recovery site. As the journal fills up during the synchronization, older checkpoints are
deleted from the journal to make room for the new data and the data prior to these checkpoints are promoted to the virtual
machine virtual disks. Thus, during the synchronization, you can recover the virtual machine to any checkpoint still in the
journal, but as time progresses the list of checkpoints available can lessen. If the journal is not big enough to complete the
synchronization without leaving at least ten minutes worth of checkpoints, the synchronization pauses for the time specified in
the Replication Pause Time value for the VPG, to enable intervention to ensure recovery to a checkpoint remains available.
The intervention can be, for example, increasing the size of the journal, or cloning the journal as described in “Deleting a VPG”,
below.

Deleting a VPG
You can delete a VPG. Any offsite backups stored for the VPG are not deleted and the virtual machines that were backed up
can be restored.
Note: You cannot delete a VPG while a backup job is running.

To delete a VPG:
1. In the Zerto User Interface, click the VPGs or VMs tab and select one or more VPGs to delete.
2. Click MORE > Delete.

Forcing the Synchronization of a VPG 85

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing VPGs

The Delete dialog is displayed.

3. Check Keep target disks at the peer site if you might reprotect the virtual machines. When protecting to Azure,
you cannot save the disks for preseeding
4. Click DONE to delete the VPG.
The VPG configuration is deleted. The VRA on the recovery site that handles the replication for the VPG is updated
including keeping or removing the replicated data for the deleted VPG, dependent on the Keep target disks at the
peer site setting during the deletion.
The locations of the saved target disks are specified in the description of the event for the virtual machines being removed,
event EV0040, displayed in MONITORING > EVENTS.

Deleting a VPG When the Status is Deleting

If, for some reason, the VPG cannot be deleted, the VPG status changes to Deleting and the substatus is VPG waiting to
be removed. Attempting to delete the VPG a second time causes the following to be displayed:

Retry – Retry deleting the VPG.

Force Delete – Forcibly delete the VPG.
Cancel – Cancel the delete operation.

Running an Unscheduled Offsite Backup

After initializing the VPG, Zerto Virtual Replication periodically checks that the schedule to run an offsite backup - either daily
or weekly - has not passed. At the scheduled backup time, the offsite backup is run and the offsite backup file stored in the
specified repository.

To run an unscheduled offsite backup:

1. In the Zerto User Interface, click the VPGs or VMs tabs and select one or more VPGs to be backed up.
Note: You can also start from the OFFSITE BACKUP tab.
2. Click MORE > Run Backup.
Note: If the VPG was previously viewed, and the tab for this VPG is still displayed, you can access the details by selecting
the tab.
3. Click OK.
The offsite backup starts. You can monitor the progress in the Offsite Backup tab and the tasks pane. During the backup job
you cannot perform any other operation on the VPG without first aborting the job. You can start a live failover and you are then
prompted to abort the job.
Scheduled backup runs for the VPG are skipped until the unscheduled run ends.
If the job runs out of the configured backup window, the virtual machines that are already stored in the repository are kept but
remaining virtual machines in the VPG are not backed up. The job is reported as a partial backup.
Note: Offsite backup is not supported for VPGs created in Azure.

Ensuring Application Consistency – Checkpoints

Checkpoints are recorded automatically every few seconds in the journal. These checkpoints ensure crash-consistency, and
are written to the virtual machines journals by the Zerto Virtual Manager.
Each checkpoint has the same timestamp which is set by the Zerto Virtual Manager.

Running an Unscheduled Offsite Backup 86

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing VPGs

During recovery you pick a checkpoint in the journal and recover to this point. The crash-consistent checkpoints guarantee
write order fidelity.
For Example:
If write A on a virtual machine in the VPG occurred before write B on a virtual machine in the VPG, then when a checkpoint
is written, the journal will contain:
■ Neither of the writes
■ Both writes, and if they overlap the B data takes precedence
■ Only A – indicating the checkpoint occurred between A and B
The coordination is done by the Zerto Virtual Manager.
You can also integrate Microsoft Volume Shadow Copy Service (VSS) with Zerto Virtual Replication to ensure transaction
consistency in a Microsoft Windows server environment.
You can also use a script to place the application in a quiesced mode, such as Oracle Hot Backup mode, and execute the Zerto
Virtual Replication PowerShell cmdlet Set-Checkpoint, then release the quiesced mode. For more information about Zerto
Virtual Replication PowerShell cmdlets, see Zerto Virtual Replication Cmdlets.
Note:
■ VSS Checkpoint insertion is not supported in VPGs replicated from Azure.
■ To write application-consistent checkpoints, there is a performance impact on the virtual machine running the application
as a result of the application-consistent mechanism used, such as VSS. This is because the guest operating system and any
integrated applications will be quiesced.
This impact on performance may be negligible and does not always happen since not all applications require these
checkpoints in order to achieve successful application recovery. Also, Zerto Virtual Replication only requires the guest and
application to quiesce for a brief moment, just long enough to add a checkpoint.
As previously mentioned, checkpoints are recorded every few seconds in the journal. After a while, the number of checkpoints
available from which to choose a recovery point can be in excess of thousands per VPG.
When this threshold is reached, in order to enable efficient management and use of the checkpoints, the number of
checkpoints is diluted with respect to time, as follows:
■ Within the latest 2 hours: All of the checkpoints are available for recovery.
■ Between 2 and ~4.5 hours: There are about two to three checkpoints every 15 minutes.
■ From 4.5 hours and over: 1 checkpoint is kept every 15 minutes.
Note: Checkpoints which are either added manually, or added via the ZertoVssAgent, or marked as part of a Failover test
are not diluted.
This section describes the different options available to ensure application consistency:
■ “Adding a Checkpoint to Identify a Key Point”, below.
■ “Ensuring Transaction Consistency in Microsoft Windows Server Environments”, on page 89.

Adding a Checkpoint to Identify a Key Point

In addition to the automatically generated checkpoints, you can add checkpoints manually to ensure application consistency
and to identify events that might influence recovery, such as a planned switch-over to a secondary generator. You can recover
the machines in a VPG to any checkpoint in the journal, to one added automatically or to one added manually. Thus, recovery is
done to a point-in-time when the data integrity of the protected virtual machines is ensured.
Note:
■ Adding a checkpoint manually does not guarantee transaction consistency.
■ Changes to a VPG that result in re-synchronization of the VPG results in all checkpoints being removed. Adding
checkpoints to the journal is resumed after synchronization completes. A forced synchronization of the VPG only removes
checkpoints if the journal fills up during the synchronization.

Ensuring Application Consistency – Checkpoints 87

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing VPGs

To add a checkpoint to a VPG:

1. In the Zerto User Interface select ACTIONS > ADD CHECKPOINT.
The Add Checkpoint dialog is displayed.

A list of VPGs is displayed with the requested VPG selected. You can select more VPGs to add the same checkpoint to, for
example, when something is happening at your site that affects multiple VPGs.
Note: Crash-consistency is per VPG and not across VPGs, even if a checkpoint was added to multiple VPGs.
2. Enter a name for the checkpoint.
3. Click SAVE.
When testing a failover, as described in “Testing Recovery”, on page 124, or actually performing a failover, as described in
“Managing Failover”, on page 147, you can choose the checkpoint as the point to recover to.

Ensuring Application Consistency – Checkpoints 88

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing VPGs

When selecting the point to recover to:

■ The refresh button is initially grayed out and is enabled for clicking after 5 seconds. It is also grayed out for 5 seconds after
being clicked, before being re-enabled.
■ A Click the refresh button to view the latest checkpoints reminder is displayed 10 seconds after the refresh button is clicked
to remind the user that there is a new Latest Checkpoint.
■ If the user has scrolled to, and selected, a checkpoint anywhere in the checkpoints list, clicking the refresh button will
automatically return the user to the selected checkpoint in the list.
Latest – Recovery is to the latest checkpoint. This ensures that the data is crash-consistent for the recovery. When
selecting the latest checkpoint, the checkpoint used is the latest at this point. If a checkpoint is added between this point
and starting the failover, the later checkpoint is not used.
Latest Tagged Checkpoint – The recovery operation is to the latest checkpoint added in one of the following situations:
■ By a user.
■ When a failover test was previously performed on the VPG which includes the virtual machine.
■ When the virtual machine was added to an existing VPG after the added virtual machine was synchronized.
Latest VSS – When VSS is used, recovery or clone is to the latest VSS snapshot, ensuring that the data is both
crash-consistent and application consistent to this point. The frequency of VSS snapshots determines how much data can
be recovered.
Note: When replicating from Azure, tagged checkpoints are not consistent across data volumes.
If you do not want to use the latest checkpoint, latest tagged checkpoint, or latest VSS checkpoint, choose Select from all
available checkpoints. By default, this option displays all checkpoints in the system. You can choose to display only
automatic, VSS, or tagged checkpoints, or any combination of these types.
The checkpoints listed include checkpoints added via the ZertoVssAgent, as described in “Ensuring Transaction Consistency in
Microsoft Windows Server Environments”, below.

Ensuring Transaction Consistency in Microsoft Windows Server Environments

The Microsoft Volume Shadow Copy Service (VSS) enables taking manual or automatic offsite backup copies or snapshots of
data, even if it has a lock, on a specific volume at a specific point-in-time over regular intervals. This ensures not just that the
data is crash consistent but also transaction consistent if recovery is needed.
Zerto Virtual Replication enables adding checkpoints to the journal that are synchronized with VSS snapshots.
To use Zerto Virtual Replication with VSS to ensure application consistency you must install the ZertoVssAgent on every virtual
machine that uses VSS and that you want to protect with Zerto Virtual Replication.
You can install the ZertoVssAgent on the following supported Windows operating systems:
OPERATING SYSTEMS
Windows Server 2008, all versions (SPs and R2)
Windows Server 2012, all versions (SPs and R2)

To install the ZertoVssAgent:

1. Download the ZertoVssAgent, ZertoVss64Agent.msi, from the Zerto Support Portal downloads page, on the virtual
machines that use VSS and that you want to protect with Zerto Virtual Replication.
2. Run the ZertoVssAgent on the virtual machines that use VSS and that you want to protect.
Note: Only a single virtual machine in a VPG can have application consistent checkpoints and the VSS checkpoint is only
applied to the virtual machine where the ZertoVssAgent is installed. Thus, even if more than one virtual machine runs VSS,
you only install the Zerto VssAgent on one of the virtual machines in the VPG. Also, the virtual machine where the
ZertoVssAgent is installed must have network connectivity to the local Zerto Virtual Manager in order to be able to add
VSS checkpoints successfully.
3. Enter the license key and click Validate.

Ensuring Application Consistency – Checkpoints 89

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing VPGs

4. Follow the wizard through the installation.

The Zerto Virtual Manager Connections Settings dialog is displayed.

5. Specify the IP address and HTTP port number for the Zerto Virtual Managers managing the protection of the virtual
machines, both for the local site and optionally, for the paired, remote site. If the same hypervisor manager is used both for
protecting and recovering virtual machines, specify the IP address and HTTP port number for the single Zerto Virtual
Manager installed.
Note: The default HTTP port number when Zerto Virtual Replication is installed is 9080.
If you enter a wrong IP address or port you can correct the address or port after the installation completes by editing the
ZertoVssAgentGUI.exe.conf file in the ZertoVssAgent folder under the folder where the ZertoVssAgent is installed,
for example, C:\Program Files\Zerto.
6. Click OK.
The ZertoVssAgent is installed and the Add VSS Checkpoint is placed on the desktop. The agent runs as a Windows service,
ZertoVssprovider.
You can add a checkpoint to the Zerto Virtual Replication via the Add VSS Checkpoint dialog, via the command line or as a
scheduled task. The ZertoVssAgent ensures that the virtual machine is in an application consistent state and then sends the
checkpoint to the Zerto Virtual Manager, which then adds the checkpoint to the journals for the VPG containing that virtual
machine.
The checkpoint is logged for the entire VPG, however any other virtual machine in the VPG will have a crash-consistent
checkpoint.

Ensuring Application Consistency – Checkpoints 90

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing VPGs

To add a checkpoint while ensuring application consistency via the Add VSS Checkpoint dialog:
1. On a virtual machine where the ZertoVssAgent has been installed, click Start > Programs > Zerto Virtual Replication > Add
VSS Checkpoint or double-click the Add VSS Checkpoint icon on the desktop.
The Add VSS Checkpoint dialog is displayed.

2. Enter a name for the checkpoint.

3. Click OK.
Note: A message that the process was completed is displayed on the machine where the ZertoVssAgent has been installed. The
handling of the checkpoint by the Zerto Virtual Manager is done asynchronously and you can check via the recent tasks list in
the Zerto User Interface that the checkpoint is added in the VPG.

To add a checkpoint while ensuring application consistency via the command line:
1. Open the command line dialog as an administrator.
2. Navigate to the directory where the ZertoVssAgent is installed. The default location is
C:\Program Files\Zerto\ZertoVssAgent\
3. In the command line, run the following:
ZertoVssAgent.exe <localURL> <localPort> <remoteURL> <remotePort> <checkpoint>
where:
localURL – The URL for the Zerto Virtual Manager that manages the protected site.
localPort – The HTTP port for the Zerto Virtual Manager that manages the protected site.
remoteURL – The URL for the Zerto Virtual Manager that manages the recovery site.
remotePort – The HTTP port for the Zerto Virtual Manager that manages the recovery site.
checkpoint – The name of the checkpoint.
Note: A message that the process was completed is displayed on the machine where the ZertoVssAgent is installed. The
handling of the checkpoint by the Zerto Virtual Manager is done asynchronously and you can check via the recent tasks list in
the Zerto User Interface that the checkpoint is added in the VPG.

To schedule checkpoints:
1. Open the Task Scheduler.
2. Under the Actions menu item, select Create Task.
The Create Task dialog is displayed.

Ensuring Application Consistency – Checkpoints 91

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing VPGs

3. Enter the following:

Name – A name for the task.
Run whether the user is logged on or not – Make sure that this is checked.
Run with highest privileges – Make sure that this is checked.
The Windows Scheduled Task will be created and run by the currently logged in user. After the task is created, Zerto
recommends changing this to NT AUTHORITY\Network Service permissions and follow the steps to allow the correct
permissions as described in “To set COM permissions for VSS when “Access Denied” errors are received:”, on page 93.
4. Select the Triggers tab and configure a new trigger.
The New Trigger dialog is displayed.

5. Select the Actions tab and create a new action to start the ZertoVssAgent with the IP address and port of the Zerto Virtual
Manager and the checkpoint to use. For example:
C:\Program Files\Zerto\ZertoVssAgent\ZertoVssAgent.exe and
106.18.206.10 9080 106.18.206.10 9080 "VSSTaskCP"
That is, with the format: <protecting_ZVM_IP> 9080 <recovery_ZVM_IP> 9080 "<CP_name>"

6. Click OK.
7. Select the Settings tab and make changes as required. Make sure Stop the task if it runs longer than is not
selected.
8. Click OK.

Ensuring Application Consistency – Checkpoints 92

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing VPGs

There are certain permissions required for the Windows scheduled task to execute successfully. For example, you may see the
following in the event logs:
Volume Shadow Copy Service error: Unexpected error querying for the IVssWriterCallback
interface. hr = 0x80070005

This is often caused by incorrect security settings in either the writer or requestor process.
If this is the case, the service which runs the Windows Scheduled Task must have NT AUTHORITY\Network Service
permissions or be using the SYSTEM account to run the task. VSS operations are performed as NT AUTHORITY\Network
Service which is not granted COM access by default on the service assigned to Windows Scheduled Tasks.

The following procedure is only required if the windows scheduled task is using the Network Services account.
The correct permissions can be assigned by using the Component Services application, accessed by running
dcomcnfg.exe, in the windows guest.

To set COM permissions for VSS when “Access Denied” errors are received:
1. Run dcomcnfg.exe.
The Component Services dialog is displayed.
2. Expand the Component Services node to My Computer and right-click to access the Properties menu.
The My Computer Properties dialog is displayed.
3. Select the COM Security tab and click Edit Limits under Access Permissions.
4. Add the NETWORK SERVICE local access.

5. Click OK and verify that the user is now in the Access Permission list.

Ensuring Application Consistency – Checkpoints 93

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing VPGs

6. Click OK to commit these changes.

Access Denied messages should no longer be written in the event viewer for VSS. Additionally, you can grant Network
Service full control over HKLM\SYSTEM\CurrentControlSet\Services\VSS\Diag. You can also check this key
HKLM\SYSTEM\CurrentControlSet\Services\VSS\VssAccessControl which should at least contain the DWORD NT
Authority\NetworkService set to value 1.
You may also add a new DWORD like DOMAIN\MyZertoServiceUserAccount and set its value to 1.
During recovery you can recover to the VSS checkpoint, ensuring both application consistency and that the data is
crash-consistent for this virtual machine. For details, refer to “To test failover:” on page 125 and “To initiate a failover:”, on
page 148.

Changing the Zerto Virtual Manager Used by the ZertoVssAgent

When you install the ZertoVssAgent, you specify the Zerto Virtual Manager to use to manage the addition of checkpoints for
the virtual machines that uses VSS and that you want to protect in VPGs. You can change the IP and port of the VPG that you
specified during the installation either by rerunning the installation and selecting the Repair ZertoVssAgent option or by
editing IP and port values in the ZertoVssAgentGUI.exe.conf file in the folder where the ZertoVssAgent is installed.

Running Scripts Before or After Recovering a VPG

Before and after executing a failover, move, or test failover, you can run executable scripts, such as Windows .bat files or
PowerShell scripts. A pre-recovery script is always run at the beginning of the recovery operation. A post-recovery script is run
after all the virtual machines are powered on at the recovery site.
The scripts must be saved to the machine where the remote Zerto Virtual Manager (ZVM) is installed.
Both pre-recovery and post-recovery scripts are run by the ZVM service on the ZVM machine. The account running the ZVM
service is the account that will run the scripts when they are executed.
The scripts can include environment variables that can be included as part of the script itself, or passed to the script as
parameters. When the script is passed an environment variable as a parameter, the variable is evaluated before executing the
script. The following environment variables are available:
%ZertoVPGName% – The name of the VPG. If the name includes a space, enclose the variable in double quotes (”). For example,
the VPG MyVPG uses the format %ZertoVPGName% but the VPG My VPG uses the format “%ZertoVPGName%”.
%ZertoOperation% – The operation being run: FailoverBeforeCommit, FailoverRollback, Test, MoveBeforeCommit,
MoveRollback. Use the result returned for this variable to limit when the script runs, dependent on the operation. The scripts
are run after all the virtual machines are powered on at the recovery site and the variable is set to FailoverBeforeCommit or
MoveBeforeCommit. Use FailoverRollback or MoveRollback when rolling back the Failover or Move operation, to undo
whatever changes a previous script has done (such as updating the DNS records).

Running Scripts Before or After Recovering a VPG 94

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing VPGs

%ZertoHypervisorManagerIP% – The IP address of the hypervisor manager, VMware vCenter Server or Microsoft SCVMM,
where the VPG is recovered.
%ZertoHypervisorManagerPort% – The port used by the Zerto Virtual Manager to communicate with the hypervisor
manager, VMware vCenter Server or Microsoft SCVMM.
%ZertoForce% – A Boolean value, Yes/No, that dictates whether to abort the recovery operation if the script fails. For
example, whether to rollback a Move operation when the script fails and returns a non-zero value.
For example, if a specific VPG should not be migrated, the pre-recovery script can determine whether to continue based on the
values of the %ZertoOperation% and %ZertoVPGName%.
When specifying scripts in the definition of a VPG, enter values for the Pre-recovery Script and Post-recovery Script:

Command to run – The full path of the script to run. The script must be located on the same machine as the Zerto Virtual
Manager for the recovery site.
Params – The values of any parameters to pass to the script. Separate parameters with a space.
Timeout (sec) – The time-out in seconds for the script to run. If the script runs before executing a failover, move, or test
failover and the script fails or a timeout value is reached, an alert is generated and the failover, move, or test failover is not
performed. If the script runs after executing a failover, move, or test failover and the timeout value is reached, an alert is
generated. The default timeout value is specified in the Site Configuration Advanced Settings dialog.

Creating a Script
There are many ways to create scripts to run before or after recovering a VPG. The following procedure uses a Windows
PowerShell file (.ps1) or a batch (.bat) file.

To create a script:
1. Create a file on the machine where the Zerto Virtual Manager that manages the recovery is installed.
2. Enter the script that you want to run in the file.
3. Save the file as a Windows PowerShell file (.ps1) or batch (.bat) file.

Running Scripts Before or After Recovering a VPG 95

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing VPGs

When writing a PowerShell script, you can include the environment variables in the script. For example, the following code
snippet shows the use of the %ZertoOperation% and %ZertoVPGName% environment variables:
$Operation = $env:ZertoOperation
$VPG = $env:ZertoVPGName
$time = Get-Date

if ($Operation -eq "Test") {

"$time VPG: $VPG was tested." >> "C:\ZertoScripts\VPG_DR.txt"
}

if ($Operation -eq "FailoverBeforeCommit") {

"$time Failover before commit was performed. VPG: $VPG" >> "C:\ZertoScripts\VPG_DR.txt"
}

if ($Operation -eq "MoveBeforeCommit"){

"$time Move before commit was performed. VPG: $VPG" >> "C:\ZertoScripts\VPG_DR.txt"
}
Pre-recovery scripts must be saved on the protected site Zerto Virtual Manager machine. Post-recovery scripts must be
saved on the recovery site Zerto Virtual Manager machine.
Note: Zerto recommends having both pre- and post-recovery scripts, available on both the protected and recovery Zerto
Virtual Manager machines, so that they will work from the protected site.
4. Update Command to run and Params fields for all the VPG definitions that you want to run the script.
Passing parameters is implemented differently for the two script types. For information about passing command line
parameters, refer to the relevant PowerShell or batch file documentation.

Using a BAT File

Windows Batch (.bat) is an executable file that does not require anything in order to run. Update Command to run and
Params fields for all the VPG definitions that you want to run the script.
Command to run – <script_including_path>
C:\ZertoScripts\PostScript.bat
Use quotes (“) around the path if it includes spaces. The bat file is an executable file and is therefore included in the
Command to run field.
Params – <Zerto_Params>, for example:
%ZertoOperation% %ZertoVPGName%

Using a PowerShell Script

Windows PowerShell scripts require Windows PowerShell (.exe) to execute. To specify a PowerShell script, update
Command to run and Params fields for all the VPG definitions that you want to run the script.
Command to run – powershell.exe
Params – <script_including_path> <Zerto_Params>, for example:
C:\ZertoScripts\PostScript.ps1 %ZertoOperation% %ZertoVPGName%
Use quotes (“) around the path if it includes spaces.
Note: You might have to set the remote signed execution policy. For example, using the following:
##PowerCLI requires remote signed execution policy - if this is not enabled,
##it may be enabled here by uncommenting the line below.

##Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Force

Note: Zerto recommends testing both PowerShell and batch scripts by running them from the command line, to ensure that
they run correctly.

Running Scripts Before or After Recovering a VPG 96

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing VPGs

Example Scripts
The following script is an example of how to track failover tests.
The following script, c:\ZertoScripts\TestedVPGs.bat, writes the VPG name and date to the
ListOfTestedVPGs.txt file every time a failover test is run:
SET isodt=%date:~10,4%-%date:~7,2%-%date:~4,2% %time:~0,2%-%time:~3,2%-%time:~6,2%
IF %1==Test ECHO %2 %isodt% >> c:\ZertoScripts\Results\TestedVPGs.txt

Where %1 is the first parameter in the list of parameters, %ZertoOperation%, and %2 is the second parameter in the list of
parameters, %ZertoVPGName%.
Note: If the file TestedVPGs.txt does not exist it is created, as long as the folder, c:\ZertoScripts\Results, exists.

Exporting and Importing VPG Definitions

You can save VPG definitions to an external file and import these definitions back to Zerto Virtual Replication, for example,
exporting the settings before uninstalling a version of Zerto Virtual Replication and importing the settings after reinstalling
Zerto Virtual Replication.
Note: Zerto Virtual Replication regularly exports settings to the Zerto_Installation_Folder\Zerto Virtual
Replication\ExportedSettings folder. You can use one of these exported files instead of creating a new export file. The
default location of Zerto_Installation_Folder is C:\Program Files\Zerto.

To export VPG settings:

1. Open the Zerto Diagnostics application. For example, via Start > Programs > Zerto Virtual Replication > Zerto Diagnostics.
The Zerto Virtual Replication Diagnostics menu dialog is displayed.

2. Select the Export Protection Group Settings option and click Next.

3. Select the destination for the file to contain exported settings and specify the Zerto Virtual Manager IP address and port
where the VPGs are protecting virtual machines.
4. Click Next.

Exporting and Importing VPG Definitions 97

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing VPGs

The list of exported VPGs is displayed.

5. Click Done.
Note: If you are uninstalling Zerto Virtual Replication, the VPGs are deleted.

To import VPG settings:

1. Click Start > Programs > Zerto Virtual Replication > Zerto Diagnostics.
The Zerto Virtual Replication Diagnostics menu dialog is displayed.
2. Select the Import Protection Group Settings option.
3. Click Next.

4. Select the file previously exported and enter the Zerto Virtual Manager IP address and port specified when exporting the
VPGs.
5. Click Next.
The list of exported VPGs is displayed.

6. Select the VPGs to import. Only VPGs with names that are not already defined can be imported. VPGs in the import files
with the same name as an existing VPG are disabled.
7. Click Next.
The list of imported VPGs is displayed. If the VPG could not be imported, the reason for the failure is specified.
Note: If a host was removed from and then re-added to the environment it is advisable to wait approximately 5 minutes
from when the host was re-added before performing the import of the VPGs.
8. Click Done.

VPG Statuses and Synchronization Triggers

During normal operations the VPG status can change. For example, a change can be made to the VPG definition, or an
operation such as move or failover is performed on the VPG, or an external event impacts the system such as the WAN going
down. When the status changes, resulting in the VPG being synchronized, for example with a Delta Sync, the estimated time

VPG Statuses and Synchronization Triggers 98

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing VPGs

to complete the synchronization is displayed under the VPG status, and if relevant, the synchronization trigger, such as
Network Congestion.

VPG Statuses
The following statuses are displayed:
STATUS SUBSTATUS COMMENT

Deleting Deleting the VPG

VPG waiting to be removed

Failing Over Committing Failover The VPG is being failed over.

Failing over – Before commit A VPG being failed over is in the initial stage, before
committing the failover.

Rolling back Failover The failover is being rolled back to prior to the failover.

History Not Meeting SLA See Not Meeting SLA, below. The VPG is meeting the RPO SLA setting.

Initializing Creating VPG

Initial Sync

Syncing

disk Initial Sync

Meeting SLA Bitmap Syncing

Delta Syncing (When Force Sync is

applied)

Recovery is Possible After a rollback.

Moving Committing Move

Moving – Before commit

Promoting

Rolling back Move

VPG Statuses and Synchronization Triggers 99

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing VPGs

STATUS SUBSTATUS COMMENT

Not Meeting SLA Delta Sync (When Force Sync is not This status means that the VPG is not meeting the
applied) journal history nor RPO SLA settings.

Delta Syncing a disk

Error

Needs configuration

Site disconnection

Site disconnection. No checkpoints

VM not protected

VPG has no VMs

RPO Not Meeting SLA See Not Meeting SLA, above. The VPG is meeting the journal history SLA setting.

The following provides a full description of the sub-statuses are displayed:

SUBSTATUS DESCRIPTION

Bitmap Syncing In Azure, standard replication is achieved by a blob level mechanism which tracks changes in the
data volumes of protected virtual machines. When the VRA at the Azure site detects a list of
changed blocks, a bitmap that is saved persistently in the Azure block blob storage is updated.
The bitmap contains references to the areas of the protected disk that have changed but not the
actual I/Os.The bitmap is small and scales dynamically in correlation to the size of the changed
data.

Committing Failover Failing over the VPG.

Committing Move Completing the move, including removing the protected virtual machines.

Creating VPG The VPG is being created based on the saved definition.

Deleting the VPG Deleting the VPG.

Delta Syncing The Delta Sync uses a checksum comparison to minimize the use of network instances. A Delta
Sync is used when the protected virtual machine disks and the recovery disks should already be
synchronized, except for a possible few changes to the protected disks, for example:
■ After a VRA on the protected site was upgrade.
■ A Force Sync operation was manually initiated on the VPG.
■ A host protecting virtual machines was restarted and the protected virtual machines on the
host had not been moved to other hosts in the cluster or a protected virtual machine was
moved to another host without a VRA, and then moved back to the original host.
For synchronization to work, the protected virtual machines must be powered on so that the VRA
has an active IO stack, which is only available when the virtual machine is powered on.
During the synchronization, new checkpoints are not added to the journal but recovery operations
are still possible, assuming there are valid checkpoints in the journal. If a disaster occurs requiring
a failover during a delta synchronization, you can recover to the last checkpoint written to the
journal.
Synchronization after a recovery starts after the promotion of data from the journal to the virtual
machine disks ends. Thus, synchronization of virtual machines can start at different times,
dependent on when the promotion for the virtual machine ends. All synchronizations are done in
parallel, whether a delta sync or full sync, etc.

VPG Statuses and Synchronization Triggers 100

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing VPGs

SUBSTATUS DESCRIPTION

Delta syncing a disk Synchronization when only delta changes for a disk needs synchronizing.
For synchronization to work, the protected virtual machines must be powered on so that the VRA
has an active IO stack, which is only available when the virtual machine is powered on.
During the synchronization, new checkpoints are not added to the journal but recovery operations
are still possible, assuming there are valid checkpoints in the journal. If a disaster occurs requiring
a failover during a delta disk synchronization, you can recover to the last checkpoint written to the
journal.
Synchronization after a recovery starts after the promotion of data from the journal to the virtual
machine disks ends. Thus, synchronization of virtual machines can start at different times,
dependent on when the promotion for the virtual machine ends. All synchronizations are done in
parallel, whether a delta sync or full sync, etc.

Error Problem situation, for example, when a ZVM is disconnected from a VRA used to protect virtual
machines. The VPG cannot be recovered until the problem is resolved,

Failing over - Before Preparing and checking the VPG virtual machines in the recovery site.
commit

Full Syncing Full synchronization to ensure that the protected disks and recovery disks are the same after
some change to the system. This type of sync is the same as an Initial Sync but occurs after
protection started. In general, this type of sync should not happen.
For synchronization to work, the protected virtual machines must be powered on so that the VRA
has an active IO stack, which is only available when the virtual machine is powered on.
During the synchronization, new checkpoints are not added to the journal. Also, recovery
operations are not possible.
Synchronization after a recovery starts after the promotion of data from the journal to the virtual
machine disks ends. Thus, synchronization of virtual machines can start at different times,
dependent on when the promotion for the virtual machine ends. All synchronizations are done in
parallel, whether a delta sync or full sync, etc.

Full syncing a disk Synchronization when a full synchronization is required on a single disk.
For synchronization to work, the protected virtual machines must be powered on so that the VRA
has an active IO stack, which is only available when the virtual machine is powered on.
During the synchronization, new checkpoints are not added to the journal. Also, recovery
operations are not possible.
Synchronization after a recovery starts after the promotion of data from the journal to the virtual
machine disks ends. Thus, synchronization of virtual machines can start at different times,
dependent on when the promotion for the virtual machine ends. All synchronizations are done in
parallel, whether a delta sync or full sync, etc.

VPG Statuses and Synchronization Triggers 101

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing VPGs

SUBSTATUS DESCRIPTION

Initial Sync Synchronization performed after creating the VPG to ensure that the protected disks and
recovery disks are the same. Recovery operations cannot occur until after the initial
synchronization has completed.
For synchronization to work, the protected virtual machines must be powered on so that the VRA
has an active IO stack, which is only available when the virtual machine is powered on.
Adding a virtual machine to a VPG is equivalent to creating a new VPG and an initial
synchronization is performed. In this case, any checkpoints in the journal become unusable and
only new checkpoints added after the initial synchronization completes can be used in a recovery.
The data in the journal however remains and is promoted to the recovered virtual machine as part
of a recovery procedure.
Synchronization after a recovery starts after the promotion of data from the journal to the virtual
machine disks ends. Thus, synchronization of virtual machines can start at different times,
dependent on when the promotion for the virtual machine ends. All synchronizations are done in
parallel, whether a delta sync or full sync, etc.

Journal storage error There was an I/O error to the journal. For example, if the journal was full and the size was
increased. Once the problem is resolved a synchronization is required.

Moving - Before commit Preparing and checking the VPG virtual machines in the recovery site.

Needs Configuration One or more configuration settings are missing.

Promoting Updating recovered virtual machines in the VPG with data from the journal.

Recovery is possible Communication with the Zerto Virtual Manager at the protected site is down so continuing
protection is halted, but recovery on the remote site is available.

Recovery storage error There was an I/O error to the recovery storage. For example, the storage is almost full or the
virtual machines are turned off and the recovery disks are inaccessible.

Recovery storage profile The storage profile in the recovery site specified to be used by the VPG cannot be found.
error

Rolling back Rolling back to an initial status, for example, after canceling a cloning operation on the VPG.

Rolling back Failover Rolling back a Failover operation before committing it.

Rolling back Move Rolling back a Move operation before committing it.

Site disconnection Communication with the Zerto Virtual Manager at the remote, recovery, site is down so
continuing protection is halted.

Site disconnection. No Communication with the Zerto Virtual Manager at the remote, recovery, site is down and there
checkpoints are no checkpoints to use to recover the VPG at the recovery site.

Syncing Status while type of synchronization is being evaluated.

User paused protection Protection is paused to enable solving a Journal disk space problem, for example, by increasing
the disk size or cloning the VPG.

VPG Statuses and Synchronization Triggers 102

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing VPGs

SUBSTATUS DESCRIPTION

Disk Initial Sync Synchronization when a full synchronization is required on a single disk, for example, when
changing the target storage or adding a virtual machine to the VPG.
For synchronization to work, the protected virtual machines must be powered on so that the VRA
has an active IO stack, which is only available when the virtual machine is powered on.
During synchronization, new checkpoints are not added to the journal. Also, recovery operations
are not possible during a disk Initial Sync.
Synchronization after a recovery starts after the promotion of data from the journal to the virtual
machine disks ends. Thus, synchronization of virtual machines can start at different times,
dependent on when the promotion for the virtual machine ends. All synchronizations are done in
parallel, whether a delta sync or full sync, etc.

VPG has no VMs A configured VPG where the virtual machines have been removed from it, for example when
changing both the storage and host for the virtual machines in the VPG, causes the VPG to be
recreated.

VPG waiting to be An attempt to remove the VPG failed and it must be forcibly removed. For details, see “Deleting a
removed VPG When the Status is Deleting”, on page 86.

Zerto Virtual Manager Protection is paused to enable solving a Journal disk space problem, for example, by increasing
paused protection the disk size or cloning the VPG.

VPG Synchronization Triggers

The following synchronization triggers can be applied:
TRIGGER DESCRIPTION

Force Sync The user requested to synchronize the VPG, as described in “Forcing the Synchronization of a
VPG”, on page 85.

Network Congestion The network bandwidth is not wide enough to handle all the data, causing some of the data to
be backed up.

Recovery or Journal Storage There was an I/O error either to the recovery storage or journal, for example if the journal
Error was full and the size was increased. Once the problem is resolved a synchronization is
required.

Recovery Storage Congestion The recovery storage is being written to a lot, causing a delay for some of the data passed
from the protected site to be written to disk.

Recovery VRA Communication A network error, such as the network being down for a period, requires a synchronization of
Problem the VPG between the two sites, for example a bitmap sync.

VPG Configuration Changed The configuration of the VPG changed resulting in a synchronization being required. For
example, the size of the journal was changed.

VPG Statuses and Synchronization Triggers 103

 CHAPTER 8: MANAGING A ZERTO
VIRTUAL MANAGER

The Zerto Virtual Manager runs as a Windows service and connects to Zerto Virtual Replication components, such as the VRA.
The following topics are described in this section:
■ “Check Connectivity Between Zerto Virtual Replication Components”, below
■ “Reconfiguring the Zerto Virtual Manager Setup” on page 105
■ “Reconfiguring the Microsoft SQL Server Database Used by the Zerto Virtual Manager”, on page 110
■ “Pair to Another Site and Unpairing Sites”, on page 110

Check Connectivity Between Zerto Virtual Replication Components

If you think that there are connectivity problems to or from a Zerto Virtual Manager, you can use the Zerto diagnostics utility to
check the connectivity.

To check connectivity between Zerto Virtual Manager components:

1. Open the Zerto Diagnostics application. For example, via Start > Programs > Zerto Virtual Replication > Zerto Diagnostics.
The Zerto Virtual Replication Diagnostics menu dialog is displayed.

2. Select the Test Connectivity to Zerto Virtual Replication components option and click Next.
The IP Connectivity dialog is displayed.

You can use this dialog to check the following:

■ TCP communication between the Zerto Virtual Managers (ZVMs) on the protected and recovery sites. The default
port, specified during installation, is 9081.
■ Communication between VRAs on the protected and recovery sites, via the control port and the data port.
3. Select the connectivity you want to test and in the case of the Zerto Virtual Manager (ZVM), specify the TCP
communication port specified during the installation, if the default port, 9081, was changed.
4. Specify the type of test to perform:
Server – Test for incoming communication.
Client – Test for outgoing communication. Specify the IP address of the receiving Zerto Virtual Manager.

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing a Zerto Virtual Manager 104
Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing a Zerto Virtual Manager

5. Click Next to test the specified connectivity.

The Server option listens for communication from a paired VRA. Stop listening by clicking Stop.

The Client options tests the client; on completion a result dialog is displayed.
6. Click Stop (server test) or OK (client test) to return to the Zerto Virtual Replication Diagnostics dialog.

Reconfiguring the Zerto Virtual Manager Setup

When installing Zerto Cloud Appliance, you provide the IP address of the machine on which you are installing it. This is where
the Zerto Virtual Manager runs and displays the Zerto User Interface.
You can change this IP address if necessary, using the Zerto Virtual Replication Diagnostics utility.

To reconfigure the Zerto Virtual Manager:

1. Click Start > Programs > Zerto Virtual Replication > Zerto Diagnostics.
The Zerto Virtual Replication Diagnostics menu dialog is displayed.

2. Select Reconfigure Zerto Manager and click Next

Reconfiguring the Zerto Virtual Manager Setup 105

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing a Zerto Virtual Manager

The Azure Authentication dialog is displayed.

3. Click AUTHENTICATE.
The Microsoft Azure authentication page is displayed. The Azure Authentication dialog remains active.

4. Specify the following:

■ The email or phone number of the account who is the Azure subscription User Access Administrator.
For instruction on how to add a user as a subscription User Access Administrator, see https://azure.microsoft.com/
en-us/documentation/articles/role-based-access-built-in-roles/.
■ The password of the account.
Zerto automatically detects the region in which the ZCA is installed.
5. Click Sign in.

Reconfiguring the Zerto Virtual Manager Setup 106

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing a Zerto Virtual Manager

The Azure Authentication dialog is displayed with fields populated by the Azure authentication.

6. From the dropdown list, select the Subscription.

7. Click NEXT.
The Connectivity dialog is displayed.

8. Select the IP Address of the machine on which you are installing the Zerto Cloud Appliance. The protected site accesses
the Azure site through VPN using this IP.
9. Click NEXT.

Reconfiguring the Zerto Virtual Manager Setup 107

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing a Zerto Virtual Manager

The ZVM Site Details dialog is displayed.

10. Enter the site details:

Site Name – A name to identify the site. This name is displayed in the Zerto User Interface. This field is mandatory.
Location – Information such as the address or name of the site to identify it. Optional.
Contact Information – The name of the person to contact if a need arises. Optional.
Contact Email – The email address to contact if a need arises. Optional.
Contact Phone – The phone number to contact if a need arises. Optional.
11. Click NEXT.
The ZVM Communication dialog is displayed.

HTTP Port (ZVM) – The port used for inbound communication between the Zerto Virtual Manager and Zerto internal
APIs, Cmdlets and a VSS Agent.
HTTPS Port (clients <->ZVM) – The port used for inbound communication between the Zerto User Interface and the
Zerto Virtual Manager.

Reconfiguring the Zerto Virtual Manager Setup 108

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing a Zerto Virtual Manager

TCP Port (ZVM <-> ZVMs) – The port used for communication between Zerto Virtual Managers. If you change the value,
when pairing sites, use the TCP port value you specify here. Pairing the sites is described in “Pairing an Azure Site”, on
page 20.
TCP Port (ZVM -> VBA) – The port used for communication between the Zerto Virtual Manager and the Virtual Backup
Appliance.
12. Click NEXT.
The Online Services and Zerto Mobile Application dialog is displayed.

13. Click NEXT.

14. Click RUN

The installation checks that the installation can proceed successfully.
If you changed the IP address of the Zerto Virtual Manager, you must unpair the Azure and protected sites, and then pair the
sites again.

Reconfiguring the Zerto Virtual Manager Setup 109

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing a Zerto Virtual Manager

Reconfiguring the Microsoft SQL Server Database Used by the Zerto Virtual Manager
When installing Zerto Virtual Replication, you can specify a Microsoft SQL Server database to use by the Zerto Virtual
Manager. If the access to this database changes, you can change the access in the Zerto Virtual Manager.

To reconfigure the access to the Zerto Virtual Manager database:

1. Click Start > Programs > Zerto Virtual Replication > Zerto Diagnostics.
The Zerto Virtual Replication Diagnostics menu dialog is displayed.

2. Select the Change SQL Server Credentials option and click Next.
The installation settings for the SQL Server are displayed. Change the IP and username and password if necessary.

Server Name – The domain name and server resource to connect to, with the format <server_name>\<instance_name>
or <Server_IP>\<instance_name>.
Specify either of the following authentication options:
Windows Authentication – Use Windows authentication. This option is only enabled if a specific service user account was
specified in the previous Service User dialog, in which case the service account name and password are used.
SQL Server Authentication – Use SQL Server authentication.
User Name – The user name for SQL Server database.
Password – A valid password for the given user name.
3. Click Next to the end of the wizard and then click Finish.
The Zerto Virtual Manager service is restarted using the new credentials.

Pair to Another Site and Unpairing Sites

See the following sections:
■ “Pair to Another Site”, below
■ “Unpairing Sites”, on page 111

Reconfiguring the Microsoft SQL Server Database Used by the Zerto Virtual Manager 110
Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing a Zerto Virtual Manager

Pair to Another Site

You can pair to any site where Zerto Virtual Replication is installed.

To pair to a site:
1. In the Zerto User Interface, in the SITES tab click PAIR.
The Add Site dialog is displayed.

2. Specify the following:

Remote Site ZVM IP Address: IP address or host name of the remote site Zerto Virtual Manager to pair to.
Port: The TCP port communication between the sites. Enter the port that was specified during the installation. The default
port during the installation was 9081.
3. Click PAIR.
The sites are paired, meaning that the Zerto Virtual Manager for the local hypervisor site is connected to the Zerto Virtual
Manager at the remote hypervisor site.

Unpairing Sites
You can unpair any two sites that are paired to each other.
IMPORTANT: if there is a VPG on either of the sites you are unpairing, the VPGs will be deleted.

To unpair two sites:

1. In the Zerto User Interface, in the SITES tab, select the site which you want to unpair.
2. Click UNPAIR.
A message appears warning the user that the sites are about to unpair.
If there are either protected or recovered VPGs on the paired sites, a message appears warning the user that the VPGs will
be deleted.
3. To unpair, click CONTINUE.
The sites are no longer paired. If there are VPGs on either site, they are deleted.

Pair to Another Site and Unpairing Sites 111

 CHAPTER 9: OVERVIEW OF
DISASTER RECOVERY OPERATIONS

Zerto Virtual Replication provides a number of operations to recover virtual machines at the remote site. This section describes
these operations. The following topics are described in this section:
■ “The Failover Test Operation”, below
■ “The Move Operation”, on page 113
■ “The Failover Operation”, on page 114
■ “The Restore File Operation”, on page 115
■ “The Clone Operation”, on page 115

The Failover Test Operation

Use the Failover Test operation to test that during recovery the virtual machines are correctly replicated in Microsoft Azure.
The Failover Test operation creates test virtual machines in a sandbox, using the test network specified in the VPG definition,
as opposed to a production network, to a specified point-in-time, using the recovery disks and journal in the storage account,
managed by the VRA. For more information see “Testing Recovery”, on page 124.
During the test, any changes to the protected virtual machines at the protected site are sent to Azure and new checkpoints
continue to be generated, since replication of the protected machines continues throughout the test. You can also add your
own checkpoints during the test period.
The following diagram shows the positioning of the virtual machines before and during a Failover test operation.

Before Failover Test

During Failover Test

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Overview of Disaster Recovery Operations 112
Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Overview of Disaster Recovery Operations

The Move Operation

Use the Move operation to transfer protected virtual machines from the protected site to Azure in a planned migration.
When you perform a planned migration of the virtual machines to Azure, Zerto Virtual Replication assumes that both sites are
healthy and that you planned to relocate the virtual machines in an orderly fashion. For details, see “Migrating a VPG to Azure”,
on page 132.
The following diagram shows the positioning of the virtual machines before and after the completion of a Move operation.

Before Move

Move: After Commit - With Reverse Protection

Move: After Commit - No Reverse Protection

Move: After Commit - Keep source VM, No Reverse Protection

The Move Operation 113

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Overview of Disaster Recovery Operations

The Failover Operation

Following a disaster, use the Failover operation to recover protected virtual machines to Azure. A failover assumes that
connectivity between the sites might be down, and thus the protected virtual machines and disks are not removed, as they are
in a planned Move operation.
When you set up a failover you always specify a checkpoint to which you want to recover the virtual machines. When you
select a checkpoint – either the last auto-generated checkpoint, an earlier checkpoint, or a user-defined checkpoint – Zerto
Virtual Replication makes sure that virtual machines in Azure are recovered to this specified point-in-time. For details, see
“Managing Failover”, on page 147.
Note: To identify the checkpoint to use, you can perform a number of test failovers, each to a different checkpoint.
The following diagram shows the positioning of the virtual machines before and after the completion of a Failover operation.

Before Failover

Failover - Protected Site Down

Failover - Protected Site Up, No Reverse Protection

Note: The Failover operation without reverse protection does not remove the VPG definition but leaves it in a Needs
Configuration state.

The Failover Operation 114

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Overview of Disaster Recovery Operations

Failover - Protected Site Up, With Reverse Protection

The Restore File Operation

Use the Restore File operation to recover individual files and folders from the recovery site.
You can recover specific files and folders from the recovery site for virtual machines that are being protected by Zerto Virtual
Replication and running Windows operating systems. You can recover the files and folders from a specific point-in-time. For
details, see “Recovering Files and Folders”, on page 151.

The Clone Operation

Use the Clone operation to create a copy of the VPG virtual machines on the recovery site in the production network. The virtual
machines on the protected site remain protected and live.
Note: When the recovery site is vCD, the clone is created in vCenter Server and the virtual machines have to be manually
imported into vCD.
You might want to create a clone if you need to have a copy of the virtual machines saved to a specific point-in-time, for
example, when the VPG enters a Replication Paused state, or when testing the VPG in a live DR test. For details, see “Cloning a
VPG to Azure”, on page 97.
The cloned machines are named the after the protected virtual machine name along with the timestamp of the checkpoint used
for the clone. The cloned virtual machines are not powered on.
The following diagram shows the positioning of the virtual machines before and after the completion of a Clone operation.

Before Clone

The Restore File Operation 115

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Overview of Disaster Recovery Operations

After Clone

The Clone Operation 116

 CHAPTER 10: ADVANCED SITE
CONFIGURATION

There are a number of configuration tasks that you can perform, some of which should be done as part of the initial site
configuration.
The following topics are described in this section:
■ “Site Settings”, below
■ “Seeing What is Licensed”, on page 122
■ “About the Zerto Virtual Replication Version”, on page 123

Site Settings
The Site Settings dialog enables configuring various site settings. These include the maximum bandwidth that Zerto Virtual
Replication uses between the protected and recovery sites, default script timeout, and protection policies such as the commit
policy for a failover or move operation.

To specify site settings:

1. In the Zerto User Interface, in the top right of the header click SETTING ( ) and select Site Settings.
The Site Settings dialog is displayed.

2. Make any required changes to the settings, click SAVE and then APPLY. The following settings can be defined:
■ “Editing Information About a Site”, below
■ “Defining Site Policies”, on page 119

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Advanced Site Configuration 117
Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Advanced Site Configuration

■ “Configuring Email Settings”, on page 120

■ “Defining the Resource Report Sampling Period”, on page 121
Licensing is described in “Seeing What is Licensed”, on page 122.

Editing Information About a Site

You provide information about the site during installation, to make it easier to identify the site in the in the user interface and to
identify the contact person at the site. After installation you can updated these settings.
In the Zerto User Interface, site information is displayed at the top of the display.

To update information about the local site:

1. In the Zerto User Interface, click SETTING ( ) in the top right of the header and select Site Settings.
The Site Settings dialog is displayed.

2. Define general information about the site.

Site Name – The name used to identify the site. Mandatory.
Site Location – Information such as the address of the site or a significant name to identify it. Mandatory.
Contact Name – The name of the person to contact if a need arises. Mandatory.
Contact Email – An email address to use if a need arises.
Contact Phone – A phone number to use if a need arises.
3. If the credentials to access Microsoft Azure from the Zerto Virtual Manager change, specify the new credentials:
Access Name – The name used to access Azure.
Client ID – A unique identifier that is associated with the access name.

Site Settings 118

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Advanced Site Configuration

Subscription – The subscription associated with the user.

Resource Name – The name of the resource the user created.
Storage Account Name – The name of the storage account created for this site.
4. Click APPLY or SAVE.

Defining Site Policies

You can set default recovery and replication policies.

Configuring Disaster Recovery Policies

To configure disaster recovery policies:

1. Click Policies.

2. Choose the Failover/Move Commit Policy to use during a failover or move operation, described in “Initiating a
Failover”, on page 148 and “Moving Protected Virtual Machines to a Remote Site”, on page 133 respectively. The following
options are available:
None – The failover or move operation must be manually committed or rolled back by the user.
Commit – After the time specified in the Default Timeout field the failover or move operation is committed, unless
manually committed or rolled back by the user before the time-out value is reached. During the specified time you can
check the recovered VPG virtual machines.
Rollback – After the time specified in the Default Timeout field the failover or move operation is rolled back, unless
manually committed or rolled back by the user before the time-out value is reached. During the specified time you can
check the recovered VPG virtual machines.
The value set here applies as the default for all failover or move operations from this point on but can be changed when
defining a failover or move operation.
3. Specify the Default Timeout after which a Commit or Rollback commit policy is performed. A value of zero indicates
that the system will automatically perform the commit policy, without waiting for any user interaction.
4. Choose the series from which to select the type. Azure series are optimized for different types of applications.
5. Choose the virtual machine size, within the series, to assign to recovered instances. Different types within a series vary
primarily in vCPU, ECU, RAM, and local storage size. The price per series is directly related to the series size.
6. Choose the Replication Pause Time, which is the time to pause when the journal might have problems, resulting in the
loss of all checkpoints, for example, when the datastore for the journal is near to being full.
The replication pause time is the amount of time that the transfer of data from the protected site to the journal on the
recovery site is paused. This time can then be used by the administrator to resolve the issue, for example by cloning the
virtual machines in the VPG, described in “Cloning Protected Virtual Machines to the Remote Site”, on page 155. The value
set here is applied to existing and new VPGs.
7. Click APPLY or SAVE.

Site Settings 119

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Advanced Site Configuration

Configuring Email Settings

You can configure Zerto Virtual Replication alerts to be sent to an email address, so as to be better informed when an alert
occurs and backups are run.

Email Settings

To configure email settings:

1. Click Email Settings.

2. Specify the SMTP server Address. The Zerto Virtual Manager must be able to reach this address.
3. If the SMTP Server Port was changed from the default, 25, specify the port number.
4. Specify a valid email address for the email sender name in the Sender Account field.
5. Specify a valid email address where you want to send the email in the To field.
You can test that the email notification is set up correctly by clicking Send Test Email. A test email is sent to the email
address specified in the To field.
6. Click APPLY or SAVE.

Alerts and Reports

You can configure when to send alerts and backup reports.

To configure when to send emails about alerts and backups:

1. To send an email when an alert is issued, check Enable sending alerts.
2. To send an email with a backup report, check Enable backup reports.
3. Specify whether you want a backup report sent daily or weekly.
Daily – Send a daily backup report
Weekly – Send a weekly backup report. Select the day of the week from the dropdown list.
4. Specify day of the week and the time of day to send the backup report.
5. Click APPLY or SAVE.

Site Settings 120

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Advanced Site Configuration

Defining the Resource Report Sampling Period

Specify when you want to take resource samples to identify resource usage, either daily at a specific hour and minute or hourly
at a specific minute within each hour.

To configure report settings:

1. Click Reports.

2. Choose the Sampling Rate.

3. Choose the Sampling Time.
If you set the daily time to be 12:00, you will get a sample taken at noon every day. Collecting a sample hourly provides a
higher resolution picture of replication traffic than if collected daily.
4. Click APPLY or SAVE.
Information is saved for 90 days when the sampling period is hourly and for one year when the sampling period is daily.
These samples are used to generate resource reports as described in “Zerto Virtual Replication Reports”, on page 178.

Site Settings 121

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Advanced Site Configuration

Seeing What is Licensed

The Zerto license includes information such as the number of virtual machines that can be protected and the license expiry
date. You can see these details in the Site Settings > License dialog.

The license includes the following details:

License – The license key itself.
License ID – An identifier for the license.
License Type – What is licensed: whether the license restricts the number of virtual machines that can be protected or the
number of sockets used.
Expiry Date – The license expiry date.
Quantity – The maximum amount licensed, either virtual machines or sockets, based on the license type. If blank, the quantity
is unlimited.
Maximum Sites – The maximum number of sites allowed.
Usage – The sites using the license and number of protected virtual machines in each site.
A warning is generated when either the license expires or more than the licensed number of virtual machines are being
protected. Protection continues but the license should be updated. After getting a new license key you can update Zerto Virtual
Replication with this key.

To update a license key:

1. In the Zerto User Interface, in the top right of the header click SETTING ( ) and select Site Settings.
The Site Settings dialog is displayed.
2. Click License.
3. Enter a valid license key and click APPLY or SAVE.
The license is updated on the local site and the paired remote sites.

Seeing What is Licensed 122

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Advanced Site Configuration

About the Zerto Virtual Replication Version

You can see details about the version of Zerto Virtual Replication being run and specify whether the version can be
automatically updated when new VMware vSphere versions are released, without the need to upgrade to a later version of
Zerto Virtual Replication. This functionality is the Zerto CALLHOME feature. You can also enable or disable the Zerto Virtual
Manager to send data to the SaaS platform for monitoring purposes.

Enable Support notification and analytics – When selected, the CALLHOME feature is enabled, whereby analytics that are
sent to Zerto that are used to improve Zerto Virtual Replication. The CALLHOME also enables to automatically update Zerto
Virtual Replication when a new version of a hypervisor is released that is supported by Zerto.
Enable Online Services and Zerto Mobile – Allows licensed Zerto Virtual Manager users to enable or disable data being sent
from the Zerto Virtual Manager to the SaaS platform thereby enabling site monitoring using the Zerto Mobile App.

To see version information, prepare to send analytics to Zerto, or send data to the Cloud:
1. In the Zerto User Interface, in the top right of the header click SETTING ( ) and select Site Settings.
The Site Settings dialog is displayed.
2. Click About.
The version and build of Zerto Virtual Replication that are installed in the site are displayed.
3. If you want to send analytics to Zerto automatically, check Enable Support notification and analytics. This initiates the
CALLHOME feature. This information is used solely to improve Zerto Virtual Replication and to automatically update
Zerto Virtual Replication when a new version of a hypervisor is released that is supported by Zerto.
4. If you want Zerto Virtual Replication to send information to our Online Services and Zerto Mobile App, check Enable
Online Services and Zerto Mobile. This allows licensed Zerto Virtual Manager users to enable or disable data being sent
from the Zerto Virtual Manager to the SaaS platform, thereby enabling site monitoring using the Zerto Mobile App.
Note: The Enable Online Services and Zerto Mobile option is enabled by default.
If the Enable Online Services and Zerto Mobile option is enabled and the user un-checks the checkbox, the user
will receive a warning that unchecking Enable Online Services and Zerto Mobile Application will stop Zerto
Virtual Replication from sending information to Online Services and to the Zerto Mobile Application, rendering these
services inoperable for the entire installation.

About the Zerto Virtual Replication Version 123

 CHAPTER 11: TESTING RECOVERY

In order to verify that the disaster recovery that you have planned is the one that will be implemented, Zerto recommends
testing the recovery of the VPGs defined in the protected site to the recovery site. This section describes how to test VPG
recovery to Azure.
The following topics are described in this section:
■ “The Test Failover Process”, below
■ “Starting and Stopping Failover Tests”, on page 125
■ “Viewing Test Results”, on page 129
■ “Live Disaster Recovery Testing”, on page 129
Note: You cannot perform a failover test while a backup job is running.
Note: When testing recovery from Azure to on-premise sites, the Move operation is used, which assures VM level consistency.
To allow checking before committing or rolling back, specify an amount of time to check the recovered machines, in minutes,
before the automatic commit or rollback action is performed. During this time period, check that the new virtual machines are
OK and then commit the operation or roll it back. The maximum amount of time you can delay the commit or rollback
operation is 1440 minutes, which is 24 hours.
Checking that involves I/O is done on scratch volumes. The longer this period the more scratch volumes are used, until the
maximum size is reached, at which point no more checking can be done. The maximum size of all the scratch volumes is
determined by the journal size hard limit and cannot be changed. The scratch volumes reside on the storage defined for the
journal.
For more information see “The Move Process” on page 140.

The Test Failover Process

Use the Failover Test operation to test that during recovery the virtual machines are correctly replicated at the recovery site.
The Failover Test operation creates test virtual machines in a sandbox, using the test network specified in the VPG definition.
During the test, any changes to the protected virtual machines at the protected site are sent to the recovery site and new
checkpoints continue to be generated, since replication of the protected machines continues throughout the test. You can also
add your own checkpoints during the test period. You can initiate a failover during a test, as described in “Initiating a Failover
During a Test”, on page 154.
The Failover Test operation has the following basic steps:
■ Starting the test.
■ The test virtual machine are created in Azure and configured to the checkpoint specified for the recovery.
■ The new virtual machines are created in a sandbox and powered on, making them available for testing.
■ Testing.
■ Testing takes place in the sandbox that was created when the VPG was created.
■ The production environment is not affected for the duration of the test.
■ Replication of the protected machines continues, with new checkpoints being created.
■ Stopping the test.
■ The virtual machines in Azure are powered off and removed from the inventory.
■ The following tag is added to the checkpoint specified for the test: Tested at startDateAndTimeOfTest
The updated checkpoint can be used to identify the point-in-time to restore the virtual machines in the VPG during a
failover.
Testing that recovery is accomplished successfully should be done periodically so that you can verify that a failover will work.
Zerto also recommends testing all the VPGs being recovered to the same cluster together.

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Testing Recovery 124
Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Testing Recovery

When configuring a VPG, specify the period between tests for that VPG in the Test Reminder field in the REPLICATION step
of the Create VPG wizard.
■ When you create a virtual machine in Azure you are provided with a temporary volume automatically. This temporary
storage is D: on a Windows virtual machine and it is /dev/sdb1 on a Linux virtual machine.
■ Temporary volume size varies according to the instance size you have selected.
■ On Windows, the temporary volume will be using the next available drive letter.
For example: If you have two volumes connected to the protected virtual machine, Azure will use C and D, and allocate
E for the temporary volume drive.

The following conditions must exist before beginning the process:

■ For Windows machines, RDP on Windows must be enabled. For Linux machines, SSH or other remote access needs to be
Installed and enabled.
■ Firewall rules must be configured for remote access.
■ Network security group rules must be configured.

Starting and Stopping Failover Tests

You can test a single VPG or multiple VPGs to make sure that if an actual failover is needed, the failover will perform as
expected.
Note: You can initiate the failover test from either the protected site or recovery site.

To test failover:
1. In the Zerto User Interface set the operation to TEST and click FAILOVER.
The Failover Test wizard is displayed.

2. Select the VPGs to test. By default, all VPGs are listed.

At the bottom, the selection details show the amount of data and the total number of virtual machines selected.
The Direction arrow shows the direction of the process: from the protected site to the peer, recovery, site.
3. Click NEXT.

Starting and Stopping Failover Tests 125

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Testing Recovery

The EXECUTION PARAMETERS step is displayed.

You can select the checkpoint to use for the recovery and see if a boot order and scripts are defined for the VPG.
4. By default, the last checkpoint added to the journal is displayed. If you want to use this checkpoint, go to the next step If
you want to change the checkpoint, click the checkpoint.
The {VPG-Name}: Checkpoints dialog is displayed.

5. Select the checkpoint to use. Click the refresh button to refresh the list. You can choose from one of the following
checkpoints:
Latest – Recovery is to the latest checkpoint. This ensures that the data is crash-consistent for the recovery. When
selecting the latest checkpoint, the checkpoint used is the latest at this point. If a checkpoint is added between this point
and starting the failover, this later checkpoint is not used.
Latest Tagged Checkpoint – The recovery operation is to the latest checkpoint added in one of the following situations:
■ By a user.
■ When a failover test was previously performed on the VPG that includes the virtual machine.
■ When the virtual machine was added to an existing VPG after the added virtual machine was synchronized.

Starting and Stopping Failover Tests 126

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Testing Recovery

Latest VSS – When VSS is used, the clone is to the latest VSS snapshot, ensuring that the data is both crash-consistent and
application consistent to this point. The frequency of VSS snapshots determines how much data can be recovered. For
details about VSS checkpoints, see “Ensuring Application Consistency – Checkpoints”, on page 86.
If you do not want to use the latest checkpoint, latest tagged checkpoint, or latest VSS checkpoint, choose Select from
all available checkpoints. By default, this option displays all checkpoints in the system. You can choose to display
only automatic, VSS, or tagged checkpoints, or any combination of these types.
6. Click OK.
7. Click NEXT.
The FAILOVER TEST step is displayed. The topology will show the VPGs and the virtual machines that are about to be
tested.

8. To start the test, click START FAILOVER TEST.

Note: If any of the VPGs have at least one VM configured with a static IP, but the static IP is in use on the recovery site, a
warning message appears enabling you to choose whether to continue with a dynamic IP, or to cancel the failover process.
The test starts for the selected VPGs. The test begins with an initialization period during which the new virtual machines are
created in Azure. Zerto creates a new resource group for the VPG, and places the newly created virtual machines and their
NICs in this resource group.
The default instance size for new virtual machines is Standard_D1_v2. If Standard_D1_v2 instance size does not meet your
needs, you can change this value in the Policies tab of the Site Settings dialog. For more information, see “Configuring Disaster
Recovery Policies”, on page 119. You can also change the instance size of new virtual machines when you create or edit a VPG.
Note: By default, every Azure virtual machine is created with an additional temporary volume. This temporary volume is a local
SSD disk. The size of the SSD disk depends on the instance size of the virtual machine.
If you did not define a private IP for a virtual machine in the VPG definition, during recovery Azure sets the private IP from the
defined subnet range.

After Starting a Test, What Happens?

The virtual machines in the virtual protection group are created in Azure. In the Azure console, the new virtual machines
appear with their original names and the suffix testing recovery.
Note: Zerto adheres to Azure naming conventions. For information, see Zerto Virtual Replication for Microsoft Azure
Environments.

Starting and Stopping Failover Tests 127

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Testing Recovery

While a test is running:

■ The virtual machines in the VPGs continue to be protected.
■ You can add checkpoints to the VPGs, and if necessary fail over the VPGs, as described in “Initiating a Failover During a
Test”, on page 154.
■ You cannot move VPGs being tested.
■ You cannot initiate a failover while a test is being initialized or closed.
Monitor the status of a failover test by doing the following:
■ In the Zerto User Interface, click the VPGs tab. The Operation field in the GENERAL view displays Testing Failover
when a failover test is being performed.

■ In the Zerto User Interface, click the VPGs tab, and then click on the name of a VPG you are testing.
A dynamic tab is created displaying the specific VPG details including the status of the failover test.

To stop a failover test:

1. Click the Abort icon, in either the Dashboard or the dynamic tab, to stop the test in the specific VPG tab.

You can also stop the test via the TASKS popup dialog in the status bar, or by selecting MONITORING > TASKS.

Starting and Stopping Failover Tests 128

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Testing Recovery

The Stop Test dialog is displayed.

2. In the Result field specify whether the test succeeded or failed.

3. Optionally, in the Notes field, add a description of the test. For example, specify where external files that describe the tests
performed are saved. Notes are limited to 255 characters.
4. Click STOP.
After stopping a test, the following occurs:
■ Virtual machines in the recovery site are powered off and removed.
■ The resource group created for the operation is deleted.
■ The checkpoint that was used for the test has the following tag added to identify the test:
Tested at startDateAndTimeOfTest.
This checkpoint can be used to identify the point-in-time to use to restore the virtual machines in the VPG during a failover.
\

Viewing Test Results

After stopping a test, you can see the test results in Zerto Virtual Replication reports. For more information, see “Zerto Virtual
Replication Reports”, on page 178.

Live Disaster Recovery Testing

This section describes how to use the basic Zerto Virtual Replication recovery operations to perform live disaster recovery
tests, in different situations.
When performing a live DR test you need to consider the following:
■ The purpose of the live DR test: Do you only want to verify that the VMs can recover properly or do you want to conduct a
full DR test that will include running user traffic against the recovered VMs?
■ The length of time you want to test the recovery, a few hours or several days.
■ Whether the changes to the new virtual machines need to be retained after the test or can they be discarded?
■ Whether you are willing to accept temporary downtime of the application.
■ Whether you want to simulate an actual disaster at the protected site, for example by simulating a network outage or
bringing down the protected site.

Viewing Test Results 129

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Testing Recovery

The following flowchart shows the testing decision flow:

During any live test, Zerto recommends that you only maintain one working version of the same virtual machine. Thus, the first
step in any test, except for a Failover Test, is to make sure that the protected virtual machines are shut down before starting to
test recovered machines. During a Zerto Virtual Replication Move operation the first step Zerto Virtual Replication performs is
to shut down the protected machines, to ensure data integrity. However, a Zerto Virtual Replication Failover operation
assumes that the protected virtual machines are no longer accessible (the total site disaster scenario) and does not attempt to
shut them down at the beginning of the operation. In a live test using a Failover operation you have to manually shut down the
virtual machines to be tested at the beginning of the test in order to prevent potential split-brain situations where two instances
of the same applications are live at the same time.
If you want to perform a live DR test that includes a simulated disaster you can simulate the disaster, for example, by
disconnecting the network between the two sites. In this type of test, once the disaster is simulated a Move operation cannot
be used, since it requires both sites to be healthy, while a Failover operation can be used.

Basic Verification – User Traffic Is Not Run against the Recovered VMs
Basic testing that the virtual machines can recover is done using either a Failover Test operation or an uncommitted Move
operation, using the Rollback setting.

Using a Failover Test Operation

Use a Failover Test operation if recovering the virtual machines in a sandbox. Using the test network specified in the VPG
definition for network isolation, is sufficient for a test.

Procedure
The Failover Test operation is described in detail in “Starting and Stopping Failover Tests”, on page 125. The following
highlights specific steps to enable using the Failover Test when recovering the virtual machines in a sandbox.
1. Change the VPG Failover Test Network to the production network used at the recovery site.
2. Manually shut down the virtual machines in the VPG.
3. Insert a new checkpoint. This avoids potential data loss since the virtual machines are shut down and the new checkpoint
is added after all I/Os have been written to disk.
4. Optionally simulate a disaster, for example by disconnecting the two sites.
5. Perform a test failover on the VPG, choosing the checkpoint you added in step 3.

Live Disaster Recovery Testing 130

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Testing Recovery

6. Verify that the test machines are recovered as expected.

7. Run user traffic against the new virtual machine in Azure.
8. Stop the failover test.
9. Reconnect the sites.

Failover Test Considerations

■ You do not have to shut down the protected virtual machines, and changes from the test phase are not kept or applied to
the protected applications.
■ You can recover to a specific point-in-time.
■ You can use an isolated network to enable testing in a sandbox environment and not a live DR environment. This is the
recommended practice.
■ At the end of the test, you can power on the virtual machines in the protected site and continue to work without the need
to save or replicate back any data changed during the test.
You can also use a Failover Test operation if you want to simulate an actual disaster for around an hour or less and do not want
to save any changes on the recovery site.

Using an Uncommitted Move Operation

Use a Move operation with the commit/rollback policy set to rollback after the test period, if you need to test the recovery of
virtual machines in the recovery site production environment.

Procedure
The Move operation is described in detail in “Moving Protected Virtual Machines to a Remote Site”, on page 133. The following
procedure highlights specific steps to enable using the Move functionality for a DR test.
1. In the Move wizard, in the EXECUTION PARAMETERS tab, for commit policy, select None.
2. Either power off the relevant virtual machines or check the Force Shutdown checkbox, in the EXECUTION PARAMETERS
tab, to make sure that the virtual machines are shut down, if they cannot be powered off using Microsoft Integration
Services.
3. After testing the new virtual machines in the recovery site you can roll back the Move operation, which will return the
virtual machines to their pre-test state.

Move Considerations
■ Changes from the pre-commit phase are not kept or applied to the protected applications.
■ The new virtual machines are connected to the network for a full test of the environment.
■ The protected machines are turned off until the end of the test, ensuring that there are no conflicts between the protected
site and recovery site.
■ You can only recover to the last checkpoint written to the journal, at the start of the Move operation.

Live Disaster Recovery Testing 131

 CHAPTER 12: MIGRATING A VPG TO
AZURE

This section describes a planned migration of a virtual protection group - VPG - to Azure. The following topics are described in
this section:
■ “The Move Process”, below
■ “Moving Protected Virtual Machines to a Remote Site”, on page 133

The Move Process

Use the Move operation to move groups of protected virtual machines from a protected site to a recovery site in a planned
migration.

A move differs from a failover in that with a move you cannot select a checkpoint to restore the virtual machine to. Also, to
ensure data integrity, the protected virtual machines are powered off completely and a final checkpoint created so that there is
no data loss before the move is implemented.
You can initiate the Move operation from either the protected site or recovery site.
When you perform a planned migration of virtual machines to a recovery site, Zerto Virtual Replication assumes that both sites
are healthy and that you plan to relocate the virtual machines in an orderly fashion without loss of data.
Note: To recover virtual machines on the recovery site during disaster recovery, see“Managing Failover”, on page 147.
The Move operation has the following basic steps:
■ Shutting down the protected virtual machines gracefully. This ensures data integrity.
If the machines cannot be gracefully shut down, for example, when VMware Tools or Microsoft Integration Services is not
available, you must manually shut down the machines before starting the Move operation or forcibly power off the virtual
machines as part of the Move operation. If the machines cannot be gracefully shut down automatically and are not shut
down manually and the Move operation does not forcibly power them off, the Move operation stops and Zerto Virtual
Replication rolls back the virtual machines to their original status.
■ Inserting a clean checkpoint. This avoids potential data loss since the virtual machines are not on and the new checkpoint
is created after all I/Os have been written to disk.
■ Transferring all the latest changes that are still in the queue to the recovery site, including the new checkpoint.
■ Creating new virtual machines in the recovery site and attaching each new virtual machine to its relevant VHD disk, based
on the last checkpoint.
Note: The new virtual machines are created without CD-ROM or DVD drives, even if the protected virtual machines had
CD-ROM or DVD drives. Also, as long as the virtual machines are created, the operation is considered successful, even if
the virtual machines are not created with their complete definition, for example setting a private IP cannot be performed.
■ Powering on the new virtual machines, making them available to the user. If applicable, the boot order defined in the VPG
settings is used to power on the machines.
If the new virtual machine does not power on, the process continues and the new virtual machine must be powered on
manually.
■ By default, automatically committing the Move operation without testing. However, you can also run basic tests on the
new virtual machines to ensure their validity. Depending of the commit/rollback policy that you specified for the operation,
the operation is committed, finalizing the move, or rolled back, aborting the operation.
■ If Keep Source VMs is not selected, the protected virtual machines are removed from the protected site.
Note: If Keep Source VMs is not selected, and the virtual machines or vCD vApp are already protected in other VPGs,
continuing with the operation will cause the virtual machines or vCD vApp to be deleted from other VPGs that are
protecting them and to the journals of these VPGs to be reset. In the event of vCD vApp or if no other virtual machines are
left to protect, the entire VPG will be removed.

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Migrating a VPG to Azure 132
Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Migrating a VPG to Azure

■ The default instance size for new virtual machines is Standard_D1_v2. If Standard_D1_v2 instance size does not meet your
needs, you can change this value in the Policies tab of the Site Settings dialog. For more information, see“Configuring
Disaster Recovery Policies”, on page 119. You can also change the instance size of new virtual machines when you create or
edit a VPG.
■ When you create a virtual machine in Azure you are provided with a temporary volume automatically. This temporary
storage is D: on a Windows virtual machine and it is /dev/sdb1 on a Linux virtual machine.
■ Temporary volume size varies according to the instance size you have selected.
■ On Windows, the temporary volume will be using the next available drive letter.
For example: If you have two volumes connected to the protected virtual machine, Azure will use C and D, and allocate
E for the temporary volume drive.

Moving Protected Virtual Machines to a Remote Site

You can move the virtual machines in a virtual protection group to Azure, where the virtual machines are replicated.
WARNING: A different static IP should not be configured for virtual machines with a Linux operating system. Configuring a
different static IP for these machines will cause them not to boot.

To initiate a move:
1. In the Zerto User Interface select ACTIONS > MOVE VPG.
The Move wizard is displayed.

2. Select the VPGs to move.

At the bottom, the selection details show the amount of data and the total number of virtual machines selected.
The Direction arrow shows the direction of the process: from the protected site to the peer, recovery, site.
3. Click NEXT.

Moving Protected Virtual Machines to a Remote Site 133

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Migrating a VPG to Azure

The EXECUTION PARAMETERS step is displayed.

You can change the following values to use for the recovery:
■ Commit Policy
■ Force Shutdown policy
■ Reverse Protection settings. For more information see “Reverse Protection For a Moved VPG”, on page 138.
■ Keep Source VMs - Prevents removal of the protected virtual machines at the Azure site.
Note: If reverse protection is specified, the Keep Source VMs option is grayed out because the virtual disks of the VMs
are used for replication and cannot have VMs attached. If Keep Source VMs is selected before reverse protection is
specified, the Keep Source VMs selection is canceled.
4. To change the commit policy, click the field or select the VPG and click EDIT SELECTED.
a) To commit the recovery operation automatically, with no testing, select Auto-Commit and 0 minutes.
b) Select None if you do not want an automatic commit or rollback. You must manually commit or roll back.
c) To test before committing or rolling back, specify an amount of time to test the recovered machines, in minutes.
This is the amount of time that the commit or rollback operation is delayed, before the automatic commit or rollback
action is performed.
During this time period, check that the new virtual machines are OK and then commit the operation or roll it back.
The maximum amount of time you can delay the commit or rollback operation is 1440 minutes, which is 24 hours.
Testing that involves I/O is done on scratch volumes.
■ The more I/Os generated, the more scratch volumes are used, until the maximum size is reached, at which point no
more testing can be done.
■ The maximum size of all the scratch volumes is determined by the journal size hard limit and cannot be changed.
■ The scratch volumes reside on the storage defined for the journal.
5. To specify reverse protection, whereby the virtual machines in the VPG are failed over to the recovery site and then
protected in the recovery site, back to the original site, either:
■ Click REVERSE PROTECT ALL. This activates reverse protection on all the VPGs that you plan to Failback. The system
default values for this procedure will be assigned to all the VPGs.
-or-
■ Click the Reverse Protection field.
If you want to configure the VPG for reverse protection, click the REVERSE link.
The Edit Reverse VPG wizard is displayed and you can edit the reverse protection configuration. The parameters are the
same as described when you create a VPG, described in “To protect from a VCenter server to a recovery site vCenter
server:”, on page 114, with the following differences:
■ You cannot add virtual machines to or remove virtual machines from the reverse protection VPG.
■ By default, reverse protection is to the original protected disks. You can specify a different storage to be used for the
reverse protection.

Moving Protected Virtual Machines to a Remote Site 134

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Migrating a VPG to Azure

■ When replicating a VPG from Azure re-IP is always enabled. If VMware Tools or Microsoft Integration Services are
available for vSphere or Hyper-V respectively, for each virtual machine in the VPG, the IP address of the originally
protected virtual machine is used. Thus, during failback the original IP address of the virtual machine on the site where
the machine was originally protected is reused. However, if the machine does not contain the utility, DHCP is used.
The host version must be 4.1 or higher for re-IP to be enabled.
When committing the Failback, you can reconfigure reverse protection, regardless of the reverse protection settings
specified here. For more information see “Reverse Protection For a Moved VPG”, on page 138.
6. Click NEXT.
■ A warning appears informing the user that the virtual machines or vCD vApp will be removed from the other VPGs
that are protecting them.
■ If your VPG has a vCD vApp, or if there are no other virtual machines left to protect, the entire VPG will be removed.
7. Click OK.
The MOVE step is displayed. The topology will show the VPGs and the virtual machines that are about to be moved from
the on-premise site to Azure.

8. Click START MOVE to start the Move.

9. If a commit policy was set with a timeout greater than zero, as described in step 4, you can check the new virtual machines
on Azure before they are removed from the protected site.

Moving Protected Virtual Machines to a Remote Site 135

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Migrating a VPG to Azure

Note: If a virtual machines exists on the recovery site with the same name as a virtual machine being migrated, the
machine is moved and named in the recovery site with a number added as a suffix to the name, starting with the number 1.
The status icon changes to orange and an alert is issued, to warn you that the procedure is waiting for either a commit or
rollback.
All testing done during this period, before committing or rolling back the Move operation, is written to a copy of the
recovery disks created during the move operation.
Note: You cannot take a snapshot of a virtual machine before the Move operation is committed and the data from the
journal promoted to recovery disks, since the virtual machine disks are still managed by the VRA and not directly by the
virtual machine. Taking a snapshot of a machine that is in the process of being moved will corrupt that machine.
10. After checking the virtual machines on the recovery site, choose one of the following:
■ Wait for the specified Commit Policy time to elapse, and the specified operation, either Commit or Rollback, is
performed automatically.
■ Click the Commit or Rollback icon ( ) in the specific VPG tab.
■ Click Commit to confirm the commit.
■ Click Rollback to roll back the operation, removing the virtual machines that were created on the recovery site and
rebooting the machines on the protected site. The Rollback dialog is displayed to confirm the rollback.

Moving Protected Virtual Machines to a Remote Site 136

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Migrating a VPG to Azure

You can also commit or roll back the operation via the TASKS popup dialog in the status bar, or by selecting
MONITORING > TASKS.
After the new virtual machines are up and running and committed in the recovery site, the powered off virtual machines in the
protected site are removed from the protected site. Finally, data is copied from the journal to the recovery disks copies,
attached to the new virtual machines in Azure.
Notes:
■ If virtual machines or vCD vApp are already protected in several VPGs, and reverse protection is configured, the virtual
machines or vCD vApp are deleted from the protected site. This will result in the removal of these virtual machines from
other VPGs that are protecting them and to the journals of these VPGs to be reset. In the event of vCD vApp or if no other
virtual machines are left to protect, the entire VPG will be removed.
Protecting virtual machines in several VPGs is enabled only if both the protected site and the recovery site, as well as the
VRAs installed on these sites, are of version 5.0 and higher.
■ If Keep Source VMs is selected, the protected virtual machines are not removed from the protected site.
The default instance size for new virtual machines is Standard_D1_v2. If Standard_D1_v2 instance size does not meet your
needs, you can change this value in the Policies tab of the Site Settings dialog. For more information, see“Configuring Disaster
Recovery Policies”, on page 119. You can also change the instance size of new virtual machines when you create or edit a VPG.
Note: By default, every Azure virtual machine is created with an additional temporary volume. This temporary volume is a local
SSD disk. The size of the SSD disk depends on the instance size of the virtual machine.
If you did not define a private IP for a virtual machine in the VPG definition, during recovery Azure sets the private IP from the
defined subnet range.
Note: If the new virtual machines do not power on, the process continues and the new virtual machines must be manually
powered on.

Moving Protected Virtual Machines to a Remote Site 137

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Migrating a VPG to Azure

Reverse Protection For a Moved VPG

When moving the virtual machines in a VPG you specify whether you want reverse protection from the recovery site back to
the original protected site.

Reverse Protection Specified

When you specify reverse protection, the virtual machines are moved to the recovery site and then protected using the values
specified during the move. Data is promoted from the journal to the moved virtual machines and then synchronization with the
original site is performed so that the VPG is fully protected. Preseeded disks are supported at on-premise sites, and when the
reverse protection is to an on-premise site, a Delta Sync is performed or, if there is only one volume to synchronize, a Volume
Delta Sync. A sync is required since the recovered machines can be updated while data is being promoted.

Reverse Protection for VMs protected in multiple VPGs (One-to-Many)

Zerto Virtual Replication enables you to protect virtual machines in a maximum of three VPGs. These VPGs cannot be
recovered to the same site.
If Reverse Protection is selected, and the virtual machines are already protected in other VPGs, the following occurs:
■ The vCD vApp are deleted from the protected site.
■ The replication of other VPGs containing these machines is paused.
■ The recovery of all the virtual machines, including the virtual machine removed from the protected site, is possible.

To resume replication do the following:

1. Open the Edit VPG wizard.
2. Select the virtual machine that was previously removed from the protected site.
3. Remove the virtual machine from the VPG.
If the protected VPG contains a vCD vApp, and the vCD vApp is protected in other VPGs, Reverse Protection is selected, the
following occurs:
■ The vCD vApp is deleted from the protected site.
■ The checkpoints of the VPG are retained.
■ The deleted vCD vApp can no longer be recovered.
In the event of vCD vApp or if no other virtual machines are left to protect, the entire VPG will be removed.
VPGs enter a state of pause, and paused replication if the following conditions apply:
■ The ZVM on the protected and recovery sites are of version 5.5 and higher.
■ The VRA installed on the recovery site is of version 5.5 and higher.
Protecting virtual machines or a vCD vApp in several VPGs is enabled if:
■ The protected site and the recovery site are of version 5.0 and higher
■ The VRAs installed on these sites are of version 5.0 and higher.

Reverse Protection Not Specified

If you do not specify reverse protection, the protected disks are removed along with the protected virtual machines at the end
of the procedure. In this case, if you want to move the virtual machines back again to the original site, you will not be able to use
the original disks and an Initial Sync will have to be performed. The VPG definition is kept with the status Needs Configuration
and the reverse settings in the VPG definition are not set.
Clicking EDIT VPG displays the Edit VPG wizard with the settings filled in, using the original settings for the virtual machines in
the VPG from the original protected site, except for the volumes, since the last step of the Move operation is to delete the
virtual machines from the original protected site inventory, including the disks. To start replicating the virtual machines in the
VPG, specify the disks to use for replication and optionally, make any other changes to the original settings and click DONE. An
initial synchronization is performed.

Reverse Protection For a Moved VPG 138

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Migrating a VPG to Azure

Notes:
■ If Keep Source VMs is not selected, and virtual machines or vCD vApp are already protected in several VPGs, the virtual
machines or vCD vApp are deleted from the protected site. This will result in the removal of these virtual machines from
other VPGs that are protecting them and to the journals of these VPGs to be reset. In the event of vCD vApp or if no other
virtual machines are left to protect, the entire VPG will be removed.
Protecting virtual machines or vCD vApps in several VPGs is enabled only if both the protected site and the recovery site,
as well as the VRAs installed on these sites, are of version 5.0 and higher.
■ You can edit the VPG definition from either of the sites, the site where the VPG virtual machines were initially protected or
the site they were moved to.

Reverse Protection For a Moved VPG 139

 CHAPTER 13: MIGRATING A VPG
FROM AZURE TO AN ON-PREMISE
SITE
This section describes a planned migration of a VPG comprised of VMs created in Azure, to an on-premise site. You can
migrate the VPG to the following on-premise platforms:
■ VMware vSphere
■ Microsoft Hyper-V
The disks all have to exist in the Zerto Storage Account.
The following topics are described in this section:
■ “The Move Process”, below
■ “Moving Protected Virtual Machines to a Remote Site”, on page 141
■ “Reverse Protection For a Moved VPG”, on page 145

The Move Process

The Migration process uses the MOVE wizard to move groups of protected virtual machines from Azure to an on-premise
recovery site in a planned migration.You can initiate the MOVE operation from either the Azure site or the on-premise
recovery site.
When you perform a planned migration of virtual machines to a recovery site, Zerto Virtual Replication assumes that both sites
are healthy and that you plan to relocate the virtual machines in an orderly fashion without loss of data. By setting a commit
policy that enables checking the recovered machines before committing the Failback (Move), you can check the integrity of the
recovered machines. If the machines are in the expected state and functioning correctly, you can commit the MOVE.
The MOVE process has the following basic steps:
■ Creating the virtual machines at the remote site in the production network and attaching each virtual machine to its
relevant virtual disks, configured to the checkpoint specified for the failback. As long as the virtual machines are created,
the operation is considered successful, even if the virtual machines are not created with their complete definition, for
example if re-IP cannot be performed.
■ Powering on the virtual machines making them available to the user. If applicable, the boot order defined in the VPG
settings is used to power on the machines.
Note: If the virtual machines do not power on, the process continues and the virtual machines must be manually powered
on. The virtual machines cannot be powered on automatically in a number of situations, such as when there are not enough
resources in the resource pool or the required MAC address is part of a reserved range or there is a MAC address conflict
or IP conflict, for example, if a clone was previously created with the MAC or IP address.
■ The default is to automatically commit the Failback (Move) operation without testing. However, you can also run basic
tests on the machines to ensure their validity to the specified checkpoint. Depending on the commit/rollback policy that
you specified for the operation, after testing either the operation is committed, finalizing the Failback (Move), or rolled
back, aborting the operation.
■ If Keep Source VMs is not selected, the protected virtual machines are removed from Azure.
Note: If Keep Source VMs is not selected, and the virtual machines, or vCD vApps are also protected in other VPGs. The
following occurs:
■ The virtual machines and vCD vApp are deleted from the protected site.
■ The checkpoints of the VPG are retained.
■ The deleted vCD vApp can no longer be recovered.
In the event of vCD vApp or if no other virtual machines are left to protect, the entire VPG will be removed.
■ VPGs enter a state of pause and pause replication if the following conditions apply:
■ The ZVM on the protected and recovery sites are of version 5.5 and higher.
■ The VRA installed on the recovery site is of version 5.5 and higher.
Protecting virtual machines or a vCD vApp in several VPGs is enabled if:
■ The protected site and the recovery site are of version 5.0 and higher

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Migrating a VPG From Azure to an On-Premise Site 140
Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Migrating a VPG From Azure to an On-Premise Site

■ The VRAs installed on these sites are of version 5.0 and higher.
■ Protecting virtual machines or vCD vApps in several VPGs is enabled only if both the protected site and the
recovery site, as well as the VRAs installed on these sites, are of version 5.0 and higher.
■ If Reverse Protection is specified for the Failback (Move) operation, the protected virtual machines in Azure are placed in a
Stopped (Deallocated) state. The virtual disks previously used by the virtual machines in the protected Azure site are used
for reverse protection. A sync is required since the recovered machines can be updated while data is being promoted. The
VPGs are reverse protected back to Azure, and an Initial Sync is performed as preseeding is not supported.
■ The data from the journal is promoted to the machines. The machines can be used during the promotion and Zerto Virtual
Replication ensures that the user sees the latest image, even if this image, in part, includes data from the journal.

Moving Protected Virtual Machines to a Remote Site

You can move the virtual machines in a virtual protection group to Azure, where the virtual machines are replicated.

To initiate a Failback (Move):

1. In the Zerto User Interface select ACTIONS > MOVE VPG.
The Move wizard is displayed.

2. Select the VPGs to failover. By default, all VPGs are listed.

At the bottom, the selection details show the amount of data and the total number of virtual machines selected.
The Direction arrow shows the direction of the process: From the protected site To the peer, recovery, site.
3. Click NEXT.

Moving Protected Virtual Machines to a Remote Site 141

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Migrating a VPG From Azure to an On-Premise Site

The EXECUTION PARAMETERS step is displayed.

You can change the following values to use for the recovery:
■ Commit Policy
■ Force Shutdown - Select Yes / No. Selecting YES places the VMs in a Stopped (Deallocated) state.
■ Reverse Protection settings. For more information see “Reverse Protection For a Moved VPG”, on page 145.
■ Keep Source VMs - Prevents removal of the protected virtual machines at the Azure site.
Note: If reverse protection is specified, the Keep Source VMs option is grayed out because the virtual disks of the VMs
are used for replication and cannot have VMs attached. If Keep Source VMs is selected before reverse protection is
specified, the Keep Source VMs selection is canceled.
4. To change the commit policy, click the field or select the VPG and click EDIT SELECTED.
a) To commit the recovery operation automatically, with no testing, select Auto-Commit and 0 minutes.
b) Select None if you do not want an automatic commit or rollback. You must manually commit or roll back.
c) To test before committing or rolling back, specify an amount of time to test the recovered machines, in minutes.
This is the amount of time that the commit or rollback operation is delayed, before the automatic commit or rollback
action is performed.
During this time period, check that the new virtual machines are OK and then commit the operation or roll it back.
The maximum amount of time you can delay the commit or rollback operation is 1440 minutes, which is 24 hours.
Testing that involves I/O is done on scratch volumes.
■ The more I/Os generated, the more scratch volumes are used, until the maximum size is reached, at which point no
more testing can be done.
■ The maximum size of all the scratch volumes is determined by the journal size hard limit and cannot be changed.
■ The scratch volumes reside on the storage defined for the journal.
5. To specify reverse protection, whereby the virtual machines in the VPG are failed over to the recovery site and then
protected in the recovery site, back to the original site, either:
■ Click REVERSE PROTECT ALL. This activates reverse protection on all the VPGs that you plan to Failback. The system
default values for this procedure will be assigned to all the VPGs.
-or-
■ Click the Reverse Protection field.
If you want to configure the VPG for reverse protection, click the REVERSE link.
The Edit Reverse VPG wizard is displayed and you can edit the reverse protection configuration. The parameters are the
same as described when you create a VPG, described in “To protect from a VCenter server to a recovery site vCenter
server:”, on page 114, with the following differences:
■ You cannot add or remove virtual machines in the reverse protected VPG.
■ By default, reverse protection is to the original protected disks. You can specify a different storage to be used for the
reverse protection.

Moving Protected Virtual Machines to a Remote Site 142

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Migrating a VPG From Azure to an On-Premise Site

■ If VMware Tools or Microsoft Integration Services are available for vSphere or Hyper-V respectively, for each virtual
machine in the VPG, the IP address of the originally protected virtual machine is used. Thus, during failback the
original IP address of the virtual machine on the site where the machine was originally protected is reused. However, if
the machine does not contain the utility, DHCP is used. The host version must be 4.1 or higher for re-IP to be enabled.
When committing the Failback, you can reconfigure reverse protection, regardless of the reverse protection settings
specified here. For more information see “Reverse Protection For a Moved VPG”, on page 145.
6. Click NEXT.
7. Click OK.
The MOVE step is displayed. The topology will show the VPGs and the virtual machines that are about to be moved from
Azure to the on-premise site.

8. Click START MOVE to start the Move.

9. If a commit policy was set with a timeout greater than zero, as described in step 4, you can check the moved virtual
machines on the recovery site before they are removed from the protected site.

Moving Protected Virtual Machines to a Remote Site 143

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Migrating a VPG From Azure to an On-Premise Site

Note: If a virtual machine exists on the recovery site with the same name as a virtual machine being migrated, the machine
is moved and named in the peer site with a number added as a suffix to the name, starting with the number 1
The status icon changes to orange and an alert is issued, to warn you that the procedure is waiting for either a commit or
rollback.
All testing done during this period, before committing or rolling back the Move operation, is written to thin-provisioned
virtual disks, one per virtual machine in the VPG. These virtual disks are automatically defined when the machines are
created on the recovery site for testing. The longer the test period the more scratch volumes are used, until the maximum
size is reached, at which point no more testing can be done. The maximum size of all the scratch volumes is determined by
the journal size hard limit and cannot be changed. The scratch volumes reside on the storage defined for the journal. Using
these scratch volumes makes committing or rolling back the Move operation more efficient.
Note: You cannot take a snapshot of a virtual machine before the Move operation is committed and the data from the
journal promoted to the moved virtual machine disks, since the virtual machine volumes are still managed by the VRA and
not directly by the virtual machine. Taking a snapshot of a machine that is in the process of being moved will corrupt that
machine.
10. After checking the virtual machines on the recovery site, choose one of the following:
■ Wait for the specified Commit Policy time to elapse, and the specified operation, either Commit or Rollback, is
performed automatically.
■ Click the Commit or Rollback icon ( ) in the specific VPG tab.
■ Click Commit to confirm the commit and, if necessary set, or reset, the reverse protection configuration. If the
protected site is still up and you can set up reverse protection, you can reconfigure reverse protection by checking
the Reverse Protection checkbox and then click the Reverse link. Configuring reverse protection here
overwrites any of settings defined when initially configuring the failover.
■ Click Rollback to roll back the operation, removing the virtual machines that were created on the recovery site and
rebooting the machines on the protected site. The Rollback dialog is displayed to confirm the rollback.

You can also commit or roll back the operation in the TASKS popup dialog in the status bar or under
MONITORING > TASKS.
After the virtual machines are up and running and committed in the recovery site, the powered off virtual machines in the
protected site are removed from Azure. Finally, data is promoted from the journal to the moved virtual machines.
During promotion of data, you cannot move a host on the moved virtual machines. If the host is rebooted during promotion,
make sure that the VRA on the host is running and communicating with the Zerto Virtual Manager before starting up the
recovered virtual machines.
Note: If the virtual machines do not power on, the process continues and the virtual machines must be manually powered on.
The virtual machines cannot be powered on automatically in a number of situations, such as when there are not enough

Moving Protected Virtual Machines to a Remote Site 144

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Migrating a VPG From Azure to an On-Premise Site

resources in the resource pool or the required MAC address is part of a reserved range or there is a MAC address conflict or IP
conflict, for example, if a clone was previously created with the MAC or IP address.
When a vCD vApp is moved to a vCenter Server recovery site, a vCenter Server vCD vApp is created in the recovery site. If
reverse protection was specified, the VPG state is Needs Configuration and the VPG must be recreated by protecting the
virtual machines in the vCD vApp as separate machines and not as part of the vCD vApp.

Reverse Protection For a Moved VPG

When moving the virtual machines in a VPG you specify whether you want reverse protection from the recovery site back to
the original protected site.

Reverse Protection Specified

When you specify reverse protection, the virtual machines are moved to the recovery site and then protected using the values
specified during the move. Data is promoted from the journal to the moved virtual machines and then synchronization with the
original site is performed so that the VPG is fully protected. Preseeded disks are supported at on-premise sites, and when the
reverse protection is to an on-premise site, a Delta Sync is performed or, if there is only one volume to synchronize, a Volume
Delta Sync. A sync is required since the recovered machines can be updated while data is being promoted.

Reverse Protection for VMs protected in multiple VPGs (One-to-Many)

Zerto Virtual Replication enables you to protect virtual machines in a maximum of three VPGs. These VPGs cannot be
recovered to the same site.
If Reverse Protection is selected, and the virtual machines are already protected in other VPGs, the following occurs:
■ The vCD vApp are deleted from the protected site.
■ The replication of other VPGs containing these machines is paused.
■ The recovery of all the virtual machines, including the virtual machine removed from the protected site, is possible.

To resume replication do the following:

1. Open the Edit VPG wizard.
2. Select the virtual machine that was previously removed from the protected site.
3. Remove the virtual machine from the VPG.
If the protected VPG contains a vCD vApp, and the vCD vApp is protected in other VPGs, Reverse Protection is selected, the
following occurs:
■ The vCD vApp is deleted from the protected site.
■ The checkpoints of the VPG are retained.
■ The deleted vCD vApp can no longer be recovered.
In the event of vCD vApp or if no other virtual machines are left to protect, the entire VPG will be removed.
VPGs enter a state of pause, and paused replication if the following conditions apply:
■ The ZVM on the protected and recovery sites are of version 5.5 and higher.
■ The VRA installed on the recovery site is of version 5.5 and higher.
Protecting virtual machines or a vCD vApp in several VPGs is enabled if:
■ The protected site and the recovery site are of version 5.0 and higher
■ The VRAs installed on these sites are of version 5.0 and higher.

Reverse Protection For a Moved VPG 145

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Migrating a VPG From Azure to an On-Premise Site

Reverse Protection Not Specified

If you do not specify reverse protection, the protected disks are removed along with the protected virtual machines at the end
of the procedure. In this case, if you want to move the virtual machines back again to the original site, you will not be able to use
the original disks and an Initial Sync will have to be performed. The VPG definition is kept with the status Needs Configuration
and the reverse settings in the VPG definition are not set.
Clicking EDIT VPG displays the Edit VPG wizard with the settings filled in, using the original settings for the virtual machines in
the VPG from the original protected site, except for the volumes, since the last step of the Move operation is to delete the
virtual machines from the original protected site inventory, including the disks. To start replicating the virtual machines in the
VPG, specify the disks to use for replication and optionally, make any other changes to the original settings and click DONE. An
initial synchronization is performed.
Notes:
■ If Keep Source VMs is not selected, and virtual machines or vCD vApp are already protected in several VPGs, the virtual
machines or vCD vApp are deleted from the protected site. This will result in the removal of these virtual machines from
other VPGs that are protecting them and to the journals of these VPGs to be reset. In the event of vCD vApp or if no other
virtual machines are left to protect, the entire VPG will be removed.
Protecting virtual machines or vCD vApps in several VPGs is enabled only if both the protected site and the recovery site,
as well as the VRAs installed on these sites, are of version 5.0 and higher.
■ You can edit the VPG definition from either of the sites, the site where the VPG virtual machines were initially protected or
the site they were moved to.

Reverse Protection For a Moved VPG 146

 CHAPTER 14: MANAGING FAILOVER

This section describes how to perform a failover to Microsoft Azure after an unforeseen disaster. The following topics are
described in this section:
■ “The Failover Process”, below
■ “Initiating a Failover”, on page 148
■ “Initiating a Failover During a Test”, on page 154
Note: If you need to perform a failover while a backup job is running, the backup job is aborted to enable the failover to run.

The Failover Process

Use the Failover operation following a disaster to recover protected virtual machines to Azure.
Note: You can also move virtual machines from the protected site to Azure in a planned migration. For details, see “Migrating a
VPG to Azure”, on page 132.
When you set up a failover you always specify a checkpoint to which you want to recover the virtual machines. When you
select a checkpoint – either the last auto-generated checkpoint, an earlier checkpoint, or a tagged checkpoint – Zerto Virtual
Replication makes sure that the new virtual machines on Azure are recovered to this specified point-in-time. By setting a
commit policy that enables checking the recovered machines before committing the failover, you can check the integrity of the
recovered machines. If the machines are OK, you can commit the failover. Otherwise, you can roll back the operation and then
repeat the procedure using a different checkpoint.
The Failover operation has the following basic steps:
■ If the protected site or Zerto Virtual Manager is down, the process continues with the next step.
If the protected site or Zerto Virtual Manager is still running, the failover requirements are determined:
■ If the default is requested, doing nothing to the protected virtual machines, the Failover operation continues with the
next step.
■ If shutting down the protected virtual machines is requested and the protected virtual machines do not have a utility
such as VMware Tools or Microsoft Integration Services available, the Failover operation fails.
■ If forcibly shutting down the protected virtual machines is requested, the protected virtual machines are shut down
and the Failover operation continues with the next step.
■ Creating the new virtual machines on Azure in the production network and attaching each virtual machine to its relevant
VHD disk, configured to the checkpoint specified for the recovery. The new virtual machines are created without CD-ROM
or DVD drives, even if the protected virtual machines had CD-ROM or DVD drives. Also, as long as the virtual machines
are created, the operation is considered successful, even if the virtual machines are not created with their complete
definition, for example setting a private IP cannot be performed.
The protected virtual machines are created as new instances in a storage account. The default value for new virtual
machines in Zerto Virtual Replication is Standard_D1_v2. If Standard_D1_v2 instances do not meet your needs, you can
change this value in the Policies tab of the Site Settings dialog, see “Configuring Disaster Recovery Policies”, on page 119.
You can also change the instance size of new virtual machines when you create or edit a VPG.
Note: The original protected virtual machines are not touched since the assumption is that the original protected site is
down.
■ Powering on the new virtual machines, making them available to the user. If applicable, the boot order defined in the VPG
settings is used to power on the machines.
If the virtual machines do not power on, the process continues and the virtual machines must be manually powered on.
■ The default is to automatically commit the Failover operation without testing. However, you can also run basic tests on the
machines to ensure their validity to the specified checkpoint. Depending on the commit/rollback policy that you specified

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing Failover 147
Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing Failover

for the operation after testing either the operation is committed, finalizing the failover, or rolled back, aborting the
operation.
■ If the protected site is still available, for example, after a partial disaster, the original protected site virtual machines are not
powered off and are not removed.
■ When you create a virtual machine in Azure you are provided with a temporary volume automatically. This temporary
storage is D: on a Windows virtual machine and it is /dev/sdb1 on a Linux virtual machine.
■ Temporary volume size varies according to the instance size you have selected.
■ On Windows, the temporary volume will be using the next available drive letter.
For example: If you have two volumes connected to the protected virtual machine, Azure will use C and D, and allocate
E for the temporary volume drive.
■ If the D:/ drive is occupied by the temporary Azure disk, recovered virtual machines in Azure require re-mapping the
volumes drive letters. See
https://docs.microsoft.com/en-us/azure/virtual-machines/virtual-machines-windows-classic-change-drive-letter

Initiating a Failover
You can initiate a failover, whereby the virtual machines in the virtual protection group are replicated to a set checkpoint in
Azure.
You can initiate a failover to the last checkpoint recorded in the journal, even if the protected site is no longer up. You can
initiate a failover during a test, as described in “Initiating a Failover During a Test”, on page 154.
If you have time to initiate the failover from the protected site you can. However, if the protected site is down, you initiate the
failover from Azure.
Note: Any VPGs that are in the process of being synchronized, cannot be recovered, unless the synchronization is a bitmap
synchronization.
WARNING: A different static IP should not be configured for virtual machines with a Linux operating system. Configuring a
different static IP for these machines will cause them not to boot.

To initiate a failover:
1. In the Zerto User Interface set the operation to LIVE and click FAILOVER.
The Failover wizard is displayed.

2. Select the VPGs to failover. By default, all VPGs are listed.

At the bottom, the selection details show the amount of data and the total number of virtual machines selected.

Initiating a Failover 148

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing Failover

The Direction arrow shows the direction of the process: from the protected site to the peer, recovery, site.
3. Click NEXT.
The EXECUTION PARAMETERS step is displayed.

You can change the following values to use for the recovery:
■ Commit Policy
■ Force Shutdown policy
■ Reverse Protection settings. For more information see “Reverse Protection for a Failed Over VPG”, on page 153.
You can also see if scripts are defined for the VPG.
4. By default, the last checkpoint added to the journal is displayed. If you want to use this checkpoint, go to the next step. If
you want to change the checkpoint, click the checkpoint.
The {VPG-Name}: Checkpoints dialog is displayed.

Initiating a Failover 149

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing Failover

When selecting the point to recover to:

■ The refresh button is initially grayed out and is enabled for clicking after 5 seconds. It is also grayed out for 5 seconds after
being clicked, before being re-enabled.
■ A Click the refresh button to view the latest checkpoints reminder is displayed 10 seconds after the refresh button is clicked
to remind the user that there is a new Latest Checkpoint.
■ If the user has scrolled to, and selected, a checkpoint anywhere in the checkpoints list, clicking the refresh button will
automatically return the user to the selected checkpoint in the list.
Latest: Recovery is to the latest checkpoint. This ensures that the data is crash-consistent for the recovery.
Latest Tagged Checkpoint: The recovery operation is to the latest checkpoint added in one of the following situations:
■ By a user.
■ When a failover test was previously performed on the VPG which includes the virtual machine.
■ When the virtual machine was added to an existing VPG after the added virtual machine was synchronized.
If you do not want to use the latest checkpoint, or latest tagged checkpoint, choose Select from all available checkpoints. By
default, this option displays all checkpoints in the system. You can choose to display only automatic, or tagged checkpoints, or
any combination of these types.

5. Select the checkpoint to use. Click the refresh button to refresh the list. You can choose from one of the following
checkpoints:
Latest VSS – When VSS is used, the clone is to the latest VSS snapshot, ensuring that the data is both crash-consistent and
application consistent to this point. The frequency of VSS snapshots determines how much data can be recovered. For
details about VSS checkpoints, see “Ensuring Application Consistency – Checkpoints”, on page 86.
6. Click OK.
7. To change the commit policy, click on the field or select the VPG and click EDIT SELECTED.
a) To commit the recovery operation automatically, without any checking, select Auto-Commit and 0 minutes.
b) If you do not want an automatic commit or rollback, select None. You must manually commit or roll back.
To allow checking before committing or rolling back, specify an amount of time to check the recovered machines, in
minutes, before the automatic commit or rollback action is performed. During this time period, check that the new virtual

Initiating a Failover 150

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing Failover

machines are OK and then commit the operation or roll it back. The maximum amount of time you can delay the commit or
rollback operation is 1440 minutes, which is 24 hours.
8. To specify the shutdown policy, double-click the VM Shutdown field and select the shutdown policy:
No (default) – The protected virtual machines are not touched before starting the failover. This assumes that you do not
know the state of the protected machines, or you know that they are not serviceable.
Yes – If the protected virtual machines have a utility such as VMware Tools or Microsoft Integration Services available, the
virtual machines are gracefully shut down, otherwise the Failover operation fails. This is similar to performing a Move
operation to a specified checkpoint.
Force Shutdown – The protected virtual machines are forcibly shut down before starting the failover. This is similar to
performing a Move operation to a specified checkpoint. If the protected virtual machines have VMware Tools or Microsoft
Integration Services available, the procedure waits five minutes for the virtual machines to be gracefully shut down before
forcibly powering them off.
9. Click NEXT.
10. Click OK. If a virtual machine is deleted from other VPGs, the journals of these VPGs are reset.
The FAILOVER step is displayed. The topology shows the number of VPGs and virtual machines being failed over to each
recovery site. In the following example, 2 VPGs will be failed over to Site6-Ent2-R2, and they contain 5 virtual machines;
and 1 VPG will be failed over to Site5-Ent2-P2-R2 and it contains 2 virtual machines.

11. Click START FAILOVER to start the failover.

Note: If any of the VPGs have at least one VM configured with a static IP, but the static IP is in use on the recovery site, the
static IPs that are in use are replaced with dynamic IPs.
12. If a commit policy was set with a timeout greater than zero, you can check the new virtual machines at the recovery site
before committing the failover operation.

Initiating a Failover 151

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing Failover

The failover starts by creating the new virtual machines on Azure to the point-in-time specified: either the last data
transferred from the protected site or to one of the checkpoints written in the journal.
Note: If a virtual machine exists on Azure with the same name as a virtual machine being failed over, the machine is
created and named in the peer site with a number added as a suffix to the name, starting with the number 1.
The status icon changes to orange and an alert is issued, to warn you that the procedure is waiting for either a commit or
rollback.
All testing done during this period, before committing or rolling back the failover operation, is written to VHD disks. These
virtual disks are automatically defined when the virtual machines are created on Azure for testing.
Note: You cannot take a snapshot of a virtual machine before the failover operation is committed and the data from the
journal promoted to the moved virtual machine disks, since the virtual machine volumes are still managed by the VRA and
not directly by the virtual machine. Using a snapshot of a recovered machine before the failover operation has completed
will result in a corrupted virtual machine being created.
13. After checking the virtual machines in Azure, choose one of the following:
■ Wait for the specified Commit Policy time to elapse, and the specified operation, either Commit or Rollback, is
performed automatically.
■ Click the Commit or Rollback icon ( ) in the specific VPG tab.
Click Commit. The Commit dialog is displayed to confirm the commit.
Click Rollback to roll back the operation, removing the virtual machines that were created on the recovery site and
rebooting the machines on the protected site. The Rollback dialog is displayed to confirm the rollback.
You can also commit or roll back the operation via the TASKS popup dialog in the status bar, or by selecting
MONITORING > TASKS.
The default instance size for new virtual machines is Standard_D1_v2. If Standard_D1_v2 instance size does not meet your
needs, you can change this value in the Policies tab of the Site Settings dialog. For more information, see “Configuring Disaster
Recovery Policies”, on page 119. You can also change the instance size of new virtual machines when you create or edit a VPG.
Note: By default, every Azure virtual machine is created with additional temporary volume. This volume is in addition to the
volumes associated with each protected virtual machine.
If you did not define a private IP for a virtual machine in the VPG definition, during recovery Azure sets the private IP from the
defined subnet range.
Note: If the new virtual machines do not power on, the process continues and the virtual machines must be manually powered
on.

Initiating a Failover 152

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing Failover

■ If you do not specify Reverse Protection, the VPG definition is kept with the status Needs Configuration and the reverse
settings in the VPG definition are not set.

■ Clicking EDIT VPG displays the Edit VPG wizard with the settings filled in, using the original settings for the virtual machines
in the VPG from the original protected site, except for the volumes. To start replicating the virtual machines in the VPG,
specify the disks to use for replication and optionally, make any other changes to the original settings and click DONE.

Reverse Protection for a Failed Over VPG

When you specify reverse protection, the virtual machines are failed over to Azure and then protected using the values
specified during the failover. Data is promoted from the journal to the failed over virtual machines and then synchronization
with the original site is performed so that the VPG is fully protected. Preseeded disks are supported at on-premise sites, and
when reverse protection is to an on-premise site, a Delta Sync is performed. A sync is required since the recovered machines
can be updated while data is being promoted.

Reverse Protection with One-to-Many

Zerto Virtual Replication enables you to protect virtual machines in a maximum of three VPGs. These VPGs cannot be
recovered to the same site.
If Reverse Protection is selected, and the virtual machines are already protected in other VPGs, the following occurs:
■ The virtual machines are deleted from the protected site.
■ The replication of other VPGs containing these machines is paused.
■ The recovery of all the virtual machines, including the virtual machine removed from the protected site, is possible.
To resume replication do the following:
1. Open the Edit VPG wizard.
2. Select the virtual machine that was previously deleted from the protected site.
3. Remove the virtual machine from the VPG.
If the protected VPG contains a vCD vApp, and the vCD vApp is protected in other VPGs, Reverse Protection is selected, the
following occurs:
■ The vCD vApp is deleted from the protected site.
■ The vCD vApp is deleted from the other VPGs, and therefore can no longer be recovered
VPGs enter a state of pause and pause replication if the following conditions apply:

Reverse Protection for a Failed Over VPG 153

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Managing Failover

■ The ZVM on the protected and recovery sites are of version 5.5 and higher.
■ The VRA installed on the recovery site is of version 5.5 and higher.
Protecting virtual machines or a vCD vApp in several VPGs is enabled if:
■ The protected site and the recovery site are of version 5.0 and higher
■ The VRAs installed on these sites are of version 5.0 and higher.

What Happens When the Protected Site is Down

If the protected site is down, you can initiate the failover from Azure, as described above in “To initiate a failover:”, on page 148.
The tab for a specific VPG tab for a VPG shows that recovery is possible.
If the Zerto Virtual Manager service is down the actual machines that are being protected can still be up, but they are only
recoverable to the last checkpoint written before the Zerto Virtual Manager service went down. If the hypervisor management
tool, such as vCenter Server or Microsoft SCVMM, is down, some of the protected virtual machines might not be protected.
When there is no connection with the protected site, the status for recovered VPGs is red with an Error status and green while
recovery is being performed. If the protected site restarts, the status changes to orange.

Initiating a Failover During a Test

Replication continues during a test. If you need to initiate a failover during a test, you initiate the failover. The test stops to
enable the failover and then a normal failover is performed, as described in “Initiating a Failover”, on page 148. Any changes
made to test the failover are not replicated, as only changes to the protected machines in the VPG are replicated.
Note: You cannot initiate a failover while a test is being initialized or closed.

What Happens When the Protected Site is Down 154

 CHAPTER 15: CLONING A VPG TO
AZURE

You can create a clone of each virtual machine in a VPG. The clone is a copy of the protected virtual machine, located on the
recovery site, while the virtual machine on the protected site remains protected and live.
The following topics are described in this section:
■ “The Clone Process”, below
■ “Cloning Protected Virtual Machines to the Remote Site”, on page 155
Note: You cannot clone virtual machines in a VPG test while a backup job is running.

The Clone Process

Use the Clone operation to create a copy of virtual machines on the recovery site. The virtual machines on the protected site
remain protected and live.
The Clone operation has the following basic steps:
■ Creating the cloned disks at the recovery site with the data from the journal to the specified checkpoint.
■ Creating the virtual machines at the recovery site in the move/failover network and attaching each virtual machine to its
relevant cloned disks, configured to the checkpoint specified for the clone.
Note: The virtual machines are created without CD-ROM or DVD drives, even if the protected virtual machines have CD-
ROM or DVD drives.
The cloned machines are named with the names of the protected machines, with the timestamp of the checkpoint used to
create the clone. The cloned virtual machines are not powered on and are not protected by Zerto Virtual Replication.
■ When you create a virtual machine in Azure you are provided with a temporary volume automatically. This temporary
storage is D: on a Windows virtual machine and it is /dev/sdb1 on a Linux virtual machine.
■ Temporary volume size varies according to the instance size you have selected.
■ On Windows, the temporary volume will be using the next available drive letter.
For example: If you have two volumes connected to the protected virtual machine, Azure will use C and D, and allocate
E for the temporary volume drive.

Cloning Protected Virtual Machines to the Remote Site

You might want to create a clone if you need to have a copy of the virtual machines saved to a specific point-in-time, for
example, when a VPG enters a Replication Paused state, or when testing a VPG in a live DR test.

To clone a VPG:
1. In the Zerto User Interface, in the VPGs tab click on the name of the VPG to be cloned.
A new tab is added to the Zerto User Interface, with the name of the VPG that you clicked. The tab displays data about the
VPG.
Note: If the VPG was previously viewed, and the tab for this VPG is still displayed, you can access the details by selecting
the tab.
2. Click MORE > Offsite Clone.

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Cloning a VPG to Azure 155
Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Cloning a VPG to Azure

The {VPG-Name}: Offsite Clone dialog is displayed.

3. If you intend to use the last checkpoint, which is displayed in the dialog, go to step 6.
To select the checkpoint, click SELECT A CHECKPOINT.
The {VPG-Name}: Checkpoints dialog is displayed.

When selecting the point to recover to:

■ The refresh button is initially grayed out and is enabled for clicking after 5 seconds. It is also grayed out for 5 seconds after
being clicked, before being re-enabled.
■ A Click the refresh button to view the latest checkpoints reminder is displayed 10 seconds after the refresh button is clicked
to remind the user that there is a new Latest Checkpoint.
■ If the user has scrolled to, and selected, a checkpoint anywhere in the checkpoints list, clicking the refresh button will
automatically return the user to the selected checkpoint in the list.
4. Select the checkpoint to use:
Latest – The clone is to the latest checkpoint. This ensures that the data is crash-consistent for the clone. When selecting
the latest checkpoint, the checkpoint used is the latest at this point. If a checkpoint is added between this point and
starting the clone, the later checkpoint is not used.
Latest Tagged Checkpoint – The recovery operation is to the latest checkpoint added by a user or when a failover test was
previously performed on the VPG which includes the virtual machine or when the virtual machine was added to an existing
VPG after the added virtual machine was synchronized. Checkpoints added to the virtual machine journals in the VPG
ensure that the data is crash-consistent to this point. If a checkpoint is added between this point and starting the
operation, this later checkpoint is not used.

Cloning Protected Virtual Machines to the Remote Site 156

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Cloning a VPG to Azure

Latest VSS – When VSS is used, the clone is to the latest VSS snapshot, ensuring that the data is both crash-consistent and
application consistent to this point. The frequency of VSS snapshots determines how much data can be recovered. For
details about VSS checkpoints, see “Ensuring Application Consistency – Checkpoints”, on page 86.
If you do not want to use the latest checkpoint, latest tagged checkpoint, or latest VSS checkpoint, choose Select from
all available checkpoints. By default, this option displays all checkpoints in the system. You can choose to display
only automatic, VSS, or tagged checkpoints, or any combination of these types.
5. Click OK.
6. Click CLONE.
The cloning starts and the status is displayed in the VPG details tab.

The cloned machines are named with names of the protected machines with the timestamp of the checkpoint used for the
clone. The cloned virtual machines are not powered on.
Virtual machines with disks that are less than 1GB are recovered with disks of 1GB. Additional volumes might be created in the
cloned virtual machine, depending on the virtual machines size used for the clone. These volumes can be ignored.

Cloning Protected Virtual Machines to the Remote Site 157

 CHAPTER 16: RECOVERING FILES
AND FOLDERS

You can recover specific files and folders from the recovery site for virtual machines that are being protected by Zerto Virtual
Replication and running Windows operating systems. You can recover the files and folders from a specific point-in-time. Thus,
you can recover files and folders for a virtual machine for as far back as the journal history is configured.
This section describes how to recover files and folders. The following topics are described in this section:
■ “The File and Folder Recovery Process”, below
■ “Recovering Files and Folders”, on page 159

The File and Folder Recovery Process

Use the RESTORE FILE operation to recover specific files and folders from the recovery site.
When you set up file and folder recovery, you always specify a checkpoint to which you want to recover the files and folders.
When you select a checkpoint – either the last automatically generated checkpoint, an earlier automatically generated
checkpoint, or a tagged checkpoint – Zerto Virtual Replication makes sure that the files and folders replicated at the remote site
are recovered to this specified point-in-time.
The file and folder operation has the following basic steps:
■ Selecting the virtual machine that is protected on which the files or folders to recover are located.
■ Selecting the checkpoint at which the files and folders will be recovered.
■ Selecting the disk which contains the files and folders to recover.
Note: You can only recover files and folders from one disk at a time.
■ Mounting the selected disk.
■ Selecting the files and folders on the disk to recover.
■ Downloading the selected files and folders. The files are downloaded to the machine where you run the Zerto User
Interface. Make sure that this machine has enough space for the recovered files.
■ Unmounting the selected disk.
You can only recover files and folders from one disk at a time. After the required disk is mounted, if you want to recover files or
folders from another disk, you can begin the mount process for the second disk. Zerto Virtual Replication does not support
mounting the same volume twice, for example if you want a file from two different checkpoints.
The operating system of the machine on which the recovery site Zerto Virtual Manager is installed determines the types of file
systems from which files and folders can be recovered. When the operating system supports a file system, files and folders can
be recovered from it. For example, if a protected virtual machine running Windows 2012 has files using the ReFS file system
and requires one or more of these files to be recovered and the recovery site Zerto Virtual Manager is on a machine with
Windows 2008, which does not support ReFS, the protected virtual machine files and folders cannot be recovered.
Note the following:
■ You cannot recover files or folders from Linux machines.
■ You cannot recover files or folders from a virtual machine when a test failover, live failover, move, clone, or backup is being
performed on a VPG that contains the virtual machine.
■ Zerto Virtual Replication does not support disks larger than 2TB.
■ You cannot recover files or folders from the Zerto plugin.

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Recovering Files and Folders 158
Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Recovering Files and Folders

Recovering Files and Folders

The procedure to recover files and folders involves the following steps:
1. “Mounting the Disk that Contains the Required Files and Folders”, on page 159
Note: While the disk is mounted:
■ If you start a live failover or move, Zerto Virtual Manager forcibly unmounts the disk so the live failover or move can be
performed.
■ Manual backups fail.
■ You can perform a test failover or clone.
2. “Downloading the Files and Folders from the Disk”, on page 162

Mounting the Disk that Contains the Required Files and Folders
Before you can recover files or folders, you must first select the checkpoint in time from which you will recover the files or
folders. Then you must select and access the disk in which the files or folders are contained.

To mount a disk that includes files and folders to restore:

1. From either the protected or recovery site, select ACTIONS > RESTORE FILE.
The File and Folder Restore wizard is displayed.

The list of all protected virtual machines is displayed. You can only recover files or folders from one virtual machine at a
time.
2. Select the virtual machine on which the file or folder is located and click NEXT.

Recovering Files and Folders 159

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Recovering Files and Folders

The CHECKPOINT step is displayed. By default, all checkpoints are displayed.

3. Select the checkpoint from which to recover the file or folder.

■ Auto: Checkpoints generated by the Zerto Virtual Manager are displayed.
■ VSS: Checkpoints that were synchronized with VSS snapshots are displayed. When VSS is used, recovery to the latest
VSS snapshot ensures that the data is both crash-consistent and application consistent to this point. The frequency of
VSS snapshots determines how much data can be recovered.
■ Tagged: Checkpoints that were added by a user, or were added by the Zerto Virtual Manager when a failover test was
performed on the VPG that included the virtual machine, or when the virtual machine was added to an existing VPG
after the virtual machine was synchronized.
4. Click NEXT.

Recovering Files and Folders 160

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Recovering Files and Folders

The DISK step is displayed. All disks associated with the selected virtual machine are displayed.

o
5. Select a disk to mount and click NEXT.
The MOUNT step is displayed. The settings you selected are displayed.

6. Click START MOUNT to mount the disk.

Mounting the disk may take some time, depending on the selected checkpoint and the number of files and folders on the
disk.
■ When the first part of the restore process is done, icons appear next to the completed task.
■ By clicking the folder icon ( ) you can browse the folders and files on the disk.
■ By clicking the unmount icon ( ) you can unmount the disk without restoring any files or folders.

Recovering Files and Folders 161

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Recovering Files and Folders

7. Continue with “Downloading the Files and Folders from the Disk” on page 162.

Downloading the Files and Folders from the Disk

In this procedure you select the files and folders. The files are downloaded to the machine where you run the Zerto User
Interface. Make sure that this machine has enough space for the recovered files.

To download folders or files:

1. Click the folder icon ( ).

Recovering Files and Folders 162

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Recovering Files and Folders

The File and Folder Restore dialog is displayed.

2. Click NEXT.
The FILE/FOLDER step is displayed.

3. Select the files and folders you want to download.

Recovering Files and Folders 163

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Recovering Files and Folders

The selected files or folders are displayed in the right pane of the dialog. The number of items selected is displayed and the
size of the selected files is also displayed.

4. Click NEXT.
The DOWNLOAD step is displayed. It shows the files and folders you selected for downloading. By default, when you select
multiple files or one or more folders, the data is compressed before it is downloaded. If you select only one file, for
download, you can choose whether or not the file is compressed.

5. Click START DOWNLOAD.

The files and folders are downloaded by default to the downloads folder on the computer where you run the Zerto User
Interface.

Recovering Files and Folders 164

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Recovering Files and Folders

Note: Saving the files and folders to a network share is dependent on the browser used to display the Zerto User Interface
and the settings for this browser.
■ When you select one file to download, and do not compress the file, the name of the downloaded file is the name of
the file. For example, if you download a file called Important-file.docx, the name of the file on your computer will
be Important-file.docx.
■ When you choose one file and choose to compress it, or you select multiple files, the files are zipped into a file called
ZertoDownloads.zip.
6. Zerto recommends that you unmount the disk after the files or folders are downloaded. To unmount the disk, click the
unmount icon ( ).

Recovering Files and Folders 165

 CHAPTER 17: FAILING BACK
(MOVING) FROM AZURE TO AN
ON-PREMISE SITE
If you have moved, or failed over a VPG to Microsoft Azure, you can failback these VPGs to the following original on-premise
platforms:
■ VMware vSphere
■ Microsoft Hyper-V
You can failback both Windows and Linux machines.
The following topics are described in this section:
■ “The Failback (Move) Process”, below
■ “Initiating a Failback (Move)”, on page 167
■ “Reverse Protection For a Moved VPG”, on page 172

The Failback (Move) Process

The failback process uses the MOVE wizard, following a disaster, to recover failed over virtual machines from Azure, back to
the original on-premise site. You can initiate the MOVE operation from either the Azure site or the on-premise recovery site.
The MOVE process differs from a FAILOVER in the following ways:
■ To ensure data integrity during a MOVE, the protected virtual machines are powered off completely and a final checkpoint
is created so that there is no data loss before the move is implemented.
■ The MOVE process supports moving VMs with multiple volumes. The disks all have to exist in the Zerto Storage Account.
When you perform a planned migration of virtual machines to a recovery site, Zerto Virtual Replication assumes that both sites
are healthy and that you plan to relocate the virtual machines in an orderly fashion without loss of data. By setting a commit
policy that enables checking the recovered machines before committing the Failback (Move), you can check the integrity of the
recovered machines. If the machines are in the expected state and functioning correctly, you can commit the MOVE.
The Failback (MOVE) process has the following basic steps:
■ Creating the virtual machines at the remote site in the production network and attaching each virtual machine to its
relevant virtual disks, configured to the checkpoint specified for the failback. As long as the virtual machines are created,
the operation is considered successful, even if the virtual machines are not created with their complete definition, for
example if re-IP cannot be performed.
■ Powering on the virtual machines making them available to the user. If applicable, the boot order defined in the VPG
settings is used to power on the machines.
Note: If the virtual machines do not power on, the process continues and the virtual machines must be manually powered
on. The virtual machines cannot be powered on automatically in a number of situations, such as when there are not enough
resources in the resource pool or the required MAC address is part of a reserved range or there is a MAC address conflict
or IP conflict, for example, if a clone was previously created with the MAC or IP address.
■ The default is to automatically commit the Failback (Move) operation without testing. However, you can also run basic
tests on the machines to ensure their validity to the specified checkpoint. Depending on the commit/rollback policy that
you specified for the operation, after testing either the operation is committed, finalizing the Failback (Move), or rolled
back, aborting the operation.
■ If Keep Source VMs is not selected, the protected virtual machines are removed from Azure.
Note: If Keep Source VMs is not selected, and the virtual machines, or vCD vApps are also protected in other VPGs, The
following occurs:
■ The virtual machines and vCD vApp are deleted from the protected site.
■ The checkpoints of the VPG are retained.
■ The deleted vCD vApp can no longer be recovered.
In the event of vCD vApp or if no other virtual machines are left to protect, the entire VPG will be removed.
■ VPGs enter a state of pause and pause replication if the following conditions apply:

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Failing Back (Moving) from Azure to an On-Premise Site 166
Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Failing Back (Moving) from Azure to an On-Premise Site

■ The ZVM on the protected and recovery sites are of version 5.5 and higher.
■ The VRA installed on the recovery site is of version 5.5 and higher.
Protecting virtual machines or a vCD vApp in several VPGs is enabled if:
■ The protected site and the recovery site are of version 5.0 and higher
■ The VRAs installed on these sites are of version 5.0 and higher.
■ Protecting virtual machines or vCD vApps in several VPGs is enabled only if both the protected site and the
recovery site, as well as the VRAs installed on these sites, are of version 5.0 and higher.
■ If Reverse Protection is specified for the Failback (Move) operation, the protected virtual machines in Azure are placed in a
Stopped (Deallocated) state. The virtual disks previously used by the virtual machines in the protected Azure site are used
for reverse protection. A sync is required since the recovered machines can be updated while data is being promoted. The
VPG’s are reverse protected back to Azure, and an Initial Sync is performed as preseeding is not supported.
■ The data from the journal is promoted to the machines. The machines can be used during the promotion and Zerto Virtual
Replication ensures that the user sees the latest image, even if this image, in part, includes data from the journal.

Failback (Move) After the Original Site is Operational

To fail back (Move) to the original protected site, the VPG that is now protecting the virtual machines at the recovery site have
to be configured, if reverse protection was not selected, and then a Delta Sync is performed with the disks at the original
protected site. Once the VPG is in a protecting state the virtual machines can be moved back to the original protected site, as
described in “Migrating a VPG to a Recovery Site”, on page 271.

Initiating a Failback (Move)

You can initiate a Failback (Move), whereby the virtual machines in the virtual protection group (VPG) are replicated to a set
checkpoint in the on-premise recovery site. As part of the process you can also set up reverse protection, whereby you create a
VPG on the recovery machine for the virtual machines being replicated, pointing back to the Azure site.
You can initiate a Failback (Move) to the last checkpoint recorded in the journal, even if the protected site is no longer up. You
can initiate a Failback (Move) during a test.
If the protected site is operational, the Failback (Move) can be initiated from the protected site, however if the protected site is
down, you can initiate the Failback (Move) from the recovery site.

Initiating a Failback (Move) 167

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Failing Back (Moving) from Azure to an On-Premise Site

To initiate a Failback (Move):

1. In the Zerto User Interface select ACTIONS > MOVE VPG.
The Move wizard is displayed.

2. Select the VPGs to failover. By default, all VPGs are listed.

At the bottom, the selection details show the amount of data and the total number of virtual machines selected.
The Direction arrow shows the direction of the process: From the protected site To the peer, recovery, site.
3. Click NEXT.
The EXECUTION PARAMETERS step is displayed.

You can change the following values to use for the recovery:
■ Commit Policy
■ Force Shutdown - Select Yes / No. Selecting YES places the VMs in a Stopped (Deallocated) state.
■ Reverse Protection settings. For more information see “Reverse Protection For a Moved VPG”, on page 172.
■ Keep Source VMs - Prevents removal of the protected virtual machines at the Azure site.
Note: If reverse protection is specified, the Keep Source VMs option is grayed out because the virtual disks of the VMs
are used for replication and cannot have VMs attached. If Keep Source VMs is selected before reverse protection is

Initiating a Failback (Move) 168

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Failing Back (Moving) from Azure to an On-Premise Site

specified, the Keep Source VMs selection is canceled.

4. To change the commit policy, click the field or select the VPG and click EDIT SELECTED.
a) To commit the recovery operation automatically, with no testing, select Auto-Commit and 0 minutes.
b) Select None if you do not want an automatic commit or rollback. You must manually commit or roll back.
c) To test before committing or rolling back, specify an amount of time to test the recovered machines, in minutes.
This is the amount of time that the commit or rollback operation is delayed, before the automatic commit or rollback
action is performed.
During this time period, check that the new virtual machines are OK and then commit the operation or roll it back.
The maximum amount of time you can delay the commit or rollback operation is 1440 minutes, which is 24 hours.
Testing that involves I/O is done on scratch volumes.
■ The more I/Os generated, the more scratch volumes are used, until the maximum size is reached, at which point no
more testing can be done.
■ The maximum size of all the scratch volumes is determined by the journal size hard limit and cannot be changed.
■ The scratch volumes reside on the storage defined for the journal.
To specify reverse protection, whereby the virtual machines in the VPG are failed over to the recovery site and then
protected in the recovery site, back to the original site, either:
■ Click REVERSE PROTECT ALL. This activates reverse protection on all the VPGs that you plan to Failback. The system
default values for this procedure will be assigned to all the VPGs.
-or-
■ Click the Reverse Protection field.
If you want to configure the VPG for reverse protection, click the REVERSE link.
The Edit Reverse VPG wizard is displayed and you can edit the reverse protection configuration. The parameters are the
same as described when you create a VPG, described in “To protect from a VCenter server to a recovery site vCenter
server:”, on page 114, with the following differences:
■ You cannot add or remove virtual machines in the reverse protected VPG.
■ By default, reverse protection is to the original protected disks. You can specify a different storage to be used for the
reverse protection.
■ If VMware Tools or Microsoft Integration Services are available for vSphere or Hyper-V respectively, for each virtual
machine in the VPG, the IP address of the originally protected virtual machine is used. Thus, during failback the
original IP address of the virtual machine on the site where the machine was originally protected is reused. However, if
the machine does not contain the utility, DHCP is used. The host version must be 4.1 or higher for re-IP to be enabled.
When committing the Failback, you can reconfigure reverse protection, regardless of the reverse protection settings
specified here. For more information see “Reverse Protection For a Moved VPG”, on page 172.
5. Click NEXT.
■ A warning appears informing the user that the virtual machines or vCD vApp will be removed from the other VPGs
that are protecting them.
■ If your VPG has a vCD vApp, or if there are no other virtual machines left to protect, the entire VPG will be removed.
6. Click OK.

Initiating a Failback (Move) 169

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Failing Back (Moving) from Azure to an On-Premise Site

The MOVE step is displayed. The topology will show the VPGs and the virtual machines that are about to be moved from
Azure to the on-premise site.

7. Click START MOVE to start the Failback.

8. If a commit policy was set with a timeout greater than zero, as described in step 4, you can check the moved virtual
machines on the recovery site before they are removed from the protected site.

Note: If a virtual machine exists on the recovery site with the same name as a virtual machine being migrated, the machine
is moved and named in the peer site with a number added as a suffix to the name, starting with the number 1
The status icon changes to orange and an alert is issued, to warn you that the procedure is waiting for either a commit or
rollback.
All testing done during this period, before committing or rolling back the Move operation, is written to thin-provisioned
virtual disks, one per virtual machine in the VPG. These virtual disks are automatically defined when the machines are
created on the recovery site for testing. The longer the test period the more scratch volumes are used, until the maximum
size is reached, at which point no more testing can be done. The maximum size of all the scratch volumes is determined by
the journal size hard limit and cannot be changed. The scratch volumes reside on the storage defined for the journal. Using
these scratch volumes makes committing or rolling back the Move operation more efficient.

Initiating a Failback (Move) 170

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Failing Back (Moving) from Azure to an On-Premise Site

Note: You cannot take a snapshot of a virtual machine before the Move operation is committed and the data from the
journal promoted to the moved virtual machine disks, since the virtual machine volumes are still managed by the VRA and
not directly by the virtual machine. Taking a snapshot of a machine that is in the process of being moved will corrupt that
machine.
9. After checking the virtual machines on the recovery site, choose one of the following:
■ Wait for the specified Commit Policy time to elapse, and the specified operation, either Commit or Rollback, is
performed automatically.
■ Click the Commit or Rollback icon ( ) in the specific VPG tab.
■ Click Commit to confirm the commit and, if necessary set, or reset, the reverse protection configuration. If the
protected site is still up and you can set up reverse protection, you can reconfigure reverse protection by checking
the Reverse Protection checkbox and then click the Reverse link. Configuring reverse protection here
overwrites any of settings defined when initially configuring the failover.
■ Click Rollback to roll back the operation, removing the virtual machines that were created on the recovery site and
rebooting the machines on the protected site. The Rollback dialog is displayed to confirm the rollback.

You can also commit or roll back the operation in the TASKS popup dialog in the status bar or under
MONITORING > TASKS.
After the virtual machines are up and running and committed in the recovery site, the powered off virtual machines in the
protected site are removed from Azure. Finally, data is promoted from the journal to the moved virtual machines.
During promotion of data, you cannot move a host on the moved virtual machines. If the host is rebooted during promotion,
make sure that the VRA on the host is running and communicating with the Zerto Virtual Manager before starting up the
recovered virtual machines.
Note: If the virtual machines do not power on, the process continues and the virtual machines must be manually powered on.
The virtual machines cannot be powered on automatically in a number of situations, such as when there are not enough
resources in the resource pool or the required MAC address is part of a reserved range or there is a MAC address conflict or IP
conflict, for example, if a clone was previously created with the MAC or IP address.
When a vCD vApp is moved to a vCenter Server recovery site, a vCenter Server vCD vApp is created in the recovery site. If
reverse protection was specified, the VPG state is Needs Configuration and the VPG must be recreated by protecting the
virtual machines in the vCD vApp as separate machines and not as part of the vCD vApp.

Initiating a Failback (Move) 171

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Failing Back (Moving) from Azure to an On-Premise Site

Reverse Protection For a Moved VPG

When moving the virtual machines in a VPG you specify whether you want reverse protection from the recovery site back to
the original protected site.

Reverse Protection Specified

When you specify reverse protection, the virtual machines are moved to the recovery site and then protected using the values
specified during the move. Data is promoted from the journal to the moved virtual machines and then synchronization with the
original site is performed so that the VPG is fully protected. Preseeded disks are not supported at Azure sites, and when reverse
protection is to an Azure site, an Initial Sync is performed. A sync is required since the recovered machines can be updated
while data is being promoted.

Reverse Protection for VMs protected in multiple VGS (One-to-Many)

Zerto Virtual Replication enables you to protect virtual machines in a maximum of three VPGs. These VPGs cannot be
recovered to the same site.
If Reverse Protection is selected, and the virtual machines are already protected in other VPGs, the following occurs:
■ The vCD vApp are deleted from the protected site.
■ The replication of other VPGs containing these machines is paused.
■ The recovery of all the virtual machines, including the virtual machine removed from the protected site, is possible.

To resume replication do the following:

1. Open the Edit VPG wizard.
2. Select the virtual machine that was previously removed from the protected site.
3. Remove the virtual machine from the VPG.

To resume replication do the following:

1. Open the Edit VPG wizard.
2. Select the virtual machine that was previously removed from the protected site.
3. Remove the virtual machine from the VPG.
If the protected VPG contains a vCD vApp, and the vCD vApp is protected in other VPGs, Reverse Protection is selected, the
following occurs:
■ The vCD vApp is deleted from the protected site.
■ The checkpoints of the VPG are retained.
■ The deleted vCD vApp can no longer be recovered.
In the event of vCD vApp or if no other virtual machines are left to protect, the entire VPG will be removed.
VPGs enter a state of pause and pause replication if the following conditions apply:
■ The ZVM on the protected and recovery sites are of version 5.5 and higher.
■ The VRA installed on the recovery site is of version 5.5 and higher.
Protecting virtual machines or a vCD vApp in several VPGs is enabled if:
■ The protected site and the recovery site are of version 5.0 and higher
■ The VRAs installed on these sites are of version 5.0 and higher.

Reverse Protection For a Moved VPG 172

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Failing Back (Moving) from Azure to an On-Premise Site

Reverse Protection Not Specified

If you do not specify reverse protection, the protected disks are removed along with the protected virtual machines at the end
of the procedure. In this case, if you want to move the virtual machines back again to the original site, you will not be able to use
the original disks and an Initial Sync will have to be performed. The VPG definition is kept with the status Needs Configuration
and the reverse settings in the VPG definition are not set.
Clicking EDIT VPG displays the Edit VPG wizard with the settings filled in, using the original settings for the virtual machines in
the VPG from the original protected site, except for the volumes, since the last step of the Move operation is to delete the
virtual machines from the original protected site inventory, including the disks. To start replicating the virtual machines in the
VPG, specify the disks to use for replication and optionally, make any other changes to the original settings and click DONE. An
initial synchronization is performed.
Notes:
■ If Keep Source VMs is not selected, and virtual machines or vCD vApp are already protected in several VPGs, the virtual
machines or vCD vApp are deleted from the protected site. This will result in the removal of these virtual machines from
other VPGs that are protecting them and to the journals of these VPGs to be reset. In the event of vCD vApp or if no other
virtual machines are left to protect, the entire VPG will be removed.
Protecting virtual machines or vCD vApps in several VPGs is enabled only if both the protected site and the recovery site,
as well as the VRAs installed on these sites, are of version 5.0 and higher.
■ You can edit the VPG definition from either of the sites, the site where the VPG virtual machines were initially protected or
the site they were moved to.

Reverse Protection For a Moved VPG 173

 CHAPTER 18: OFFSITE BACKUP
CONFIGURATION

When using Zerto Virtual Replication for offsite backups, you must first define the repository that will be used to store the
backups.
Disaster recovery using Zerto Virtual Replication enables recovering from a disaster to any point between the moment just
before the disaster and a specified amount of time in the past up to 30 days. The recovery is done in real time at the recovery
site with a minimal RTO.
If there is an additional requirement to extend the recovery ability to more than 30 days, Zerto Virtual Replication provides an
offsite back up option that enables saving the protected virtual machines offsite for up to one year in a state where they can be
easily deployed.
The virtual machine files are saved in a repository for the required period. Each virtual machine can have multiple offsite
backups created according to a fixed schedule.
The offsite backups are managed by a Windows service, the Virtual Backup Appliance (VBA). The VBA is installed as part of
the Zerto Virtual Replication installation. During an offsite backup, the VBA communicates with the VRAs on the recovery site
to create the virtual machine files, such as the configuration and virtual disk files in a repository. The offsite backups are fixed
points saved either weekly or monthly in the repository. Before you can create an offsite backup for virtual machines, you must
first create one or more repositories for the offsite backup jobs.
The following offsite backup set up options are described in this section:
■ “Creating an Offsite Backup Repository”, below
■ “Editing an Offsite Backup Repository”, on page 176

Creating an Offsite Backup Repository

You define the repositories where offsite backups are defined on the recovery site and can be stored, either locally at the
recovery site, or on a network share that uses the SMB, Server Message Block, protocol. The repository where you want this
offsite backup stored is specified when an offsite backup is defined.

To create an offsite backup repository:

1. In the Zerto User Interface, click SETUP > REPOSITORIES.
2. Click NEW REPOSITORY.

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Offsite Backup configuration 174
Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Offsite Backup configuration

The New Repository dialog is displayed.

3. Specify the following settings:

Repository Name – Specify a unique name for the repository.
Repository Type – Specify the type of repository. The options are Local or Network Share (SMB). If Local is specified,
backups are stored on the local machine where the Zerto Virtual Manager is installed. If SMB is specified, the network
share drive must be an SMB drive and if specified the username and password to access the drive must be provided. If the
repository location is a network drive, this drive can be mounted to third party storage, such as Azure Backup Service
enabling you to save your offsite backups to a cloud repository mounted disk as if you are using a LAN or locally mounted
drive. You can mount one or more Azure storage accounts as network drives or as removable local drives, and to use them
exactly as you would use any other drive folder on your computer.
Username – Username to access the Network Share drive. The name can be entered using either of the following formats:
■ username
■ domain\username
This field is not displayed when the type is Local.
Password – Password to access the Network Share drive. This field is not displayed when the type is Local.
Path – The path where the repository will reside. The path must be accessible from the Zerto Virtual Manager, so if the
repository is on a different domain to the Zerto Virtual Manager, the domain must be included in the path.
Enable Compression – Check this option to compress backups stored in the repository. Compression is done using zip
compression, set to level six. If you want better compression, which requires more CPU, or less compression to reduce the
CPU overhead, contact Zerto support.
Set as Default Repository– Check if you want the repository to be used as the default when specifying extended recovery
in a VPG.
4. Click VALIDATE.You must validate the path specified. If the folder does not exist, you are asked if you want to create it.
5. Click SAVE.

Creating an Offsite Backup Repository 175

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Offsite Backup configuration

The repository is created.

You can define more than one repository. When defining offsite backup, you specify which repository to use.

Editing an Offsite Backup Repository

You edit the repositories from the Repositories tab.

To edit an offsite backup repository:

1. In the Zerto User Interface, click SETUP > REPOSITORIES.
2. Select the repository to edit and click the edit, pencil, icon.
The Edit Repository dialog is displayed.
Edit any of the following settings:
Repository Name – Specify a unique name for the repository.
Repository Type – Either specify that the repository resides on a local or shared network disk, using the SMB protocol,
accessible from the recovery site. If the repository location is a network drive, this drive can be mounted to third party
storage, such as Amazon Web Services, AWS, or Microsoft Azure.
Username – Username to access the Network Share drive. The name can be entered using either of the following formats:
■ username
■ domain\username
This field is not displayed when the type is Local.
Password – Password to access the Network Share drive. This field is not displayed when the type is Local.
Path – The path from the recovery site where the repository will reside. The path must be accessible from the Zerto Virtual
Manager, so if the repository is on a different domain to the Zerto Virtual Manager, the domain must be included in the
path.
Enable compression – Check this option to compress backups stored in the repository. Compression is done using zip
compression, set to level six. If you want better compression, which requires more CPU, or less compression to reduce the
CPU overhead, contact Zerto support.
Note: Compression usually reduces the effectiveness of deduplication on stored data. If the backup repository resides on a
deduplication-enabled storage appliance, it is recommended that the data be stored uncompressed.

Editing an Offsite Backup Repository 176

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Offsite Backup configuration

Note: Backup to TntDrive with compression enabled is not supported.

Set as default repository– Check if you want the repository to be used as the default when specifying extended recovery in
a VPG.
3. Click VALIDATE.You must validate the path specified. If the folder does not exist, you are asked if you want to create it.
4. Click SAVE.
The updated definition of the repository is saved.

Editing an Offsite Backup Repository 177

 CHAPTER 19: ZERTO VIRTUAL
REPLICATION REPORTS

Zerto Virtual Replication includes reporting for the following:

■ “Outbound Protection Over Time Report”, below
■ “Recovery Reports”, on page 178
■ “Recovery Reports”, on page 178
■ “Resources Report”, on page 180
■ “VPG Performance”, on page 184
■ “Backup Report”, on page 185

Outbound Protection Over Time Report

Information about how much data is actually being protected against the amount configured for any of the sites can be
displayed in the Outbound Protection Over Time report under the REPORTS tab.
The data displayed can be up to 30 minutes old, since the Zerto Virtual Manager collects the relevant data every 30 minutes.

You can filter the information by the following:

From and To – The dates for which you want information.
Recovery Site – Select the site for which you want information or select all sites. If all sites are selected, All is displayed. The
dropdown list displays all sites paired with the local site.
Click APPLY to apply the selected filtering and produce the report.
Click RESET to reset the display to the default values.

Recovery Reports
Information about recovery operations — failover tests, moves, and failovers — can be displayed in Recovery Reports under the
REPORTS tab. The information includes the following:
■ The name of the virtual protection group (VPG) on which the operation was done
■ The type of operation

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Zerto Virtual Replication Reports 178
Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Zerto Virtual Replication Reports

■ The protected and the recovery sites involved

■ When the recovery operation was started
■ The RTO
■ Whether the operation succeeded or not
■ Any notes added during a failover test
Recovery Reports are always kept, and never deleted.

You can filter the tests by the following:

From and To – The dates for which you want information. Only operations performed between these dates are displayed.
VPG – Select the VPGs for which you want information. The number of VPGs you selected is displayed. If you select All, the
total number of VPGs is shown.
Type – Select the recovery operations for which you want information: Failover, Move, Failover Test. If more than one
operation is selected, the number of recovery operations you selected is displayed.

Recovery Reports 179

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Zerto Virtual Replication Reports

Status – Select the statuses for which you want information: Success, Failed. If more than one status is selected, the number
of statuses you selected is displayed.
Click APPLY to apply the selected filtering.
Click RESET to reset the display to the default values.
Click EXPORT and choose PDF or ZIP to generate a report.
If the report is exported to a PDF, information is displayed by VPG and then by virtual machine within the VPG. The following
information is described in the report.
■ The date and time when the report was generated.
The Recovery Operation Details include the following information:
■ The name of the person who initiated the operation
■ The type of recovery operation
■ The point in time
■ The start time
■ The end time
■ RTO
■ The result
■ Notes
The Virtual Protection Group Recovery Settings includes the following:
■ The name of the protected site
■ The name of the recovery site
The Virtual Machine Recovery Settings, which include the following:
■ The name of the virtual machine
■ Any custom settings
The Detailed Recovery Steps, which include the following:
■ The step number
■ The description of the step (for example, creating a machine and scratch volumes for testing)
■ Whether the step was successful or not
■ The start and end time of the step
■ The time it took to complete the step
Note: When failover test (FOT) is still in progress, the End Time in the Recovery Report appears as NA.
The Recovery Operation Start Time and Recovery Operation End Time values are shown in UTC according to the Zerto Virtual
Manager clock in the recovery site. The Point in Time value takes the checkpoint UTC time, which was created in protected site,
and converts it to the recovery site time zone.

Branding the Recovery Report

A branded logo can be placed in the report in the top left corner by adding the logo as a .png file to the
<ZertoInstallFldr>\Zerto\Zerto Virtual Replication\gui\ folder with the name provider_logo.png.
The folder ZertoInstallFldr is the root folder where Zerto Virtual Replication in the recovery site is installed. For
example, C:\Program Files\Zerto.

Resources Report
Information about the resources used by the virtual machines being recovered to a particular site is displayed in the Resources
report under the REPORTS tab. The information is collected at fixed times that are defined in the Reports tab of the Site Settings
dialog in the recovery site. Information for the report is saved for 90 days when the sampling period is hourly and for one year
when the sampling period is daily.

Resources Report 180

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Zerto Virtual Replication Reports

The report collects the resource information for the virtual machines being recovered to the site where the report is run.
If no virtual machines are recovered to the site where the report is run, the report is empty.
You can filter the information by the following:
From and To – The dates for which you want information.
Click EXPORT to generate the report, which is produced as an Excel file.
The information presented in this report is divided into three tabs:
Details Tab – Shows information for each protected virtual machine.
Performance Tab – Shows bandwidth and throughput information for each virtual machine in a table and in a graph.
Target Host Tab – Shows information per host in the recovery site.

Using a REST API to Generate a Report

Zerto Virtual Replication exposes a REST API to produce resource data. The report is generated by passing a URL. For details
about the ResourcesReport API (and all other Zerto Virtual Replication REST APIs), see the Zerto Virtual Replication RESTful API
Reference Guide.

Details Tab
The Details tab includes the names and IDs of the virtual machines being protected and, for each virtual machine, the
timestamp for the information, where it is protected, the CPU used, the memory used by the host and the guest, the storage
used, and other information.

Interpreting the Details Tab

The Details tab provides a breakdown of every protected virtual machine, identified by its internal identifier and name in the
hypervisor manager. The report also includes the name of the VPG that is protecting the virtual machine and information such
as the protected and recovery sites.
The Timestamp column displays the time when the last sample, as defined in the Reports tab of the Site Settings dialog, was
taken.
The VPG Type column is one of:
VC2VC – vCenter to vCenter replication
VC2VCD – vCenter to vCloud Director replication
VCD2VCD – vCloud Director to vCloud Director replication
VCD2VC – vCloud Director to vCenter replication
The ZORG column defines organizations set up in the Zerto Cloud Manager that use a cloud service provider for recovery.
The Bandwidth (Bps) and Throughput (Bps) columns display the average between two consecutive samples. With daily
samples, these figures represent the average daily bandwidth and throughput. For hourly samples, the timestamp represents
an average between the sample at the timestamp and the previous sample. A value of -1 means that the system failed to
calculate the value, which can happen for several reasons, for example:
■ Sites were disconnected when the sample was collected. Although the protected site measures the throughput and
bandwidth, the recovery site logs the results.
■ The bandwidth or throughput values at the time of the sample was lower than the bandwidth or throughput value in the
previous sample. This can happen, for example, if the protected site VRA is rebooted since the sample values are not
stored persistently by the VRA.
■ If valueInLastSample does not exist, since currentValue is the first sample for the virtual machine, the data is not
calculated.

Resources Report 181

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Zerto Virtual Replication Reports

Bandwidth is calculated as: (currentValue – valueInLastSample)/elapsedTtime

For example:
TIME ACTION/DESCRIPTION
2:29:59.999 A virtual machine is placed in a VPG
2:30 A sample is generated. The total transmitted bytes is zero since the virtual machine was just placed in the
VPG
2:30-2:59.999 The VM is writing data at 1MB/minute
3:00 The virtual machine lowers its write rate to 0.5MB/minute
3:30 A new sample is calculated. Current value of total data transmitted is 45MB:
1MB/minute)*(30 minutes) + (0.5MB/minute)*(30 minutes)
Last value of total data transmitted is 0, from the 2:30 sample.
Bandwidth = (45MB-0)/(60 minutes) = 0.75MB/minute = 13107Bps

Report output fields

The following describes the fields in the Details tab.
PARAMETER DESCRIPTION
Active Guest Memory (MB) The active memory of the virtual machine.
Bandwidth (Bps) The average bandwidth used between two consecutive samples, in bytes per second.
Consumed Host Memory (MB) The amount of host memory consumed by the virtual machine.
CPU Limit (MHz) The maximum MHz available for the CPUs in the virtual machine.
CPU Reserved (MHz) The MHz reserved for use by the CPUs in the virtual machine.
CPU Used (MHz) The MHz used by the CPUs in the virtual machine.
CrmId The CRM identifier specified in Zerto Cloud Manager for an organization that uses a
cloud service provider for recovery.
Memory (MB) The virtual machine defined memory.
Memory Limit (MB) The upper limit for this virtual machine’s memory allocation.
Memory Reserved (MB) The guaranteed memory allocation for this virtual machine.
Number Of vCPUs The number of CPUs for the virtual machine.
Number Of Volumes The number of volumes attached to the virtual machine.
Recovery Journal Provisioned Storage The amount of provisioned journal storage for the virtual machine. The provisioned
(GB) journal size reported can fluctuate considerably when new volumes are added or
removed.
Recovery Journal Used Storage (GB) The amount of journal storage used by the virtual machine.
Recovery Volumes Provisioned The amount of provisioned storage for the virtual machine in the target site. This
Storage (GB) value is the sum of volumes’ provisioned size.
Recovery Volumes Used Storage (GB) The amount of storage used by the virtual machine in the target site.
Service Profile The service profile used by the VPG.
Source Cluster The source cluster name hosting the virtual machine.
Source Host The source host name hosting the virtual machine.
Source Organization VDC The name of the source vDC organization.
Source Resource Pool The source resource pool name hosting the virtual machine.
Source Site The source protected site name, defined in the Zerto User Interface.
Source vCD Organization The name of the source vCD organization.

Resources Report 182

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Zerto Virtual Replication Reports

PARAMETER DESCRIPTION
Source Volumes Provisioned Storage The amount of provisioned storage for the virtual machine in the source site. This
(GB) value is the sum of volumes’ provisioned size.
Source Volumes Used Storage (GB) The amount of storage used by the virtual machine in the source site. This value is the
sum of the volumes’ used size.
Source VRA Name The name of the source VRA used to send data to the recovery site.
Target Cluster The target cluster name hosting the virtual machine.
Target Datastores The target storage used by the virtual machine if it is recovered.
Target Host The target host name hosting the virtual machine when it is recovered.
Target Organization vDC The name of the target vDC organization.
Target Resource Pool The target resource pool name where the virtual machine will be recovered.
Target Site The target site name, defined in the Zerto User Interface.
Target Storage Profile The target vCD storage profile used.
Target vCD Organization The name of the target vCD organization.
Target VRA Name The name of the VRA managing the recovery.
Throughput (Bps) The average throughput of the VM used between two consecutive samples, in bytes
per second.
Timestamp The date and time the resource information was collected. The value can be
converted to an understandable date using code similar to the following:
var date = new Date(jsonDate);
or code similar to the Perl code example, jsonDateToString($), described in Zerto
Virtual Replication RESTful API Reference Guide.
VM Hardware Version The VMware hardware version.
VM Id The internal virtual machine identifier.
VM Name The name of the virtual machine.
VPG Name The name of the VPG.
VPG Type The VPG type:
VCVpg – VMware vCenter Server
VCvApp – Deprecated
VCDvApp – VMware vCloud Director vApp
PublicCloud – Amazon WebServices or Microsoft Azure
HyperV – Microsoft SCVMM
ZORG The name assigned to an organization using a cloud service provider for recovery. The
name is created in the Zerto Cloud Manager. For details, see the Zerto Cloud Manager
Administration Guide.

Performance Tab
The Performance tab shows bandwidth and throughput information for each virtual machine per sampling period in a table and
in a graph. The Performance tab enables the user to view the total bandwidth and throughput per sampling period.
The graph allows the user to view performance trends over time per VM.
For full explanation of the bandwidth and throughput information, refer to the “Details Tab”, on page 181.
You can filter information by date and VM name.

Resources Report 183

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Zerto Virtual Replication Reports

The following describes the fields in the Performance tab:

PARAMETERS DESCRIPTION
Time Stamp For explanation see the Details tab.
Bandwidth (Bps) The average bandwidth of the VM used between two consecutive samples, in bytes
per second.
Throughput (Bps) The average throughput of the VM used between two consecutive samples, in
bytes per second.
Total Bandwidth The total bandwidth of all VMs during the measured period.
Total Throughout The total throughput of all VMs during the measured period.

Target Host Tab

The Target Host tab shows information per host in the recovery site. This enables the user to perform capacity planning on the
recovery host. You can filter information by time and by host.
The following describes the fields in the Target Host tab.
PARAMETERS DESCRIPTION
Active Guest Memory The active memory of the virtual machine.
(MB)
CPU Used (MHz) The MHz used by the CPUs in the virtual machine.
Host The Target Host's IP address or DNS name.
Total Bandwidth The total bandwidth of all VMs replicating to the host during the measured period.
Total Throughput The total throughput of all VMs replication to the host during the measured period.
vCPUs The number of CPUs for the virtual machine.
VMs The number of VMs protected.
Volumes The number of volumes attached to the virtual machine.

VPG Performance
Performance graphs for all VPGs or for an individual VPG can be seen in the VPG Performance report under the REPORTS tab.
These graphs show more detailed resolution than the corresponding graphs in the DASHBOARD tab.
You can specify the VPGs whose performance should be displayed. When you request information about multiple VPGs, each
VPG is shown in a different color, with a key at the top of the report that maps each color to the VPG it represents.
Position the cursor on a graph line to see exact information about that point.
Click APPLY to apply the selected filtering and produce the report.
Click RESET to reset the display to the default values.

VPG Performance 184

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Zerto Virtual Replication Reports

Backup Report
Information about offsite backups can be sent as a report every day or weekly on a specified day. To set up the report, select
Site Settings > Email Settings.

Enter an email address to receive Zerto Virtual Replication backup reports.

SMTP Server Address – The SMTP server address of the hypervisor manager. The Zerto Virtual Manager must be able to
reach this address.
SMTP Server Port – The SMTP server port, if it was changed from the default, 25.
Sender Account– A valid email address for the email sender name.
To – A valid email address where that will receive the email containing the backup reports.
SEND TEST EMAIL button – Tests that the email notification is set up correctly. A test email is sent to the email address
specified in the To field.

To configure backup reports:

1. Select Enable backup reports.
2. Specify whether you want a backup report sent daily or weekly.
Daily – Sends a daily backup report.
Weekly – Sends a weekly backup report. Select the day of the week from the dropdown list.
3. Specify the time of day to send the backup report.
The backup report is sent as HTML with the following information:
■ A summary listing every VPG for which an offsite backup job has run. The summary information includes the following:
■ An entry for each backup job that was run.
■ The result of the job: successful, partial successful, or failed.
A partially successful job means that some, but not all, of the virtual machines were successfully backed up.
■ The time the job started.
■ The time the job completed.
■ The duration of the job.
■ The size of the backup that was stored in the repository.
■ The type of the job: automatic, meaning a scheduled run, or manually initiated.
■ Summary details of the run.
■ Specific details about the job, including:
■ The name of the ZORG of the VPG.
■ The protected site.

Backup Report 185

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Zerto Virtual Replication Reports

■ The backup site where offsite backup can be restored.

■ The number of virtual machines backed up from the totally number in the VPG.
■ The number of virtual machines only partially backed up.
■ The start and end times of the run and the run duration.
■ The backup size.
■ Whether the backup was scheduled or initiated manually.
■ The repository name.
■ The next time a backup of the VPG is scheduled.
■ The previous run time.

Backup Report 186

 CHAPTER 20: TROUBLESHOOTING

You can handle problems related to the WAN connecting the protecting or recovery sites, or other problems using a variety of
diagnostic and troubleshooting tools.
The following topics are described in this section:
■ “Ensuring the Zerto Virtual Manager is Running”, below
■ “Troubleshooting: “Needs Configuration” Problems”, on page 188
■ “Troubleshooting VRA Problems”, on page 188
■ “Zerto Virtual Replication Diagnostics Utility”, on page 188
■ “Collecting Zerto Virtual Replication Logs”, on page 189
■ “Understanding the Logs”, on page 194
For details about Zerto Virtual Manager alarms, alerts, and events, refer to Zerto Virtual Replication Guide to Alerts and Events.

Ensuring the Zerto Virtual Manager is Running

If you have problems accessing the Zerto User Interface, check under Windows Services, on the machine where Zerto Virtual
Replication is installed, that the Zerto Virtual Manager Windows service is started.

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Troubleshooting 187
Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Troubleshooting

Troubleshooting: “Needs Configuration” Problems

When the VPG status changes to Needs Configuration, the settings in the VPG need to be checked and, when necessary,
updated.

The following scenarios result in the VPG status changing to Needs Configuration:
■ A protected disk resize operation fails, for example when there is not enough disk space.
■ When a volume is added to a protected virtual machine and the VPG settings are not updated because of a site
disconnection or a Microsoft Azure error. In some situations, after the sites reconnect, the state corrects itself
automatically.

Troubleshooting VRA Problems

VPG Syncing Takes a Long Time – Network Problems
Check the network. If the firewall configuration is modified, the VRA TCP connections have to be reset. After a VRA disconnect
and reconnect the system can wait for up to fifteen minutes before syncing the sites after the reconnection.

Zerto Virtual Replication Diagnostics Utility

Zerto Virtual Replication includes a diagnostics utility to help resolve actual and potential problems. Using the diagnostics tool,
you can do the following:
■ Collect logs to help Zerto support resolve problems. The Zerto Virtual Manager must be running on each site for which you
want logs. See “To collect logs for Zerto support to use when troubleshooting:”, below.
■ Collect local Zerto Virtual Manager logs. Use this option if the Zerto Virtual Manager is not running. See “To collect local
Zerto Virtual Manager logs when the Zerto Virtual Manager is not running:”, on page 192.
■ Check the connectivity between Zerto Virtual Replication components. See “To check connectivity between Zerto Virtual
Manager components:”, on page 104.
■ Export VPG settings to an external file and import these settings.
■ Reconfigure access to the Microsoft SQL Server that is used by the Zerto Virtual Manager. This database was specified
during the installation of Zerto Virtual Replication. See “Reconfiguring the Microsoft SQL Server Database Used by the
Zerto Virtual Manager”, on page 110.

Troubleshooting: “Needs Configuration” Problems 188

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Troubleshooting

Note: A separate installation kit is available for download from the Zerto Support Portal downloads page that installs the Zerto
Virtual Replication Diagnostics utility as a standalone utility on any Windows machine that has Microsoft .NET Framework
4.5.2 installed.

Collecting Zerto Virtual Replication Logs

Virtual replication logs can be collected to help Zerto support resolve problems related to Zerto Virtual Replication. Virtual
replication logs can be collected in the following ways:
“Using Remote Log Collection”, below
“Using the Zerto Diagnostics application”, on page 190

Using Remote Log Collection

Remote Log Collection allows customers to authorize Zerto support engineers to collect logs from their environment. By using
remote log collection customers can avoid having to use the Diagnostic Tool on their ZVM server in order to collect logs for
analysis, a potentially complex and time-consuming procedure.

To enable Remote Log Collection:

1. In the Zerto User Interface, click SETTING ( ) in the top right of the header and select Remote Support.
The Remote Support dialog is displayed.

2. Click the drop down menu to display the remote log collection options.

3. Select the remote log collection option you wish to allow:

Never – Remote log collection is not allowed (default). If remote log collection is currently is allowed, it will be terminated
if you select this option.
For the next 30 days -Remote log collection is allowed. This permission will automatically terminate in 30 days unless
terminated by selecting the Never option.
Only for a specific case - You will be prompted to enter the Case number opened via the Salesforce Self-service Portal.
Remote log collection will be allowed for as long as the case is active or until remote log collection is terminated by
selecting the Never option.

Collecting Zerto Virtual Replication Logs 189

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Troubleshooting

4. Click Save.

Using the Zerto Diagnostics application

You can collect logs using the diagnostics tool to help Zerto support resolve problems when the Zerto Virtual Manager is
running or when the Zerto Virtual Manager is not running.
■ When the Zerto Virtual Manager is running, see “To collect logs for Zerto support to use when troubleshooting:”, below.
This option enables you to specify the logs that you want to collect, generated by Zerto Virtual Replication, for example
VRA logs, as well as logs generated by VMware, for example, vCenter Server logs or host logs. The Zerto Virtual
Replication generated logs can be filtered by any alerts issued and by the VPGs that require analysis to identify problems.
■ When the Zerto Virtual Manager is not running, see “To collect local Zerto Virtual Manager logs when the Zerto Virtual
Manager is not running:”, on page 192.
■ You can also collect logs for the ZertoVssAgent. For details, see “Collecting Zerto Virtual Replication Logs”, on page 189.

To collect logs for Zerto support to use when troubleshooting:

1. Open the Zerto Diagnostics application. For example, via Start > Programs > Zerto Virtual Replication > Zerto Diagnostics.
The Zerto Virtual Replication Diagnostics menu dialog is displayed.

2. Select the Collect the Zerto Virtual Replication logs for use by Zerto support option.
3. Click Next.
The Initialize dialog is displayed.

4. Specify the following and click Next.

IP / Host Name – The IP of the Zerto Virtual Manager where the log collection runs from. Logs are collected from this site
and from the paired site.
Port – The port used for inbound communication with the Zerto Virtual Manager.
Your Company Name – A name to identify the log collection for the customer. This information is used by Zerto support.
An account name must be entered. After this information is added, it is displayed in subsequent uses of the diagnostics
utility.
Email – An email address for use by Zerto support when analyzing the logs. An email address must be entered. After this
information is added, it is displayed in subsequent uses of the diagnostics utility.
Timeframe – The amount of time you want to collect logs for. The more time, the bigger the collection package.

Collecting Zerto Virtual Replication Logs 190

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Troubleshooting

Case Number – The case number assigned by Zerto support, if one already exists. Optional.
Description – An optional free text description of the reason for collecting the logs.
After clicking Next the utility connects to the Zerto Virtual Replication and if any alerts have been issued, they are
displayed in the Select Alerts dialog.
If there are no alerts, this dialog is skipped.

5. Select any alerts that need analyzing from the list and click Next.
The Select VPGs dialog is displayed.

6. Select the VPGs that you want analyzed and click Next.
The Customize dialogs are displayed. With Azure these values are not relevant.
7. Click Next until the Save Log Destinations dialog is displayed.

8. Specify destination for the files that you want collected.

Destination – The name and location where the log collection will be saved.
Automatically upload files to Zerto FTP Server – When this option is checked, the log collection is automatically uploaded
to a specified FTP site.
If you choose to upload the log collection to a site that you specify, make sure that the site is up.
9. Specify the FTP site to send the collection and the protocol to use, either FTP or HTTP.

Collecting Zerto Virtual Replication Logs 191

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Troubleshooting

10. Click Next.

The Review dialog is displayed.

Check that you have specified everything you want to collect and if you want to make changes, click Back to change the
selection.
11. Click Start.
The data is collected and stored in the destination file which, by default, is timestamped. If specified, the collection is also
sent to an FTP site.
Note: The log collection is performed on the server. Canceling the collection in the GUI does not stop the collection from
continuing on the server and a new log collection cannot be run until the running collection finishes.
When the log collection has completed the result is displayed. For example:

12. Click Done to return to the Zerto Virtual Replication Diagnostics menu dialog.
13. Send the log to Zerto support, unless the Automatically upload files to Zerto FTP Server option was specified,
in which case it is automatically sent to Zerto.

To collect local Zerto Virtual Manager logs when the Zerto Virtual Manager is not running:
1. Open the Zerto Diagnostics application. For example, via Start > Programs > Zerto Virtual Replication > Zerto Diagnostics.
The Zerto Virtual Replication Diagnostics menu dialog is displayed.
2. Select the Local Zerto Virtual Manager diagnostics option and click Next.

Collecting Zerto Virtual Replication Logs 192

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Troubleshooting

You are prompted to use the first option to collect more comprehensive diagnostics. If you continue, the Initialize dialog is
displayed.

3. Specify the details that you want collected.

IP / Host Name – The IP of the Zerto Virtual Manager where the log collection runs from. Logs are collected from this site
and from the paired site.
Port – The port used for inbound communication with the Zerto Virtual Manager.
Your Company Name – A name to identify the log collection for the customer account. This information is used by Zerto
support. An account name must be entered.
Email – An email address for use by Zerto support when analyzing the logs. An email address must be entered.
Timeframe – The amount of time you want to collect logs for. The more time, the bigger the collection package.
Case Number – An optional field for the case number assigned to the issue by Zerto.
Description – An optional free text description of the reason for collecting the logs.
4. Click Next.
The Save Log Destinations dialog is displayed.
5. Specify the details that you want collected.
Destination – The name and location where the log collection will be saved.
Automatically upload files to Zerto FTP Server – When this option is checked, the log collection is automatically uploaded
to a specified FTP site.
If you choose to upload the log collection to a site that you specify, make sure that the site is up before clicking Finish.
The data is collected and stored in the destination file which, by default, is timestamped. If specified, the collection is also
sent to an FTP site.
6. Click Next.
The collection progress is displayed. When the log collection has completed the result is displayed.

7. Click Done to return to the Zerto Virtual Replication Diagnostics menu dialog.
8. Send the log to Zerto support, unless the Automatically upload files to Zerto FTP Server option was specified,
in which case it is automatically sent to Zerto.

Collecting Zerto Virtual Replication Logs 193

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Troubleshooting

Understanding the Logs

If problems arise with Zerto Virtual Manager, you can view the Zerto Virtual Manager logs to see what is happening.
The current log is called logfile.csv and resides in the <Zerto_Install_Dir>\Zerto Virtual Replication\logs folder,
where Zerto_Install_Dir is the folder specified during the installation.
When the log reaches 10MB its name is changed to log.nnnn.csv, where nnnn is a number incremented by one each time
logfile.csv reaches 10MB. Up to 150 log files are kept.
The log file has the following format:
FFFF, yyyy-mm-dd hh:mm:ss, ####, LVL, Component, API, Message
where:
FFFF – A HEX code. For internal use.
yyyy-mm-dd hh:mm:ss – Timestamp for the message.
#### – Number for internal use.
LVL – Severity level of the message. The more messages written to the log the bigger the impact on performance. The number
of messages written to the log decreases from Debug to Error. The level can be one of the following:
Debug – All messages are written to the log. This level should only be specified during testing.
Info – Information messages.
Warn – Warning messages such as a reconnect ion occurred.
Error – Error messages that need handling to find the problem.
Component – The specific part in the Zerto Virtual Manager that issued the message.
API – The specific API that issued the message.
Message – The message written in the log.
The following is a sample from a log:
07f4c878,2010-12-01 19:54:41.4237,Debug,5,
Zerto.Zvm.RemoteZvmConnector.ResyncingRemoteZvmConnector,
TestConnectivity,TestConnectivity returning true,
07f4c878,2010-12-01 19:54:41.7362,Info,11,
Zerto.Zvm.ZvmServices.Protection.PromotionMonitor,
PromotionMonitoringThreadFunc,Promoting protection groups: ,
07f4c878,2010-12-01 19:54:42.7987,Info,9,
Zerto.Infra.ZvmReaderWriterLock,LogLock,Synchronizer: Enter Writer,
07f4c878,2010-12-01 19:54:42.7987,Info,9,
Zerto.Zvm.ZvmServices.ReconnectingConnectorProxy,
GetConnector,"Connecting IP=106.16.223.86, PORT=4005, attempt (1/3)",
07f4c878,2010-12-01 19:54:42.7987,Debug,9,
Zerto.Zvm.VraConnector.VraNetworkConnector,
Connect,try to connect 106.16.223.86:4005 ...,
07f4c878,2010-12-01 19:54:43.0643,Debug,17,
Zerto.Zvm.ZvmServices.CrossSiteService,Ping,Ping,
07f4c878,2010-12-01 19:54:43.0643,Debug,17,
Zerto.Zvm.ZvmServices.PingService,Ping,Ping called,
07f4c878,2010-12-01 19:54:43.8612,Error,9,
Zerto.Zvm.VraConnector.VraNetworkConnector,
ClearAndThrow,connection is closed: No connection could be made because the target
machine actively refused it 106.16.223.86:4005,
07f4c878,2010-12-01 19:54:43.8612,Warn,9,
Zerto.Zvm.ZvmServices.ReconnectingConnectorProxy,GetConnector,failed,

Understanding the Logs 194

 CHAPTER 21: THE ZERTO VIRTUAL
MANAGER USER INTERFACE

Configuration and management of disaster recovery for a site are performed in the Zerto User Interface.
The following dialogs and tabs are described in this section:
■ “Add Checkpoint Dialog”, below
■ “Add Site Dialog”, on page 197
■ “Add Static Route Dialog”, on page 197
■ “Advanced Journal Settings Dialog”, on page 198
■ “Advanced Journal Settings Dialog (vCD)”, on page 199
■ “Advanced VM Recovery Settings Dialog”, on page 200
■ “Advanced VM Replication Settings Dialog”, on page 201
■ “Advanced VM Replication Settings Dialog (vCD)”, on page 202
■ “Advanced VM Settings for Cloud Dialog”, on page 203
■ “ALERTS”, on page 203
■ “Boot Order Dialog”, on page 204
■ “Browse for File Dialog”, on page 205
■ “Change Host Password VRA Dialog”, on page 205
■ “Change VM Recovery VRA Dialog”, on page 206
■ “Checkpoints Dialog”, on page 207
■ “Configure and Install VRA Dialog”, on page 208
■ “Configure Paired Site Routing Dialog”, on page 209
■ “Configure Provider vDCs Dialog”, on page 210
■ “Configure VM Settings Dialog”, on page 211
■ “Configure Volume Dialog (vCD)”, on page 211
■ “Edit NIC Dialog”, on page 212
■ “Edit Selected Volumes Dialog”, on page 213
■ “Edit VM Dialog”, on page 213
■ “Edit VM Dialog (vCD)”, on page 214
■ “Edit VM Settings Dialog (Azure)”, on page 215
■ “Edit vNIC Dialog”, on page 216
■ “Edit vNIC Dialog (vCD)”, on page 217
■ “Edit Volumes Dialog”, on page 217
■ “Edit Volumes Dialog (vCD)”, on page 219
■ “Edit VRA Dialog”, on page 220
■ “Manage Static Routes Dialog”, on page 221
■ “New Repository Dialog” on page 222
■ “Offsite Clone Dialog”, on page 223
■ “Offsite Clone Dialog”, on page 223
■ “Open Support Ticket Dialog”, on page 223
■ “Remote Support Dialog”, on page 225
■ “Site Settings Dialog”, on page 225
■ “Stop Failover Test Dialog”, on page 231
■ “TASKS”, on page 232

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface 195
Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

Add Checkpoint Dialog

Checkpoints are recorded automatically every few seconds in the journal. These checkpoints ensure crash-consistency and are
written to the virtual machine journals by the Zerto Virtual Manager. Each checkpoint has a timestamp set by the Zerto Virtual
Manager. In addition to the automatically generated checkpoints, you can manually add checkpoints to identify events that
might influence the recovery, such as a planned switch over to a secondary generator.
The list of VPGs is displayed. You can select more VPGs to add the same checkpoint.
Enter a name for the checkpoint – The name to assign to the checkpoint.
Dir – The direction of the protection.
VPG Name – The name of the VPG.
Protected Site Name – The name of the site where virtual machines are protected.
Recovery Site Name – The name of the site where protected virtual machines are recovered.
You can filter columns in the list via the filter icon next to each column title. You can also sort the list by each column. Clicking
the cog on the right side of the table enables you to change the columns that are displayed and to create a permanent view of
the columns you want displayed.

Add Checkpoint Dialog 196

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

Add Site Dialog

Pair sites
Remote Site ZVM IP Address – IP address or fully qualified DNS host name of the remote site Zerto Virtual Manager to pair to.
Port – The TCP port communication between the sites. Enter the port that was specified during installation. The default port
during the installation is 9081.

Add Static Route Dialog

Add a static route for a specified group, defined in “Manage Static Routes Dialog”, on page 221, when the Zerto Cloud
Connector and cloud site Zerto Virtual Manager are on different networks.

Address – The network address for the static route that you want to route to.
Subnet Mask – The subnet mask for the network.
Gateway – The gateway address for the network on the local network of the Zerto Cloud Connector cloud network interface.
Note: If you change the Zerto Virtual Manager and VRAs cloud network, changing the static route settings for a group to the
new network only changes the access for new Zerto Cloud Connectors with the specified group. Existing Zerto Cloud
Connectors must be redeployed to use the changed static route.

Add Site Dialog 197

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

Advanced Journal Settings Dialog

Manage the journal used for recovery.

Journal History: The time that all write commands are saved in the journal.
The longer the information is saved, the more space is required for each journal in the VPG to store the saved information.
You can select the number of hours from 1 to 23 or the number of days from 1 to 30.
Default Journal Datastore: The datastore used for the journal data for each virtual machine in the VPG.
Select a datastore accessible to the host.
When you select a specific journal datastore, the journals for each virtual machine in the VPG are stored in this datastore,
regardless of where the recovery datastores are for each virtual machine.
In this case, all protected virtual machines must be recovered to the hosts that can access the specified journal datastore.
Journal Size Hard Limit: The maximum size that the journal can grow, either as a percentage or a fixed amount.
The journal is always thin-provisioned.
■ Unlimited: The size of the journal is unlimited and it can grow to the size of the recovery datastore.
Note: If Unlimited is selected, the Size and Percentage options are not displayed.
■ Size (GB): The maximum journal size in GB.
■ The minimum journal size, set by Zerto Virtual Replication, is 8GB.
■ Percentage: The percentage of the virtual machine volume size to which the journal can grow.
■ This value can be configured to more than 100% of the protected VM's volume size.
Journal Size Warning Threshold: The size of the journal that triggers a warning that the journal is nearing its hard limit.
■ Unlimited: The size of the journal is unlimited and it can grow to the size of the recovery datastore.
Note: If Unlimited is selected, the Size and Percentage options are not displayed.
■ Size (GB): The size in GB that will generate a warning.
■ Percentage: The percentage of the virtual machine volume size that will generate a warning.
Both the values of Size and Percentage must be less than the configured Hard Limit so that the warning will be generated when
needed. In addition to the warning threshold, Zerto Virtual Replication will issue a message when the free space available for
the journal is almost full.

Advanced Journal Settings Dialog 198

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

Advanced Journal Settings Dialog (vCD)

Used in vCD environments only.

Manage the journal used for recovery in a vCD environment.
Journal History: The time that all write commands are saved in the journal.
The longer history is saved, the more space is required for each journal in the VPG.
You can select the number of hours from 1 to 24 or the number of days from 2 to 30.
Journal Size Hard Limit: The maximum size that the journal can grow, either as a percentage or a fixed amount.
The journal is always thin-provisioned.
■ Unlimited: The size of the journal is unlimited and it can grow to the size of the recovery datastore.
Note: If Unlimited is selected, the Size and Percentage options are not displayed.
■ Size (GB): The maximum journal size in GB.
■ The minimum journal size, set by Zerto Virtual Replication, is 8GB.
■ Percentage: The percentage of the virtual machine volume size to which the journal can grow.
■ This value can be configured to more than 100% of the protected VM's volume size.
Journal Size Warning Threshold: The size of the journal that triggers a warning that the journal is nearing its hard limit.
■ Unlimited: The size of the journal is unlimited and it can grow to the size of the recovery datastore.
Note: If Unlimited is selected, the Size and Percentage options are not displayed.
■ Size (GB): The size in GB that will generate a warning.
■ Percentage: The percentage of the virtual machine volume size that will generate a warning.
Both the values of Size and Percentage must be less than the configured Hard Limit so that the warning will be generated when
needed. In addition to the warning threshold, Zerto Virtual Replication will issue a message when the free space available for
the journal is almost full.

Advanced Journal Settings Dialog (vCD) 199

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

Advanced VM Recovery Settings Dialog

Displays the recovery settings for the virtual machines in the VPG. You can choose to edit information in one field by clicking
the field and updating the information. You can choose to edit information for several virtual machines at the same time by
selecting the virtual machines and clicking EDIT SELECTED.

Advanced VM Recovery Settings Dialog 200

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

Advanced VM Replication Settings Dialog

Displays the replication settings for the virtual machines in the VPG. You can choose to edit information in one field by clicking
the field and updating the information. You can choose to edit information for several virtual machines at the same time by
selecting the virtual machines and clicking EDIT SELECTED. For more details, see “Edit VM Dialog” on page 213.

Advanced VM Replication Settings Dialog 201

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

Advanced VM Replication Settings Dialog (vCD)

Used in vCD environments only.

Displays the settings of the virtual machines in the VPG. You can choose to edit information in one field by clicking the field and
updating the information. You can choose to edit information for several virtual machines at the same time by selecting the
virtual machines and clicking EDIT SELECTED. For more details, see “Edit VM Dialog” on page 213.

Advanced VM Replication Settings Dialog (vCD) 202

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

Advanced VM Settings for Cloud Dialog

Displays the recovery settings for the virtual machines in the VPG. You can choose to edit information in one field by clicking
the field and updating the information. You can choose to edit information for several virtual machines at the same time by
selecting the virtual machines and clicking EDIT SELECTED.

ALERTS

Monitor the recent alerts by clicking the ALERTS area in the status bar at the bottom of the Zerto User Interface. The following
information is displayed for the most recent alerts:
■ The alert status.
■ The site where the alert is issued.
■ A description of the alert.
Click See All Alerts to access MONITORING > ALERTS.

Advanced VM Settings for Cloud Dialog 203

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

Boot Order Dialog

To specify the boot order of virtual machines in a VPG. When machines are started up on recovery, for example, after a move
operation, the virtual machines in the VPG are not started up in a particular order. If you want specific virtual machines to start
before other machines, you can specify a boot order. The virtual machines are defined in groups and the boot order applies to
the groups and not to individual virtual machines in the groups. You can specify a delay between groups during startup.
Initially, virtual machines in the VPG are displayed together under the default group. If you want specific machines to start
before other virtual machines, define new groups with one or more virtual machines in each group.
There is no boot order for virtual machines within a group, only between groups.
ADD GROUP button – Adds a group. After adding a group you can edit the group name by clicking the Edit icon at the right of
the group name and remove the group via the delete icon at the right of the group. You cannot remove the Default group nor
a group that contains a virtual machine.
Boot Delay – Specifies a time delay between starting up the virtual machines in the group and starting up the virtual machines
in the next group. For example, assume three groups, Default, Server, and Client defined in this order. The Start-up delay defined
for the Default group is 10, for the Server group is 100 and for the Client group 0. The virtual machines in the Default group are
started together and after 10 seconds the virtual machines in the Server group are started. After 100 seconds the virtual
machines in the Client group are started up.

Boot Order Dialog 204

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

Browse for File Dialog

To select the folder with the preseeded disk to use. Drill-down to select the disk.
Note: Disks that are not viable for preseeding are grayed out.

Change Host Password VRA Dialog

To change the connectivity, VIB or password, used by the VRA to connect to the host. If using a password to connect to the
host, to change the password used by the VRA.
■ If the VRA is using a password to connect to the host and using VIB is required, check Use credentials to connect to host.
■ If the VRA is using VIB to connect to the host and using a password is required, uncheck Use credentials to connect to host
and enter the password. To display the password in plain text, click in the checkbox next to the field.
■ If the VRA is connecting to the host with a password and the password for the host has changed, enter the new password.
To display the password in plain text, click in the checkbox next to the field.

Browse for File Dialog 205

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

Change VM Recovery VRA Dialog

To change the recovery host required by the VRA to access the host.
Alert icon status indicator – The color indicates the status of the alert:
■ Green icon – The virtual machine can be moved to the replacement host.
■ Red icon – The virtual machine cannot be moved to the replacement host.
Direction – The direction of the replication, from this site to the remote site or from the remote site to this site.
VM Name – The name of the virtual machine.
VPG Name – The name of the VPG.
ZORG – The Zerto name given to the organization, the ZORG, by a cloud service provider. For details, refer to Zerto Cloud
Manager Administration Guide.
VM Size GB – The virtual machine size in gigabytes.
# of Volumes – The number of volumes used by the virtual machine.
VM Hardware Version – The hardware version of the virtual machine.
Select the replacement host – The name of the host to move the recovery virtual machines information.

Change VM Recovery VRA Dialog 206

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

Checkpoints Dialog

When selecting the point to recover to:

■ The refresh button is initially grayed out and is enabled for clicking after 5 seconds. It is also grayed out for 5 seconds after
being clicked, before being re-enabled.
■ A Click the refresh button to view the latest checkpoints reminder is displayed 10 seconds after the refresh button is clicked
to remind the user that there is a new Latest Checkpoint.
■ If the user has scrolled to, and selected, a checkpoint anywhere in the checkpoints list, clicking the refresh button will
automatically return the user to the selected checkpoint in the list.
Latest – Recovery is to the latest checkpoint. This ensures that the data is crash-consistent for the recovery. When selecting
the latest checkpoint, the checkpoint used is the latest at this point. If a checkpoint is added between this point and starting the
failover, the later checkpoint is not used.
Latest Tagged Checkpoint – The recovery operation is to the latest checkpoint added in one of the following situations:
■ By a user.
■ When a failover test was previously performed on the VPG which includes the virtual machine.
■ When the virtual machine was added to an existing VPG after the added virtual machine was synchronized.
Latest VSS – When VSS is used, recovery or clone is to the latest VSS snapshot, ensuring that the data is both crash-consistent
and application consistent to this point. The frequency of VSS snapshots determines how much data can be recovered.
If you do not want to use the latest checkpoint, latest tagged checkpoint, or latest VSS checkpoint, choose Select from all
available checkpoints. By default, this option displays all checkpoints in the system. You can choose to display only
automatic, VSS, or tagged checkpoints, or any combination of these types.

Checkpoints Dialog 207

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

Configure and Install VRA Dialog

ESXi versions from 5.5 ESXi versions before version 5.5

Host – The host on which the VRA is installed. The drop-down displays the hosts that do not have a VRA installed, with the
selected host displayed by default.
From ESXi 5.5, by default, Zerto Virtual Manager uses a vSphere Installation Bundle, VIB, to connect to the host. When using
VIB:
■ The user does not enter a password.
■ Once a day, Zerto Virtual Manager checks that the VRA and host can connect. If the connection fails, Zerto Virtual
Manager re-initiates the connection automatically and logs it.
For ESX/i versions earlier than 5.5, when using a password, root access is required. Once a day, Zerto Virtual Manager checks
that the password is valid. If the password was changed, an alert is issued, requesting the user enter the new password.
Use credentials to connect to host – When unchecked, the Zerto Virtual Manager uses VIB to connect to the host. This
field is only relevant for ESXi 5.5 and later.
Host Root Password – When the VRA should connect to the host with a password, check Use credential to connect to host
and enter the root user password used to access the host. When the box on the right side is checked, the password is
displayed in plain text.This field is only relevant for ESXi 4.x and 5.x hosts. This field is disabled for ESX 4.x hosts.
Datastore – The datastore that the VRA will use for protected virtual machine data on the recovery site, including the journals.
You can install more than one VRA on the same datastore.
Network – The network used to access the VRA.
VRA RAM – The amount of memory to allocate to the VRA. The amount determines the maximum buffer size for the VRA for
buffering IOs written by the protected virtual machines, before the writes are sent over the network to the recovery VRA. The
recovery VRA also buffers the incoming IOs until they are written to the journal. If a buffer becomes full, a Bitmap Sync is
performed after space is freed up in the buffer.
AMOUNT OF VRA RAM VRA BUFFER POOL SIZE
1GB 450MB
2GB 1450MB
3GB 2300MB
3GB 2300MB

Configure and Install VRA Dialog 208

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

AMOUNT OF VRA RAM VRA BUFFER POOL SIZE

4GB 3,300MB
5GB 4,300MB
6GB 5,300MB
7GB 6,300MB
8GB 7,300MB
9GB 8,300MB
10GB 9,300MB
11GB 10,300MB
12GB 11,300MB
13GB 12,300MB
14GB 13,300MB
15GB 14,300MB
16GB 15,300MB
The protecting VRA can use 90% of the buffer for IOs to send over the network and the recovery VRA can use 75% of the
buffer. That is, for example, a protecting VRA defined with 2GB of RAM can buffer approximately 1305MB before the buffer is
full and a Bitmap Sync is required.
VRA Group – Specify the VRA Group as free text to identify the group or select from a previously specified group. You group
VRAs together when VRAs use different networks so they can be grouped by network, for example when the protected and
recovery sites are the same site and you want to replicate to different datastores in the site. The group name is free text you
use to identify the group.
The priority assigned to a VPG dictates the bandwidth used. The Zerto Virtual Manager distributes bandwidth among the
VRAs based on this priority and the VPGs with higher priorities are handled before writes from VPGs with lower priorities.
To create a new group, enter the new group name over the text New group and click CREATE.

Configuration – Either have the IP address allocated via a static IP address or a DHCP server. The Static option is the
recommended option.
Address – The IP address for the VRA.
Subnet Mask – The subnet mask for the network. The default value is 255.255.255.0.
Default Gateway – The default mask for the network.

Configure Paired Site Routing Dialog

The IP address, subnet mask, and gateway to access the peer site VRAs when access to the peer site VRAs is not via the
default gateway.

Configure Paired Site Routing Dialog 209

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

Enable Paired Site Routing – When checked, enables paired site routing.
Address – The IP address of the next hop at the local site, the router, or gateway address that is used to access the peer site
network.
Subnet Mask – The subnet mask for the peer site network.
Gateway – The gateway for the peer site network.
These access details are used to access the VRAs on the peer site.
The settings in the Configure Paired Site Routing dialog apply to all VRAs installed after the information is saved. Any existing
VRA is not affected and access to these VRAs continues via the default gateway. If the default gateway stops being used, you
must reinstall the VRAs that were installed before setting up paired site routing.

Configure Provider vDCs Dialog

Set up access to provider vDCs and their datastore configuration.

Provider vDCs: Add button – Add the provider vDCs that you want to enable to use Zerto Virtual Replication. Only these
provider vDCs are visible to the user in Zerto Virtual Replication.
Provider vDCs: Remove button – Remove a selected provider vDC.
Provider Datastore
Unlisted datastores are not used by Zerto Virtual Replication – Unlisted datastores cannot be used.
Unlisted datastores are used only for recovery volumes – Unlisted datastores of all provider vDCs, even those provider
vDCs that have not been added to the list of Provider vDCs can be used as recovery datastores.
Provider datastore: Add button – Add datastores.
Provider datastore: Remove button – Remove a selected datastore.
Datastore – The name of the added datastore.

Configure Provider vDCs Dialog 210

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

Recovery Volume – Check if the datastore can be used as a recovery datastore.

Journal – Check if the datastore can be used for the journal. If no datastores are configured as journals, all datastores in the
provider vDC can serve as journals. If at least one datastore, on any provider vDC, is configured as a journal but the recovery
provider vDC does not see any journal datastore, all datastores eligible to be recovery datastores on that provider vDC, can
also serve as journal datastores. If at least one datastore is configured as a journal and the recovery provider vDC sees at least
one journal datastore, only datastores configured as journal, that are visible to that provider vDC can serve as journal
datastores.
Preseed – Check if the datastore can be used for preseeded disks. Only datastores marked as preseeded can be used,
preventing different organizations being exposed to datastores of other customers using the preseed option.

Configure VM Settings Dialog

Specifies the values to use when restoring the selected virtual machines.
Restore on Host – The IP address of the host where you want the virtual machine restored.
Restore on Datastore – The datastore to use for the restored virtual machine files.
Power On – Check this if you want the restored virtual machine to be powered on.

Configure Volume Dialog (vCD)

Used in vCD environments only.
To configure the datastore for recovery. If a cluster or resource pool is selected for the host, only datastores that are accessible
by every ESX/ESXi host in the cluster or resource pool are displayed.
■ Temp Data Disk – If the virtual machine to be replicated includes a temp data disk as part of its configuration, you can
specify a mirror disk for replication that is marked as a temp data disk. In this case, data is not replicated to the temp data
disk after initial synchronization.
■ Use vCD Managed Storage Profile – The datastore is allocated based on the available free space. You can specify whether
the recovery volume is thin provisioned or not. If the Org vDC only supports thin-provisioned volumes, you cannot change
the setting. If Zerto Virtual Replication cannot find a storage profile that can be used as target storage, the value is set to
Zerto_Any. In this case, any of the datastores configured in the Configure Provider vDCs dialog can be selected as recovery
datastores, provided they are exposed to the relevant recovery hosts. Upon recovery, Zerto Virtual Replication chooses a
storage profile available to the Org vDC, for the recovered vApp, that contains all of the datastores on which recovery
volumes of the VPG reside. If there is no such storage profile, the recovery operation cannot start. The storage profile can
be set to Zerto_Any for a number of reasons, such as adding a virtual machine to the VPG which does not have a storage
profile that can be used as the target.
■ Preseed – A virtual disk (the vmdk flat file and header file) in the recovery site that has been prepared with a copy of the
protected data, so that the initial synchronization is much faster since a Delta Sync is used to synchronize any changes
written to the recovery site after the creation of the preseeded disk. When using a preseeded VMDK, you specify the exact
location, the preseed folder configured for the customer and the disk name, of the preseeded disk. A provider datastore
must have been specified for preseeded disks in the “Configure Provider vDCs Dialog”, on page 210 dialog. Zerto Virtual

Configure VM Settings Dialog 211

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

Replication takes ownership of the preseeded disk, moving it from its source folder to the folder used by the VRA. Note
that if the virtual machine has more than one preseeded disk, these disks must reside on the same datastore. If the
preseeded disk is greater than 1TB on NFS storage, the VPG creation might fail. This is a known VMware problem when the
NFS client does not wait for sufficient time for the NFS storage array to initialize the virtual disk after the RPC parameter of
the NFS client times out. The timeout default value is 10 seconds. Refer to the VMware documentation, http://
kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1027919, which
describes the configuration option to tune the RPC timeout parameter using the esxcfg-advcfg -s <Timeout> /NFS/
SetAttrRPCTimeout command.
If the VPG is being defined for a Zerto Organization, ZORG, the location of the preseeded disk must be defined in the Zerto
Cloud Manager. For details, refer to Zerto Cloud Manager Administration Guide.
Note: Zerto Virtual Replication supports the SCSI protocol. Only disks that support this protocol can be specified.

Edit NIC Dialog

Specify the NIC settings when restoring an offsite backup to the recovery site.
NIC Name – The name of the selected NIC.
Network – The network to use for the restored virtual machine.
Create new MAC address – The Media Access Control address (MAC address) to use. The default is to use the same MAC
address for the restored virtual machine that was used in the protected site. Check the box to create a new MAC address on
the restore site.
Change vNIC IP Configuration – Whether or not to keep the default virtual NIC (vNIC) IP configuration. The vNIC IP is changed
after the restore has completed when VMware Tools are installed. If Static is selected, the IP address, subnet mask, and default
gateway must be set. If DHCP is selected, the IP configuration and DNS server configurations are assigned automatically, to
match the protected virtual machine.
IP Address – The IP for the restored virtual machine. This can be the same IP as the original protected virtual machine.
Subnet Mask – The subnet mask for the network. The default value is 255.255.255.0.
Default Gateway – The default mask for the network.

Edit NIC Dialog 212

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

Preferred DNS Server– The IP address of the primary DNS server to handle Internet protocol mapping.
Alternate DNS Server – The IP address of the alternate DNS server.
DNS Suffix – The DNS name excluding the host.

Edit Selected Volumes Dialog

If more than one datastore is selected, the path is not displayed.

Datastore / Raw Disk – The storage or RDM disk where the virtual machine files will be restored.
Thin – Whether the virtual machine disks will be thin-provisioned or not.

Edit VM Dialog

Edit the replication settings for a particular virtual machine in a VPG.

Recovery Host – The cluster, resource pool, or host that will host the recovered virtual machine. If the site is defined in Zerto
Cloud Manager, only a resource pool can be specified and the resource pool must also have been defined in Zerto Cloud
Manager. For details about Zerto Cloud Manager, see Zerto Cloud Manager Administration Guide.
When a resource pool is specified, Zerto Virtual Replication checks that the resource pool capacity is enough for the specified
virtual machine.
VM Recovery Datastore– The datastore where the VMware metadata files for the virtual machine are stored, such as the vmx
file. If a cluster or resource pool is selected for the host, only datastores that are accessible by every ESX/ESXi host in the
cluster or resource pool are displayed. This is also the datastore where RDM backing files for recovery volumes are located.
When specifying the recovery datastore for a virtual machine with a storage cluster, specify a datastore in the cluster.
Journal Size Hard Limit – The maximum size that the journal can grow, either as a percentage or a fixed amount. The minimum
journal size, set by Zerto Virtual Replication, is 8GB. The journal is always thin-provisioned.

Edit Selected Volumes Dialog 213

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

Unlimited – The size of the journal is unlimited and it can grow to the size of the recovery datastore. If Unlimited is chosen,
the fields Size and Percentage are not relevant.
Size (GB) – The maximum journal size in GB.
Percentage – The percentage of the virtual machine volume size the journal can grow to.
Journal Size Warning Threshold – The size of the journal that triggers a warning that the journal is nearing its hard limit.
Unlimited – The size of the journal is unlimited and it can grow to the size of the recovery datastore. If Unlimited is chosen,
the fields Size and Percentage are not relevant.
Size (GB) – The size in GB that will generate a warning.
Percentage – The percentage of the virtual machine volume size that will generate a warning.
Both the value of Size and Percentage must be less than the configured hard limit so that the warning will be generated when
needed. In addition to the warning threshold, Zerto Virtual Replication will issue a message when the free space available for
the journal is almost full.
Journal Datastore – The datastore used for the journal data for each virtual machine in the VPG. To change the default, specify
a host and then select one of the datastores accessible by this host to be used as the journal datastore. When you select
specific journal datastore, the journals for each virtual machine in the VPG are stored in this datastore, regardless of where the
recovery datastores are for each virtual machine. In this case, all the protected virtual machines must be recovered to hosts
that can access the specified journal datastore.

Edit VM Dialog (vCD)

Used in vCD environments only.

Storage Profile – Storage profiles enable mapping virtual machines to storage levels according to predefined service levels,
storage availability, performance requirements, or cost. You can define and label storage tiers and then specify the tier to use
as a storage profile, for each virtual machine in the VPG. The default storage profile is the default for the Recovery Org vDC.
Zerto will place all the volumes of each virtual machine in a datastore, according to the following considerations:
■ The datastore is part of the selected storage profile.
■ The datastore is configured as recovery datastore target in the Configure PVDC dialog.
■ The datastore has enough space to contain all of the virtual machine volumes.
If Zerto Virtual Replication cannot find a storage profile that can be used as target storage, the value is set to Zerto_Any. In
this case, any of the datastores configured in the Configure Provider vDCs dialog can be selected as recovery datastores,
provided they are exposed to the relevant recovery hosts. Upon recovery, Zerto Virtual Replication chooses a storage profile
available to the Org vDC, for the recovered vApp, that contains all of the datastores on which recovery volumes of the VPG
reside. If there is no such storage profile, the recovery operation cannot start. The storage profile can be set to Zerto_Any for a
number of reasons, such as adding a virtual machine to the VPG which does not have a storage profile that can be used as the
target.
Journal Size Hard Limit – The maximum size that the journal can grow, either as a percentage or a fixed amount. The minimum
journal size, set by Zerto Virtual Replication, is 8GB. The journal is always thin-provisioned.
Unlimited – The size of the journal is unlimited and it can grow to the size of the recovery storage.

Edit VM Dialog (vCD) 214

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

Size (GB) – The maximum journal size in GB.

Percentage – The percentage of the virtual machine volume size the journal can grow to.
Journal Size Warning Threshold – The size of the journal that triggers a warning that the journal is nearing its hard limit.
Unlimited – The size of the journal is unlimited and it can grow to the size of the recovery storage.
Size (GB) – The size in GB that will generate a warning.
Percentage – The percentage of the virtual machine volume size that will generate a warning.
Both the value of Size and Percentage must be less than the configured hard limit so that the warning will be generated when
needed. In addition to the warning threshold, Zerto Virtual Replication will issue a message when the free space available for
the journal is almost full.

Edit VM Settings Dialog (Azure)

Edit the network settings for one or more virtual machines in a VPG that will be recovered to AWS. There are recovery settings
for failovers and moves, and for failover tests.
VNet: A The virtual network dedicated to your Azure subscription.
Subnet: A range of IP addresses in your VPC.
Network Security Group: The Azure network security to be associated with the virtual machines in this VPG. You can associate
one or more network security groups with the virtual machines.
Instance Family:– The instance family from which to select the type. Azure instance families are optimized for different types
of applications. Choose the instance family appropriate for the application in the virtual machine protected in the VPG.
Instance Type: The instance size, within the instance family, to assign to recovered instances. Different sizes within an
instance family vary primarily in vCPU, ECU, RAM, and local storage size. The price per instance is directly related to the
instance size.
Private IP: The private IP of an instance from the selected subnet. If you do not set the private IP, during recovery, Azure sets
the private IP from the defined subnet range.

Edit VM Settings Dialog (Azure) 215

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

Edit vNIC Dialog

To configure the NIC used for the replicated VM disks. You can configure a maximum of four NICs.
Note: You can only change the vNIC IP for virtual machines with VMware Tools running.
Specify the network details to use for the recovered virtual machines after a live recovery or migration, in the Failover/Move
column, and for the recovered virtual machines when testing replication, in the Test column.
Network – The recovery site network to use. For testing, this network can be a fenced-out network to avoid impacting the
production network.
Create New MAC Address – Whether the Media Access Control address (MAC address) used on the protected site should be
replicated on the recovery site. The default is to use the same MAC address on both sites.
Change vNIC IP Configuration – Whether or not to keep the default virtual NIC (vNIC) IP configuration. You can only change
the vNIC IP after recovery has completed with VMware Tools installed.
To change the vNIC IP, select Yes in the Failover/Move or Test column. If you select a static IP connection, set the IP address,
subnet mask, and default gateway. Optionally, change the preferred and alternate DNS server IPs and the DNS suffix. If you
select DHCP, the IP configuration and DNS server configurations are assigned automatically, to match the protected virtual
machine. You can change the DNS suffix.
If the virtual machine has multiple NICs but is configured to only have a single default gateway, fill in a 0 for each octet in the
Default gateway field for the NICs with no default gateway.
Note: During a failover, move, or test failover, if the recovered virtual machine is assigned a different IP than the original IP,
after the virtual machine has started it is automatically rebooted so that it starts up with the correct IP. If the same network is
used for both production and test failovers, Zerto recommends changing the IP address for the virtual machines started for the
test, so that there is no IP clash between the test machines and the production machines.
Copy to failover test – When clicked, copies the settings in the Failover/Move column to the Test column.
Copy to failover/move – When clicked, copies the settings in the Test column to the Failover/Move column.

Edit vNIC Dialog 216

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

Edit vNIC Dialog (vCD)

Used in vCD environments only.

To configure the network details to use for the recovered virtual machines after a failover or move or test operation.
Network – The network to use for this virtual machine.
MAC Address – Whether the Media Access Control address (MAC address) used on the protected site should be replicated
on the recovery site. The default is to use the same MAC address on both sites.
vNIC IP Mode – Which IP mode to use. Specify the IP address if you choose static IP pool.
Note: During a failover, move, or test failover, if the recovered virtual machine is assigned a different IP than the original IP,
after the virtual machine has started it is automatically rebooted so that it starts up with the correct IP. If the same network is
used for both production and test failovers, Zerto recommends changing the IP address for the virtual machines started for the
test, so that there is no IP clash between the test machines and the production machines.
Copy to failover test – Copies the settings in the Failover/Move column to the Test column.
Copy to failover/move – Copies the settings in the Test column to the Failover/Move column.

Edit Volumes Dialog

To edit recovery datastore information for a protected virtual machine.
Volume Source – The source on the recovery site for the replicated data: Datastore, RDM or Preseeded volume.

Datastore

Edit vNIC Dialog (vCD) 217

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

Datastore – A new volume is used for replicated data. Specify the datastore to use to create disks for the replicated data. If the
source disk is thin provisioned, the default for the recovery volume is that it is also thin provisioned.
The datastore specified for replication must have at least the same amount of space as the protected volume and an additional
amount for the journal. The amount of additional space needed for the journal can be fixed by specifying a maximum size for
the journal, or can be calculated as the average change rate for the virtual machines in the VPG, multiplied by the length of time
specified for the journal history.
You can use the vSphere Client console Performance tab for each virtual machine to help estimate the change rate. Zerto Virtual
Replication supports the SCSI protocol. Only disks that support this protocol can be specified.

RDM

Raw Disk – The VMware RDM (Raw Device Mapping) to use for the replication: By default, RDM is recovered as thin-
provisioned VMDK in the datastore specified in the VM Recovery Datastore field in the Edit VM dialog, and not to RDM. You
cannot define an RDM disk if the virtual machine uses a BusLogic SCSI controller, nor when protecting or recovering virtual
machines in an environment running vCenter Server 5.x with ESX/ESXi version 4.1 hosts. Only a raw disk with the same size as
the protected disk can be selected from the list of available raw disks. Other raw disks with different sizes are not available for
selection. The RDM is always stored in the recovery datastore used for the virtual machine. The following limitations apply to
protecting RDM disks:
■ RDM disks with an even number of blocks can replicate to RDM disks of the same size with an even number of blocks and
to VMDKs.
■ RDM disks with an odd number of blocks can only replicate to RDM disks of the same size with an odd number of blocks
and not to VMDKs.

Preseeded volume

Whether to copy the protected data to a virtual disk in the recovery site. Zerto recommends using this option particularly for
large disks so that the initial synchronization will be faster since a Delta Sync can be used to synchronize any changes written
to the recovery site after the creation of the preseeded disk. When not using a preseeded disk, the initial synchronization phase
must copy the whole disk over the WAN. When using a preseeded virtual disk, you select the datastore and exact location,
folder, and name of the preseeded disk, which cannot be an IDE disk. Zerto Virtual Replication takes ownership of the
preseeded disk, moving it from its source folder to the folder used by the VRA. Only disks with the same size as the protected
disk can be selected when browsing for a preseeded disk. The datastore where the preseeded disk is placed is also used as the
recovery datastore for the replicated data.

Edit Volumes Dialog 218

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

If the preseeded disk is greater than 1TB on NFS storage, the VPG creation might fail. This is a known VMware problem when
the NFS client does not wait for sufficient time for the NFS storage array to initialize the virtual disk after the RPC parameter of
the NFS client times out. The timeout default value is 10 seconds. See the VMware documentation, http://kb.vmware.com/
selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1027919, which describes the configuration
option to tune the RPC timeout parameter using the esxcfg-advcfg -s <Timeout> /NFS/SetAttrRPCTimeout
command.
Note the following conditions:
■ If the protected disks are non-default geometry, configure the VPG using preseeded volumes.
■ If the protected disk is an RDM disk, it can be used to preseed to a recovery VMDK disk. Zerto Virtual Replication makes
sure that the VMDK disk size is a correct match for the RDM disk.
■ If the VPG is being defined for a Zerto Organization, ZORG, the location of the preseeded disk must be defined in the Zerto
Cloud Manager. For details, see Zerto Cloud Manager Administration Guide.
Datastore – The datastore where the preseeded disk is located.
Path – The full path to the preseeded disk.
Temporary Data Disk – If the virtual machine to be replicated includes a temp data disk as part of its configuration, specify a
mirror disk for replication that is marked as a temp data disk. In this case, data is not replicated to the temp data disk after
initial synchronization.
Thin provisioning – If the recovery volumes are thin-provisioned or not.

Edit Volumes Dialog (vCD)

To edit recovery datastore information in a vCD environment.

Volume Source – The source on the recovery site for the replicated data.
vCD managed storage profile – The datastore is allocated based on the available free space. You can specify whether the
recovery volume is thin-provisioned or not. If the Org vDC only supports thin-provisioned volumes, you cannot change the
setting.
Preseeded volume – A virtual disk (the VMDK flat file and descriptor) in the recovery site that has been prepared with a
copy of the protected data. Zerto recommends using this option particularly for large disks so that the initial
synchronization is much faster since a Delta Sync is used to synchronize any changes written to the recovery site after
the creation of the preseeded disk. When not using a preseeded disk the initial synchronization phase has to copy the
whole disk over the WAN. Browse to the preseed folder configured for the customer and the disk name, of the preseeded
disk. In order to use a preseeded VMDK, do the following:
■ Create a folder in vCD to use for the preseeded disks in the datastore you want to use for the customer.
■ Specify this datastore as a provider datastore for preseeded disks in the Configure Provider vDCs dialog, from the
Advanced Settings dialog, as described in Zerto Cloud Manager Administration Guide.
■ In the Zerto Cloud Manager specify the Preseed Folder Name for the ZORG, in the Manage ZORG tab.
Zerto Virtual Replication searches for the preseeded folder in the available datastores in the Org vDCs specified in the vCD
Cloud Resources for the ZORG in the Zerto Cloud Manager and takes ownership of the preseeded disk, moving it from its
source folder to the folder used by the VRA. Note that if the virtual machine has more than one preseeded disk, these disks
must reside on the same datastore. If the preseeded disk is greater than 1TB on NFS storage, the VPG creation might fail.
This is a known VMware problem when the NFS client does not wait for sufficient time for the NFS storage array to

Edit Volumes Dialog (vCD) 219

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

initialize the virtual disk after the RPC parameter of the NFS client times out. The timeout default value is 10 seconds. Refer
to the VMware documentation, http://kb.vmware.com/selfservice/microsites/
search.do?language=en_US&cmd=displayKC&externalId=1027919, which describes the configuration option to tune the
RPC timeout parameter using the esxcfg-advcfg -s <Timeout> /NFS/SetAttrRPCTimeout command.
If the VPG is being defined for a Zerto Organization, ZORG, the location of the preseeded disk must be defined in the Zerto
Cloud Manager. For details, refer to Zerto Cloud Manager Administration Guide.
Zerto Virtual Replication supports the SCSI protocol. Only disks that support this protocol can be specified. Virtual
machine RDMs in a vCenter Server are replicated as VMDKs in a vCD environment.
Temp Data Disk – If the virtual machine to be replicated includes a temp data disk as part of its configuration, specify a mirror
disk for replication that is marked as a temp data disk. In this case, data is not replicated to the temp data disk after initial
synchronization.
Zerto Virtual Replication supports the SCSI protocol. Only disks that support this protocol can be specified.
Thin provisioning – If the recovery volumes are thin-provisioned or not.

Edit VRA Dialog

To change the network settings for a VRA, for example when the gateway to the VRA is changed.
Host – The IP of the host on which the VRA is installed.
For ESXi 5.5 and later hosts, by default, Zerto Virtual Manager uses a vSphere Installation Bundle, VIB, to connect to the host.
When using VIB:
■ The user does not enter a password.
■ Once a day, Zerto Virtual Manager checks that the VRA and host can connect. If the connection fails, Zerto Virtual
Manager re-initiates the connection automatically and notes this in the log.
When using a password, root access is required if the Zerto host component is down and needs an automatic restart. Once a
day, Zerto Virtual Manager checks that the password is valid. If the password was changed, an alert is triggered, requesting the
user enter the new password.
Use credentials to connect to host – When unchecked, the Zerto Virtual Manager uses VIB to connect to the host. This
field is only relevant for ESXi 5.5 and later.

Edit VRA Dialog 220

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

Host Root Password – When the VRA should connect to the host with a password, check Use credential to connect to host
and enter the root user password used to access the host. When the box on the right side is checked, the password is
displayed in plain text.This field is only relevant for ESXi 4.x and 5.x hosts. This field is disabled for ESX 4.x hosts.
VRA Group – The free text to identify the group to which a VRA belongs. If you create a group and then change the name when
editing the VRA so that there is no VRA in the site that belongs to the originally specified group, the group is automatically
deleted from the system.
To create a new group, enter the new group name over the text New group and click CREATE.
Configuration – Either have the IP address allocated via a static IP address or a DHCP server. If the VRA was originally installed
with a static IP, you cannot change this to DHCP. If the VRA was originally installed to use a DHCP server, you can change this
to use a static IP.
Address – The static IP address for the VRA to communicate with the Zerto Virtual Manager.
Subnet Mask – The subnet mask for the network. The default value is 255.255.255.0.
Default Gateway – The default mask for the network.

Manage Static Routes Dialog

When providing DR as a Service, the cloud service provider needs to ensure complete separation between the organization
network and the cloud service provider network. The cloud service provider needs to be able to route traffic between an
organization network and the cloud replication network, in a secure manner without going through complex network and
routing setups.
The cloud service provider can define a Zerto Cloud Connector per organization site, that has two Ethernet interfaces, one to
the organization’s network and one to the cloud service provider's network. If the cloud service provider wants to add
additional security, considering both cloud connector interfaces as part of the organization network, the cloud service provider
can define a static route that will hop to a different cloud network, specifically for use by the Zerto Virtual Manager and VRAs
in the cloud site.
ADD – Click this field to add an entity and to define the static route it will use. Once you click ADD, the dialog changes:

Manage Static Routes Dialog 221

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

NEW GROUP – Defines a group that will use a static route to the subnet used by the Zerto Virtual Manager. Enter the name of
the organization that will use this static route.
Add Static Route – Opens the Add Static Route Dialog.

New Repository Dialog

To create a new repository for backups.

Repository Name – The name of the repository.

Repository Type – The type of repository. The options are Local or Network Share (SMB). If Local is specified, backups are stored
on the local machine where the Zerto Virtual Manager is installed. If Network Share (SMB) is specified, the network share drive
must be an SMB drive and if specified the username and password to access the drive must be provided.
Username – Username to access the Network Share drive. The name can be entered using either of the following formats:
■ username
■ domain\username
This field is not displayed when the type is Local.
Password – Password to access the Network Share drive. This field is not displayed when the type is Local.
Path – The path where the repository will reside. The path must be accessible from the Zerto Virtual Manager, so if the
repository is on a different domain to the Zerto Virtual Manager, the domain must be included in the path.

New Repository Dialog 222

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

Free Space – The amount of free space currently available for the repository.
Used Space – The amount of space currently used in the repository.
Capacity – The overall capacity of the repository.
VALIDATE – Click to validate the path. The path must be valid in order to save the information.
Enable compression – Check this option to compress backups stored in the repository. Compression is done using zip
compression, set to level six. If you want better compression, which requires more CPU, or less compression to reduce the CPU
overhead, contact Zerto support.
Note: Compression usually reduces the effectiveness of deduplication on stored data. If the backup repository resides on a
deduplication-enabled storage appliance, it is recommended that the data be stored uncompressed.
Set as default repository – Check this option to make the repository the default repository.

Offsite Clone Dialog

To create a clone of each virtual machine in a VPG on the recovery site in the production network. The clone is a copy of the
protected virtual machines on the recovery site, while the virtual machines on the protected site remain protected and live.
SELECT A CHECKPOINT button – Opens the Checkpoints Dialog dialog to select the checkpoint to use to make the clone.
Recovery Datastore – Select the datastore to use for the recovery virtual machines.

Open Support Ticket Dialog

Support tickets can be opened directly in the Zerto User Interface.
Creating a support ticket in the Zerto User Interface simplifies the submission process since much of the information that is
required when entering a ticket using the Zerto Support Portal, such as the version and build numbers, is automatically added
to the ticket when it is submitted via the Zerto User Interface.
In addition, when the ticket is submitted, a snapshot of the current environment is also attached to the ticket. The snapshot
information includes the lists of alerts, events, tasks, VPGs, and virtual machines that are protected.
This information is used to help Zerto resolve the ticket quickly and, whenever possible, without the need to request more
information from you.
Note: The clocks on the machines where Zerto Virtual Replication is installed must be synchronized with UTC and with each
other (the timezones can be different). Zerto recommends synchronizing the clocks using NTP. If the clocks are not
synchronized with UTC, submitting a support ticket can fail.
To open a support ticket:

Offsite Clone Dialog 223

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

1. In the Zerto User Interface, click SETTING ( ) in the top right of the header and select Submit Support Ticket.
The Open Support Ticket dialog for the site is displayed.

2. Specify the ticket details:

■ Subject: The subject of the support ticket.
■ Type: The type of ticket being opened. Available options are:
■ Problem
■ Feature Request
■ Question
■ Description: A description of the problem or question in addition to the information supplied in the subject.
■ Allow remote log collection: How many logs is Zerto allowed to collect. Available options are:
■ Only for this ticket
■ For the next 30 days
■ Never
■ SSP Email Address: A valid email address registered with Zerto, with permission to open tickets.
3. Click SUBMIT.
The ticket is processed and its progress is displayed. If the email address is not valid, the ticket is rejected. Once the ticket
submission starts, it cannot be canceled.

Open Support Ticket Dialog 224

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

Remote Support Dialog

Remote Log Collection allows customers to authorize Zerto support engineers to collect logs from their environment. By using
remote log collection customers can avoid having to use the Diagnostic Tool on their ZVM server in order to collect logs for
analysis, a potentially complex and time-consuming procedure.
Never: Remote log collection is not allowed (default). If remote log collection is currently is allowed, it will be terminated if you
select this option.
For the next 30 days: Remote log collection is allowed. This permission will automatically terminate in 30 days unless
terminated by selecting the Never option.
Only for a specific case: You will be prompted to enter the Case number opened via the Salesforce Self-service Portal. Remote log
collection will be allowed for as long as the case is active or until remote log collection is terminated by selecting the Never
option.

Site Settings Dialog

Contains site-wide settings:
■ “Site Information Dialog”, below
■ “Policies Dialog”, on page 227
■ “Email Settings Dialog”, on page 228
■ “Reports Dialog”, on page 229
■ “License Dialog”, on page 230
■ “About Dialog”, on page 231

Remote Support Dialog 225

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

Site Information Dialog

During installation, information about the site is entered to identify the site in the user interface and to identify the contact
person at the site. After installation you can update this information.
Site Name – The name used to identify the site.
Site Location – Information such as the address of the site or a significant name to identify it.
Contact Name – The name of the person to contact if a need arises.
Contact Email – An email address to use if a need arises.
Contact Phone – A phone number to use if a need arises.
User Name – The administrator name used to access the hypervisor management tool. The name can be entered using either
of the following formats:
■ username
■ domain\username
Password – The password used to access the hypervisor management tool for the given user name. If the password changes,
specify the new password. To ensure security, after saving the settings, the password field is cleared.

Site Settings Dialog 226

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

Policies Dialog

Failover/Move Commit Policy – The commit policy to use during a failover or move operation. The value set here is the default
for all failover or move operations from this point on but can be changed when defining a failover or move operation. The
following options are available:
■ None – The failover or move operation must be manually committed or rolled back by the user.
■ Commit – After the time specified in the Default Timeout field, the failover or move operation is committed. During the
specified time you can check the recovered VPG virtual machines, and you can manually commit or roll back.
■ Rollback – After the time specified in the Default Timeout field the failover or move operation is rolled back, unless you
manually commit it or roll it back before the time out value is reached. During the specified time you can check the
recovered VPG virtual machines.

Site Settings Dialog 227

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

Email Settings Dialog

Define an email address to receive Zerto Virtual Replication alerts and backup reports.
SMTP Server Address – The SMTP server address. The Zerto Virtual Manager must be able to reach this address.
SMTP Server Port – The SMTP server port, if it was changed from the default, 25.
Sender Account– A valid email address for the email sender name.
To – A valid email address where you want to send the email.
SEND TEST EMAIL button – Tests that the email notification is set up correctly. A test email is sent to the email address
specified in the To field.
Enable sending alerts – Check to be notified by email about any Zerto Virtual Replication alerts issued. An email is sent when
the alert is issued, and after it has been successfully handled and the alert is no longer valid.
Enable backup reports – Defines when backup reports will be emailed.

Site Settings Dialog 228

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

Reports Dialog

Configures the Resource Report.

Sampling Rate: When to take resource samples to identify resource usage, either daily at a specific hour and minute or hourly
at a specific minute within each hour. Note that collecting a sample hourly provides a higher resolution picture of replication
traffic than if samples are only collected once a day.
Sampling Time: The time that the sample is taken.

Site Settings Dialog 229

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

License Dialog

The Zerto license includes information such as the number of virtual machines that can be protected and the license expiry
date.
The cloud and enterprise license include the following details:
License – The license key itself.
License ID – An identifier for the license.
License Type – What is licensed: whether the license restricts the number of virtual machines that can be protected or the
number of sockets used.
Expiry Date – The license expiry date.
Quantity – The maximum number of virtual machines or sockets licensed, based on the license type. If blank, the quantity
is unlimited.
Maximum Sites – The maximum number of sites allowed.
An enterprise license also includes the following:
Usage – The sites using the license and number of protected virtual machines in each site. The number of virtual machines
is independent of whether they are in vApps or not.

Site Settings Dialog 230

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

About Dialog

The About dialog includes the Zerto Virtual Replication version number and whether to allow analytics to be sent to the
ZertoCall Home server to help improve Zerto Virtual Replication. You can also enable or disable the Zerto Virtual Manager to
send data to the SaaS platform for monitoring purposes.
Send analytics to Zerto – When selected, analytics are sent to Zerto that are used to improve Zerto Virtual Replication and to
automatically update Zerto Virtual Replication when a new version of a hypervisor is released that is supported by Zerto.
Send Data to Cloud – Allows licensed Zerto Virtual Manager users to enable or disable data being sent from the Zerto Virtual
Manager to the SaaS platform thereby enabling site monitoring using the Zerto Mobile App.
Note: The Enable Online Services and Zerto Mobile option is enabled by default.

Stop Failover Test Dialog

Enables stopping the testing of the selected VPG.

Result – Whether the test passed or failed.

Stop Failover Test Dialog 231

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
The Zerto Virtual Manager User Interface

Notes – A description of the test. For example, defines where external files that describe the tests are saved. Notes are limited
to 255 characters.
Stop button – Stops the testing. After stopping a test, the virtual machines in the recovery site are powered off and then
removed, and the checkpoint that was used for the test has the following tag added to identify the test:
Tested at startDateAndTimeOfTest.

TASKS

Monitor the recent tasks by clicking the TASKS area in the status bar at the bottom of the Zerto User Interface. The following
information is displayed for the most recent tasks:
■ The task status.
■ The name of the task.
■ A description of the task.
Also, actions, such as stopping a failover test, can be performed from this dialog.
Click See All Tasks to access MONITORING > TASKS.
For more details, see “Edit VM Dialog”, on page 213.

TASKS 232
 CHAPTER 22: GLOSSARY

Access Key (AWS) An alphanumeric text string that uniquely identifies the AWS account owner. No two accounts can
have the same AWS Access Key.
Amazon Web Services A collection of remote computing services, also called web services, that make up a cloud computing
(AWS) platform by Amazon.com. The most central and well-known of these services are Amazon EC2 and
Amazon S3. The service is advertised as providing a large computing capacity (potentially many
servers) much faster and cheaper than building a physical server farm.
Asynch Replication See Replication, Asynchronous.
Backup See Extended Recovery.
Bare Metal A computer system or network in which a virtual machine is installed directly on hardware rather than
within the host operating system (OS).
Bitmap Sync1 A change tracking mechanism of the protected machines during a disconnected state when Zerto
Virtual Replication starts to maintain a smart bitmap in memory to track and record changed storage
areas. Since the bitmap is kept in memory, Zerto Virtual Replication does not require any LUN or
volume per VPG at the source side.
The bitmap is small and scales dynamically, containing references to the areas of the source disk that
have changed but not the actual I/O. The bitmap is stored locally on the VRA within the available
resources. For example, when a VRA goes down and is then rebooted.
When required, Zerto Virtual Replication starts to maintain a smart bitmap in memory, to track and
record storage areas that change. When the issue that caused the bitmap sync is resolved, the bitmap
is used to check updates to the source disks and send any updates to the recovery site. A bitmap sync
occurs during the following conditions:
■ Synchronization after WAN failure or when the load over the WAN is too great for the WAN to
handle, in which case the VPGs with the lower priorities will be the first to enter a Bitmap Sync.
■ When there is storage congestion at the recovery site, for example when the VRA at the recovery
site cannot handle all the writes received from the protected site in a timely fashion.
■ When the VRA at the recovery site goes down and is then rebooted.
During the synchronization, new checkpoints are not added to the journal but recovery operations are
still possible. If a disaster occurs requiring a failover during a bitmap synchronization, you can recover
to the last checkpoint written to the journal.
Note: For the synchronization to work, the protected virtual machines must be powered on. The VRA
requires an active IO stack to access the virtual machine data to be synchronized across the sites. If
the virtual machine is not powered on, there is no IO stack to use to access the source data to
replicate to the target recovery disks.
Bucket (AWS) Amazon buckets are like a container for your files. You can name your buckets the way you like but it
should be unique across the Amazon system.
Business Continuity & An organization’s ability to recover from a disaster and/or unexpected event and resume or continue
Disaster Recovery operations. A disaster recovery, DR, plan is a subset of a Business Continuity plan. Organizations
(BC/DR) should have a business continuity, BC, plan in place that outlines the logistics and business operations.
The key metrics to be measured in a disaster recovery environment are the Recovery Point Objective
(RPO) and Recovery Time Objective (RTO).
Business Continuity Holistic management process that identifies potential threats to an organization and the impacts to
Management (BCM) business operations that those threats, if realized, might cause, and which provides a framework for
building organizational resilience with the capability for an effective response that safeguards the
interests of its key stakeholders, reputation, brand and value-creating activities. (ISO 22313, formerly
BS 25999-1).

Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Glossary 233
Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Glossary

Business Continuity Contains the instructions, procedures and guidelines that are developed and maintained in readiness
Plan for use during and after any potentially disruptive event in order to enable the organization to continue
to deliver its critical activities at an acceptable, predefined level.
Business Impact The process of analyzing business functions and processes and the effects that a business disruption
Analysis (BIA) might have upon them.
Checkpoint Zerto Virtual Replication ensures crash consistency by writing checkpoints to the journal every few
seconds. These checkpoints ensure write order fidelity and crash-consistency to each checkpoint.
During recovery you pick one of these crash-consistent checkpoints and recover to this point.
Additionally, checkpoints can be manually added by the administrator, with a description of the
checkpoint. For example, when an event is going to take place that might result in the need to perform
a recovery, you can pinpoint when this event occurs as a checkpoint in each journal.
Cloud Service Provider A service provider that offers customers storage or software services available via a private (private
(CSP) cloud) or public network (cloud). Usually, it means the storage and software is available for access via
the Internet. Typically Infrastructure as a Service (IaaS), Software as a Service (SaaS), or Platform as a
Service (PaaS) – are offered to their customers. Zerto enables them to offer Disaster Recovery As A
Service (DRaaS) and In-Cloud DR (ICDR), too.
Crisis Management Provides the overall coordination of the organization’s response to a crisis (which is a critical event
Plan that needs to be handled appropriately to prevent a damaging impact to the organization’s
profitability, reputation or ability to operate).
Data Deduplication A specialized data compression technique for eliminating duplicate copies of repeating data.
Delta Sync 1 The Delta Sync uses a checksum comparison to minimize the use of network resources. A Delta Sync
is used when the protected virtual machine disks and the recovery disks should already be
synchronized, except for a possible few changes to the protected disks, for example, when the target
recovery disk is defined as a preseeded (not available in the cloud) disk or after a VRA upgrade, or for
reverse protection after a move or failover.
During the synchronization, new checkpoints are not added to the journal but recovery operations are
still possible. If a disaster occurs requiring a failover during a delta synchronization, you can recover to
the last checkpoint written to the journal.
Note: For the synchronization to work, the protected virtual machines must be powered on. The VRA
requires an active IO stack to access the virtual machine data to be synchronized across the sites. If
the virtual machine is not powered on, there is no IO stack to use to access the source data to
replicate to the target recovery disks.
Disaster The occurrence of one or more events which, either separately or cumulatively, activate disaster
recovery.
Disaster Recovery The ability to restart operations after an interruption to the business according to a plan that ensures
an orderly and timely restoration.
Disaster Recovery Plan The disaster recovery, DR, plan is a component of the Business Continuity plan that details the
process and procedures to recover the organization’s resources to continue business operations. The
Technology DR plan focuses on the IT disaster recovery. Also see Business Continuity Plan.
Disaster Recovery As A disaster recovery solution that incorporates a service provider to replace or augment the
A Service (DRaaS) organization’s data protection implementation. In a DRaaS scenario, the customer may manage and
have complete control over the production data. The Cloud Service Provider (CSP) may provide a
partial or completely managed service. In either case, the CSP must ensure the availability of the data
and adapt as the customers infrastructure changes. An advantage of this model is the CSP has
dedicated resources skilled in DR operations.
DRS (vSphere) Enables balancing computing workloads with available resources in a VMware vCenter cluster.
Emergency Covers the immediate response to a situation or set of circumstances that present a clear and present
Management threat to the safety of personnel or other assets of the organization.
Estimated Recovery This is the estimated timings based on full resource provision available during a live invocation. This
Time (ERT) time typically sits between the Net Recovery Time and the Recovery Time Achieved (RTA) time.

234
Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Glossary

ESX/ESXi (vSphere) Bare-metal hypervisor from VMware, meaning it installs directly on top of the physical server and
partitions it into multiple virtual machines that can run simultaneously, sharing the physical resources
of the underlying server. ESXi is the most recent version.
Extended Recovery Extended DR includes the ability to configure both disaster recovery and offsite backups for the
protected virtual machines in the VPG, according to a user-defined data retention policy.
High Availability VMware high availability decreases downtime and improves reliability with business continuity by
(VMHA) enabling another ESX/ESXi host to start up virtual machines that were running on another ESX/ESXi
host that went down. High availability is automatically disabled by Zerto Virtual Replication while
updating recovered virtual machines in the recovery site from the VRA journal. After the promotion of
the data from the journal to the virtual machine completes, high availability is automatically re-
enabled. The HA configuration can include admission control to prevent virtual machines being
started if they violate availability constraints. If this is the case, then a failover, test failover or
migration of the virtual machines in a VPG to the cluster with this configuration will fail, if the
availability constraints are violated when the virtual machines are recovered.
Hyper-V A hybrid hypervisor, which is installed in the operating system. However, during installation it
redesigns the operating system architecture and becomes just like a next layer on the physical
hardware.
Hypervisor The host for multiple VMs in a virtualized environment. vSphere, ESX/ESXi, is the VMware brand
hypervisor. The hypervisor is the virtualization architecture layer that allows multiple operating
systems, termed guests, to run concurrently on a host computer.
Hypervisor Manager The tool used to manage the host. For example VMware vCenter Server and Microsoft SCVMM.
I/O (Input/Output) Describes any operation, program, or device that transfers data to or from a computer. Typical I/O
devices are printers, hard disks, keyboards, and mouses. In fact, some devices are basically input-only
devices (keyboards and mouses); others are primarily output-only devices (printers); and others
provide both input and output of data (hard disks, diskettes, writable CD-ROMs). In computer
architecture, the combination of the CPU and main memory (memory that the CPU can read and write
to directly, with individual instructions) is considered the brain of a computer, and from that point of
view any transfer of information from or to that combination, for example to or from a disk drive, is
considered I/O.
In-Cloud DR (ICDR) A disaster recovery solution that incorporates a service provider to replace or augment the
organization’s data protection implementation. When customers leverage an ICDR service, the CSP
hosts the production and DR sites. The virtual machines (VMs) are typically replicated from one CSP
datacenter to another CSP datacenter as a managed service or as managed co-located datacenters.
The customers have the ability to interact with their applications as if they were locally hosted.
Initial Sync1 Synchronization performed after creating the VPG to ensure that the protected disks and recovery
disks are the same. Recovery operations cannot occur until after the initial synchronization has
completed.
Adding a virtual machine to a VPG is equivalent to creating a new VPG and an initial synchronization
is performed. In this case, any checkpoints in the journal become unusable and only new checkpoints
added after the initial synchronization completes can be used in a recovery. The data in the journal
however remains and is promoted to the recovered virtual machine as part of a recovery procedure.
Note: For the synchronization to work, the protected virtual machines must be powered on. The VRA
requires an active IO stack to access the virtual machine data to be synchronized across the sites. If
the virtual machine is not powered on, there is no IO stack to use to access the source data to
replicate to the target recovery disks.
iSCSI An Internet Protocol (IP)-based storage networking standard for linking data storage facilities. By
carrying SCSI commands over IP networks, iSCSI is used to facilitate data transfers over intranets and
to manage storage over long distances.

235
Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Glossary

Journal Every write to a protected virtual machine is intercepted by Zerto Virtual Replication and a copy of the
write is sent, asynchronously, to the recovery site, while the write continues to be processed on the
protected site. On the recovery site the write is written to a journal managed by the Virtual Replication
Appliance. Each protected virtual machine has its own journal.
Each journal can expand to a size specified in the VPG definition and automatically shrinks when the
expanded size is not needed.
LUN Disk drives are the foundation of data storage, but operating systems cannot use physical disk storage
directly. The platters, heads, tracks and sectors of a physical disk drive must be translated into a
logical space, which an OS sees as a linear address space comprised of fixed-size blocks. This
translation creates a logical entity that allows operating systems to read/write files. Storage networks
must also partition their physical disks into logical entities so that host servers can access storage
area network (SAN) storage. Each logical portion is called a logical unit number (LUN). A LUN is a
logical entity that converts raw physical disk space into logical storage space, which a host server's OS
can access and use. Any computer user recognizes the logical drive letter that has been carved out of
their disk drive. For example, a computer may boot from the C: drive and access file data from a
different D: drive. LUNs do the same basic job.
Level of Business The reduced level of service that has been agreed if there is an interruption to business operations.
Continuity
Managed Service See Cloud Service Provider (CSP).
Provider (MSP)
Maximum Tolerable The maximum tolerable data loss an organization can endure without compromising its business
Data Loss objectives.
Maximum Tolerable The maximum time after which an outage will compromise the ability of the organization to achieve
Outage (MTO) its business objectives.
Maximum Tolerable The duration after which an organization's viability will be irrevocably threatened if product and
Period of Disruption service delivery cannot be resumed.
NAS A network-attached storage (NAS) device is a server that is dedicated to nothing more than file
sharing. NAS does not provide any of the activities that a server in a server-centric system typically
provides, such as e-mail, authentication or file management. NAS allows more hard disk storage
space to be added to a network that already utilizes servers without shutting them down for
maintenance and upgrades. With a NAS device, storage is not an integral part of the server. Instead, in
this storage-centric design, the server still handles all of the processing of data but a NAS device
delivers the data to the user. A NAS device does not need to be located within the server but can exist
anywhere in a LAN and can be made up of multiple networked NAS devices.
Net Recovery Time The net time achieved in recovering one or more VPGs after a disaster.
Offsite Backup See Extended Recovery.
Operational Level The agreement between the service management and the Service Provision Partners. It defines the
Agreement (OLA) responsibilities for support and delivery of the services provided.
Pair Zerto Virtual Replication can be installed at one or more sites and each of these sites can connect to
any of the other sites enabling enterprises to protect virtual machines across multiple vCenters or
within the same vCenter. Two sites connected to each other are considered paired. Also see
Replication to Self.
Preseed A virtual disk (a. vmdk flat file and descriptor or a .vhdx file) in the recovery site that has been
prepared with a copy of the protected data. Using this option is recommended particularly for large
disks so that the initial synchronization is much faster. When not using a preseeded disk the initial
synchronization phase has to copy the whole disk over the WAN. Zerto Virtual Replication takes
ownership of the preseeded disk, moving it from its source folder to the folder used by the VRA.
Note that preseeding is not available in the cloud.

236
Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Glossary

Quiesce Pausing or altering the state of running processes on a computer, particularly those that might modify
information stored on disk during a backup, in order to guarantee a consistent and usable backup.
Critical applications, such as databases have quiescent mechanisms that Zerto Virtual Replication can
use to get application consistent checkpoints.
RBAC Role-based Access control, available in the Zerto Cloud Manager via the Permissions tab.
RDM (vSphere) RDM is a mapping file in a separate VMFS volume that acts as a proxy for a raw physical storage
device. The RDM allows a virtual machine to directly access and use the storage device. The RDM
contains metadata for managing and redirecting disk access to the physical device.
The file gives you some of the advantages of direct access to a physical device while keeping some
advantages of a virtual disk in VMFS. As a result, it merges VMFS manageability with raw device
access.
Zerto Virtual Replication supports both physical and virtual mode RDMs.
Recovery Point The maximum amount of data that may be lost when the activity or service is restored after an
Objective (RPO) interruption. Expressed as a length of time before the interruption.
Recovery Time The actual times achieved during a DR test.
Achieved (RTA)
Recovery Time Related to downtime. The metric refers to the amount of time it takes to recover from a data loss
Objective (RTO) event and how long it takes to return to service. The metric is an indication of the amount of time the
system's data is unavailable or inaccessible, thus preventing normal service.
Replication, Technique for replicating data between databases or file systems where the system being replicated
Asynchronous does not wait for the data to have been recorded on the duplicate system before proceeding.
Asynchronous Replication has the advantage of speed, at the increased risk of data loss during due to
communication or duplicate system failure.
Replication to Self When a single vCenter is used, for example with remote branch offices, when replicating from one
datacenter to another datacenter, both managed by the same vCenter Server, you have to enable
replication to the same vCenter Server and pairing is not required.
Resource The elements (such as staff, site, data, IT systems) that are required to deliver an activity or service.
Resource Recovery Contains the instructions, procedures and guidelines to recover one or more resources and return
Plan conditions to a level of operation that is acceptable to the organization. Recovery Plans include
detailed recovery procedures for IT equipment and infrastructure.
Rolling Back Rolling back to an initial status, for example, after canceling a cloning operation on the VPG.
RPO See Recovery Point Objective (RPO).
RTO See Recovery Time Objective (RTO).
SAN A storage area network (SAN) is any high-performance network whose primary purpose is to enable
storage devices to communicate with computer systems and with each other. A storage device is a
machine that contains nothing but a disk or disks for storing data. A SAN's architecture works in a way
that makes all storage devices available to all servers on a LAN or WAN. As more storage devices are
added to a SAN, they too will be accessible from any server in the larger network. In this case, the
server merely acts as a pathway between the end user and the stored data. Because stored data does
not reside directly on any of a network's servers, server power is utilized for business applications, and
network capacity is released to the end user.
SCSI Acronym for Small Computer System Interface. SCSI is a parallel interface standard used by many
servers for attaching peripheral devices to computers. SCSI interfaces provide for faster data
transmission rates (up to 80 megabytes per second) than standard serial and parallel ports. In
addition, you can attach many devices to a single SCSI port, so that SCSI is really an I/O bus rather
than simply an interface.
SCVMM A Microsoft management solution for the virtualized datacenter, enabling you to configure and
manage your virtualization host, networking, and storage resources in order to create and deploy
virtual machines and services to private clouds that you have created.

237
Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Glossary

Secret Access Key A password. The Secret Access Key with the Access Key forms a secure information set that confirms
(AWS) the user's identity.
Security Group A virtual firewall that controls the traffic for one or more instances.
Service Continuity The continuity plan that acts as an umbrella document for a service, referencing other plans as
Plan required and providing service-specific emergency management and recovery plans.
Service Level The agreement between the customer and service provider which defines the service that is to be
Agreement (SLA) delivered to the customer.
Service Profile A predefined set of default properties to use when VPGs are defined or edited. Zerto provides a
default service profile and the option for the organization to specify their own requirements. The cloud
service provider can define service profiles to manage specific service level agreements (SLAs) with
its customers.
Service Test Plan Detailed plan defining the activities required to test the recovery of an individual IT service to meet
business requirements documented in the RTO and RPO.
Shadow VRA During normal operation, a VRA might require more disks than a single virtual machine can support. If
this situation arises, the VRA creates new shadow VRA virtual machines, used by the VRA to maintain
additional disks. These virtual machines must not be removed. A VRA can manage a maximum of
1500 volumes, whether these are volumes being protected or recovered.
Snapshots A snapshot is a block device which presents an exact copy of a logical volume, frozen at some point in
time. Typically this would be used when some batch processing, a backup for instance, needs to be
performed on the logical volume, but you don't want to halt a live system that is changing the data.
Zerto does NOT use a snapshot mechanism, but is constantly replicating data writes.
Storage Account Storage accounts are like a container for your files. You can name your storage account the way you
(Azure) like but it should be unique across the Azure system.
Subnet A logical, visible subdivision of an IP network.[1] The practice of dividing a network into two or more
networks is called subnetting.
Subscription (Azure) The description uses information derived from the following site:
https://blogs.msdn.microsoft.com/arunrakwal/2012/04/09/create-windows-azure-subscription/
An Azure subscription grants access to Azure services and Platform Management Portal. A
subscription has two aspects:
■ The Windows Azure account, through which resource usage is reported and services are billed.
■ The subscription itself, which governs access to and use of the Azure services that are subscribed
to.
System Center Virtual See SCVMM.
Machine Manager
Virtual Machine (VM) A virtual machine (VM) is an environment, usually a program or operating system, which does not
physically exist but is created within another environment. In this context, a VM is called a guest while
the environment it runs within is called a host.
Virtual Network A virtual network dedicated to an Azure subscription.
(VNet) (Azure)
Virtual Private Cloud An on demand configurable pool of shared computing resources allocated within a public cloud
(VPC) (AWS) environment, providing a certain level of isolation between the different organizations (denoted as
users hereafter) using the resources. The isolation between one VPC user and all other users of the
same cloud (other VPC users as well as other public cloud users) is achieved normally through
allocation of a Private IP Subnet and a virtual communication construct (such as a VLAN or a set of
encrypted communication channels) per user.
Virtual Protection See VPG.
Group
Virtual Replication See VRA.
Appliance

238
Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Glossary

VMDK, Virtual Virtual Machines created with VMware products typically use virtual disks. The virtual disks, stored
Machine Disk as files on the host computer or remote storage device, appear to the guest operating systems as
standard disk drives.
Volume Delta Sync1 Synchronization when only delta changes for a volume needs synchronizing, for example, when a
virtual machine is added to a VPG using a preseeded disk.
During the synchronization, new checkpoints are not added to the journal. Also, recovery operations
are not possible during a Volume Delta Sync.
For the synchronization to work, the protected virtual machines must be powered on. The VRA
requires an active IO stack to access the virtual machine data to be synchronized across the sites. If
the virtual machine is not powered on, there is no IO stack to use to access the source data to
replicate to the target recovery disks.
Preseeding is not available in the cloud.
Volume Full Sync1 Synchronization when a full synchronization is required on a single volume.
During the synchronization, new checkpoints are not added to the journal. Also, recovery operations
are not possible during a Volume Full Sync.
Note: For the synchronization to work, the protected virtual machines must be powered on. The VRA
requires an active IO stack to access the virtual machine data to be synchronized across the sites. If
the virtual machine is not powered on, there is no IO stack to use to access the source data to
replicate to the target recovery disks.
Volume Initial Sync1 Synchronization when a full synchronization is required on a single volume, for example, when
changing the target datastore or adding a virtual machine to the VPG without using a preseeded (not
available in the cloud) disk.
During the synchronization, new checkpoints are not added to the journal. Also, recovery operations
are not possible during a Volume Initial Sync.
For the synchronization to work, the protected virtual machines must be powered on. The VRA
requires an active IO stack to access the virtual machine data to be synchronized across the sites. If
the virtual machine is not powered on, there is no IO stack to use to access the source data to
replicate to the target recovery disks.
VPG Virtual machines are protected in virtual protection groups. A virtual protection groups (VPG) is a
group of virtual machines that you want to group together for replication purposes. For example, the
virtual machines that comprise an application like Microsoft Exchange, where one virtual machine is
used for the software, one for the database and a third for the Web Server, require that all three virtual
machines are replicated to maintain data integrity.
VRA A virtual machine installed on each hypervisor hosting virtual machines to be protected or recovered,
that manages the replication of protected virtual machine writes across sites. A VRA must be installed
on every hypervisor that hosts virtual machines that require protecting in the protected site and on
every hypervisor that will host the replicated virtual machines in the recovery site.
vSphere VMware’s server virtualization platform for building a cloud infrastructure.
Zerto Cloud Connector A virtual machine installed on the cloud side, one for each customer organization replication network.
(ZCC) The Zerto Cloud Connector requires both cloud-facing and customer-facing static IP addresses. The
ZCC routes traffic between the customer network and the cloud replication network, in a secure
manner ensuring complete separation between the customer network and the cloud service provider
network. The ZCC has two Ethernet interfaces, one to the customer’s network and one to the cloud
service provider's network. Within the cloud connector a bidirectional connection is created between
the customer and cloud service provider networks. Thus, all network traffic passes through the ZCC,
where the incoming traffic on the customer network is automatically configured to IP addresses of the
cloud service provider network.

239
Zerto Virtual Manager Administration Guide for Microsoft Azure Environments - Version 5.5 Update 3
Glossary

Zerto Cloud Manager A Windows service, which enables managing all the cloud sites offering disaster recovery using a
(ZCM) single interface. The ZCM manages the DR either as a service (DRaaS) or completely within the cloud
environment, protecting on one cloud site and recovering to a second site (ICDR).
Zerto User Interface Recovery using Zerto Virtual Replication is managed via a user interface: in a browser via the Zerto
Virtual Manager Web Client, or in either the vSphere Web Client or vSphere Client console in the
Zerto tab.
Zerto Self-service An out-of-the-box DR portal solution with a fully functioning browser-based service portal to enable
Portal (ZSSP) cloud service providers to quickly introduce disaster recovery as part of their portal offering.
Zerto Virtual Backup A Zerto Virtual Replication service that manages the offsite backup.
Appliance (VBA)
Zerto Virtual Manager A Windows service, which manages everything required for the replication between the protection
(ZVM) and recovery sites, except for the actual replication of data. The ZVM interacts with the vCenter
Server to get the inventory of VMs, disks, networks, hosts, etc. The ZVM also monitors changes in the
VMware environment and responds accordingly. For example, a vMotion operation of a protected VM
from one host to another is intercepted by the ZVM so the Zerto User Interface is updated
accordingly.
ZORG, Zerto Cloud customers are defined to Zerto Cloud Manager as Zerto organizations, ZORGs. A ZORG is
Organization defined with the cloud resources it can use, the permissions that it has to perform operations, such as
testing a failover or defining a VPG.
1. Synchronization after a recovery starts after the promotion of data from the journal to the virtual machine disks ends. Thus, synchronization of virtual ma-
chines can start at different times, dependent on when the promotion for the virtual machine ends. All synchronizations are done in parallel, whether a delta
sync or full sync, etc.

240
 INDEX

A site settings ............................................................................119

access key ID ................................................................................. 118 compression
alerts ...............................................................................................203 configuring for backups ...............................................77, 175
caused by timeout ................................................................. 95 to minimize bandwidth ......................................................... 14
email settings ....................................................................... 120 compression for offsite backup, enabling ............................. 223
generated by a failover .......................................................152 connecting sites, see pairing
generated by a move ...........................................................136 connectivity, checking ............................................................... 104
in Dashboard .......................................................................... 65 crash consistency, VSS ................................................................ 89
in single VPG tab ................................................................... 70
analytics, sending to Zerto ................................................123, 231 D
application-consistent checkpoints .......................................... 87 Dashboard ................................................................................17, 64
architecture ......................................................................................10 alerts, events, and running tasks ...............................65, 70
AWS performance graphs ..............................................................65
access key ID ......................................................................... 118 stopping a failover test .......................................................128
editing VPG settings ............................................................215 default gateway, configuring .......................................................52
Azure delta sync .......................................................................50, 59, 100
limitations ........................................................................22, 28 for volumes ............................................................................ 101
diagnostics utility ............................................................... 104, 105
B changing IP address of ZCA ..............................................105
backups, see offsite backup checking connectivity ........................................................ 104
bandwidth collecting logs ............................................................. 190, 192
freeing up ................................................................................84 reconfiguring access to SQL Server DB ......................... 110
in resources report ............................................................... 181 troubleshooting ....................................................................188
bitmap sync ................................................................100, 148, 233 disaster recovery
boot order ............................................................................. 132, 147 during a test ..........................................................................154
configuring .................................................... 34, 45, 55, 204 initiating ................................................................141, 148, 168
branding the Recovery report .................................................. 180 types .......................................................................................... 19
disk
RDM ....................................................................... 39, 218, 219
C
swap ......................................................................................... 50
CALLHOME ...................................................................................123
disk size
change rate
estimating ...............................................................39, 49, 218
estimating .............................................................. 39, 49, 218
checkpoint ..................................85, 87, 89, 150, 156, 196, 207
add ............................................................................................ 87 E
adding manually .................................................................... 88 email settings ......................................................................120, 228
adding via Add VSS Checkpoint dialog ............................ 91 configure ................................................................................120
adding via command line ..................................................... 91 for alerts and backup reports ............................................120
application-consistent ......................................................... 87 environment variable ............................................................94, 95
choosing .....................................................126, 147, 150, 156 ZertoForce ...............................................................................95
purpose .................................................................................... 24 ZertoOperation ..................................................................... 94
renaming after testing failover .........................................129 ZertoVCenterPort ..................................................................95
scheduling ................................................................................ 91 ZertoVPGName ..................................................................... 94
Chrome ............................................................................................. 15 events
clock synchronization with NTP ..............................................223 in Dashboard ...........................................................................65
cloning ...................................................................................... 155–?? in single VPG tab ............................................................65, 70
definition .................................................................................155 export to CSV
COM permissions, setting for VSS ........................................... 93 VPG details ............................................................................. 69
commit policy ............................................................................... 147
failover and move ................................................................. 119
for failover and move .........................................................227
site setting .............................................................................227

241
F journal history ................................................................................ 70
failback ........................................................................................... 166
after failover ..........................................................................167 K
enable after failover ..........................................134, 142, 169 Keep Source VMs ............................................................... 132, 137
failover ..........................................................................147–154, 166
commit policy ...............................................................119, 227
L
description ............................................................................ 147
license ............................................................................................. 122
during a test .......................................................................... 154
updating ................................................................................. 122
failback .................................................................134, 142, 169
Linux machines
generating alerts ...................................................................152
file and folder recovery .......................................................158
initiating ............................................................... 141, 148, 168
logs
initiating during a test ........................................................ 154
collecting .........................................................................190–??
overview ................................................................................. 114
collecting when Zerto Virtual Manager is down .........192
process ................................................................................... 166
logs, collecting .....................................................................189–193
stopping a test ......................................................................128
logs, understanding .....................................................................194
testing .................................................................................... 124
topology .......................................................135, 143, 151, 170
failover test M
in a sandbox .......................................................................... 130 MAC address .................................................................................. 61
overview ..................................................................................112 Microsoft SQL Server DB
file recovery ...................................................................................158 reconfiguring ......................................................................... 110
Linux machines .....................................................................158 migration, see move
Firefox ................................................................................................ 15 monitor
folder recovery ..............................................................................158 alerts, events, and running tasks ...............................65, 70
Linux machines .....................................................................158 recent tasks .......................................................................... 232
force delete ..................................................................................... 99 monitoring
VPG ........................................................................................... 86 one VPG .................................................................................. 69
full synchronization ...................................................................... 101 sites ...........................................................................................76
for volumes ............................................................................ 101 virtual machines .................................................................... 74
VPGs tab ..................................................................................65
move .................................................................... 132–137, 144, 170
G
commit policy ..............................................................119, 227
geometry, non-default ........................................................ 39, 219
definition ................................................................................ 132
glossary ............................................................................... 233–240
description ............................................................................ 140
generating alerts ..................................................................136
H initiating .................................................................................. 133
HTTPS ............................................................................................... 15 overview ..................................................................................113
using a scratch volume ............................................. 144, 170
I
initial synchronization ..........................................21, 24, 102, 211 N
instance family NAT rules ........................................................................................ 60
choosing ................................................................................. 119 needs configuration .....................................................................102
instance size troubleshooting ....................................................................188
choosing ......................................................127, 133, 137, 152 network
instance type for failing over or moving ............................................ 40, 50
choosing ........................................................................ 119, 147 for testing ........................................................................ 40, 50
Internet Explorer, supported versions ....................................... 15 NTP clock synchronization ....................................................... 223

J O
journal ............................................................. 47, 56, 85, 198, 199 offsite backup ................................................................... 12, 20, 26
adding a checkpoint .............................................................. 87 configuring .............................................................................174
defining its storage ...............................................................49 enabling compression ........................................................ 223
defining save time ............................................................... 198 flow ........................................................................................... 20
description .............................................................................. 24 monitoring ...............................................................................77
storage ..............................................................................36, 47 repository ......................................................................174, 176

242
 restoring ..................................................................................20 Recovery .................................................................................178
retention period ......................................................20, 26, 82 recovery operations (test, failover, move) ....................178
running ..................................................................................... 86 Resources ...............................................................................180
running unscheduled ............................................................ 86 Resources report ..................................................................180
setting up ............................................................................... 174 VPG Performance ................................................................184
status in Dashboard ......................................................67, 75 repository
status in single VPG tab ...................................................... 70 defining new ......................................................................... 222
status in VPGs tab ........................................................ 67, 68 offsite backup ..............................................................174, 176
storing ...................................................................................... 26 Resources report ..........................................................................180
offsite backup repository configuring ............................................................................ 229
editing .....................................................................................176 generating with REST API ...................................................181
Offsite Backups report ................................................................185 output .....................................................................................182
Outbound Protection Over Time report .................................178 Resources report, configure .......................................................121
restore
P offsite backup ........................................................................ 20
pairing ....................................................................................110, 209 retention period
pause protection ............................................................................84 offsite backup .................................................................20, 26
performance graphs ..................................................................... 65 reverse protection, see failback
for a single VPG ..................................................................... 69 rollback
policies failover ...........................................................................147, 152
configuring ............................................................................. 119 move ........................................................................................136
PowerShell cmdlet setting for failover or move ................................................119
Set-Checkpoint ...................................................................... 87 running tasks, see tasks
preseed ................................................................... 39, 50, 218, 219
recovery volume .............................................................39, 59 S
preseeding ....................................................................................... 86 sandbox ..........................................................................................130
promotion of data ................................................................ 144, 171 scheduling checkpoints ................................................................ 91
protection scratch volume ................................................................... 144, 170
pause ........................................................................................ 85 scripts
resume ..................................................................................... 85 creating .....................................................................................95
provisioned storage ...............................................................67, 75 examples ..................................................................................97
running ..................................................................................... 94
R ZertoForce environment variable ......................................95
raw disk (RDM) ............................................................................218 ZertoOperation environment variable ............................ 94
recovery ................................................................................ 147, 166 ZertoVCenterPort environment variable .........................95
during a test .......................................................................... 154 ZertoVPGName environment variable ........................... 94
initiating ............................................................... 141, 148, 168 security certificate
to Hyper-V ..............................................................................44 adding ....................................................................................... 15
to VMware vCenter Server ................................................. 32 Set-Checkpoint cmdlet .................................................................87
to VMware vCloud Director ............................................... 53 settings
types .......................................................................................... 19 importing VPG ....................................................................... 98
recovery host, changing ............................................................ 206 settings, for a site .................................................................117–122
Recovery report ............................................................................178 shadow VRA ................................................................................. 238
branding ................................................................................. 180 signature matching, WAN optimization .................................. 14
recovery site, pairing ................................................................... 110 site details
recovery volume monitoring .............................................................................. 64
preseeding ........................................................................39, 59 site settings .................................................................................. 226
swap ..................................................................................39, 59 commit policy ..............................................................119, 227
registration .....................................................................................122 defining ....................................................................................117
re-IP .....................................................................................42, 52, 61 email ........................................................................................120
vNIC configuration ................................................................ 42 recovery policies ...................................................................119
Replication Pause Time ........................................................85, 119 Resources report ...................................................................121
reports ................................................................................... 178–186 Sites tab ............................................................................................76
Offsite Backups .....................................................................185 sizing
Outbound Protection Over Time .....................................178 volumes ...................................................................39, 49, 218

243
SLA information .............................................................................. 21 V
status v
VPG ................................................................................... 98, 99 vApp network mapping ............................................................... 60
storage VBA ..................................................................................................174
for replicated data .................................................................49 vCD guest customizing ................................................................ 60
provisioned ......................................................................67, 75 VIB ............................................................................. 205, 208, 220
sizing .........................................................................................49 Virtual Backup Appliance, see VBA
storage profile ....................................................................... 57, 183 virtual machine
for vCD ..................................................................................... 59 modifying replication settings .......................................... 213
stored offsite backup .................................................................... 26 monitoring .............................................................................. 74
summary tab ...................................................................................64 virtual protection group, see VPG
swap disk .........................................................................................50 Virtual Replication Appliance, see VRA
recovery volume .............................................................39, 59 VM in Several VPGs .......................................................11, 82, 132
synchronization vNIC
bitmap .................................................................................... 100 configuring ............................................................................... 61
delta ..........................................................................................50 configuring re-IP .....................................................................52
delta sync .............................................................................. 100 vNIC configuration
delta sync for volumes ........................................................ 101 re-IP .......................................................................................... 42
forcing ...................................................................................... 85 volume
full ............................................................................................. 101 estimating size .......................................................39, 49, 218
initial ................................................................. 21, 24, 59, 102 full synchronization ............................................................. 101
length of time ......................................................................... 25 preseed ............................................................................. 39, 59
status ...................................................................................... 102 Volume Shadow Copy Service, see VSS
taking a long time ................................................................ 188 VPG .................................................................................................... 19
synchronization triggers add a virtual machine ........................................................... 82
VPG ..................................................................................98, 103 configuring ............................................................................... 21
creating to vCenter Server ........................................... 32, 43
T definition ............................................................................19, 21
tasks .................................................................................................. 72 deleting .....................................................................................85
in Dashboard .......................................................................... 65 editing ..................................................................................... 215
in single VPG tab ................................................................... 70 force delete ............................................................................. 99
monitoring .............................................................................232 importing settings ................................................................. 98
test failover ................................................................................... 124 modifying ................................................................................. 81
description ............................................................................ 124 monitoring ...............................................................................65
overview ..................................................................................112 monitoring one ...................................................................... 69
stopping ..................................................................................128 pausing protection ................................................................ 84
thin provisioning ............................................................................ 59 saving details to a file .......................................................... 69
throttling ...........................................................................................14 synchronization triggers ............................................ 98, 103
topology synchronizing ..........................................................................85
for failover ...................................................135, 143, 151, 170 testing failover ......................................................................124
transaction consistency topology ................................................................................... 71
VSS ............................................................................................ 89 waiting to be removed ......................................................... 86
triggers VPG Performance report ............................................................184
synchronization ..................................................................... 98 VPG status
VPG synchronization .......................................................... 103 VPG waiting to be removed ........................................86, 99
troubleshooting ................................................................... 187–194 VPG statuses ...........................................................................98, 99
collecting logs ...................................................................... 189 VPGs tab
collecting logs when Zerto Virtual Manager is down .192 monitoring ...............................................................................65
Needs Configuration .......................................................... 188 VRA ...................................................................................12, 19, 238
using the Diagnostics utility ............................................. 188 changing recovery host .....................................................206
VPG syncing ......................................................................... 188 troubleshooting ....................................................................188
VRA problems ...................................................................... 188 VSS ................................................................................... 87, 89, 160
Zerto Virtual Manager service .........................................187 crash consistency ................................................................. 89
setting COM permissions ....................................................93
transaction consistency ...................................................... 89

244
 W
WAN
signature matching ................................................................14
WAN bandwidth, freeing up ......................................................84
WAN optimization .........................................................................14
Windows service
Zerto Virtual Manager ........................................................187
ZertoVssprovider ..................................................................90

Z
Zerto Cloud Appliance .................................................................. 15
Zerto User Interface
accessing .................................................................................. 15
configuration ........................................................................... 17
customizing ............................................................................. 18
description ............................................................................... 17
Zerto Virtual Manager ..................................................................10
checking component connectivity .................................. 104
managing ............................................................................... 104
reconfiguring ........................................................................ 105
Windows service ..................................................................187
Zerto Virtual Replication
architecture .............................................................................10
benefits ..................................................................................... 12
description ...............................................................................10
logs .......................................................................................... 194
version information ..............................................................123
ZertoForce script ........................................................................... 95
ZertoOperation script ..................................................................94
ZertoVCenterPort script .............................................................. 95
ZertoVPGName script .................................................................94
ZertoVssAgent
installing .................................................................................. 89
ZertoVssAgent.exe ........................................................................ 91
ZertoVssAgentGUI.exe.conf .............................................. 90, 94
ZertoVssprovider
Windows service ...................................................................90
ZORG
preseeding ............................................................................... 59
ZVM, see Zerto Virtual Manager

ABOUT ZERTO www.zerto.com

Zerto is committed to keeping enterprise and cloud IT running 24/7 by providing scalable business continuity For further assistance
software solutions. Through the Zerto Cloud Continuity Platform, organizations seamlessly move and protect using Zerto Virtual
virtualized workloads between public, private and hybrid clouds. The company’s flagship product, Zerto Virtual Replication, contact
Replication, is the standard for protection of applications in cloud and virtualized datacenters. @Zerto Support.

Copyright © 2017, Zerto Ltd. All rights reserved.