×

Jira 文件级恢复方式 + 虚拟机恢复方式

在

Jira 文件级恢复方式

一、部署新的Jira

1、镜像

版本号：

 jira:20220113.1

来自原正式环境镜像，可能有自定义。

2、启动

（1）创建文件夹

 mkdir -p /workspace/atlassian/jira/logs
 chown -R 2001:2001 /workspace/atlassian/jira
 chmod -R 755 /workspace/atlassian/jira

（2）启动docker

注意——镜像设计问题：

这个 Jira 镜像可能设计为从挂载的数据卷读取 setenv.sh，而不是使用内置的文件

所以在下列启动语句中加上setenv.sh文件及配置，或者启动后参照下列解决办法添加该文件。

否则因为下面两个配置读取不到报错：

 # JVM memory settings
 #
 : ${JVM_MINIMUM_MEMORY:=1024m}
 : ${JVM_MAXIMUM_MEMORY:=2048m}
 ​
 # JIRA HOME path
 #
 JIRA_HOME="/var/atlassian/application-data/jira"

启动命令：

来源正式环境docker inspect + AI恢复

 docker run -d \
   --name jira \
   --restart always \
   -p 80:8080 \
   -v /workspace/atlassian/jira:/var/atlassian/application-data/jira \
   -v /workspace/atlassian/jira/logs:/logs \
   -e JVM_MINIMUM_MEMORY=1024m \
   -e JVM_MAXIMUM_MEMORY=2048m \
   -e TZ=Asia/Shanghai \
   -e LANG=en_US.UTF-8 \
   -e LANGUAGE=en_US:en \
   -e LC_ALL=en_US.UTF-8 \
   -e JAVA_VERSION=jdk-11.0.13+8 \
   -e JAVA_HOME=/opt/java/openjdk \
   -e APP_NAME=jira \
   -e RUN_USER=jira \
   -e RUN_GROUP=jira \
   -e RUN_UID=2001 \
   -e RUN_GID=2001 \
   -e JIRA_HOME=/var/atlassian/application-data/jira \
   -e JIRA_INSTALL_DIR=/opt/atlassian/jira \
   --user root \
   --workdir /var/atlassian/application-data/jira \
   jira:20220113.1

问题发现：

镜像直接启动没有 setenv.sh 文件，也可能是挂载覆盖问题，总之缺失这个文件报错

 lrwxrwxrwx 1 root root      46 Jan  4  2022 setenv.sh -> /var/atlassian/application-data/jira/setenv.sh
 ​
 root@2d2dd49be850:/opt/atlassian/jira/bin# cat /var/atlassian/application-data/jira/setenv.sh
 ​
 cat: /var/atlassian/application-data/jira/setenv.sh: No such file or directory
 ​
 root@2d2dd49be850:/opt/atlassian/jira/bin# cd /var/atlassian/application-data/jira/
 root@2d2dd49be850:/var/atlassian/application-data/jira# ls
 atlassian-jira.log  dbconfig.xml  docker-app.pid  logs  server.xml

解决办法：

（内容参照正式环境的setenv.sh文件，直接复制-粘贴-重启）

