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

Jerry

大道至简,行者无疆。

Leave a Reply

Optimized by WPJAM Basic