1、opengemini备份机制

opengemini是全量备份，这里的全量指的是包括其中的一些配置文件，这里直接列一个例子

这是没有备份的opengemini的原始数据

这里通过官方给的方法进行全量备份

curl -i -XPOST 'http://127.0.0.1:8086/debug/ctrl?mod=backup&backupPath=/beifen&isInc=false'

这个命令尽量在容器内执行，目录也是容器内的目录，以下是备份后的目录

也就是说其实它全量备份就是直接全部复制data、meta、log一份给你，而这里就会导致一个问题，里面其实是包括一些配置文件的，比如meta中的json配置和raft.db，这里也直接展示一下

这两个目录下都有一个meta.json文件，另一个raft.db还没法直接改

这里带了一些ip配置，这就导致会影响后面的一些东西，这里后面展示

2、关于容器部署导致的一些底层问题

首先展示第一个坑这里涉及到linux以及docker的底层逻辑

services:
  opengemini:
    image: opengeminidb/opengemini-server:latest
    container_name: opengemini
    ports:
      - "8086:8086"   # HTTP API
    volumes:
       - /home/opengemini/data:/tmp/openGemini/data
       - /home/opengemini/logs:/tmp/openGemini/logs
       - /home/opengemini/beifen:/tmp/openGemini/beifen
       - /home/opengemini/meta:/tmp/openGemini/meta
    restart: unless-stopped

这里单独挂载了好几个地址，从容器内看这就是几个目录没什么区别，但是从底层逻辑看这几个就有点不太一样了，因为是通过映射关系的访问的所以从底层逻辑看他们分别是属于不同的系统，这里展示一下，直接恢复备份

官方给的命令是这个

./ts-recover \
  -config=/home/opengemini/config/opengemini.conf \
  -recoverMode=2 \
  -fullBackupDataPath=文件目录

再说一下这里还有一个坑，默认的opengemini容器部署是不带ts-recover文件的还得自己找一个才行

可以找官方的文件下载一个压缩包版本然后复制过来

Releases · openGemini/openGemini

下载完解压然后复制到对应目录映射进去

执行命令开始恢复备份，然后就会出现以下报错，这个就是映射的问题，以及opengemini不像一些数据库一样是通过是数据备份的，具体怎么解决呢

其实也很简单，改一下映射，这是最简单的方法，必须保证备份文件，openmini的data logs meta保持在同个系统文件下

services:
  opengemini:
    image: opengeminidb/opengemini-server:latest
    container_name: opengemini
    ports:
      - "8086:8086"   # HTTP API
    volumes:
       #保持备份、data、logs、meta在同一目录下
       #并把整个目录都映射出来就能保证这几个文件都是同一操作系统下
       - /home/opengemini:/tmp/openGemini/
    restart: unless-stopped

这里文件目录跟前面基本一样，差别就是docker的映射不一样了

3、备份机制导致的坑

这里先讲一下另一个坑，就是一开始说的那个opengemini备份的坑，每个环境的opengemini配置不一样，以前opengemini的config配置文件可能是这样写的，因为之前在docker中指定了ip地址

这里导致一开始说的meta中的文件会根据之前的配置文件生成这个对应ip的配置文件

这里会导致备份虽然显示恢复了，但是实际opengemini启不来，logs中有个raft.log文件会提示以下报错

2026-06-29T01:22:08.384Z [INFO]  raft: starting restore from snapshot: id=22-109063578-1780284861768 last-index=109063578 last-term=22 size-in-bytes=2210289
2026-06-29T01:22:08.415Z [INFO]  raft: snapshot restore progress: id=22-109063578-1780284861768 last-index=109063578 last-term=22 size-in-bytes=2210289 read-bytes=2210289 percent-complete="100.00%"
2026-06-29T01:22:08.415Z [INFO]  raft: restored from snapshot: id=22-109063578-1780284861768 last-index=109063578 last-term=22 size-in-bytes=2210289
2026-06-29T01:22:08.415Z [INFO]  raft: initial configuration: index=1 servers="[{Suffrage:Voter ID:172.30.0.30:8088 Address:172.30.0.30:8088}]"
2026-06-29T01:22:08.415Z [INFO]  raft: entering follower state: follower="Node at 127.0.0.1:8088 [Follower]" leader-address= leader-id=
2026-06-29T01:22:10.323Z [WARN]  raft: not part of stable configuration, aborting election

