Merge pull request #255 from skiffer-git/n6

add docs

docs/guides/gettingStarted/faultRecovery.mdx

@@ -1,89 +1,61 @@
 ---
-title: '生产环境注意事项'
-sidebar_position: 21
+title: '单机生产环境异常处理及数据恢复'
+sidebar_position: 12
 ---
 
-本文主要讲解在单机（源码和`docker`部署）生产环境下，从数据备份到故障恢复需要关注的事项。
 
-## 一、Mongo数据备份、恢复
 
-服务端的核心数据保存在`mongo`中，只需要对mongo数据进行备份就足以恢复大部分数据，步骤如下：
 
-1. 修改`.env`文件中的`MONGO_BACKUP_DIR`为需要保存备份文件的目录（默认备份目录为`components/backup/mongo/`），尽量选择和`components`目录不同磁盘的目录。
-2. 运行`docker compose up -d`启动容器。
-3. 运行`docker exec -it mongo mongodump --uri="mongodb://openIM:openIM123@localhost:27017/openim_v3" --out="/data/backup/$(date +\%Y-\%m-\%d_\%H-\%M-\%S)";`，即可完成一次当前数据的备份。
+在生产环境中，通常会采用集群部署来保证组件和服务的高可用性。然而，在资源有限的情况下，一些开发者可能会选择在生产环境中进行单机部署（使用源码部署或`docker`容器）。本文将介绍在单机部署环境下如何进行数据备份、异常恢复，以及潜在的风险。
 
-### 定时备份
+## 一、mongo定时数据备份
+OpenIM核心数据存储在MongoDB中，因此备份MongoDB数据就能恢复大部分数据。在容器启动之前，设置mongo数据备份目录和定时任务。
+### 数据备份
 
-如果想要实现定时备份的功能，建议使用`linux`的`Crontab`定时任务实现。例如，想要每天凌晨2时进行一次数据备份，可以参考下面的步骤：
+OpenIM服务的核心数据存储在MongoDB中，因此备份MongoDB数据就能恢复大部分数据。以下是备份的步骤：
 
-1. 创建定时脚本，例如在`/data/open-im-server/`目录下创建一个名为`backup_mongo.sh`的脚本：
-   ```sh
-   vim /data/open-im-server/backup_mongo.sh
-   ```
+1. **修改备份目录**
 
-2. 在脚本中添加如下内容：
+   - `.env`文件中修改`MONGO_BACKUP_DIR`的路径，默认值为`components/backup/mongo/`。建议将备份目录设置为与`components`目录不同的磁盘路径，以避免同一磁盘故障导致原始数据和备份数据同时丢失。
+3. **定时备份配置**
+   - 配置Linux系统的定时备份任务，执行以下命令编辑crontab：
    ```sh
-   #!/bin/bash
-   docker exec mongo mongodump --uri="mongodb://openIM:openIM123@localhost:27017/openim_v3" --out="/data/backup/$(date +\%Y-\%m-\%d_\%H-\%M-\%S)"   # 备份数据
-   docker exec mongo sh -c 'find /data/backup/ -mindepth 1 -maxdepth 1 -type d -exec stat --format="%Y %n" {} \; | sort -n | head -n -2 | cut -d" " -f2- | xargs rm -rf'   # 只保留最新两个备份
+   crontab -e
    ```
-
-3. 添加执行权限：
-   ```bash
-   chmod +x /data/open-im-server/backup_mongo.sh
-   ```
-
-4. 创建定时任务：
-
+   - 添加如下定时任务，表示每天凌晨2点执行备份，并保存最新的2个备份文件。如果需要其他定时规则，请调整`cron`表达式：
    ```sh
-   crontab -e  # 打开cron配置
-   # 在crontab文件中添加下面一行表示每天2时执行命令,并且只保留最新的2个备份。
-   0 2 * * * /data/open-im-server/backup_mongo.sh
+   0 2 * * * docker exec mongo mongodump --uri="mongodb://openIM:openIM123@localhost:27017/openim_v3" --out="/data/backup/$(expr $(date +\%s) / 86400 \% 2)"
    ```
+   - 使用`crontab -l`命令可以查看当前定时任务是否设置成功。
 
