[讨论]直接copy ebd和stm恢复的可行性

huanglr

一.相同OS<br>
1.系统win2k+ex2k繁体.<br>
2.新装一台server并做AD及装上EX.<br>
dc name和ad和旧系统不同,直接copy旧系统的*.ebd和*.stm到新系统,路径一样,MOUNT OK.<br>
3.新建USER,重新帮定MAILBOX,测试户的MAIL还在.<br>
<br>
二.不同OS<br>
1.原系统win2k+ex2k繁体.<br>
2.新系统win2003+ex2003,英文.<br>
dc name和ad和旧系统不同,直接copy旧系统的*.ebd和*.stm到新系统,路径一样,MOUNT OK.<br>
3.新建USER,重新帮定MAILBOX,测试户的MAIL还在.<br>
<br>
我已经测试OK,请问大家有没有类似用COPY的方式修复MAIL资料.

cs_vitamin

硬拷肯定会出现奇怪的问题，毕竟不是GHOST

x278384

不错!帮顶!

钉子

下面的KB讨论类似的问题，请大家参考：
How to move a database to another Exchange Server 2003
http://support.microsoft.com/kb/555603/en-us

fz500

試過了Mount不起來，會出現與資料庫的訊息不一致，無法讓我mount

最後用Ontrack Powercontrols來進行救援，ok~~

[ 本帖最后由 fz500 于 2007-6-16 14:17 编辑 ]

pieazhang

我们之前也碰到过这样的问题，我把*.ebd和*.stm拷贝过去里面有很多文件打不开.有的是可以开的.在公共资料夹问题更明显.有的文件夹权限设置的太严格,这样拷贝就容易出问题.个人认为最好找其他的办法恢复.

yangzok

受益匪浅啊

abcdxy

确实受益非浅！

lcayy

楼上的说得好，受益非浅！

yinjie

呵呵，，看来大家没有理解什么叫DR（灾难恢复。灾难恢复不是等发生灾难以后才做的事情。楼主的这种做法其实也是要在灾难发生之前就要做准备的，如果你依仗可以COPY恢复，就不去管拉，我估计你也会死得很难看的。这点我想不用再说例子了吧。<br>
<br>
这种方法我在至少2个月前就提出过了（并不是什么新东西），在微软的官方资料中也提到过，不信我拿资料给你看。但是也不止一次的提到我上面说的危险性，在官方提供的WP中。专门有一篇是介绍EXCHANGE存储结构的，在WINMAG杂志上也有一个主题是介绍这个的，有兴趣的可以看看。EXCHANGE存储结构就是一个ESE的数据库引擎，它和数据库一样，也是两段提交的。所以也有日志、检查点文件和数据库文件。你不要以为它只是个文件。你对数据库会这样来恢复吗（当然我告诉你，数据库这样也可以恢复），那就是了。你为什么对待数据库那么重视呢。而对待同样是数据库的活动目录、EXCHANGE就不管不问呢？这就是意识问题。我不想谈那么多（会有人说我说的是废话的）。<br>
<br>
作为数据库系统，都有一个校验机制，通过检查点文件来对日志里的信息进行校验，校验成功的日志才能被删除（事实上是通过备份来确认这一校验的），有关知识，我就不班门弄斧了。你只复制了数据库文件，而没有对相应的日志饿检查点文件做处理，就很有可能会丢失重要的信息，比如上文所说的公共文件夹的权限信息。在繁忙的业务系统中，这样的恢复不仅要中断业务系统的运行，还可能丢失数据、权限等重要资料。你觉得它比正常的恢复来的好吗（我怎么不觉得？）<br>
<br>
微软给我们提供了太多的东西，使得我们太依赖他了。我承认。但微软提供的标准备份和恢复手段是最完整的，最安全的，你为什么不用呢？我只能说你……<br>
<br>
还是那句话，我们讨论的不是一个技术实现问题，而是一个IT工作者的敬业精神、认真精神、负责精神。如果你平时有制订合理的备份措施，也按照做了，我想以上的一切的一切都和你没关系。如果你整天除了泡MM就是上网，我想你迟早会死的，而且迟死不如早死。免得贻害大家