Confluence数据丢失惊魂记

Code 代码
2020年2月2日 ~

时间:2020年2月1日 
版本:confluence 7.1.1

先讲结论:

  1. 冗余备份一定要定期做,并且定期确认,出现问题后悔莫及;
  2. 系统卷和数据卷尽可能分离,还需要加上备份卷,定期同步应用备份归档。数据出现问题,首先umount数据卷,防止系统读写导致数据覆盖;
  3. 能用云服务就用云服务,可使用定期数据卷备份,多一层数据保护机制,本地运维没有专业团队和工具,支撑太累了,钱是小事,数据丢失或损坏,损失更大!
  4. Confluence好用,但运维非常不友好,程序经常报错,备份机制陈旧,很多操作只能通过UI操作,命令行可操作性不强,一旦应用无法启动,运维操作基本就废了;
  5. 最后,遇到问题不要着急,想好对策,再下手,多查资料并验证,有时候会峰回路转。

今天突然发生confluence无法访问的情况。查看应用日志后,发现是由于数据库文件损坏psql服务无法正常启动导致。至于原因,只有天知道了。

想到几个解决办法:

  1. 尝试恢复psql数据库文件;
  2. 通过应用备份数据恢复所有文件。

方法1

如果进行大量磁盘操作,比如安装应用等,可能会影响数据恢复,并且发生这种情况第一件事应该是umount数据卷。却发现系统盘和数据盘并没有分开,与运维工程师确认,确实没做分离。那现在唯一的办法是关闭系统,将磁盘挂载到其他虚拟机尝试恢复。

测试使用extundeleted、debugfs等工具均无法发现任何删除的痕迹。尝试采用photorec恢复工具,花了几个小时,就恢复出一堆无用文件,不得不放弃。

方法2

查看了backups备份文件,最近的备份居然是2019年9月5号的。这下傻眼了,那岂不是半年的数据全没了?实在太坑爹了吧!

# ll -ah
total 34G
drwx------  3 2002 2002 4.0K Feb  1 21:10 ./
drwxr-xr-x 32 2002 2002 4.0K Feb  1 19:44 ../
-rwx------  1 2002 2002 6.7G Sep  1 10:19 wiki-backup-2019_09_01.zip*
-rwx------  1 2002 2002 6.7G Sep  2 10:19 wiki-backup-2019_09_02.zip*
-rwx------  1 2002 2002 6.7G Sep  3 10:19 wiki-backup-2019_09_03.zip*
-rwx------  1 2002 2002 6.7G Sep  4 10:16 wiki-backup-2019_09_04.zip*
-rwx------  1 2002 2002 6.7G Sep  5 10:16 wiki-backup-2019_09_05.zip*

现在不是找问题的时候,先看看有没有其他方式恢复数据。查找官方资料得知,如果数据库损坏,基本没有数据恢复的可能,大部分内容均是存于数据库的,磁盘只保留了静态文件和缓存索引,当时可真有点欲哭无泪。应用默认开启每天备份,怎么会一直没有备份上?google了一圈没有任何价值信息。怎么办?

数据库丢失,可否恢复数据的解答

先检查数据目录下还有没有用来恢复的文件。发现应用数据目录下有个recovery目录,其中有upgrade数据库留下的备份文件,压缩文件还挺大,100多mb。

drwx------  2 2002 2002       4096 Feb  1 16:47 ./
drwxr-xr-x 32 2002 2002       4096 Feb  1 19:44 ../
-rwx------  1 2002 2002   90219478 Sep 12 13:57 upgradeRecoveryFile-8100-8202-after.xml.gz*
-rwx------  1 2002 2002  174994534 Sep 12 13:55 upgradeRecoveryFile-8100-8202-before.xml.gz*
-rwx------  1 2002 2002  104018479 Nov 14 19:54 upgradeRecoveryFile-8202-8301-after.xml.gz*
-rwx------  1 2002 2002  104019287 Nov 14 19:52 upgradeRecoveryFile-8202-8301-before.xml.gz*
-rw-r-----  1 2002 2002  117108122 Feb  1 14:06 upgradeRecoveryFile-8301-8401-before.xml.gz

感觉有戏,google了一番,并没有什么卵用,一盆凉水浇下。不信邪,解压缩备份文件查看,真邪!

upgradeRecoveryFile然并卵的证据

通过 du -hd1 . 方式查看目录下还有哪些较大的目录。

# du -hd1 .
4.0K    ./stagil_navigation_image
784M    ./plugins-osgi-cache
196K    ./.java
4.0K    ./scripts
52K    ./scriptrunner
4.0K    ./plugins-temp
197M    ./logs
704K    ./analytics-logs
20K    ./webresource-temp
2.0G    ./to-be-removed
4.0K    ./resources
4.0K    ./bundled-plugins
3.1G    ./temp
35M    ./thumbnails
4.0K    ./restore
92K    ./.cache
12K    ./journal
4.0K    ./plugins-cache
42G    ./backups
544M    ./imgEffects
52M    ./index
32K    ./cute
8.0K    ./subspace
195M    ./shared-home
8.0K    ./__pycache__
40M    ./_backup
23M    ./fonts
15M    ./viewfile
12G    ./attachments
1.9G    ./recovery
62G    .

遂发现temp目录有3.1gb,进去一看,发现新大陆。居然看到了xmlexport文件夹,而且还是今天生成的!这不就是苦苦寻找的备份文件么?只是这个体积有点小,去年9月的备份文件压缩包都有7gb多,半年过去了,没增反而少了一大半?查看了exportDescriptor.properties和entities.xml的确和备份文件同出一辙,死马当活马医。

