[id='cross-site-automatic-offline_{context}']
= Automatic offline parameters for backup locations

Operations to replicate data across clusters are resource intensive, using excessive RAM and CPU.
To avoid wasting resources {brandname} can take backup locations offline when they stop accepting requests after a specific period of time.

{brandname} takes remote sites offline based on the number of failed sequential requests and the time interval since the first failure.
Requests are failed when the target cluster does not have any nodes in the cross-site view (JGroups bridge) or when a timeout expires before the target cluster acknowledges the request.

[discrete]
== Backup timeouts

Backup configurations include timeout values for operations to replicate data between clusters.
If operations do not complete before the timeout expires, {brandname} records them as failures.

In the following example, operations to replicate data to NYC are recorded as failures if they do not complete after 10 seconds:

.XML
[source,xml,options="nowrap",subs=attributes+,role="primary"]
----
include::xml/xsite_backup_timeout.xml[]
----

.JSON
[source,json,options="nowrap",subs=attributes+,role="secondary"]
----
include::json/xsite_backup_timeout.json[]
----

.YAML
[source,yaml,options="nowrap",subs=attributes+,role="secondary"]
----
include::yaml/xsite_backup_timeout.yaml[]
----

[discrete]
== Number of failures

You can specify the number of **consecutive** failures that can occur before
backup locations go offline.

In the following example, if a cluster attempts to replicate data to NYC and five consecutive operations fail, NYC automatically goes offline:

.XML
[source,xml,options="nowrap",subs=attributes+,role="primary"]
----
include::xml/xsite_backup_number_failures.xml[]
----

.JSON
[source,json,options="nowrap",subs=attributes+,role="secondary"]
----
include::json/xsite_backup_number_failures.json[]
----

.YAML
[source,yaml,options="nowrap",subs=attributes+,role="secondary"]
----
include::yaml/xsite_backup_number_failures.yaml[]
----

[discrete]
== Time to wait

You can also specify how long to wait before taking sites offline when backup operations fail.
If a backup request succeeds before the wait time runs out, {brandname} does not take the site offline.

One or two minutes is generally a suitable time to wait before automatically taking backup locations offline.
If the wait period is too short then backup locations go offline too soon.
You then need to bring clusters back online and perform state transfer operations to ensure data is in sync between the clusters.

A negative or zero value for the number of failures is equivalent to a value of `1`.
{brandname} uses only a minimum time to wait to take backup locations offline after a failure occurs, for example:

[source,xml,options="nowrap",subs=attributes+]
----
<take-offline after-failures="-1"
              min-wait="10000"/>
----

In the following example, if a cluster attempts to replicate data to NYC and there are more than five consecutive failures and 15 seconds elapse after the first failed operation, NYC automatically goes offline:

.XML
[source,xml,options="nowrap",subs=attributes+,role="primary"]
----
include::xml/xsite_backup_time_wait.xml[]
----

.JSON
[source,json,options="nowrap",subs=attributes+,role="secondary"]
----
include::json/xsite_backup_time_wait.json[]
----

.YAML
[source,yaml,options="nowrap",subs=attributes+,role="secondary"]
----
include::yaml/xsite_backup_time_wait.yaml[]
----
