Bitnami-Redmine备份迁移恢复

事情起因

Redmine 作为一款项目管理软件，曾经很是流行，现如今风光不在，不过依然在某些场景下受到欢迎。

常见的 Redmine 使用方式为：Redmine + markdown + svn/git ，这种组合可以满足项目进度管理、代码管理、文档管理的需求。

在使用过程中，最为头疼的莫过于 markdown 的集成，官方给出的插件太过陈旧，而第三方插件，或多或少都会引起 redmine 访问不稳定，还会导致CPU跑满，机器宕掉，这一度让小伙伴的情绪处于失控的边缘，于是乎，就下决心动动这个老古董。

经过调研发现，redmine 3.x 版本内置了 markdown 插件，于是乎，把老版本的数据迁移到新版本似乎是个不错的选择。

这里有两个选择：

可以在原 redmine 2.6 的基础上进行升级，不过之前安装的过程中，ruby 的版本已经有点混乱，做起来会比较麻烦，再者官方没有提供无缝升级文档，还有一个是 3.0 的数据库不兼容 2.6；

当然也可以重新搭建一个新的 redmine  3.0，这样会更干净一些，后续的维护包袱也会小一些，所以下面就以此方法为准。

环境（迁移前）

系统：CentOS 6.6 x64

软件：Bitnami-Redmine 2.6

目录：/opt/redmine

服务器：11.11.11.11

环境（迁移后）

系统：CentOS 7.0 x64

软件：Bitnami-Redmine 3.0

目录：/opt/redmine

服务器：22.22.22.22

数据库备份（旧服务器）

（1）备份数据库

这里有一个小插曲，之前安装的小伙伴说，没有留意安装过程中有让填写 mysql 密码，所以，有必要手动恢复一下 root 密码，操作如下

（2）停止 redmine

cd /opt/redmine
./ctlscript.sh stop

（3）使用安全模式启动 msyql，跳过权限认证（此处的操作会使数据库处于危险之中，所以操作之前一定在停掉mysql）

./mysql/bin/mysqld_safe --skip-grant-tables &
./mysql/bin/mysql -uroot

（4）恢复 mysql root 的密码为 123456

update mysql.user set password=PASSWORD('123456') where User='root';
flush privileges;
quit

（5）查找 mysql 进程，并且关闭

ps -ef|grep mysql

找到进程PID后，可以使用 kill -9 pid 命令来关掉进程

（6）启动 redmine

./ctlscript.sh start

（7）备份数据库到 当前目录的 bitnami_redmine.sql 文件

./mysql/bin/mysqldump -uroot -p'123456' bitnami_redmine > bitnami_redmine.sql

（8）使用文本工具编辑 bitnami_redmine.sql 文件，使用新的服务器 22.22.22.22 替换 旧的 11.11.11.11

数据库恢复（新服务器）

（9）安装 bitnami-redmine

安装不作为此文章的重点，所以，就选择性跳过了，后续我会再补一篇《Bitnami-Redmine 快速部署》文章。

此处只给出 bitnami-redmine 的下载地址 https://bitnami.com/stack/redmine/installer ，下载之后，对照 README 文档操作就可以了，几乎是一键式安装，比较轻松。

（10）启动 bitnami-redmine

cd /opt/redmine
./ctlscript.sh start

（11）备份数据库

./mysql/bin/mysqldump -uroot -p'123456' bitnami_redmine > bitnami_redmine_bak.sql

（12）使用 mysql 命令清理 bitnami_redmine 数据库

./mysql/bin/mysql -uroot -p'123456'
DROP DATABASE bitnami_redmine;
CREATE DATABASE bitnami_redmine;
quit

（13）上传 bitnami_redmine.sql 到 /opt/redmine ，并恢复旧数据库

./mysql/bin/mysql -uroot -p'123456' bitnami_redmine < bitnami_redmine.sql

（14）接下来的基本上是体力活了，因为上面提到 redmine 从 2.6 升级到 3.0 数据库结构发生的改变，所以涉及到的数据表，需要手动修复

主要修改如下：

用户表 users 中，删除了 email 字段，拆分为单独的 邮件地址表 email_addresses

users 表的插入语句，手动删除 email 字段即可；

至于新增的 email_addresses 表，懒一点的办法就是所有操作完成后，手动在管理后台中给每个用户添加邮件，每个用户60秒足够了（注意此处添加邮件会修改掉用户的密码，设置一个统一的，强制用户登录修改吧）

问题状态表 issue_statuses 中，删除中 is_default 字段

issue_statuses 表的插入语句，手动删除 email 字段即可；

角色表 roles 中，添加了 users_visibility 字段

roles 表的插入语句中，每个 VALLUES 的末字段添加一个 ‘all‘ 即可

跟踪表 tracker 中，添加了 default_status_id 字段

tracker 表的插入语句中，每个 VALUES 的末字段添加一个 1 即可

wiki表 wiki_redirects 中，添加了 redirects_to_wiki_id 字段

此处的旧项目中，并未用到此表，所以操作无从谈起

