服务器 Gind.cn

服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器

Windows DFSR – 更改复制的目录权限,现在有超过一个星期的350,000积压

问题:有没有办法使这个35万文件的积压工作更快完成? 对于几乎每个文件,唯一的变化是每个受影响文件的ACL更改。 一些文件已经改变了内容,但在这种情况下并不常见。 这可能是固定的。 我将在一段时间和validation后编辑这个文本以确认成功/失败。 在这个问题文本的末尾,我已经详细介绍了最近可能修正的变化。 我们有一个DFSR复制组,大约有45万个文件,占用1.5TB的空间。 在这种情况下,有两台距离大约500英里的Windows Server 2008 R2服务器。 还有其他服务器,但它们不参与此复制组。 服务器ALPHA是主要的服务器,是大多数工作人员使用的服务器。 服务器BETA是远程办公室的服务器,不太繁忙。 以下是此复制组 (在Google Drive上托pipe的PNG) 的积压图表,显示慢同步进度。 我需要删除该复制组的根目录中的权限条目,这当然是在大多数子文件夹中inheritance的。 我在服务器ALPHA上做了这个改变。 在此之后,DFSR有35万个文件积压。 已经有一个多星期了,现在是26.7万。 唯一改变的(最初)是单个权限更改。 这就是发生了什么事(这不是解决scheme,只是解释导致此问题的原因): http : //blogs.technet.com/b/askds/archive/2012/04/14/saturday-mail-sack -因为,它匝数出周五夜-为-好吧换fighting.aspx#DFSR 在服务器BETA上发生的任何更改都会非常快速地复制到服务器ALPHA,因为在该方向上没有积压。 任何在BETA上更改的文件都可以顺利地进入ALPHA。 它将一个24端口全速复制,一端连接50Mbps连接,另一端连接100Mbps光纤。 每台服务器上的临时区域为100GB。 事件日志根本没有什么有趣的地方。 有一个不相关的高水位事件显示了一个不相关的复制组,既不适用于此特定的复制,也不适用于此ALPHA / BETA服务器对。 特别是没有高水位事件日志条目和连接错误。 ALPHA对复制组的看法: 带宽节省 :减less99.83%(复制30.85 MB而不是18.1 GB) 我相信自从我上次重启ALPHA和BETA的DFSR服务以来,发生了30.85MB / 18.1GB。 如果是这样,这表明,即使它花了很长的时间(比我认为应该花费的时间更长),它实际上并不是通过networking传输文件内容。 复制文件夹 :1.46TB(实际大小),439,387(文件),52,886(文件夹) 冲突和删除文件夹 :100.00GB( 已configuration大小),34.01GB(实际大小),19,620(文件),2,393(文件夹) 暂存文件夹 :200.00GB(已configuration大小),92.54GB(实际大小) 日志中(5月14日晚7点)我得到了一个高水印错误,所以从100GB升级了200GB的升级配额。 我知道微软批准的路线是增加20%,但我并没有在这方面玩弄。 […]