Confluence数据丢失惊魂记

时间：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