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 up to a year. The user defines what data is saved where, and for how long the data should be retained, according to the organizations regulation policy. When the user needs to restore the data, they can then select a specific point in time.
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 retention repository.
When the second reading 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 retention set is independent of other 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?
When the defined Retention Policy period is completed, as new retention sets are added, the oldest retention sets are deleted and can no longer be restored.
Before You Begin
Review Long Term Retention limitations and considerations:
■ Repository Type:
■ SMB and local repositories are not supported.
■ Only NFS Repository is supported.
■ Supported NFS protocol version 3.
■ NFS repository does not support authentication.
■ NFS repository based on PBBA (eg data domains and so on), is not supported.
■ Incremental:
■ Zerto can track and maintain up to 40TB of changes between copies (incremental) for long term retention on a single VRA. In the event of exceeding 40TB at any point, the VRA will be locked for running future retention processes. To release that lock, please contact Zerto Support.
■ Performing incrementals is based on identifying the initial copy and maintaining changes which happened since. In the event where either the changes tracked between copies or the reference to the initial copy are lost, a full copy will be created.
■ Retention Policy:
■ The retention policy aggregation rule is described in the Administration Guide > Using Zerto's Long Term Retention > Storing Repository Sets.
■ Deleted retention sets are removed from the repository according to the configured retention policy.
In scenarios where the total volume consumed size (meaning, the initial copy and incrementals) exceeds 10TB, some of the unreferenced data blocks will not be removed.
■ Only complete Backups and Restores of VMs is allowed. Partial Backups and Restores are not supported.
■ Restoring of VPGs is allowed for VPGs which currently exist, or which were deleted.
■ Reconnecting to 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 volume will be performed.
■ Long Term Retention requires Enterprise Cloud Edition, Cloud One2Many or NFR/Trial license.
■ Certain failures when running retention sets may require Support intervention to re-enable them.
■ Zerto is moving away from Offsite Backup into modern Long Term Retention. Therefore, Offsite Backup will no longer be supported. As such, repositories and backup configurations created in previous versions are deleted as part of the upgrade to v6.5.
■ Backups created in versions prior to ZVR v6.5 cannot be restored in v6.5.
■ Backup configurations in v6.0Ux are deleted upon upgrade to v6.5.
■ Configuring a backup from v6.0Ux to v6.5 is not possible.
■ Restoring of backups which were created in version 6.0 or prior, requires using ZVM version 6.0Ux.
■ 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.
■ When editing a VPG where the protected site is v6.0Ux, and the recovery site is v6.5x, the user will need to ensure that Long Term Retention is disabled in order to save any changes to the VPG.
■ Long Term Retention is not supported where the recovery site is a Public Cloud.
■ The SETUP tab in the ZCA was removed.
■ Backup Reports are no longer available.
■ Repository failures such as insufficient space or unavailability are not displayed in the GUI.