Long Term Retention - Overview
Using Zerto’s data retention to restore data, IT users are able to define a Retention Policy for their organization, where data can be retained for extended periods of time. The user defines what data is saved where, and for how long the data should be retained, according to the organizations regulation policy. Each VPG is equipped with its own retention policy.
When the user needs to restore the data, they can then select a specific point in time and perform a VPG level restore.
To support advanced VM-level or file-level restore scenarios, Zerto offers the capability to index files and folders of selected VMs that are enabled for retention. This allows users to search for the necessary files and folders and to perform a one-click restore of the VMs or VPGs containing those files and folders.
What does the Repository Contain?
The Repository contains retention sets, where each retention set has it’s own mapping file (DOM file).
How does the Long Term Retention process work?
When Long Term Retention is first configured, and the first reading of the data has occurred, the retention set consists of:
■ All the data copied to the Repository.
When the second reading and any subsequent readings after a full retention of the data occurs, the retention set consists of:
■ All the data from the first reading, but not including any original data which was marked as changed during the second reading.
■ The changed data from the second reading.
Each incremental retention set is independent of previous incremental and full retention sets, and gives a complete and total picture of the data at the point in time of the reading.
What happens when the Retention Policy period is overdue?
Retention sets are kept for the retention period specified as part of the Retention Policy configuration. Once the retention expires, the expired retention sets will be deleted from the Repositories.
Before You Begin
Review Long Term Retention limitations and considerations:
■ Upgrade:
■ Existing NFS Repositories will be renamed to deprecated and can be used for Restores only. New repositories must be created for continued LTR use with Zerto 7.0.
■ Long Term Retention configuration settings for all VPGs will be removed. All other VPG settings will remain unaffected.
■ Retention processes will fail until all VRAs have been upgraded to 7.0.
■ Repository Supported Protocols:
■ NFS - up to version 3.
■ SMB - version 2 and 3.
■ SMB can be configured using IP address only (no DNS Name).
■ Incremental:
■ Zerto can track up to 40TB of changes per volume.
■ Scheduling and Retention Policy:
■ All scheduled retention process periods (Daily, Weekly, Monthly, Yearly) are scheduled to run at the same time. If a Full and Incremental are scheduled for the same day, the system will run a Full retention process. For example, if a Daily retention process is set to run a Full on Sunday and a Weekly is set to run an Incremental on Sunday, a Full retention process will be performed.
■ Deleted VPGs are not managed and their retention sets are not removed from the repository, even when the retention period has passed.
■ Retention sets generated in 6.5 will not be managed by any retention policy and will need to be manually deleted from the Repository when expired.
■ In some scenarios, the retention process will wait in queue and will start running only on the following day, resulting in two retention sets on the same day.
■ Sync from Repository:
■ Restoring VPGs is allowed for VPGs which currently exist, or which were deleted.
■ Restoring previously created retention sets, which were created before the Repository was created, from a previously populated 6.5 Repository which has been added to the 7.0 system is not supported.
■ Restoring from a Repository containing retention sets, which were created prior to adding the repository to the system, is not supported.
■ Reconnecting a Repository is not supported.
■ Attaching an existing Repository and leveraging copies for the next incremental is not supported. Therefore, any Repository is considered new after defining it and a complete reading of the repository will be performed.
■ Search and Restore:
■ ZVM minimum requirements for performing Search and Restore: at least 4 vCPUs and 10GB RAM.
■ Saving indexed meta-data is currently only supported on SMB Repositories which are not PBBA based.
■ When configuring SMB repositories used for indexing, do not use a local user account.
■ Operating Systems, File Systems and Volume Manager that Zerto can index:
■ Operating Systems: Windows Vista and 2008 server and above and Linux
■ File System and Volume Manger: NTFS and EXT2/EXT3/EXT4
■ LVM is not supported for indexing
■ A VM with over 100 million entries (files or folders) cannot be indexed.
■ Rate of entries (files or folders) indexed in NTFS per second: 2000 files.
■ Rate of entries (files or folders) indexed in EXT per second: 1500 files.
■ Supported partitioning methods: GPT, MBR.
■ Zerto can index up to 3 VMs in parallel and no more than one per recovery host.
■ Search and Restore is available only from a recovery ZVM GUI.
■ While indexing, only a Failover operation is allowed and this will stop the indexing process (indexing cannot be resumed).
■ Modified date: displayed in the browser local time.
■ Search is not case sensitive.
■ Support only search according to entry name (not full path).
■ If the user does not configure a Repository for indexing and indexing starts after the retention process, no alert will be displayed to notify the user that indexing has not happened.
■ No multi-tenancy support.
■ Search and Restore requires Enterprise Cloud Edition, Cloud One2Many or NFR/Trial license.
■ If a VM with a Retention policy set has 2 disks with the same name, the 2 disks cannot be restored to the same datastore.
■ Licensing:
■ Long Term Retention requires Enterprise Cloud Edition, Cloud One2Many or NFR/Trial license.
■ Error Handling:
■ Certain failures when running retention sets may require Support intervention to re-enable them.
■ Performance:
■ DSS and VRA consume CPU. As such, if the CPU on the VRA reaches high consumption rates, another CPU should be added to the VRA machine. Adding additional CPUs on top of the additional one is redundant and the additional CPUs will not be utilized.
■ Manual Retention Processes:
■ If the scheduled retention process on that day has already executed, manual retention will either run the last settings used, or run a default of 90 days incremental.
■ Cloud Service Providers and Zerto Cloud Manager Users:
■ Extended Recovery" Service profiles are not supported.
■ Other:
■ Partial retention processes (e.g. some volumes have succeeded and others have not) and Restores are not supported.
■ When editing a VPG where the protected site is 6.5Ux, and the recovery site is 7.0, the user will not be able to see updated scheduling settings. Any scheduling configuration done on the 6.5 GUI will be ignored.
■ Long Term Retention is not supported where the protected or recovery site is a Public Cloud. Therefore, the SETUP tab in the ZCA was removed.
■ Only one Long Term Retention task can run on a VPG concurrently.
■ Retention Reports are not available in 7.0.
■ When configuring FreeNAS as an LTR Repository connected via the SMB protocol, the “Server minimum protocol” parameter needs to be explicitly set with “3_00”.
■ If one or more volumes are in "initial sync" state during a Retention process, these volumes are excluded and the Retention process will be considered as Failed.