有几台服务器，两年没有被拆分。 在碎片整理之前，有多less百分比应该碎片化？
服务器是Windows 2003。
实际上我从来没有对我的服务器上的数据进行碎片整理。 在文件服务中，我没有看到足够的性能提升，因此值得打碎碎片整理时间。 事实上，大多数服务器都不会真正完成碎片整理，除非你把它们离线几天。 如果您使用的是相对较新的文件系统（除非您select更改Windows 2003上的默认设置），否则无关紧要。 另外，如果您正在运行任何types的条带化RAID，文件碎片并不是问题，因为它们已经在许多磁盘上分解了。
如果我有一台服务器，我真的希望数据干净和碎片整理出于某种原因，我更有可能把它备份到磁带，擦拭驱动器，并恢复它。 那会把他们全部写下来。
就我所知，对Windows服务器进行碎片整理的唯一用例就是提高备份性能。 备份只是文件服务器唯一的大规模顺序I / O，而这正是注意到分段的I / O。 I / O文件服务器在用户点击时所做的是非常随机的，在这种情况下，碎片有时可以提高性能。
在我以前的工作中，我们有一个文件服务器，我们刚刚迁移到新的硬件。 迁移后，立即进行450MB /分钟的备份（这是多年前的事情）。 两年后，该服务器备份大约300MB /分钟。 然后我们第一次对它进行整理，速度再次回到450MB /分钟。
如果您无法按时完成所有备份，并且看起来像备份的服务器是瓶颈，则碎片整理可能会有所帮助。
另一个用于碎片整理的用例是一个备份到磁盘的系统，存档在NTFS上。 这种卷上的备份和恢复完全是顺序的，并注意到碎片。 但是，如果底层存储抽象得足够（如HP EVA磁盘arrays），即使这种I / O也不会注意到碎片。
这一切都归结为大量顺序I / O是最通知碎片的I / Otypes。 如果这不是您所关心的I / O，那么整理不是一个问题。
我会同意，如果性能是你的目标，你经常不需要也不应该这样做（不断的碎片整理会造成更多的伤害）。
像任何规则一样，但有一些例外：
如果你是，或者在磁盘空间非常less（<15％免费）的地方，那么你应该在有时间的时候进行碎片整理。 即使是现代文件系统，如果有几个扇区可供select的话，也很难避免出现碎片。
如果您正在运行导致不可避免的碎片的特定types的应用程序，您可能希望投资于服务器特定的碎片整理程序（这些程序devise为在后台连续运行并在需要时/在需要时进行碎片整理）。 在Windows环境下会导致不可避免的碎片化的应用程序types将是那些在多个文件中进行大量懒惰写入的应用程序（大多数function强大的服务器devise软件避免这种情况，但是像桌面下载pipe理器，特别是某些特定的BitTorrent客户端，这种侵略性的破碎行为）
我在之前的工作中在服务器上运行了Diskeeper，因此在文件服务器和应用程序服务器上都有明显的性能提升。 我认为我们没有接近他们发表的统计数据，但我们确实看到了一些好处。
它被设置为在空闲时间和设定的时间表上进行碎片整理，以便在启动时join一些额外的位来限制影响。
一个关于智能碎片整理的工具，由IOBit。 它在后台进行碎片整理，当您的计算机空闲时，并具有深度优化和其他function。 这似乎很有用，所以你可以把它放在那里，而不必担心碎片整理。
AFAIK，RAID不受碎片影响; 尽pipe物理磁盘数量众多，但FS仍然需要为每个碎片发出单独的I / O请求，对吧？
是的，一个很好的整理系统更快地完成备份。 也同意，低空间和碎片不是一个好的组合…最好避免这种情况。
如果磁盘碎片整理时间/日程安排是一个问题，像Diskeeper Server版本之一（不是免费的！）的后台碎片整理解决scheme是一个不错的select。 它只使用空闲资源进行碎片整理，所以即使在生产服务器上也不会有任何影响。 我们这里的一些服务器使用DK，pipe理员似乎很满意。
顺便说一下，一些BT客户端（uTorrent的想到）有一个预先分配选项的torrent，所以没有在下载过程中的碎片，只要有足够的连续可用空间来容纳文件。
（我同意）的共识似乎是不要在服务器上整理碎片，因为在实际的碎片整理过程中，效益不值得。
但是，TechNet关于进行物理到虚拟转换的文章build议使用碎片整理来减less执行P2V所需的时间。 如果您有一个有限的维护时间来完成P2V，这一点尤其重要。
为了帮助最小化映像阶段所需的时间，请在源计算机的硬盘驱动器上执行磁盘碎片整理。 另外，确保源计算机和主机之间有一个快速的networking连接。