在宿主机上创建 setenv.sh 文件——设置文件权限——重启

 # 创建 setenv.sh 文件
 cat > /workspace/atlassian/jira/setenv.sh << 'EOF'
 #!/bin/bash
 #
 # If the limit of files that Jira can open is too low, it will be set to this value.
 #
 MIN_NOFILES_LIMIT=16384
 ​
 #
 # JIRA HOME path
 #
 JIRA_HOME="/var/atlassian/application-data/jira"
 ​
 #
 # JVM arguments
 #
 : ${JVM_SUPPORT_RECOMMENDED_ARGS:=""}
 JVM_GC_ARGS="-XX:+ExplicitGCInvokesConcurrent"
 ​
 #
 # JVM memory settings
 #
 : ${JVM_MINIMUM_MEMORY:=1024m}
 : ${JVM_MAXIMUM_MEMORY:=2048m}
 ​
 #
 # JVM code cache
 #
 JVM_CODE_CACHE_ARGS='-XX:InitialCodeCacheSize=32m -XX:ReservedCodeCacheSize=${JVM_RESERVED_CODE_CACHE_SIZE:=512m}'
 ​
 #
 # Required arguments for Jira
 #
 JVM_REQUIRED_ARGS='-Djava.awt.headless=true -Datlassian.standalone=JIRA -Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true -Dmail.mime.decodeparameters=true -Dorg.dom4j.factory=com.atlassian.core.xml.InterningDocumentFactory'
 ​
 #-----------------------------------------------------------------------------------
 # Prevents the JVM from suppressing stack traces
 #-----------------------------------------------------------------------------------
 JVM_EXTRA_ARGS="-XX:-OmitStackTraceInFastThrow -Djava.locale.providers=COMPAT"
 ​
 # Set file limits
 CURRENT_NOFILES_LIMIT=$( ulimit -Hn )
 ulimit -Sn $CURRENT_NOFILES_LIMIT
 ulimit -n $(( CURRENT_NOFILES_LIMIT > MIN_NOFILES_LIMIT  ? CURRENT_NOFILES_LIMIT : MIN_NOFILES_LIMIT ))
 ​
 PRGDIR=`dirname "$0"`
 [ -f "${PRGDIR}/jirabanner.txt" ] && cat "${PRGDIR}/jirabanner.txt"
 ​
 JIRA_HOME_MINUSD=""
 if [ "$JIRA_HOME" != "" ]; then
     echo $JIRA_HOME | grep -q " "
     if [ $? -eq 0 ]; then
         echo "WARNING: JIRA_HOME with spaces is ignored"
     else
         JIRA_HOME_MINUSD=-Djira.home=$JIRA_HOME
     fi
 fi
 ​
 JAVA_OPTS="-Xms${JVM_MINIMUM_MEMORY} -Xmx${JVM_MAXIMUM_MEMORY} ${JVM_CODE_CACHE_ARGS} ${JAVA_OPTS} ${JVM_REQUIRED_ARGS} ${JVM_SUPPORT_RECOMMENDED_ARGS} ${JVM_EXTRA_ARGS} ${JIRA_HOME_MINUSD}"
 ​
 export JAVA_OPTS
 ​
 echo "If you encounter issues starting or stopping Jira, please see the Troubleshooting guide"
 if [ "$JIRA_HOME_MINUSD" != "" ]; then
     echo "Using JIRA_HOME: $JIRA_HOME"
 fi
 ​
 # Set CATALINA_PID
 if [ -z "$CATALINA_PID" ] ; then
     if [ -n "$CATALINA_BASE" ] ; then
         CATALINA_PID="$CATALINA_BASE"/work/catalina.pid
     elif [ -n "$CATALINA_HOME" ] ; then
         CATALINA_PID="$CATALINA_HOME"/work/catalina.pid
     fi
 fi
 export CATALINA_PID
 ​
 echo "Server startup logs are located in logs/catalina.out"
 EOF
 ​
 # 设置文件权限
 chown 2001:2001 /workspace/atlassian/jira/setenv.sh
 chmod 755 /workspace/atlassian/jira/setenv.sh
 ​
 # 重启
 docker restart jira

打开网页端如下则成功：

——1——

（3）检查数据库

【此方法不需要单独恢复数据库，但是不包含LDAP，所以恢复完用户无法直接登录】

注意：Jira 的数据库连接在confluence 服务器上

首先确保数据库没有残留数据，如果有，通过下列步骤删除。

删除旧数据库

sql

 -- 首先断开所有连接到 jira 数据库的连接
 SELECT pg_terminate_backend(pid) 
 FROM pg_stat_activity 
 WHERE datname = 'jira' AND pid <> pg_backend_pid();
 ​
 -- 删除 jira 数据库
 DROP DATABASE IF EXISTS jira;