-   然后在编辑器中保存并退出 `crontab` 配置（通常按 `CTRL+X`，然后按 `Y` 保存）。
-
-5. 运行`crontab -l`命令可查看定时任务是否添加成功。
-
-如果需要其他定时规则，修改`cron`表达式即可。
-
-以上命令会保留的最新的两个备份，可以防止在备份的过程中出现异常导致备份数据损坏而损失数据的情况。
 
-### 恢复备份数据
 
-如果需要恢复备份的数据，需要进行以下步骤：
+## 二、组件异常停止处理
 
-1. 停止`open-im-server`服务，运行`docker compose down`删除容器。
+1. 如果 `mongo`、`redis`、`kafka`、`etcd` 等组件异常停止，首先尝试重启所有组件和 OpenIM 服务。
 
-2. 删除`components/redis/`和`components/mongodb/data/`文件夹。
+2. 如果由于数据问题（如磁盘故障、磁盘满等）导致服务启动失败，则先停止所有组件和 OpenIM 服务。
+   - 如果 `redis` 启动失败，删除 `components/redis/` 目录。
+   - 如果 `kafka` 启动失败，删除 `components/kafka/` 目录。
+   - 如果 `mongo` 启动失败
+        - 1. 删除 `components/redis/` `components/mongodb/` `components/kafka/`目录
+        - 2. 恢复备份数据 docker exec -it mongo mongorestore --uri="mongodb://openIM:openIM123@localhost:27017/openim_v3" /data/backup/your_backup_name/openim_v3 
+		- **your_backup_name 为0 或者1， 选择时间较新的那个目录**
+   - 如果 `etcd` 启动失败，删除 `components/etcd/` 目录。
 
-3. 到备份的目录中找到需要恢复的数据的名称，将下面命令中的`your_backup_name`替换为备份数据目录名称并运行：
+3. 在进行上述操作后，重启所有组件和 OpenIM 服务。
 
-   ```sh
-   docker exec -it mongo mongorestore --uri="mongodb://openIM:openIM123@localhost:27017/openim_v3" /data/backup/your_backup_name/openim_v3
-   ```
-
-4. 运行`docker compose up -d`启动容器，启动`open-im-server`服务。
-
-## 二、组件异常停止
-
-1. 如果`mongo`、`redis`、`kafka`异常停止，先尝试重启服务。
-
-2. 如果由于数据原因启动失败：
+## 三、潜在风险
 
-   - `redis`启动失败：删除`components/redis/`目录。
-   - `kafka`启动失败：删除`components/kafka/`目录。
-   - `mongo`启动失败：尝试[恢复备份数据文件](#恢复备份数据)。
+1. **单机部署风险**  
+   如果机器故障导致原始数据磁盘和备份磁盘都无法访问，则无法直接恢复数据。此时，可能需要通过运营商的快照服务来恢复数据。
 
-   对数据进行相应操作后启动服务。
+2. **备份目录建议**  
+   为防止由于单一磁盘故障导致的数据丢失，建议将 `mongo` 的备份目录 `MONGO_BACKUP_DIR` 设置为与 `components` 目录分开的磁盘。
 
-3. 如果`etcd`异常停止，需要首先关闭`open-im-server`和`chat`服务，然后重启`etcd`组件后，再启动`open-im-server`和`chat`服务。
-   如果`etcd`启动失败，删除`components/etcd/`目录，再尝试启动。
+3. **数据恢复风险**  
+   恢复 MongoDB 数据时，备份时间之后的数据将会丢失。因此，备份频率过快可能会对 MongoDB 的性能造成较大的影响。
 
-## 三、潜在风险
+4. **Redis 数据删除的影响**  
+   如果删除 Redis 中的数据，可能会导致 **消息未读数不正确**。
 
-1. 单机情况下，如果由于机器故障导致服务崩溃，则无法恢复数据。
-2. 为了防止由于磁盘硬件故障导致的数据丢失，建议将`mongo`的备份目录设置为与`components`目录不同磁盘的目录下。
-3. 当恢复备份数据时，会丢失备份时间之后的所有数据。备份数据的间隔如果过短，**会对性能造成较大损耗**。
-4. 恢复备份数据为了保证数据一致性，需要删除`redis`中的数据，会导致**消息的未读数异常**。