为了方便操作，可以将数据库修复操作，放在一个文件 bitnami_redmine_upgrade_26_to_30.sql 中，

【特别注意】如下代码中，出现了 ... 字符，这里代表中，需要替换为你的旧数据库中的真实数据，如果没有数据，可以直接删除所在 INSERT 行

【此处有坑】保存此文件时，一定要注意，文档格式为UTF-8，否则在下面的导入中，会一直报错，在管理后台的表现就是，缺少数据

USE bitnami_redmine;

DROP TABLE IF EXISTS `email_addresses`;
CREATE TABLE `email_addresses` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `user_id` int(11) NOT NULL,
  `address` varchar(255) NOT NULL,
  `is_default` tinyint(1) NOT NULL DEFAULT '0',
  `notify` tinyint(1) NOT NULL DEFAULT '1',
  `created_on` datetime NOT NULL,
  `updated_on` datetime NOT NULL,
  PRIMARY KEY (`id`),
  KEY `index_email_addresses_on_user_id` (`user_id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;

DROP TABLE IF EXISTS `issue_statuses`;
CREATE TABLE `issue_statuses` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(30) NOT NULL DEFAULT '',
  `is_closed` tinyint(1) NOT NULL DEFAULT '0',
  `position` int(11) DEFAULT '1',
  `default_done_ratio` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `index_issue_statuses_on_position` (`position`),
  KEY `index_issue_statuses_on_is_closed` (`is_closed`)
) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8;

LOCK TABLES `issue_statuses` WRITE;
INSERT INTO `issue_statuses` VALUES ...;
UNLOCK TABLES;

DROP TABLE IF EXISTS `roles`;
CREATE TABLE `roles` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(30) NOT NULL DEFAULT '',
  `position` int(11) DEFAULT '1',
  `assignable` tinyint(1) DEFAULT '1',
  `builtin` int(11) NOT NULL DEFAULT '0',
  `permissions` text,
  `issues_visibility` varchar(30) NOT NULL DEFAULT 'default',
  `users_visibility` varchar(30) NOT NULL DEFAULT 'all',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8;

LOCK TABLES `roles` WRITE;
INSERT INTO `roles` VALUES ...;
UNLOCK TABLES;

DROP TABLE IF EXISTS `trackers`;
CREATE TABLE `trackers` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(30) NOT NULL DEFAULT '',
  `is_in_chlog` tinyint(1) NOT NULL DEFAULT '0',
  `position` int(11) DEFAULT '1',
  `is_in_roadmap` tinyint(1) NOT NULL DEFAULT '1',
  `fields_bits` int(11) DEFAULT '0',
  `default_status_id` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`)

) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=utf8;

LOCK TABLES `trackers` WRITE;
INSERT INTO `trackers` VALUES ...;
UNLOCK TABLES;

DROP TABLE IF EXISTS `users`;
CREATE TABLE `users` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `login` varchar(255) NOT NULL DEFAULT '',
  `hashed_password` varchar(40) NOT NULL DEFAULT '',
  `firstname` varchar(30) NOT NULL DEFAULT '',
  `lastname` varchar(255) NOT NULL DEFAULT '',
  `admin` tinyint(1) NOT NULL DEFAULT '0',
  `status` int(11) NOT NULL DEFAULT '1',
  `last_login_on` datetime DEFAULT NULL,
  `language` varchar(5) DEFAULT '',
  `auth_source_id` int(11) DEFAULT NULL,
  `created_on` datetime DEFAULT NULL,
  `updated_on` datetime DEFAULT NULL,
  `type` varchar(255) DEFAULT NULL,
  `identity_url` varchar(255) DEFAULT NULL,
  `mail_notification` varchar(255) NOT NULL DEFAULT '',
  `salt` varchar(64) DEFAULT NULL,
  `must_change_passwd` tinyint(1) NOT NULL DEFAULT '0',
  `passwd_changed_on` datetime DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `index_users_on_id_and_type` (`id`,`type`),
  KEY `index_users_on_auth_source_id` (`auth_source_id`),
  KEY `index_users_on_type` (`type`)
) ENGINE=InnoDB AUTO_INCREMENT=28 DEFAULT CHARSET=utf8;

LOCK TABLES `users` WRITE;
INSERT INTO `users` VALUES ...;
UNLOCK TABLES;