创建新数据库

sql

 -- 创建新的 jira 数据库
 CREATE DATABASE jira 
     WITH 
     OWNER = smarthome
     ENCODING = 'UTF8'
     LC_COLLATE = 'en_US.utf8'
     LC_CTYPE = 'en_US.utf8'
     TEMPLATE = template0;
 ​
 -- 授予权限
 GRANT ALL PRIVILEGES ON DATABASE jira TO smarthome;

（4）配置数据库

——2——

（5）设置应用程序的属性

——3——

（6）破解Jira

atlassian-agent.jar 地址：/opt/atlassian/jira 【这个jar包用来生成密钥破解jira，需要配置路径在setenv.sh中】

 root@2d2dd49be850:/opt/atlassian/jira# ls
 atlassian-agent.jar  conf             licenses     README.md    webapps
 atlassian-jira       CONTRIBUTING.md  logs         README.txt   work
 bin                  external-source  NOTICE       temp
 BUILDING.txt         lib              README.html  tomcat-docs
 root@2d2dd49be850:/opt/atlassian/jira# pwd
 /opt/atlassian/jira

把下面的代码放到最上面 setenv.sh 的最后一行（这里很重要，破解的关键）

 CATALINA_OPTS="-javaagent:/opt/atlassian/jira/atlassian-agent.jar ${CATALINA_OPTS}"

然后重启，用下面命令生成密钥：

 java -jar atlassian-agent.jar -d -m zhongping.wei@akuvox.com -n Akuvox -p jira -o http://192.168.202.202:80 -s B85B-0PMY-3YL1-2FUG

这里注意点为:

  • -m表示邮箱, 可以根据需要更换
  • -n表示名称, 可以根据需要更换
  • -o表示访问地址, 可以根据需要更换
  • -s表示服务器ID, 即上图中那个，要求输入秘钥时会显示

完成后即可生成对应的和谐码, 复制进去点击下一步即可完成和谐.

