Data Recovery
原载于 Telegram 频道。
今天来讲个关于备份的小故事。
以前有个同事之前在某使用UNIX的传统行业干了多年，他们的系统可用性要求不算高，但数据非常重要，
所以备份自然也是必不可少的。为了确保备份的安全性，
他们还雇了一家专门的保全公司定期把备份磁带从办公室拿走到该保全公司的仓库。
阅读全文…(
本文约 491 字，阅读大致需要 1 分钟
)📜
历史文件已不具备现实意义
OpenLDAP 现已转为使用 lmdb。
今天帮陈总研究一个奇怪的问题的时候误操作导致机器停止ssh响应，遂请机房重启。由于机房做的是power cycle，导致部分数据丢失。先前在配置OpenLDAP时，忘记在其中配置checkpoint，另外也没有对这台机器的LDAP进行备份，因此只好尝试从现有的数据库中恢复。冗余不做，日子甭过；备份不做，十恶不赦！
记录一下修复过程。
第一件事是把出问题的数据库做一份备份：rsync -av /var/db/openldap-data/ /var/db/openldap-data.old/
接着尝试slapcat。出现下面的错误：
1
2
3
4
5
6
| bdb(dc=********.com): file id2entry.bdb has LSN 1/1476384, past end of log at 1/374639
bdb(dc=********.com): Commonly caused by moving a database from one database environment
bdb(dc=********.com): to another without clearing the database LSNs, or by removing all of
bdb(dc=********.com): the log files from a database environment
bdb(dc=********.com): /var/db/openldap-data/id2entry.bdb: unexpected file type or format
bdb_db_open: database "dc=********.com": db_open(/var/db/openldap-data/id2entry.bdb) failed: Invalid argument (22).
|
尝试使用BerkeleyDB的修复工具修复：
1
2
3
4
5
| # db_recover-4.6 -vvf
Finding last valid log LSN: file: 1 offset 374639
recovery 0% completeRecovery starting from [1][374527]
recovery 67% completeRecovery complete at Tue Jul 13 16:41:59 2010
Maximum transaction ID 800000c0 Recovery checkpoint [1][374639]
|
slapcat发现问题依旧。搜索Google发现答案基本上都是从备份中恢复，看了一下Oracle的网站，关于这类问题也没有很好的办法。尝试将bdb文件dump出来再load回去：
1
2
3
4
5
| db_recover-4.6 -vvf
db_dump-4.6 id2entry.bdb > /tmp/id2entry.dump
rm id2entry.bdb
db_load-4.6 id2entry.bdb < ~/id2entry.dump
db_recover-4.6 -vvf
|
再次slapcat，发现对另一文件报错，用类似的方法修补之后，slapcat成功。
将slapcat的输出导出到一个文件中： slapcat > /tmp/my.ldif
然后，删除OpenLDAP数据目录：rm /var/db/openldap-data/_* /var/db/openldap-data/[a-z]*
最后，重新使用导出的ldif文件恢复：slapadd -l /tmp/my.ldif。
至此，恢复完成。
阅读全文…(
本文约 1071 字，阅读大致需要 3 分钟
)