配置文件中ip和meta中配置文件的对不上，opengemini启动就一直卡在启动中无法进入下一步

[root@localhost config]# docker logs opengemini --since 5m
WARNING:(ast) sonic only supports go1.17~1.23, but your environment is not suitable
2026-06-29 01:18:15.652060583 +0000 UTC m=+0.049174536 init logger, conf: {app:single Format:auto Level:info MaxSize:67108864 MaxNum:16 MaxAge:7 CompressEnabled:true Path:/root/.openGemini/logs}
2026-06-29 01:18:15.660915693 +0000 UTC m=+0.058029663 init logger, conf: {app:single Format:auto Level:info MaxSize:67108864 MaxNum:16 MaxAge:7 CompressEnabled:true Path:/tmp/openGemini/logs/}

 _________   ______    ______   ________  _______  ____   ____  ________  _______
|  _   _  |.' ____ \ .' ____ \ |_   __  ||_   __ \|_  _| |_  _||_   __  ||_   __ \
|_/ | | \_|| (___ \_|| (___ \_|  | |_ \_|  | |__) | \ \   / /    | |_ \_|  | |__) |
    | |     _.____''.  _.____''.   |  _| _   |  _/   \ \ / /     |  _| _   |  __ /
   _| |_   | \____) || \____) | _| |__/ | _| |  \ \_  \ ' /     _| |__/ | _| |  \ \_
  |_____|   \______.' \______.'|________||____| |___|  \_/     |________||____| |___|

2026-06-29 01:18:15.66139928 +0000 UTC m=+0.058513235 TSMeta starting

4、由备份机制导致的另一个大坑，及部分解决方法和解决方向

这里有个最大的坑，而且官方完全没有这方面的资料想解决也解决不了，反正我是找了半天没有找到的，就是前面说的他全量备份是完完全全一点不改的直接备份，这就导致你的ip只要变了你的数据就废了，你导入的时候只能查询到表结构和库，实际数据根本无法访问，只有保证ip一致才可以，这里的ip一致指的是备份前配置文件中指向的节点ip，这里讲一下简单讲一下他的工作机制，他类似于主从的结构，数据指向是节点ip，备份时其实是这个节点整个备份，恢复的时候节点信息必须和他保证一致才能读取到他的数据，所以即使恢复了也读取不到数据就是这个原因导致的，如果是容器部署的就还好解决，或者以前就直接用的127.0.0.1就不用考虑很多直接恢复就行，如果以前用的ip和现在的不一样就凉凉了

以前就用docker的话就看一下之前设置的ip，然后原封不动把配置文件以及ip配置都迁移到新的服务器上跑，所以这里把之前的配置文件也备份过来，docker也设置一下ip

services:
  opengemini:
    image: opengeminidb/opengemini-server:latest
    container_name: opengemini
    ports:
      - "8086:8086"   # HTTP API
    volumes:
       - /home/opengemini:/tmp/openGemini/
       - /home/opengemini/opengemini.conf:/home/opengemini/config/opengemini.conf
    restart: unless-stopped
    networks:
      opengemini:
        ipv4_address: 172.30.0.30
        
networks:
  opengemini:
    driver: bridge
    ipam:
      config:
        - subnet: 172.30.0.0/16

都弄完了就可以执行恢复了

恢复后验证一下有没有数据

如果只有表结构和库的话类似于这样什么数据都没有的，就看看我上面标红的字！！！

不过我估计是可以通过其他方法去修改备份文件指向的ip的，猜测大概率是被存储在raft.db中，不过这个我就不清楚了，他不是sqlit不能直接访问，各类工具也打不开，需要方向的可以了解一下

还有一个方向是他是基于influxdb去二次开发的，可以从这里下手，不过influxdb是用命令去修改的，命令是

influxd-ctl update-data <旧地址> <新地址>

不过嘛······我已经试过了，不行，只能给个参考方向要是真有解决方法直接改ip的，麻烦跟我说一下