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

To avoid wasting resources {brandname} can take backup locations offline when they stop accepting requests after a specific period of time.

{brandname} takes remote clusters offline based on the number of failed sequential requests and/or the time interval since the first failure.
Requests fail when a response is not received or a connection between cluster is down.

[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 backup cluster offline following a failure.
If a backup request succeeds before the wait time elapses, {brandname} does not take the backup location offline.
The elapsed time is checked only after a write operation.
Therefore, if the cluster has no load, the backup location will not transition to the offline state.

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

[NOTE]
====
If both `after-failures` and `min-wait` are configured, both conditions must be met.
====

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 initial failure, 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[]
----