# ll
total 12
drwx------  3 2002 2002 4096 Feb  1 10:00 ./
drwxr-xr-x 32 2002 2002 4096 Feb  1 19:44 ../
drwxr-x---  3 2002 2002 4096 Feb  1 10:05 xmlexport-20200201-100001-1/

# du -hd1 .
3.1G    ./xmlexport-20200201-100001-1
3.1G    .

# ll -h
total 614M
drwxr-x---   3 2002 2002 4.0K Feb  1 10:05 ./
drwx------   3 2002 2002 4.0K Feb  1 10:00 ../
drwxr-x--- 778 2002 2002  20K Feb  1 10:07 attachments/
-rw-r-----   1 2002 2002 614M Feb  1 10:05 entities.xml
-rw-r-----   1 2002 2002  661 Feb  1 10:00 exportDescriptor.properties

# du -hd1 .
2.5G    ./attachments
3.1G    .

官方资料说temp目录是confluence应用运行态生成的临时文件,半成品的备份文件应该是每日备份定时任务的中间产物,备份过程出现了错误,未生成最后的压缩文件,过了半年才发现这个问题,我们的运维工程师可真是粗心大意。

解压缩了去年9月的备份文件,检查目录结构的差异。

# ll -h
total 717M
drwxr-xr-x    5 root root 4.0K Feb  1 21:24 ./
drwx------    3 2002 2002 4.0K Feb  1 21:10 ../
drwxr-xr-x 1612 root root  52K Sep  5 02:06 attachments/
-rw-r--r--    1 root root 717M Sep  5 02:04 entities.xml
-rw-r--r--    1 root root  657 Sep  5 02:00 exportDescriptor.properties
drwxr-xr-x    3 root root 4.0K Sep  5 02:06 plugin-data/
drwxr-xr-x    2 root root 4.0K Sep  5 02:06 resources/

# du -hd1 .
65M    ./plugin-data
4.0K    ./resources
7.7G    ./attachments
8.4G    .

将temp目录下有用的文件拷贝出来,再拷贝最新的attachments目录,重新打包,自制备份文件完成。心里舒了一大口气。

见证奇迹的时刻,启动全新的应用环境,重新初始化应用,导入自制备份文件,过了几十分钟,没有反应,查看日志,错误提示说有非法的unicode,通过官方的xml工具修复后再导入还是没有反应。再次陷入绝望…

放弃是不可能的。仔细查看导入日志和数据,发现数据并没有真正导入,连数据库都是空的,导入时数据库更新有错误信息。会不会是半成品备份文件部分关联问题导致的?试试先导入9月备份再导入自制备份。又是漫长的等待。

导入完2份备份文件后,已经凌晨1点,重启服务。OMG,终于出现了令人激动的dashboard!至少数据是保住了!悬着的心总算是落下了。

过程中遇到不少小插曲,不得不吐槽下confluence:

  1. 即使全新环境,经常会报错无法启动。需要将文件和数据库全部删除,再重新启动才行,有几次还需要重启机器!
  2. 无论是备份还是新系统都创建了内置的admin用户,但导入9月份数据后,系统中的admin用户居然消失了!数据库里也找不到对应的admin用户。而其他用户是通过外部directory同步的,外部directory没有confluence-administrators和confluence-users群组,导致没有权限管理系统。真是服了!!
  3. 导入2份备份文件均会出现导入失败,却没有具体的原因!
  4. 日志输出复杂,不专业开发和运维,很难看懂。

别以为故事到此结束,confluence备份恢复是不包含插件的,意味着所有插件需要重新安装。结果再次入坑,插件怎么都安装不上,系统报错,而错误对应的解决方法屡试不通!

估计是备份文件出的bug,只能通过备份恢复来解决。执行系统备份任务,继续漫长的等待,任务执行结束,但奇怪的是,就是没有备份文件出现?这可能就是无法自动备份的问题所在了。检查日志,发现可能与attachments丢失有关,导致数据库有信息,但找不到静态文件,这也是为什么同事反应部分空间文件无法打开的原因。

最后通过取消备份attachments仅备份内容解决,再次重新启动应用,导入,安装插件,Perfect!一切正常!

美中不足,日历数据丢失了,原来日历并不是和空间一起备份了…我去!最后还有这么一个坑等着呢!还好日历用的并不多,暂时先不管了…

一波三折,总算可以安心睡觉了。但愿Confluence别入梦,不然看我怎么扁你!

Reference:

https://blog.51cto.com/ixdba/1566856
https://community.atlassian.com/t5/Confluence-questions/Postgresql-database-removed-what-can-be-restored/qaq-p/452194
https://community.atlassian.com/t5/Confluence-questions/How-do-I-use-the-upgradeRecoveryFile-file/qaq-p/863563
https://confluence.atlassian.com/doc/confluence-home-and-other-important-directories-590259707.html#ConfluenceHomeandotherimportantdirectories-Tempdirectory(installationdirectory)
https://confluence.atlassian.com/doc/rebuilding-the-ancestor-table-153948.html
https://confluence.atlassian.com/jira/removing-invalid-characters-from-xml-backups-12079.html?_ga=2.191168162.949146932.1570563903-1362297403.1564667992

标签

Jerry

大道至简,行者无疆。

Great! You've successfully subscribed.
Great! Next, complete checkout for full access.
Welcome back! You've successfully signed in.
Success! Your account is fully activated, you now have access to all content.