DROP TABLE IF EXISTS `wiki_redirects`;
CREATE TABLE `wiki_redirects` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `wiki_id` int(11) NOT NULL,
  `title` varchar(255) DEFAULT NULL,
  `redirects_to` varchar(255) DEFAULT NULL,
  `created_on` datetime NOT NULL,
  `redirects_to_wiki_id` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `wiki_redirects_wiki_id_title` (`wiki_id`,`title`),
  KEY `index_wiki_redirects_on_wiki_id` (`wiki_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

上传此文件到 /opt/redmine ，并执行更新操作

./mysql/bin/mysql -uroot -p'123456' < bitnami_redmine_upgrade_26_to_30.sql

（15）至此，所有数据库操作已经完成，下面开始文件附件操作

文件附件迁移（旧服务器）

（16）将 /apps/redmine/htdocs/files 下的所有文件打包，并拷贝至新服务器相同目录即可。

插件迁移（旧服务器）

（17）将 /apps/redmine/htdocs/plugins 下的所有文件打包，，并拷贝至新服务器相同目录即可。

大功告成

（18）至此，迁移工作完成，浏览器中访问新版 redmine ，确认功能是否正常。

参考资料

Bitnami Redmine Install https://bitnami.com/stack/redmine/installer

Redmine 数据迁移记录  https://ruby-china.org/topics/8340

Redmine README.txt  Redmine安装目录

时间： 2024-10-16 04:29:31

Bitnami-Redmine备份迁移恢复的相关文章

Windows 7下备份恢复bitnami redmine记录

因服务器更换,需要将原来服务器上的bitnami redmine系统及所有项目记录迁移到新的服务器下,以下是记录: 环境:redmine 1.1.2.1 因原来的版本就是这个,也没有时间更换最新版本,只有用原来这个比较老的版本. 原系统:windows server 2003 新系统:windows 7 步骤: 1. 在老系统中备份数据: 1.1 在安装的bitnami redmine快捷菜单下运行“use bitnami redmine stack”,进入命令行界面: 1.2 到redmine

bitnami redmine安装、配置、备份、恢复(这篇文章靠谱)

bitnami redmine安装.配置.备份.恢复 2012-12-17 12:33 2596人阅读 评论(0) 收藏 举报 1. 安装时语言选择英文,不可以选择中文,否则不能正常运行,可以在账户里改为显示中文: 2. 安装完成后,最上面的标题栏字体太小,修改: D:\BitNami\redmine-2.1.4-0\apps\redmine\htdocs\public\themes\classic\stylesheets\application.css 中  #top-menu { font-

Docker中容器的备份、恢复和迁移

转自:http://www.linuxidc.com/Linux/2015-08/121184.htm 1. 备份容器 首先,为了备份Docker中的容器,我们会想看看我们想要备份的容器列表.要达成该目的,我们需要在我们运行着Docker引擎,并已创建了容器的Linux机器中运行 docker ps 命令. # docker ps Docker Containers List 在此之后,我们要选择我们想要备份的容器,然后去创建该容器的快照.我们可以使用 docker commit 命令来创建快照

Git系列七之备份迁移 升级 恢复管理

0.Gitlab安装 1.安装和配置必要的依赖关系在CentOS7,下面的命令将在系统防火墙打开HTTP和SSH访问. yum install curl openssh-server postfix systemctl enable sshd postfix systemctl start sshd postfix firewall-cmd --permanent --add-service=http systemctl reload firewalld 2.添加gitlab包服务器安装包 cu

无忧之道：Docker中容器的备份、恢复和迁移

原创:LCTT https://linux.cn/article-5967-1.html译者: GOLinux本文地址:https://linux.cn/article-5967-1.html 2015-8-6 15:02    评论: 2 收藏: 3 今天,我们将学习如何快速地对docker容器进行快捷备份.恢复和迁移.Docker是一个开源平台,用于自动化部署应用,以通过快捷的途径在称之为容器的轻量级软件层下打包.发布和运行这些应用.它使得应用平台独立,因为它扮演了Linux上一个额外的操作

Docker 备份、恢复、迁移数据卷

可以利用数据卷对其中的数据进行进行备份.恢复和迁移. 备份 首先使用 --volumes-from 标记来创建一个加载 dbdata 容器卷的容器,并从本地主机挂载当前到容器的 /backup 目录.命令如下: $ sudo docker run --volumes-from dbdata -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /dbdata 容器启动后,使用了 tar 命令来将 dbdata 卷备份为本地的 /backup/ba

Gitlab备份、恢复与迁移

Gitlab 创建备份 使用Gitlab一键安装包安装Gitlab非常简单, 同样的备份恢复与迁移也非常简单. 使用一条命令即可创建完整的Gitlab备份: gitlab-rake gitlab:backup:create 使用以上命令会在/var/opt/gitlab/backups目录下创建一个名称类似为1393513186_gitlab_backup.tar的压缩包, 这个压缩包就是Gitlab整个的完整部分, 其中开头的1393513186是备份创建的日期. Gitlab 修改备份文件默

Jira/Confluence的备份、恢复和迁移

一.Jira.Confluence的备份.恢复1)Confluence的备份 管理员账号登录Confluence,点击右上角的"一般配置"-"每日备份管理",如下图(默认配置): 默认每天会自动备份一个zip打包的数据,存放在服务器的/var/atlassian/application-data/confluence/backups路径下.还可以点击"编辑"进行自定义. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Bitnami redmine升级

从3.2.1升级至3.3.0,不确定数据库结构是否有变化,主要过程:先停止服务,安装redmine模块,恢复服务. 以下适用于windows操作系统,采用Bitnami安装方式: 1.完整备份 Follow these steps: Stop all servers using the shortcuts in the Start Menu or the graphical manager tool. Create a compressed file with the stack content