remove backuping eventbus

content/en/docs/features/monitoring-and-diagnostics/disaster-recovery.md

@@ -54,7 +54,7 @@ plgd hub doesn't guarantee delivery of all events to the EventBus. It guarantees
 
 ## Data Management and Failover Strategies
 
-The plgd hub is a stateful application, indicating that the data is stored in the EventStore, which is a MongoDB. The data could also be stored in JetStream, a component of NATS. In this section, we will describe how to back up and restore data in the scenario where two clusters are running in different locations (e.g., East US / West US). The first cluster is used for normal operations, while the secondary cluster serves as a backup for disaster recovery.
+The plgd hub is a stateful application, indicating that the data is stored in the EventStore, serving as the source of truth, which is a MongoDB. In this section, we will describe how to back up and restore data in a scenario where two clusters are running in different locations (e.g., East US / West US). The first cluster is utilized for normal operations, while the secondary cluster serves as a backup for disaster recovery.
 
 ### Backup Databases
 
@@ -64,21 +64,23 @@ To back up the database, two approaches can be used:
 
   ![passive-backup](/docs/features/monitoring-and-diagnostics/static/disaster-recovery-passive-backup.drawio.svg)
 
-  The database is regularly backed up to a different location and can be used in case of failure. Although this approach is simple and requires fewer resources, the data may be outdated. For MongoDB, utilize the `mongodump` tool to create a binary export of the database contents, store it securely, and use it in case of failure. Regular backups are essential to keep the data up-to-date.
+  The database is regularly backed up to a different location and can be used in case of failure. Although this approach is simple and requires fewer resources, the data may become outdated, and the restoration process may take some time. For MongoDB, utilize the `mongodump` tool to create a export of the database contents, store it securely, and use it in case of failure. Regular backups are essential to keep the data up-to-date. For more details on this approach, refer to the [MongoDB documentation](https://www.mongodb.com/docs/database-tools/mongodump/).
 
 * **Active Backup**
 
   ![active-backup](/docs/features/monitoring-and-diagnostics/static/disaster-recovery-active-backup.drawio.svg)
 
   The database actively synchronizes data between two clusters in realtime. This approach is more complex and resource-intensive but is more reliable for disaster recovery. For MongoDB, use `cluster-to-cluster-sync` feature to synchronize data between two MongoDB clusters. For more details on this approach, refer to the [MongoDB documentation](https://www.mongodb.com/docs/cluster-to-cluster-sync/current/connecting/onprem-to-onprem/).
 
-### Backup JetStream
+{{< warning >}}
+
+**Using a backup from EventBus (JetStream) is not recommended in a restored cluster**, as it is not the source of truth for the plgd hub. This could result in data inconsistency because creating backups is not synchronized for both EventStore and EventBus (JetStream). The EventBus can contain events that are not stored in the EventStore, and vice versa.
 
-To back up JetStream, use the `nats` tool to create a regular backup of the JetStream data. Regular backups are necessary to keep the data current. For more information on JetStream backup, refer to the [NATS Disaster Recovery documentation](https://docs.nats.io/running-a-nats-service/nats_admin/jetstream_admin/disaster_recovery).
+{{< /warning >}}
 
 ### OAuth2 Server
 
-Devices connected to the hub have access tokens used to authorize device access. The access tokens are generated by the OAuth2 server, and its database needs to be backed up regularly. In case of OAuth2 server failure, devices won't connect to the hub. To prevent this, regularly back up the OAuth2 server database as described in the [Backup Database](#backup-databases) section.
+Devices connected to the hub have access tokens used to authorize device access. The access tokens are generated by the OAuth2 server, and its database needs to be backed up regularly. In case of OAuth2 server failure, devices won't connect to the hub. To prevent this, regularly back up the OAuth2 server database as described in the [Backup Databases](#backup-databases) section.
 
 ### Certificates