This privacy policy applies to owned and operated by OTAVA, LLC. (“OTAVA”, “We”, “Us”) This privacy policy describes how OTAVA collects and uses the personal information you provide on our web site and client facing portal. It also describes the choices available to you regarding our use of your personal information and how you can access and update this information.
Last revised: 07/10/23
This Service Level Agreement (“SLA”) is an addendum to and is hereby incorporated into that certain Master Services Agreement entered into between Otava, LLC and the Client (the “MSA”). This SLA is subject to the MSA. Capitalized terms used in this SLA but not otherwise defined in this SLA, will have the meaning attributed to such terms in the MSA.
2.1. “Commitment” means collectively and individually, the Workload Protection Commitment, DRaaS Commitment, Network Availability Commitment, Power Availability Commitment, and Server Availability Commitment.
2.2. “Critical Maintenance” means a maintenance event intended to prevent or correct the failure of any component or system that is used to provide services to Otava clients.
2.3. “Downtime” means the interruption or unavailability of a Service as further set forth in this SLA and includes Workload Protection Downtime, DRaaS Downtime, Network Downtime, Power Downtime, and Server Downtime. Downtime does not include Downtime Exclusions.
2.4. “Maintenance Event” means, collectively, Critical Maintenance and Planned Maintenance.
2.5. “Planned Maintenance” means a planned maintenance event that may cause a Service component provided to Client to become interrupted or unavailable.
2.6. “Service Credit” means that certain percentage of the applicable Service fee as set forth in this SLA for the specific Service component that may be credited to Client’s account in accordance with this SLA.
2.7. “Statuspage” means https://status.otava.com, or such other url for status updates as Otava may provide.
2.8. “Support Portal” means https://support.otava.com, or such other url for support issues as Otava may provide.
3.1. General Applicability. The terms in this Section 3 apply to all Otava services contemplated in this SLA and are in addition to any service level terms that may be set forth in this SLA for specific Otava service components, provided that any such additional service level terms are limited to the specific service component referenced in the relevant section.
3.2. Support. Otava will provide technical support to Client via e-mail, telephone, and online chat 24 hours a day, 7 days a week, provided that Client understands that Otava may have limited staff availability during holidays. To initiate a support ticket, Client may call Otava at the designated support phone number or submit a support request via the Support Portal. Only those individuals who are listed as authorized individuals in the Support Portal or those individuals who such authorized individuals expressly designate in writing (via e-mail or by submitting a ticket in the Support Portal) may receive support from Otava. Client sets the initial severity level of a support issue in reporting to Otava. Otava may downgrade the severity level according to Client’s information and Otava’s discoveries during the problem resolution efforts. The support issue severity will determine the response levels within Otava. The description, response times, and responsibilities are as follows:
| Severity | Client Impact | Initial Response | Resolution Target | |
| Severity 1: Critical | Service or production outage, significant risk of outage, or a significant impact on mission critical functions | Within 1 hour | Within 3 hours (quarter hour updates) | |
| Severity 2: High | Degraded Services or production or there is a Services outage and a workaround may be available | Within 2 hours | Within 6 hours (hourly updates) | |
| Severity 3: Medium | Non-critical environment degradation, non-critical systems degradation, or single user is impacted | Within 4 hours | Within 48 hours (four-hour updates) | |
| Severity 4: Low | General questions, a low impact issue, documentation issue, changes or moves, or scheduled or planned work | As scheduled | As scheduled | |
Initial response indicates the time from the creation of the ticket until Otava has the relevant Service restored, provides a status update on the impact on services, provides information about a workaround, or determines that a software or third party vendor fix is required. Resolution target indicates the time from the creation of a ticket until Otava has a long term fix and maintenance is fully completed to deploy a fix or avoid a workaround. Client understands that the resolution target is an estimate and may be impacted by multiple factors that are outside the direct control of Otava, including, without limitation, Client’s failure to respond to Otava’s inquiries, Client staffing, and the like. Resolution target does not apply when a software or third-party vendor fix is required.
3.3. Maintenance Events. Client may view the availability of Otava’s services at any time by visiting the Statuspage. Otava will notify Client about Maintenance Events by posting a notice on the Statuspage. Client will ensure that its relevant workforce members subscribe to the Statuspage to receive Services related notices and updates, including about Maintenance Events. In general, Otava provides notice of (a) Planned Maintenance approximately 5 calendar days prior to the Planned Maintenance; and (b) Critical Maintenance approximately 24 hours prior to the Critical Maintenance. Client understands and acknowledges that circumstances may arise where Otava may provide less or no notice about a Maintenance Event and in such circumstances, Otava will provide as much notice as reasonably feasible in light of the circumstances and will provide prompt updates on the Statuspage. During any Maintenance Event, Otava will make commercially reasonable efforts to ensure that Client does not experience a Downtime event to any of the Services. Otava will make commercially reasonable efforts to ensure that Maintenance Events are scheduled during off-peak hours.
3.4. Downtime Exclusions. Downtime does not include interruption or unavailability (this Section 3.4 collectively, as the “Downtime Exclusions”):
(a) caused by (i) a Maintenance Event or a Force Majeure Event, or (ii) during proof of concept, initial deployment, staging, or migration into production;
(b) caused by factors outside of the commercially reasonable control of Otava, including, without limitation, Internet access or related problems beyond the Otava Network Demarcation Point (such as DDoS attacks);
(c) caused by or resulting from equipment, software, or other infrastructure (i) that is managed by Client, a Clientvendor (other than Otava), or a third party (such as Microsoft® with respect to Microsoft Azure® services or Client’s registrar), (ii) that is outside the direct control of Otava, or (iii) that was developed by a third party, even if managed or monitored by Otava (such as patches issued by Microsoft, Cisco®, Fortinet®, LogRhythm®, Veeam®, VMware®, and the like);
(d) resulting from or are caused by the actions or inactions of Client or its agents or vendors, including, without limitation, Client’s use of unsupported software or failure to upgrade to or permit an upgrade to supported software;
(e) resulting from (i) Client suspension due to violations of the Acceptable Use Policy, billing issues, or such other reasons as expressly permitted under the Master Terms or another Addendum, or (ii) Client’s breach of applicable third‑party license terms (such as Microsoft’s terms for Azure);
(f) DNS issues outside of the direct control of Otava;
(g) of the Virtual Private Network (“VPN”) or access thereto, which results from any situation or circumstance other than a failure of equipment managed by Otava; or
(h) any other circumstance set forth in the Additional Downtime Exclusions section (e.g., Section 4.2) for the relevant Otava service, provided that any such additional exclusion event is limited to the specific service identified in such section.
3.5. Service Credits.
3.5.1. Availability of Service Credits. If Client experiences a Downtime event that results in Otava missing a relevant Commitment for the applicable Service component, Client may be eligible to receive Service Credits for such missed Commitment. Service Credits are applied towards future payments for the relevant Service component. To be eligible to receive Service Credits, (a) the relevant Otava service must be identified as a Service line item on the relevant Sales Order; (b) Client must be in material compliance with the MSA; and (c) Otava must be able to confirm the Downtime event.
3.5.2. Procedure for Claiming Service Credits. To claim Service Credits, Client must open an Otava trouble ticket through the Support Portal and request the Service Credits. All Service Credits tickets must be submitted to Otava within 30 calendar days of Client experiencing the Downtime event. All Downtime is measured from the time the Downtime incident occurred (as recorded by Otava’s system) to the time Otava is able to resolve the reported incident, to the extent Otava can confirm that the issue exists.
3.5.3. Service Credit Limitations. Service Credits apply only to the monthly fees paid for the Service component for which a Commitment has not been met in accordance with this SLA. In no event will the Service Credits awarded (a) during any billing month for the relevant Service component exceed the monthly recurring fee billed to Client by Otava for that billing month for that Service component; (b) for any single Downtime event exceed the monthly recurring fee billed to Client by Otava for the relevant billing month; or (c) during any billing month, exceed 100% of the monthly recurring fees billed to Client by Otava for the relevant billing month. Client may not sell or transfer Service Credits and may not unilaterally offset the monthly Services fees for any performance or availability issues. Service Credits and Client’s right to terminate the affected Service component in the event of a Chronic Service Interruption are Client’s sole and exclusive remedies for any performance or availability issues for any Services under the MSA. Further, Service Credits are not available for (i) Services that are not affected by a Downtime event; or (ii) third party services that are being purchased through Otava (e.g., third-party public cloud).
3.6. Modifications. Otava reserves the right to modify this SLA during the Services Term upon providing 30 days’ advance written notice to the Client’s Authorized Contact or by posting a notice of the update in the Support Portal or on the Statuspage. If within 60 days of receipt of such SLA change notice (“Notice Period”), Client determines, in Client’s reasonable discretion, that the proposed change has a material effect on Client’s business or operations, Client will provide written notice to Otava within the Notice Period, sufficiently detailing such material impact. Upon Otava’s receipt of such notice, the Parties will negotiate, in good faith, an appropriate SLA accommodation. To be effective, any agreed upon SLA accommodation shall be in writing and signed by an authorized representative of each Party. If the Parties cannot agree upon a mutually acceptable SLA accommodation, within 90 days of Otava’s receipt of Client’s written SLA notice, then Client may, upon 90 days advanced written notice to Otava, cancel the Service component(s) for which Otava is amending the SLA.
The terms of this Section 4 apply only if Client’s Sales Order includes Colocation Space Services as a line item.
4.1. Commitment. Otava makes the following Commitment with respect to the power availability for the Colocation Space Services: the power specified in the relevant Sales Order will be available (a) 99.9% of the time during each calendar month of the relevant Services Term for Standard Non-HA Configuration; and (b) 100% of the time during each calendar month of the relevant Services Term for a High Availability Configuration (collectively, the “Power Availability Commitment”). Power downtime occurs when power is unavailable to Client’s Equipment during a given calendar month (the “Power Downtime”) and such downtime is measured in accordance with Section 3.5.2 (Procedure for Claiming Service Credits).
4.2. Additional Downtime Exclusions. In addition to the other Downtime Exclusions set forth in this SLA, the following events will also be considered as “Downtime Exclusions” for purposes of calculating Service Credits for missing any Power Availability Commitment: interruption or unavailability due to (a) power loss caused by Client exceeding the power specification set forth in the Sales Order; (b) power loss caused by a Client overloaded circuit or a tripped breaker resulting from Client’s overloaded circuit; (c) power loss caused by Client installation or use of unauthorized power generating equipment (e.g., uninterruptable power supply) connected to power circuits; or (d) power loss caused by Client’s misconfiguration of redundant power supply.
4.3. Service Credits. If the Power Availability Commitment falls below the applicable level specified in Section 4.1 (Commitment) during a calendar month and Client experiences Power Downtime during such incident for any reason other than a Downtime Exclusion, then, subject to Client’s compliance with the terms of this SLA (e.g., submitting a ticket in the Support Portal), Otava will apply the following Service Credits to Client’s account: (a) an initial Service Credit of an amount equal to 5% of the monthly recurring Service fees for the affected Service for the relevant calendar month; and (b) additional Service Credits of 5% (of the monthly recurring Service fees for the affected Service for such calendar month) each for each additional full hour of Power Downtime for such calendar month.
The terms of this Section 5 apply only if Client’s Sales Order includes Internet Bandwidth Services as a line item.
5.1. Commitment. Otava makes the following Commitment with respect to the Internet Bandwidth Services: Otava’s network will be available (a) 99.9% of the time during each calendar month of the relevant Services Term for a Standard (Non-HA) Configuration; and (b) 100% of the time during each calendar month of the relevant Services Term for a High Availability Configuration (collectively, the “Network Availability Commitment”). Network downtime occurs when Client is unable to transmit and receive data from the Internet caused by the failure of network equipment managed and either owned or leased by Otava (the “Network Downtime”), and such downtime is measured in accordance with Section 3.5.2 (Procedure for Claiming Service Credits).
5.2. Additional Downtime Exclusions. In addition to the other Downtime Exclusions set forth in this SLA, the following events will also be considered as “Downtime Exclusions” for purposes of calculating Service Credits for missing any Network Availability Commitment: (a) unavailability of the services or software running on the server; (b) unavailability of the server’s hardware; (c) unavailability caused by denial of service attacks, hacker activity, or other malicious activity targeted against Client; (d) unavailability of the Services due to Client misuse, Client equipment failure, application programming, non-performance, or other negligent or unlawful acts committed by Client or its agents or vendors; (e) network unavailability outside of Otava’s server network; (f) unavailability caused by failure of Client’s access circuits to the Data Center, unless such failure is caused solely by Otava; or (g) unavailability of the Services due to a change made by Otava at the express request or instruction of Client.
5.3. Service Credits. If the Network Availability Commitment falls below the applicable level specified in Section 5.1 (Commitment) during a calendar month and Client experiences Network Downtime during such incident for any reason other than a Downtime Exclusion, then, subject to Client’s compliance with the terms of this SLA (e.g., submitting a ticket in the Support Portal), Otava will apply the following Service Credits to Client’s account: (a) an initial Service Credit of an amount equal to 5% of the monthly recurring Service fees for the affected Service for the relevant calendar month; and (b) additional Service Credits of 5% (of the monthly recurring Service fees for the affected Service for such calendar month) each for each additional full hour of Network Downtime for such calendar month.
The terms of this Section 6 apply only if Client’s Sales Order includes Dedicated Server or Dedicated SAN Services or Otava Cloud Services as a line item.
6.1. Commitment. Otava makes the following Commitment with respect to the Dedicated Server or Dedicated SAN Services and the Otava Cloud Services, as applicable (the “Server Availability Commitment”):
6.1.1. Dedicated Server or Dedicated SAN Services. Promptly within a hardware failure, Otava will, as it may determine in its sole discretion, repair or replace any failed hardware component and restore the operating system to its original operating system configuration or replace the entire Dedicated Server or Dedicated SAN.
6.1.2. Otava Cloud Services. The Otava Cloud Services will be available 99.99% of the time during each calendar month of the relevant Services Term.
6.2. Server Downtime. Server downtime occurs when a Client’s server is shut down due to a component failure (“Server Downtime”), and such downtime is measured in accordance with Section 3.5.2 (Procedure for Claiming Service Credits), subject to Section 6.5 (Additional Terms).
6.3 Additional Downtime Exclusions. For the avoidance of doubt, the Downtime Exclusions set forth in Sections 3.4 (Downtime Exclusions) also apply to this Section 6.
6.4. Service Credits. If the Server Availability Commitment falls below the level specified in Section 6.1 (Commitment) during a calendar month for any reason other than a Downtime Exclusion, then, subject to Client’s compliance with the terms of this SLA (e.g., submitting a ticket in the Support Portal) and subject to Section 6.5 (Additional Terms), Otava will apply the following Service Credits to Client’s account: (a) an initial Service Credit for an amount equal to 5% of the monthly recurring Service fees for the affected Service for the relevant calendar month; and (b) additional Service Credits of 5% (of the monthly recurring Service fees for the affected Service for such calendar month) each for each additional full hour of Server Downtime for such calendar month.
6.5. Additional Terms. If Client’s Sales Order includes Dedicated Server or Dedicated SAN Services as a line item, then Client understands that (a) the hardware replacement contemplated in Section 6.1.1 (Dedicated Server or Dedicated SAN Services) only applies to the replacement of the failed hardware; (b) Otava may re-load the operating system and applications and apply any applicable data restorations and backups if necessary, provided that the time to perform such activities does not count toward the Server Downtime calculation; and (c) once the hardware is installed, the hardware failure (i.e., the Server Downtime) incident timer is stopped, and Client is not entitled to any further Service Credits.
The terms of this Section 7 apply only if Client’s Sales Order includes Disaster Recovery as a Service. “DRaaS” as a line item.
7.1. Commitment and Service Credits. Otava makes the Commitments set forth in Sections 7.1.1 (Replication Network Downtime), 7.1.2 (Recovery Point Objective), and 7.1.3 (Recovery Time Objective) with respect to the DRaaS Services (collectively, the “DRaaS Commitment”) and will apply those Service Credits to Client’s account as further set forth in such section for the relevant DRaaS Commitment Service incident (i.e., delayed replication, missed RPO, or missed RTO) (each incident, a “DRaaS Downtime”). DRaaS Downtime is measured in accordance with Section 3.5.2 (Procedure for Claiming Service Credits). The relevant Service Credit will be calculated by multiplying the identified percentage rate for the relevant DRaaS Commitment Service incident by the monthly recurring Service fees for the relevant DRaaS Service. For example, in the event Otava experiences an event that impacts DRaaS replication for 6 consecutive hours, then the relevant percentage for calculating Service Credits would be 30%. Otava will only apply Service Credits for DRaaS Services, in the event (a) the DRaaS Commitment falls below the applicable level specified in the tables set forth in Sections 7.1.1, 7.1.2, or 7.1.3; and (b) Client experiences a DRaaS Downtime event for any reason other than a Downtime Exclusion. For the avoidance of doubt, the maximum total Service Credit for all failures of Otava to meet the DRaaS Commitment is limited to the total monthly recurring fees charge to Client for the DRaaS Services for the month in which the failure occurs.
7.1. Replication Network Downtime. In the event Otava experiences an interruption to the Otava network that renders replication services of the DRaaS Services unavailable for 60 or more consecutive minutes for each single event, the Service Credits percentage rate will be as set forth in the table immediately following below:
| Duration (Consecutive Hours) | 1-4 | 5-23 | 24+ |
| Total Cumulative Service Credit | 10% | 30% | 100% |
7.1.2. Recovery Point Objective. The recovery point objective (“RPO”) for DRaaS Services (i.e., 1 Hour RPO or 4 Hour RPO) will be specified in the Sales Order. In the event Otava experiences an interruption that causes Otava to miss the relevant RPO for any reason other than a Downtime Exclusion, the Service Credits percentage rate will be as set forth in the table immediately following below, with the amount of such Service Credits to be calculated based on the number of consecutive hours by which the RPO is delayed:
| RPO Service | 1 Hour RPO | 4 Hour RPO | ||||
| RPO Delayed (Consecutive Hours) | 1-4 | 5-24 | 24+ | 4-7 | 8-24 | 24+ |
| Total Cumulative Service Credit | 10% | 50% | 100% | 10% | 50% | 100% |
7.1.3. Recovery Time Objective. The recovery time objective (“RTO”) for DRaaS Services (i.e., 1 Hour RTO or 4 Hour RTO) will be specified in the Sales Order. If the DRaaS Services are for a virtual machine and any built-in service functions for failover testing, planned migration, or live failover and recovery result in any virtual machine replicas failing to power on within the purchased RTO, then the Service Credits percentage rate will be as set forth in the table immediately following below, with the amount of such Service Credits to be calculated based on the number of consecutive hours by which the RTO is delayed.
| RTO Service | 1 Hour RTO | 4 Hour RTO | ||||
| RTO Delayed (Consecutive Hours) | 1-4 | 5-24 | 24+ | 4-7 | 8-24 | 24+ |
| Total Cumulative Service Credit | 30% | 50% | 100% | 10% | 50% | 100% |
7.2. Additional Downtime Exclusions. In addition to the other Downtime Exclusions set forth in this SLA (including, without limitation, those set forth in Sections 3.4 (Downtime Exclusions), 4.2 (Additional Downtime Exclusions), 5.2 (Additional Downtime Exclusions), and 6.3 (Additional Downtime Exclusions)), the following events will also be considered as “Downtime Exclusions” for purposes of calculating Service Credits for missing any DRaaS Commitment:
(a) interruption or unavailability caused by Client’s bandwidth provider experiencing throughput or latency issues;
(b) interruption or unavailability caused by Client’s bandwidth levels not supporting the change rate of replicated virtual machines;
(c) interruption or unavailability caused by (i) Client making changes to its network or core routing infrastructure (e.g., IP changes, adding new equipment), which cause a break in the replication chain or are otherwise not compatible with the replication technology used; or (ii) Client making other environment changes including, without limitation, power off, HA event, or improper vMotions;
(d) interruption or unavailability caused by Client upgrading a host to outside of the compatibility of the replication technology used;
(e) interruption or unavailability caused by Client adding or rebuilding a host and not installing the agent or submitting a ticket via the Support Portal, at least 24 hours in advance of the required installation, for Otava to install the agent;
(f) interruption or unavailability caused by (i) any external access to applications including, without limitation, those responsible for DNS failover or global-load balancing; or (ii) failure to use compatible private IP schemes;
(g) interruption or unavailability caused by RPO and RTO replication of third-party software or services not purchased through and delivered by Otava;
(h) interruption or unavailability caused by (i) Client’s failure to meet a Client DRaaS Obligation, including, without limitation, purchasing additional DRaaS resources to accommodate changes in Client’s infrastructure; or (ii) the malware and virus exception contemplated in Section 7.3.2; or
(i) interruption or unavailability caused by in-guest shares in a virtual machine (iSCSI, CIFS, and NFS).
7.2. Additional Terms.
7.3.1. Client Obligations. In connection with the DRaaS Services, Client will (a) promptly, within purchasing the DRaaS Services, coordinate with Otava to schedule a meeting to develop a DRaaS plan, reasonably cooperate with Otava to develop such plan, and review and update the DRaaS plan on an as needed basis, but no less than once every 6 months during the DRaaS Services Term; (b) if DRaaS Services include virtual machines, then ensure new virtual machines are placed into appropriate protection groups or request inclusion by submitting a service ticket to Otava via the Support Portal; (c) promptly notify Otava of any changes in Client’s on-premises infrastructure that may impact replication or otherwise impact Otava’s ability to meet the relevant DRaaS Commitment and, as needed, purchase additional DRaaS related resources from Otava to accommodate Client’s infrastructure changes; (d) promptly notify Otava of any virtualization or network maintenance that may impact replication or otherwise impact Otava’s ability to meet the relevant DRaaS Commitment; (e) conduct a disaster recovery test no less than once every 6 months during the DRaaS Services Term and coordinate with Otava to conduct such failover tests as reasonably necessary or otherwise requested by Otava; and (f) maintain and timely update Client’s on-premises infrastructure to permit Otava to meet the relevant DRaaS Commitment(each of (a) – (f), a “Client DRaaS Obligation”).
7.3.2. Malware and Virus Exception. Client understands that in the event a failover is intended to remedy a security related issue (e.g., malware, virus, ransomware, or other vulnerability), the failover will not be effective unless the previous checkpoint is clean and does not contain the vulnerability.
The terms of this Section 8 apply only if Client’s Sales Order includes Otava Workload Protection Services as a line item. DPaaS Powered by Actifio, OTAVA Cloud Backup, OTAVA Cloud Connect and Backup for Microsoft 365 are collectively “Workload Protection.”
8.1. Commitment and Service Credits. Otava makes the Commitment set forth in the table in this Section 8.1 with respect to the Workload Protection Services (collectively, the “Workload Protection Commitment”). Workload Protection downtime occurs when any of the following events directly impacts a Workload Protection job: (a) any Network Downtime that renders backup or restore services unavailable for more than 12 consecutive hours; or (b) any storage downtime that renders backup or restore services unavailable for more than 12 consecutive hours (each incident, a “Workload Protection Downtime”). Workload Protection Downtime is measured in accordance with Section 3.5.2 (Procedure for Claiming Service Credits). The relevant Service Credit will be calculated by multiplying the identified percentage rate for the relevant total cumulative Service Credit set forth in the table below by the monthly recurring Service fees for the affected Service. Otava will only apply Service Credits for Workload Protection Services in the event (i) the Workload Protection Commitment falls below the applicable level specified in the table set forth in this Section 8.1; and (ii) Client experiences a Workload Protection Downtime event for any reason other than a Downtime Exclusion. For the avoidance of doubt, the maximum total Service Credit for all failures of Otava to meet the Workload Protection Commitment is limited to the total monthly recurring fees charge to Client for Workload Protection Services for the month in which the failure occurs.
| Duration (Consecutive Hours) | 12-24 | 24+ |
| Total Cumulative Service Credit | 10% | 50% |
8.2. Additional Downtime Exclusions. In addition to the other Downtime Exclusions set forth in this SLA (including, without limitation, those set forth in Sections 3.4 (Downtime Exclusions), 4.2 (Additional Downtime Exclusions), 5.2 (Additional Downtime Exclusions), and 6.3 (Additional Downtime Exclusions)), the following events will also be considered as “Downtime Exclusions” for purposes of calculating Service Credits for missing any Workload Protection Commitment:
(a) interruption or unavailability caused by Client’s bandwidth provider experiencing throughput or latency issues or Client’s bandwidth levels not supporting the change rate of replicated virtual machines;
(b) interruption or unavailability caused by a backup test conducted by Client, its agent, or Otava at the request of Client;
(c) interruption or unavailability caused by (i) Client making changes to its network or core routing infrastructure (e.g., IP changes, adding new equipment), which cause a break in the backup or are otherwise not compatible with the backup technology used, or (ii) Client making other environment changes, including, without limitation, power off, HA event, firewall rules, IPS blocking/exclusions, or web application firewall;
(d) interruption or unavailability caused by Client upgrading host to outside of the compatibility of the backup technology used;
(e) interruption or unavailability caused by Client adding or rebuilding a server and not installing the agent or submitting a ticket via the Support Portal, at least 24 hours in advance of the required installation, for Otava to install the agent; or
(f) interruption or unavailability caused by (i) Client’s failure to meet a Client Workload Protection Obligation; or (ii) the malware and virus exception contemplated in Section 8.3.2.
8.3. Additional Terms.
8.3.1. Client Obligations. In connection with the Workload Protection Services, Client will (a) install an Otava provided software agent for the duration of the Workload Protection Services Term; (b) select a backup window when backup jobs will be started for each server protected with the Workload Protection Services; (c) ensure that there is no application or other user controlled activity (e.g., open file) that inhibits the backup job; (d) promptly notify Otava of any virtualization or network maintenance that may impact replication or otherwise impact Otava’s ability to meet its Workload Protection Commitment; and (e) conduct a recovery test of the backups no less than once every 6 months during the Workload Protection Services Term and coordinate with Otava to conduct such additional tests as reasonably necessary or otherwise requested by Otava (each of (a) – (e), a “Client Workload Protection Obligation”).
8.3.2. Malware and Virus Exception. Client understands that in the event a restore is intended to remedy a security related issue (e.g., malware, virus, ransomware, or other vulnerability), the failover will not be effective unless the previous checkpoint is clean and does not contain the vulnerability.
