[讨论]直接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资料.

zfzy

如果某天硬盘突然挂掉，*.edb&*.stm无法COPY出来，怎么办？<br>
MOUNT一个空的数据库？

huanglr

晕,难到你们的SERVER没做MIRRO的吗?做MIRRO通常可以防止坏掉一个硬盘系统不能用的可能性.

yinjie

你干脆组个群集更合适，

ruchen

楼上的兄弟，<br>
<br>
你那个旧的邮件资料还在吗？

yinjie

不好意思，有太多的人恶意使用FTP资源，所以FTP资源实行登记使用跟踪制度，需要的请与我联系并说明清楚理由并保证不传播资料，方可得到访问权，访问权当月有效，每30天更改一次。

钉子

冷酷在我们QQ群中说到这个经验时，我第一的反应是不太相信，然后我请冷酷和大家分享一下这个经验，希望通过它发起大家的讨论和实践，先不说可不可行，不过通过这件事，我到是有两点感想，想和大家分享下：<br>
1.创新。2.中毒太深。<br>
我们看了不少微软的书，学也受到不少微软的教育，可能了解的太多，反到越是按规则来办事，按白皮书，按KB来发现问题和处理问题。冷酷的方法，让我想到了另一个侧面，虽然我到还在还不赞同使用这种方式来处理灾难恢复的问题，但我想学会转换思维看问题，解决问题，是一个飞跃。<br>

yinjie

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

lcayy

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

abcdxy

确实受益非浅！