Project

General

Profile

QA #810

Redmineのバックアップとリストアについて

Added by tama ryo 11 months ago. Updated 3 months ago.

Status:
回答済
Priority:
通常
Assignee:
-
Category:
-
Target version:
-
Start date:
05/25/2018
Due date:
% Done:

0%

Estimated time:

Description

下記の環境でリストアしたところ、ユーザだけがリストアされずに困っています。
ユーザはRedmineローカルユーザ(adminやguest等)とAD連携(LDAP認証利用)によるユーザがいました。

バックアップ、リストア方法に間違いがないか教えて頂けないでしょうか。

バックアップ方法
  • ファイル類
    /var/lib/redmine まるごと
  • SQLデータ
    pg_dump -U {db_user} {db_name} > DBbackup

リストア方法
1. /var/lib/redmineにバックアップしたredmineディレクトリを丸コピー
2. 同名のDBユーザ、DB名でDBを作成。
3. redmineのDB周りの初期設定を実施
4. httpdを起動しRedmineにアクセスできるか確認
5. httpdを停止し、SQLデータをリストア

psql -U postgres {db_name} < DBbackup

この時点でRedmineにアクセス可能であり、ユーザ以外は全てリストアされているのを確認。

環境(バックアップ、リストアRedmine共に同じ環境)

Redmine version                3.4.3.stable.17022
  Ruby version                   2.4.2-p198 (2017-09-14) [x86_64-linux]
  Rails version                  4.2.8
  Environment                    production
  Database adapter               PostgreSQL

History

#1

Updated by 奈良 裕記 11 months ago

mysqlしか使っていませんが、考えにくいですね

usersテーブル単体でdump,insertして、エラー内容確認

users無ければ、チケット、pjメンバー表示も異常になる筈です。
どうなっていますか

usersを直接見るmembersは?

#2

Updated by tama ryo 11 months ago

奈良様

usersテーブル単体でdump,insertしてみたところ正常に反映されました。

移行元Redmineでusersをdump

# pg_dump -U postgres -t users {db_name} > redmineDBusersBack

移行先Redmineでテーブルを一旦削除して反映させる

# psql -U redmine -d {db_name}
DROP TABLE users;

psql -U postgres {db_name} < redmineDBusersBack

テーブル指定なしでdumpしたファイルの中を覗くとusersテーブルは存在しており、データもきっちりと入っていましたので
なぜ反映されていないのか(初期設定のやり方が間違っている?)は不明です。

#3

Updated by tama ryo 11 months ago

追記

email_addressesのテーブルも同様に単独でdumpしてリストアする必要がありました。

#4

Updated by tama ryo 11 months ago

この事象についてですが原因がわかりました。
Redmineのインストールの手順に従ってデフォルトデータの登録をしてしまっていたのが問題のようでした。
もう一度空のDBを作成してそこにリストアしたところユーザもきちんと引き継がれていました。

お騒がせして申し訳ございまs年でした。

#5

Updated by 奈良 裕記 11 months ago

解決して良かったですね。

usersのIDは一意性制約がありますから、id=1のadminが先に登録されているだけでも失敗します。
issue,projectなどは最初はカラなので影響無し、
workflow,statusなどは初期値と同じで気付かなかったのかも。

DBのdump/restoreは、こういったトラブル起こりがちなので、ログをちゃんと見る必要あります。
(ある意味、見つかる様な状態で幸運だったかと)

ただ、mysqlのdumpのSQLは、tableを一旦drop,create table, insertしているので、
pgが同じ処理になっていれば考えにくいんですよね。

下記抜粋

DROP TABLE IF EXISTS `users`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `users` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `login` varchar(255) NOT NULL DEFAULT '',
。。。
  `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=291 DEFAULT CHARSET=utf8;
/*!40101 SET character_set_client = @saved_cs_client */;

LOCK TABLES `users` WRITE;
/*!40000 ALTER TABLE `users` DISABLE KEYS */;
INSERT INTO `users` VALUES (1,'admin','fdsffdfd8948f99fe0c','Redmine','Admin',1,1,'2018-05-27 15:04:39','',NULL,'2018-05-02 16:40:56','2018
-
#6

Updated by 奈良 裕記 3 months ago

  • Status changed from 新規 to 回答済

解決済なので回答済で終了します。

Also available in: Atom PDF