示例：

 [root@localhost ~]# docker restart jira
 jira
 [root@localhost ~]# java -jar atlassian-agent.jar -d -m zhongping.wei@akuvox.com -n Akuvox -p jira -o http://192.168.202.202:80 -s BMR9-ESFM-S38L-E5NR
 ​
 ====================================================
 =======     Atlassian Crack Agent v1.3.1     =======
 =======           https://zhile.io           =======
 =======          QQ Group: 30347511          =======
 ====================================================
 ​
 Your license code(Don't copy this line!!!):
 ​
 AAAB9w0ODAoPeJyNU1uPojAUfudXkOyjAbl4AZMm6wBmyQK64sxm5q3iUapYSCk6+uunCGZnRmM2K
 Q805zvnu5z+WFQgR/lB1i1xRuZwpFmyEy9kQzP60oYB0DQvCmBqQBKgJSxOBUR4D8iZhqE3d/xxI
 DkMMCc5dTEHVAMVXVd0S3oAcaFMGClqFHqmGdkTDis5awDy8iSnnBflqNs9pyQDleRSiAnlQDFNw
 HsvCDu10yxb0YbiSFvC8JWltyJN6yjwQ3/huVJU7ZfApuvnEliJFP1K7kGvguWrKuFq/aOU+ZofM
 QP1ptGDWpxwcgDEWQVfvPx8/wAuWGEHhGrWlLb2vIjBtThDiqvlPxsvJd4BZ9UlDLTGWdm2/95oy
 jaYkrKpq50WRuu2oeoDSxX51d/I0iQnp1xQ9YT1GTqnOd0UhG7UI5CfeFcd8nc1yffNhBtXWq6/c
 Jmi0Dk6E7dDtb/VPjE7zusfa41f2Hrlmeffw/7rOJ2/mXax25478dtskq7GvW1v9tTt7+zYPyLUj
 PhP02KOWS20kd+m7Lso8N3Yi5RAHw7M3sAwDMvsf12ae3saAzsAE/CncG4rXjwJldi0AsXrR3NpB
 6drFvpA04aaZZr6vUdzu46ziiUpLuH7k/kMvgRWMFK2ogV9dEdCm9KF+fgSywfWFUzfMCwCFFJqb
 r2F+1+IXPb3objzDi1xZkaDAhQsOBaPqOs+hP2cbUDtMCZc00gapg==X02nr

把这段密钥复制到网页中：

——4——

进入以下页面代表成功：

创建管理员账号密码等一系列步骤省略……

——5——

二、通过备份文件恢复 Jira

1、随便创建一个项目进入项目界面，点击如下设置——系统——登录管理员账号

——6——

2、找到恢复系统

——7——

3、生产环境/workspace/atlassian/jira/export目录下获得备份文件

文件格式例如：2025-Nov-19–0620.zip

文件传到目标主机：/workspace/atlassian/jira/import 该目录下

【注意这里赋予文件777权限，否则权限不足报错】

——8——

4、复制填入文件名——点击恢复，成功如下：

——9——

等待大约10多分钟，出现如下成功界面

——10——

以上完成还登录不了，因为没有连接LDAP，需要进入管理员后台设置

三、连接LDAP恢复用户登录

创建一个可登录的新管理员【测试失败】

请在 Jira 数据库执行：

Step 1. 创建用户 sysadmin（密码：admin）

 INSERT INTO cwd_user (id, user_name, lower_user_name, active, directory_id)
 VALUES (99999, 'sysadmin', 'sysadmin', 1, 1);

设置密码：

 UPDATE cwd_user
 SET credential = 'PKCS5S2:sha1:1000:4703f1fdd26daa874e54a113a8588e92:aceed8bab258af4ea2ce694c76707c9efbbb7174'
 WHERE id = 99999;

这个密文对应密码：

 admin

Step 2. 加入管理员组

先查管理员组 ID：

 select id, group_name from cwd_group;

运行显示

 jira=# select id, group_name from cwd_group;
   id   |           group_name
 -------+--------------------------------
  11265 | jira-indus-design-user
  11278 | jira-hw-admin
  11261 | jira-platform-software-user
  11289 | jira-product-PM-admin
  11275 | jira-product-PO-admin
  11277 | jira-product-user
  11285 | jira-homecloud-software-intern
  11282 | jira-product-PM-user
  10000 | jira-administrators
  10010 | jira-software-users
  10113 | 产品团队
  11284 | jira-product-PE-user
  11276 | jira-product-PO-user
  11263 | jira-sale-all-user
  11280 | jira-super-admin
  11266 | jira-sqa-admin
  10114 | 技术团队
  11258 | jira-ts-python-admin
  11264 | jira-system-software-admin
  11268 | jira-ts-intern
  10115 | 产品管理团队
  11270 | jira-ts-web-user
  11260 | jira-ts-linux-user
  10116 | 技术管理团队
  10210 | 部门主管
  11259 | jira-ts-linux-admin
  11254 | jira-software-users
  11262 | jira-sh-otherleaders
  11312 | jira-smarthome-qa-all-user
  11314 | jira-ui-user
  11290 | jira-product-assistant
  11256 | jira-ts-android-user
  11253 | jira-system-software-user
  11255 | jira-ts-user
  11291 | jira-techsupport
  11310 | jira-ts-web-admin
  11311 | jira-it-user
  10312 | 家居终端软件管理团队
  10311 | 家居终端软件团队
  10346 | jira-product-PM-user
  10347 | jira-product-PM-admin
  10353 | jira-ts-python-admin
  10354 | jira-ts-python-user
  10355 | jira-product-PE-admin
  10356 | jira-product-PE-user
  10357 | jira-ts-linux-user
  10358 | jira-ts-android-user
  10362 | jira-super-admin
  10363 | jira-product-user
  10364 | jira-ts-user
  10365 | jira-homecloud-software-user
  10366 | jira-product-PO-user
  10367 | jira-ts-linux-admin
  10368 | jira-ts-android-admin
  11274 | jira-project-manager-user
  11269 | jira-project-user
  10610 | jira-project-manager-user
  10911 | xiaoyan
  11281 | jira-homecloud-software-admin
  11257 | jira-ts-android-admin
  11286 | jira-homecloud-software-user
  11271 | jira-system-work-user
  11288 | jira-ts-python-user
  11287 | jira-product-PE-admin
  11283 | jira-dev-center-user
 (65 rows)

最安全配置（确保你 100% 能管理系统）

把你的本地管理员加入以下两个组：

1. jira-administrators

（Jira 官方默认 / 系统级管理员）

2. jira-super-admin

（你们公司自定义的扩展管理员组）

这两个组合在一起可以保证：

  • 能登录后台
  • 能访问系统设置
  • 能配置 LDAP 目录
  • 能创建项目、方案、字段
  • 能做任何恢复操作

创建语句：

 -- 给 sysadmin 用户加入 jira-administrators
 INSERT INTO cwd_membership (id, parent_id, child_id, membership_type, parent_name, child_name, lower_parent_name, lower_child_name, directory_id)
 SELECT
   COALESCE((SELECT max(id) FROM cwd_membership) + 1, 200001),
   10000,
   99999,
   'GROUP_USER',
   'jira-administrators',
   'sysadmin',
   lower('jira-administrators'),
   lower('sysadmin'),
   1
 WHERE NOT EXISTS (
   SELECT 1 FROM cwd_membership
   WHERE parent_id = 10000 AND child_id = 99999 AND directory_id = 1
 );
 ​
 -- 给 sysadmin 用户加入 jira-super-admin
 INSERT INTO cwd_membership (id, parent_id, child_id, membership_type, parent_name, child_name, lower_parent_name, lower_child_name, directory_id)
 SELECT
   COALESCE((SELECT max(id) FROM cwd_membership) + 1, 200002),
   11280,
   99999,
   'GROUP_USER',
   'jira-super-admin',
   'sysadmin',
   lower('jira-super-admin'),
   lower('sysadmin'),
   1
 WHERE NOT EXISTS (
   SELECT 1 FROM cwd_membership
   WHERE parent_id = 11280 AND child_id = 99999 AND directory_id = 1
 );

【此处预研失败，无法登录，失败后台报错如下】

 root@2d2dd49be850:/var/atlassian/application-data/jira/log# grep 985d34b9-8c51-4971-900b-3d562e0f6b46 atlassian-jira.log
 2025-11-21 14:22:33,123+0800 http-nio-8080-exec-2 ERROR      [c.a.j.web.servlet.InternalServerErrorServlet] {errorId=985d34b9-8c51-4971-900b-3d562e0f6b46, interpretedMsg=, cause=java.lang.IllegalStateException: User 'sysadmin' has no unique key mapping., stacktrace=java.lang.IllegalStateException: User 'sysadmin' has no unique key mapping.

具体错误：

 java.lang.IllegalStateException: User 'sysadmin' has no unique key mapping.

这个错误的意思是 Jira 数据库里虽然有一个 cwd_user 记录，但这个用户没有正确的唯一标识（unique key）或没有被 Jira 的用户目录完整识别。所以 Jira 启动或者登录时会报 “User has no unique key mapping”，这是导致你无法用 sysadmin 登录的根本原因。

问题根源

  1. 你直接在数据库里插入了 cwd_user 和 cwd_membership，但是 Jira 的 用户目录表结构很复杂，单靠几条 INSERT/UPDATE 不足以让 Jira 识别用户。
  2. 关键字段缺失：
    • lower_user_name
    • active
    • directory_id （你填的是 1，要确保对应的目录存在）
    • 唯一键字段：user_key 或 active_directory_user_key（具体版本不同字段名不同）
  3. cwd_membership 也必须和 cwd_user 完全对应。

简单地修改 credential 或随便插入用户是无法绕过这个检查的。

正确解决思路【未解决】

方法 1：使用 Jira 自带恢复脚本（最安全）【找不到脚本位置】

  • Jira 提供 set-password.sh 脚本（或 forgot-password 功能）来重置密码，而不是直接操作数据库。
  • 你之前找不到脚本，是因为 你用的 Docker 镜像里路径不同。在官方镜像里通常在： /opt/atlassian/jira/bin/set-password.sh
  • 如果不存在，你可以下载官方支持工具或者用临时用户通过 恢复管理员密码脚本。

方法 2：通过数据库重建用户（高级）

如果必须用 SQL，需要保证：

  1. 用户目录存在（cwd_directory 表里要有一条记录，对应 directory_id=1）。
  2. cwd_user 表完整： INSERT INTO cwd_user (
        id, user_key, user_name, lower_user_name, active, created_date, updated_date, directory_id
     ) VALUES (
        99999, ‘sysadmin’, ‘sysadmin’, ‘sysadmin’, true, now(), now(), 1
     );注意：user_key 是必须的，很多版本 Jira 会在登录时检查它。
  3. 然后加入 cwd_membership，保证 child_id 对应 cwd_user.id。
  4. 重启 Jira，让它重新加载用户目录。

方法 3（推荐）：创建新的管理员用户

  1. 通过 Jira 自带恢复功能（jira-admin.sh 或 set-password.sh）创建一个新管理员。
  2. 用新管理员登录后台。
  3. 再修复或删除你之前的手动插入的 sysadmin。

理论上创建临时管理员——进入系统连接LDAP就可以登录——恢复成功

Step A：创建新的内置管理员（只能通过数据库）

（官方文档写得很明确，Jira 自己也推荐这样做）

登录后进入：

 Jira 管理后台 → User Management → User Directories

你会看到原来的 LDAP 目录，但它是“未配置状态”。

Step B：重新填写你的 LDAP 信息：

  • LDAP URL
  • Base DN
  • User DN
  • Bind DN
  • Bind Password
  • Filter（若有）

保存 → 测试连接 → 成功。

Step C：让 LDAP 目录的优先级高于 Internal Directory

将 LDAP 目录上移到第 1 位（官方建议）。

Step D：LDAP 用户恢复可登录

无须重建用户。 因为：

  • ZIP 中保存了 LDAP 用户的账号记录（没有密码）
  • 保存 LDAP 配置后，Jira 会再次去 LDAP 验证密码
  • 用户可继续用 LDAP 密码正常登录

这就是官方支持的方式。

四、数据库恢复方式：

【上面的方式和这个理论上选择一种方式即可，但是没有登录进系统，无法确定成功性】

第一步：在生产环境备份Jira数据库

1.1 进入生产环境PostgreSQL容器并备份

bash

 # 进入生产环境PostgreSQL容器
 docker exec -it postgres bash
 ​
 # 在容器内执行备份（使用自定义格式，推荐）
 pg_dump -U smarthome -Fc jira > /tmp/jira_production_backup_$(date +%Y%m%d_%H%M%S).dump
 ​
 # 或者
 pg_dump -U smarthome -Fc -v -Z 9 jira > /tmp/jira_complete_backup_$(date +%Y%m%d_%H%M%S).dump
 ​
 # 或者使用纯SQL格式
 pg_dump -U smarthome jira > /tmp/jira_production_backup_$(date +%Y%m%d_%H%M%S).sql
 ​
 # 验证备份文件
 ls -lh /tmp/jira_production_backup_*.dump

参数解析：

  • pg_dump: PostgreSQL数据库备份工具
  • -U smarthome: 使用用户名 smarthome 连接数据库
  • -Fc: 指定备份格式为自定义格式 (Custom format)
  • jira: 要备份的数据库名称
  • >: 输出重定向到文件
  • /tmp/jira_production_backup_$(date +%Y%m%d_%H%M%S).dump: 备份文件路径，包含时间戳
两种格式的详细区别
1. 文件格式和内容
特性自定义格式 (.dump)纯SQL格式 (.sql)
文件类型二进制格式纯文本格式
可读性不可直接阅读可以直接用文本编辑器查看
文件内容压缩的二进制数据可读的SQL语句
文件大小较小（压缩）较大（未压缩）
2. 性能比较
特性自定义格式纯SQL格式
备份速度较快较慢
恢复速度较快较慢
压缩率内置压缩，文件较小无压缩，文件较大
网络传输传输量小传输量大
3. 功能特性对比
特性自定义格式纯SQL格式
并行备份/恢复✅ 支持 (-j 参数)❌ 不支持
选择性恢复✅ 支持（表级、数据级）❌ 有限支持
恢复前预览✅ pg_restore -l✅ 直接查看文件
版本兼容性要求pg_restore版本兼容较好的向前兼容性

1.2 将备份文件从容器复制到宿主机

bash

 # 在宿主机执行（不是容器内）
 docker cp postgres:/tmp/jira_production_backup_20251119_092959.sql /tmp/
 ​
 # 确认文件已复制
 ls -lh /tmp/jira_production_backup_*.dump

1.3 （可选）验证备份文件内容

bash

 # 查看备份文件中的表列表
 docker exec -it postgres pg_restore -l /tmp/jira_production_backup_*.dump | head -50
 ​
 # 检查关键表是否存在
 docker exec -it postgres pg_restore -l /tmp/jira_production_backup_*.dump | grep -E "(cwd_user|jiraissue|project)"

第二步：将备份文件传输到新环境

2.1 传输备份文件

bash

 # 使用scp将文件传输到新服务器
 scp /tmp/jira_production_backup_*.dump root@新服务器IP:/tmp/
 ​
 scp /tmp/jira_production_backup_20251119_063654.dump root@192.168.202.211:/root
 ​
 # 或者使用其他传输方式（rsync, sftp等）

第三步：在新环境恢复数据库

3.1 停止相关服务

bash

 # 停止任何可能连接Jira数据库的服务

3.2 将备份文件复制到新数据库容器

bash

 # 将备份文件复制到新PostgreSQL容器
 docker cp /root/jira_production_backup_20251119_092959.sql akuvox-postgres:/tmp/

3.3 备份当前新环境的Jira数据库（可选）

bash

 # 进入新数据库容器
 docker exec -it akuvox-postgres bash
 ​
 # 备份当前空的Jira数据库（以防需要回滚）
 pg_dump -U smarthome -Fc jira > /tmp/jira_new_empty_backup_$(date +%Y%m%d).dump

3.4 删除并重新创建Jira数据库

bash

 # 在容器内执行
 psql -U smarthome
 ​
 DROP DATABASE jira;
 ​
 -- 创建新的 jira 数据库
 CREATE DATABASE jira 
     WITH 
     OWNER = smarthome
     ENCODING = 'UTF8'
     LC_COLLATE = 'en_US.utf8'
     LC_CTYPE = 'en_US.utf8'
     TEMPLATE = template0;
 ​
 -- 授予权限
 GRANT ALL PRIVILEGES ON DATABASE jira TO smarthome;

3.5 恢复生产环境备份

bash

 # 使用pg_restore恢复（推荐使用自定义格式）
 pg_restore -U smarthome -d jira --verbose --clean --if-exists /tmp/jira_production_backup_*.dump
 ​
 # 例如：（已测试失败）
 pg_restore -U smarthome -d jira --verbose --no-owner --no-privileges --no-tablespaces --exit-on-error /tmp/jira_production_backup_20251119_063654.dump
 ​
 # 如果遇到错误，可以尝试忽略小错误
 pg_restore -U smarthome -d jira --verbose --clean --if-exists --exit-on-error=false /tmp/jira_production_backup_*.dump
 ​
 # 如果使用SQL格式备份
 psql -U smarthome -d jira -f /tmp/jira_production_backup_20251119_092959.sql

参数解析：

  • -U smarthome: 使用用户名 smarthome 连接数据库
  • -d jira: 恢复到名为 jira 的数据库
  • --verbose: 显示详细的恢复过程信息
  • --clean: 在恢复前删除/清空目标数据库中的对象
  • --if-exists: 使用 DROP ... IF EXISTS 语法，避免对象不存在时报错
  • /tmp/jira_production_backup_*.dump: 备份文件路径

3.6 验证恢复结果

bash

 # 检查关键表和数据
 psql -U smarthome -d jira -c "SELECT count(*) FROM cwd_user;"
 psql -U smarthome -d jira -c "SELECT count(*) FROM jiraissue;"
 psql -U smarthome -d jira -c "SELECT count(*) FROM project;"
 ​
 # 检查数据库大小
 psql -U smarthome -d postgres -c "\l+ jira"

第四步：恢复后操作

4.1 启动服务并验证

bash

 # 启动所有服务
 docker start jira
 ​
 # 等待服务启动后，检查日志

4.2 在Jira中执行重索引

  1. 使用管理员账户登录Jira
  2. 进入 管理 > 系统 > 索引
  3. 执行 完整重索引

4.3 清理临时文件

bash

 # 在生产环境清理
 docker exec postgres rm -f /tmp/jira_production_backup_*.dump
 ​
 # 在新环境清理
 docker exec akuvox-postgres rm -f /tmp/jira_production_backup_*.dump
 docker exec akuvox-postgres rm -f /tmp/jira_pre_restore_backup_*.dump
 ​
 # 在宿主机清理
 rm -f /tmp/jira_production_backup_*.dump

注意事项

  1. 确保有足够的磁盘空间用于备份和恢复
  2. 在业务低峰期操作，避免影响生产环境
  3. 先备份当前环境，以便出现问题时可以回滚
  4. 验证关键数据在恢复后是否正确
  5. 如果恢复过程中断，可能需要重新开始整个流程

五、问题记录

1、创建缺失的函数

恢复后会因为一个函数的缺失报错，暂时未解决，可以尝试自建解决，目前未发现有影响，无法进入系统验证

bash

 # 创建 aurora_version 函数
 docker exec akuvox-postgres psql -U smarthome -d jira -c "CREATE OR REPLACE FUNCTION aurora_version() RETURNS text AS \$func\$ BEGIN RETURN 'PostgreSQL 14.1'; END; \$func\$ LANGUAGE plpgsql;"

为什么需要手动创建函数？

原因：

  • aurora_version() 是AWS Aurora数据库特有的函数
  • 您使用的是标准PostgreSQL，没有这个函数
  • 备份中不包含这个函数定义，因为它是数据库引擎级别的函数
  • Jira可能在某些查询中调用了这个函数（可能是某些插件或功能）

实际上，这个函数可能不是必需的，如果Jira能正常运行的话。我们可以先不创建，看看是否会影响运行。

Alaric 个人博客网站

Jira 虚拟机恢复方式

企业架构基础完成！

通过Proxmox平台 pbs 备份实现——首先找到Jira对应虚拟机整机备份文件

选择还原位置（注意修改Mac地址，复制虚拟机Mac地址还原会导致原本的生产环境虚拟机网络Mac地址冲突）

还原完成后启动虚拟机，打开对应网址链接

存储方面如果有异机存储，记得修改对应存储位置，不要与生产环境冲突（如果生产环境还在运行）

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

作者

fffff@xf.nn

文章推荐

🧰 常用 Linux 命令大全

读出全部

IndexTTS2 部署

读出全部

MeterSphere 测试平台部署

读出全部

AFFiNE 新版本升级

读出全部

Confluence 数据恢复演练与定期备份策略

读出全部

GitLab EE Premium 18.4.1 企业版安装部署

读出全部