一个用onbar进行不完全恢复的比较诡异问题，大家看看是怎么回事？

wysfenghuo007

不完全恢复的比较诡异问题，大家看看是怎么回事？
是这样的，我用onbar -b -L 0 做了整库的0级备份，然后进行基于日志的不完全恢复。

测试步骤是：首先，将服务器停止，onmode -kuy,然后运行onbar -r -n 679 rootdbs命令，结果查看bar_log发现其他的dbspace也进行了转储，怎么命令中指定的rootdbs没起作用呢？
[informix@wangysh ~]$ vi /u01/informix/bar_act.log
2009-12-03 18:10:02 9878  9876 /u01/informix/bin/onbar_d -r -n 678 rootdbs
2009-12-03 18:10:02 9878  9876 (-43020) Storage space names ignored for fake backup, whole
system backup/restore, log restore, or log salvage.
2009-12-03 18:10:02 9878  9876 Successfully connected to Storage Manager.
2009-12-03 18:10:03 9878  9876 Begin salvage for log 673.
2009-12-03 18:10:03 9878  9876 Completed salvage of logical log 673 (Storage Manager copy ID: 1443928346 0).
2009-12-03 18:10:03 9878  9876 Duplicate log unique ID 678 found for specified point-in-log restore.
Onbar is restoring to the latest log unique ID 678.
2009-12-03 18:10:03 9878  9876 Successfully connected to Storage Manager.
2009-12-03 18:10:04 9878  9876 Begin reserved pages restore (level 0 of rootdbs, Storage Manager copy ID: 1443928320 0).
2009-12-03 18:10:04 9878  9876 Completed reserved pages restore (level 0 of rootdbs).
2009-12-03 18:10:04 9878  9876 Successfully connected to Storage Manager.
2009-12-03 18:10:04 9878  9876 Begin cold level 0 restore rootdbs (Storage Manager copy ID: 1443928320 0).
2009-12-03 18:10:16 9878  9876 Completed cold level 0 restore rootdbs.
2009-12-03 18:10:16 9896  9878 Process 9896  9878 successfully forked.
2009-12-03 18:10:16 9897  9878 Process 9897  9878 successfully forked.
2009-12-03 18:10:16 9898  9878 Process 9898  9878 successfully forked.
2009-12-03 18:10:16 9899  9878 Process 9899  9878 successfully forked.
2009-12-03 18:10:16 9900  9878 Process 9900  9878 successfully forked.
2009-12-03 18:10:16 9896  9878 Successfully connected to Storage Manager.
2009-12-03 18:10:16 9897  9878 Successfully connected to Storage Manager.
2009-12-03 18:10:16 9898  9878 Successfully connected to Storage Manager.
2009-12-03 18:10:16 9899  9878 Successfully connected to Storage Manager.
2009-12-03 18:10:16 9900  9878 Successfully connected to Storage Manager.
2009-12-03 18:10:17 9896  9878 Begin cold level 0 restore logdbs (Storage Manager copy ID: 1443928323 0).
2009-12-03 18:10:18 9897  9878 Begin cold level 0 restore blobdbs (Storage Manager copy ID: 1443928321 0).
2009-12-03 18:10:19 9896  9878 Completed cold level 0 restore logdbs.
2009-12-03 18:10:19 9896  9878 Process 9896  9878 completed.
2009-12-03 18:10:19 9899  9878 Begin cold level 0 restore geo3d_dbs (Storage Manager copy ID: 1443928322 0).
2009-12-03 18:10:21 9897  9878 Completed cold level 0 restore blobdbs.
2009-12-03 18:10:21 9897  9878 Process 9897  9878 completed.
2009-12-03 18:10:26 9898  9878 Begin cold level 0 restore geo3d_data2 (Storage Manager copy ID: 1443928324 0).
2009-12-03 18:10:27 9899  9878 Completed cold level 0 restore geo3d_dbs.
2009-12-03 18:10:27 9899  9878 Process 9899  9878 completed.
2009-12-03 19:48:43 10174  10172 /u01/informix/bin/onbar_d -b -l
2009-12-03 19:48:47 10174  10172 Begin backup logical log 679.
2009-12-03 19:48:47 10174  10172 Successfully connected to Storage Manager.
2009-12-03 19:48:49 10174  10172 Completed backup logical log 679 (Storage Manager copy ID: 1443928347 0).
2009-12-03 19:48:49 10174  10172 /u01/informix/bin/onbar_d complete, returning 0 (0x00)
那位碰到过这种情况，是什么原因呢？

antyison

你在onbar回复中使用了-n选项，这是一种特殊的时间点恢复，它要求必须恢复所有的dbspace以保证数据库的一致性。所以你加的rootdbs其实是被忽略的。

wysfenghuo007

明白，谢谢。
我使用onbar -r -t "2009-12-03 14:00:00" 时恢复，提示错误：
2009-12-04 09:06:41 12788  12786 Invalid Point In Time value specified: .

不知道啥原因，怎么解决俄u？
另外，问一下，是不是基于某个dbspace 进行恢复到某个日志点的不完全恢复不能实现呀？

3sane

备份时加上-w，则时间点就没有什么限制了；否则就要查ixbar里面的记录了。
不明白你为何需要恢复某个dbs到n个log，日志是一整体的，试想如果一个表分布在多个dbs上，你只恢复其中一个dbs到指定日志，那么这个表的数据如何保持一致呢？如果只是为了恢复dbs上面的表到指定日志或时间点，建议你用onchecker吧。

[ 本帖最后由 3sane 于 2009-12-4 19:53 编辑 ]

liaosnet

原帖由 3sane 于 2009-12-4 19:52 发表
备份时加上-w，则时间点就没有什么限制了；否则就要查ixbar里面的记录了。
不明白你为何需要恢复某个dbs到n个log，日志是一整体的，试想如果一个表分布在多个dbs上，你只恢复其中一个dbs到指定日志，那么这个表 ...

是archecker ~