本周早些时候，我的服务器上有一个“完美风暴”的时刻：两个备份工作（系统上的每个RAID10arrays都有一个备份工作）一直嗡嗡作响了18个小时，然后我的I / Ostream量持续高峰密集的应用。 结果是性能低得令人难以接受，我不得不迫使pipe理员取消备份。 （他对此一点也不高兴， “如果……我不负责任” ）
最终的结果是很多的压力，不愉快的客户，和一个非常不满的Stu。
瓶颈是磁盘利用率。 一旦工作被取消，一切都运转良好。 我可以向pipe理员build议什么来减轻对我的服务器的影响？
这里是一些血淋淋的细节：
备份命令本身 （我得到了这一点，但真的不知道这是什么意思。）
bpbkar -r 1209600 -ru root -dt 0 -to 0 -clnt xtx-le00 -class F_Full_on_Thursday -sched Incr_Fri_to_Wed -st INCR -bpstart_to 300 -bpend_to 300 -read_to 300 -blks_per_buffer 127 -stream_count 8 -stream_number 8 -jobgrpid 223932 -tir -tir_plus -use_otm -use_ofb -b svr_1259183136 -kl 28 -fso
系统
数据
1TB
应用程序
我不确定bpbkar是如何工作的，但我会使用rsync将所有文件备份到异地，然后保持同步，这将消耗非常less的资源，因为只有更改的文件才会更新。 当然，这意味着最初的备份需要相当长的一段时间，但是你已经说过你已经“哼了18个小时”了。
然后，您只需pipe理其他机器的备份数据即可。
小编辑：如果您select离开磁带备份到磁盘备份，您可能需要使用RAID6，它将提供双重奇偶校验。
我们有一个rsync live服务器系统，用于备份服务器（由廉价的1TB SATA光盘构build而成），然后对备份服务器进行完整的磁带备份。 这是非常好的：
如果您的备份需要18个小时才能正常运行，那么重新排列这些备份可能无法解决问题（除非您想每次运行备份几天）。 我倾向于将磁盘复制机制设置为另一台机器（我喜欢DRBD，我自己），然后使用LVM来获取时间点快照，备份，然后继续。 因为它运行在一个单独的机器上，（a）它可以在不影响实时应用程序的情况下尽可能地进行锤击，并且（b）它不会与磁盘IO的实时应用程序竞争，这意味着它可能运行整个很快也是如此。
有一件事我可以肯定地说：在同一台机器上执行的任何操作都会彻底破坏磁盘caching – 当备份进程读取磁盘上的所有数据以备份时（即使它只是检查m次而不是读取并检查所有的文件），这仍然是很多元数据块运行到你的caching中，那些将从caching中踢出有用的数据，并导致更多的磁盘IO比另外的保证。
bpbkar是Veritas Netbackups备份客户端。 它支持节stream，因此正常I / O和备份I / O的组合不会使磁盘饱和。 看看这里：
http://seer.entsupport.symantec.com/docs/265707.htm
有没有什么办法可以阻止你在周末进行完整备份，正如你所说的那样，系统大部分都是繁忙的工作日，还有一周内的增量备份？ 这可以帮助您在2300到0900之间的安静插槽中完成备份
另一个投票的rsync 。 我用它来每天备份一个非常繁重的文件服务器的9TB。 从来没有一个问题。
如果您担心“时间点”，请创build一个LVM快照，mount，rsync，umount，destroy。 服务器上的负载稍高一点，但比完整副本还要less（甚至更less）。
如果pipe理员说必须是肯定的，那么绝对是bpbkar ，首先对较less使用的系统执行rsync，然后从中运行bpbkar 。 不需要占用你的生产系统。
来自testing的一个错误：当我们接近ext3的8TB限制时，做了一些“拔插”testing，以确定在复制时如何通过硬件故障破坏文件。 拔下服务器，存储盒和SAN线上的插头。 复制了数以千万计的文件。
结论：
简而言之， rsync真的很好用。 任何错误可以更好地归因于您的硬件和/或文件系统。 面对同样的失败， bpbkar不会有更好的performance。
根据你发布的命令，看看上课的选项，看起来你周四正在运行一个完整的备份 – 考虑到你的使用时间表（900-2300平日），这可能不是最好的计划。
对于这样的大数据集，您应该查看完整备份的时间，以及您在一周内进行的增量备份的types。 在NetBackup中有两种增量备份：
我会考虑将该系统的备份策略转换为周六或周日的完全备份，以及本周余下时间的差异增量备份。 当有足够的时间来完成备份（没有/很less的用户），并且在less用几个小时的时间内就可以完成一个完整的备份。 这种方法的问题是恢复可能会更复杂 – 您将需要更多的磁带 – 完整磁带加上所有增量从完整的数据恢复到您需要恢复的点。
从你的问题，这听起来像你是不是非常熟悉备份系统。 我知道将系统pipe理员从备份操作员中分离出来，但是需要在他们之间进行一些讨论。 如果备份操作员不知道如何使用系统，则不能为系统形成适当的策略和时间表。
让您的NetBackuppipe理员更好地安排备份 – 为每个RAIDarrays交替周进行完整备份。
您可能还想查看合成的完整备份，因此您不需要执行尽可能多的完整备份。
一些build议：
其他的rsyncbuild议也很好 – 没有理由说为什么数据的rsynced副本不会像主服务器上的映像一样好，除非这是一个数据库应用程序。 如果是数据库types的应用程序，则应该将事务日志和备份映像复制到其他系统，并将其备份。
我会将rsync目标上的数据备份到netbackup上，但是我还会备份操作系统以及除了主要和rsync目标上的程序数据（占用空间的东西）之外的所有内容。 备份操作系统和程序数据应该既简单又快速，而且应该在不同的备份策略中。
有两个问题在起作用 – 一个是你的架构，另一个是你的实现。
您可以通过更改备份窗口或更less频繁地备份或购买更快的磁盘或networking或磁带机或将数据复制到另一个系统来轻松优化您的实施。 这些更改是有效的，适当的，并且在您的方面摩尔定律，他们可能会让您的服务永远正常运行。
您也可能正在陷入越来越频繁出现扩展问题的情况。 如果你有点担心你会越来越频繁地遇到问题，那么你就需要考虑如何重新devise你的系统来使其更好地扩展。 这样的事情不容易，但是因为它们不容易，所以在你拿到枪的时候，你需要好好计划好。
调整体系结构的示例可能涉及将所有数据移动到NAStypes系统，如NetApp文件pipe理器或运行Solaris和ZFS的盒子。 通过这样的设置，您可以备份服务器（主要是您的程序和configuration），并使用SAN的数据pipe理function来备份SAN。 这些将是快照和事务日志之类的事情。
你也可以做一些类似于archive.org的工作，你可以在很多不同的系统上存储数据，通常任何给定的数据存在于多个系统上，然后你有一个前端系统的场，无论哪个系统实际托pipe数据。
最后 – 你确定你的备份工作？ 在实时系统上运行18小时的备份会产生反映整个18小时系统的备份。 理想情况下，备份是在一个primefaces时间点反映一个系统，而不是一个疯狂的滚动备份，其中有些东西是从一个时间点开始的，而另一个则是几乎整整一天的时间。 如果你的任何数据依赖于或指向其他地方的其他数据，如果备份得到的东西中间变化，这些依赖关系将变得非常混乱，而对于这样大的数据集，你可能有100％如果可能的话，每个备份都有。