Chinaunix

标题: T级的备份兄弟们都怎么做 [打印本页]

作者: 披发头陀 时间: 2006-04-22 08:38
标题: T级的备份兄弟们都怎么做
一个扫描系统，存储图片持续增长可能最后到十几几十T的东西，用什么方式来备份比较好

作者: wangyuep 时间: 2006-04-22 09:07
从产品来讲用虚拟磁带库，同时采用适当时备份任务。

作者: orian 时间: 2006-04-22 12:47
用虚拟带库成本太高，做近线备份还可以，再配一些大带库。现在一盘磁带裸容量可以达到400G，几十个T也不过百十来盘磁带而已。ibm的3584都不需要扩展柜。\r\n\r\n如果是图片，尽管总量大，改变却很少，tsm软件比较适合，省磁带空间。

作者: prada_gu 时间: 2006-04-22 17:28
orian呀,数据那么大,怎么可能用磁带来备呢,时间窗口和RTO如何控制呢

作者: orian 时间: 2006-04-25 00:23
现在磁带海量、高速啊！80MB/s的吞吐量（还没算压缩），配上10个带机，800MB/s啊，1个T不过几分钟的事情。虚拟带库？那是骗低端用户的！（也不能说骗啦）\r\n\r\n磁盘什么速度？通常也就是几百M吧！要是配那种SATA的磁盘。。。唯一的优点是同时支持很多客户端并行。另外一些备份软件没有回收、收集功能，不希望把数据备份到多盘磁带上，因此也希望用虚拟带库。哈哈\r\n\r\n我觉得如果只有两三个磁带机的时候，客户端很多，还是需要磁盘中间做缓冲的，但不一定是虚拟带库，比如很多软件直接支持磁盘文件格式，就用文件系统好了。如果都是大数据库的海量数据，配了十个八个的带机，虚拟带库就是个累赘了。

作者: 披发头陀 时间: 2006-04-25 08:39
不知道磁带损坏的问题怎样？就是一盘磁带丢失了一部分数据，会不会整盘带子的备份都无效了？

作者: wangyuep 时间: 2006-04-25 08:56
总感觉orian对于虚拟带库的认识还处于初期阶段（不涉及个人攻击）

storage.jpg

126.48 KB, 下载次数: 1692

作者: orian 时间: 2006-04-25 08:59

最初由披发头陀发布\r\n[B]不知道磁带损坏的问题怎样？就是一盘磁带丢失了一部分数据，会不会整盘带子的备份都无效了？ [/B]

\r\n\r\n至少感觉比磁盘好。另外现在磁带又复杂的校验技术，只要不是磁带断了，出几个洞都没事。\r\n\r\n但是磁带怕灰（这个影响比较大），怕潮湿，怕干燥（这两个还没那么极端）。\r\n\r\n总体来说，如果普通环境，磁带成本比磁盘低很多，越大越低。磁盘的耗电也不可忽视（甚至是非常大）。\r\n\r\n个人建议（尚未仔细核算）：\r\n\r\n几个T以内的数据量，备份性能要求不高：\r\n带库，2个带机。\r\n\r\n几个T以内的数据量，备份性能要求高：\r\n带库，2个带机，配合几十G以上的磁盘空间，但不要太多，而且内置的磁盘都可以（有raid保护），定期做迁移。\r\n\r\n几十个T以内的数据量，备份性能要求不高：\r\n带库，根据备份窗口选择带机数量，对某些大量碎文件，客户端数量非常多（几十个以上），可以考虑用用一些磁盘空间，否则直接LANFree到磁带。\r\n\r\n如果以上操作不能用LANfree，必须走lan，那么虚拟磁带库似乎有些用途，但实际上如果备份软件支持，直接用磁盘空间好了，为什么还要把磁盘再虚拟成磁带呢？\r\n\r\n市场上一些虚拟带库可能由于是集成化的产品，包括了备份服务器等，这样不用再单独配置软件，所以其实卖的是集成备份方案，减少了集成、维护、管理的复杂性，跟是否虚拟关系不大。

作者: 迪思杰数码 时间: 2006-05-15 18:12
如果你需要我可以给你提供一些我们公司的资料

作者: vecentli 时间: 2006-05-15 18:29
我这里的磁带每盒800g。。用dell 20个slot 带库，legato驱动的。。\r\n \r\n图形扫描这种系统，file形式的增量备份就可以了。。

作者: 披发头陀 时间: 2006-05-15 22:03

最初由迪思杰数码发布\r\n[B]如果你需要我可以给你提供一些我们公司的资料 [/B]

\r\n谢谢，如果方便发到版面上给大家参考，如果不方便发到我的信箱，zql79@263.net

作者: jackpan 时间: 2006-05-17 11:54
如果是动态数据备份的话可以斟酌一下EMC的snapview（PS:成本允许的情况下），或者使用windows的shadow copy

作者: yddll 时间: 2006-05-18 00:53
对数据的实时性要求不是很高，随便用个磁带库就可以了

作者: lakher 时间: 2006-06-02 22:05
谁提供一些虚拟磁带库的资料啊，\r\n我们斑竹好象不是很清楚

作者: orian 时间: 2006-06-03 18:32

最初由 wangyuep 发布\r\n[B]总感觉orian对于虚拟带库的认识还处于初期阶段（不涉及个人攻击） [/B]

\r\n\r\n\r\n没有仔细研究虚拟带库，所以确实处于初级阶段。主要是对这个东西有反感。\r\n\r\n很多备份软件都可以支持磁盘缓冲，包括类似lanfree技术，所以虚拟带库只是简化了操作，增加了安全性。（磁盘缓冲的lanfree技术对于一些底端产品，特别是操作系统支持不好）\r\n\r\n硬盘临时存放数据还可以，长期存放，可靠性、运营成本都是个问题。1堆磁盘整天在那里转，电费也很高的，而且磁盘通常可以坏到5%/年的比率\r\n\r\n磁带也便于异地搬迁。\r\n\r\n\r\n当然，不能完全抹杀虚拟带库的意义，我觉得具体选择应当看涉及的目标。如果目标必须虚拟带库来实现，那当仁不让。如果可以简单、低成本一些，为什么额外弄个复杂的玩意儿？甚至凭空增加了很多麻烦？

作者: monkeyai 时间: 2006-06-04 13:47
那么，我现在数据库200G左右的数据，有必要用磁带设备么？现在备份都放硬盘上的

作者: orian 时间: 2006-06-04 18:32
看你需要保存的方式，以及备份策略。\r\n\r\n放到硬盘上也挺好，虚拟带库也省了

作者: monkeyai 时间: 2006-06-04 18:36
其实我是想找理由玩玩中高端设备，

作者: prada_gu 时间: 2006-06-04 19:20
我不同意orian的意见,在使用物理磁带和虚拟带库之间,还是倾向于用虚拟带库的\r\n对读写的性能还是提高很多的，而且故障率也不高；\r\n物理带库经常驱动器或是机械臂出问题，挂一盘磁带要找半天，磁带保存也容易受潮什么的而发生故障\r\n在虚拟带库上，其实就是物理磁盘上，这些都是可以避免的

作者: 兰剑 时间: 2006-06-05 14:14
学习学习，近来有朋友问我，也是TB级的备份，各位兄弟，软件硬件的实现方法告知，谢谢！

作者: prada_gu 时间: 2006-06-06 09:44
上TB的数据，如果考虑备份/恢复窗口以及恢复时间的话，最好是采用同步/异步复制的方式，备用磁盘/磁带备份的方式，只能是等级最低的了，灾难发生时，能在多长时间内恢复很难把握

作者: orian 时间: 2006-06-06 09:48

最初由 prada_gu 发布\r\n[B]我不同意orian的意见,在使用物理磁带和虚拟带库之间,还是倾向于用虚拟带库的\r\n对读写的性能还是提高很多的，而且故障率也不高；\r\n物理带库经常驱动器或是机械臂出问题，挂一盘磁带要找半天，磁带保存也容易受潮什么的而发生故障\r\n在虚拟带库上，其实就是物理磁盘上，这些都是可以避免的 [/B]

\r\n\r\n看来我们立场不同：\r\n\r\n最主要原因是我用tsm, 很少用veritas\r\n你用veritas?\r\n\r\ntsm里通常配一个磁盘存储池，磁带作为二级，因此就也就虚拟了。对于数据库一类的备份，通常是大文件，会直接写磁带，这时候lanfree写磁带的速度我觉得还不错。\r\n\r\nmount磁带的时间确实是磁带的大问题，但通常也不会超过1分钟，除非非常繁忙的备份，原来还有磁带在里面，但也不会很长时间。\r\n\r\nveritas缺省情况每个客户端写单独的一盘磁带，tsm中一个pool中大家写在一起（也可以通过参数调整），然后如果需要，后台再作整理（collection）所以磁带倒换的情况并不严重。\r\n\r\n磁带机机械手故障稍频繁，毕竟是机械的东西，但是越大型的带库稳定性越高，有一些还配备有双机械手。而虚拟带库由于其起点，不会是高端的，中、低端居多，稳定性就其设计成本不会太高。\r\n\r\n---------------\r\n当然，我绝对没有舍虚拟带库而最好磁带的想法，否则我就是硬件销售了，专门卖带机的。实际选择还是需要根据需求选择（排名不分先后）：\r\n1. 大文件还是碎文件碎文件--〉虚拟带库\r\n2. 备份客户端数量多--〉虚拟带库\r\n3. 恢复的频繁程度频繁--〉虚拟带库\r\n4. 备份的并行度高--〉虚拟带库\r\n5. 管理经验低--〉虚拟带库\r\n6. 总备份容量少--〉虚拟带库\r\n7. 钱多---〉虚拟带库\r\n8. 异地保存要求没有--〉虚拟带库\r\n9. 备份软件（看软件特性）\r\n如果选择相反，建议直接用磁带库\r\n\r\n-------------------------\r\n关于TB的备份，也没有一定的规则，看备份数据类型、备份窗口、性能要求等等，最好把情况说清楚。IT设计不是一把香灰，什么病都是一包，就是外观病症一样，也可能给你不同的药。

作者: prada_gu 时间: 2006-06-06 13:20
嗯,orian,现在市场上使用veritas的是比TSM高一些的;\r\n我具体没用过TSM,所以对它的一些特性也不大清楚，但一般大家看法，TSM备份配置复杂，恢复起来方便些；

作者: prada_gu 时间: 2006-06-06 13:23

最初由 orian 发布\r\n[B]\r\n\r\n关于TB的备份，也没有一定的规则，看备份数据类型、备份窗口、性能要求等等，最好把情况说清楚。IT设计不是一把香灰，什么病都是一包，就是外观病症一样，也可能给你不同的药。 [/B]

\r\n\r\n嗯，对的，具体采用哪种技术线路，要根据具体情况来分析，也不能一概而论的，每个用户都有自己不同的考虑的

作者: wangyuep 时间: 2006-06-06 16:41
推荐虚拟磁带库并不是要取消原来物理带库，毕竟相对于磁盘来说磁带还是有着他固有的优势；其实虚拟带库只是在客户数据量比较大，而备份窗口又比较小的情况下的一个折中的方案，用磁盘速度较快的特性，来满足客户相对比较苛刻备份的需求，然后在其他的时间再将虚拟带库的内容迁移到物理带库中去，以便作为永久的归档来使用。\r\n\r\n我的观点是物理带库是不能够取消的，虚拟带库只能是作为一个补充产品存在（至少暂时是这样）。毕竟从虚拟带库这个概念推出那一天开始就是把它定位在Nearline的产品，而不是online或者offline。\r\n\r\n我没做过TSM的东西，但是听orian说的好像和虚拟带库的原理相差不大，但是不知道这个磁盘缓冲能够设多大。

作者: vecentli 时间: 2006-06-07 15:34

最初由 jackpan 发布\r\n[B]如果是动态数据备份的话可以斟酌一下EMC的snapview（PS:成本允许的情况下），或者使用windows的shadow copy [/B]

\r\n\r\n从某种意义上来说，snapview不是真正的备份。。\r\n\r\n\r\n何况snapview只有在EMC的产品上才可以使用。

作者: vecentli 时间: 2006-06-07 15:42

最初由 wangyuep 发布\r\n[B]推荐虚拟磁带库并不是要取消原来物理带库，毕竟相对于磁盘来说磁带还是有着他固有的优势；其实虚拟带库只是在客户数据量比较大，而备份窗口又比较小的情况下的一个折中的方案，用磁盘速度较快的特性，来满足客户相对比较苛刻备份的需求，然后在其他的时间再将虚拟带库的内容迁移到物理带库中去，以便作为永久的归档来使用。\r\n\r\n我的观点是物理带库是不能够取消的，虚拟带库只能是作为一个补充产品存在（至少暂时是这样）。毕竟从虚拟带库这个概念推出那一天开始就是把它定位在Nearline的产品，而不是online或者offline。\r\n\r\n我没做过TSM的东西，但是听orian说的好像和虚拟带库的原理相差不大，但是不知道这个磁盘缓冲能够设多大。 [/B]

\r\n\r\n赞同观点..\r\n\r\n虚拟带库是备份窗口比较小的情况下的一个折中的方案。然后归档到物理带库。。\r\n\r\n我们目前没有虚拟带库，备份也不是全san的架构。。\r\n就划了一个lun充当虚拟带库的功能，以实现紧急恢复的时候\r\n能走san，不走IP.

作者: orian 时间: 2006-06-08 08:36

最初由 wangyuep 发布\r\n[B]推荐虚拟磁带库并不是要取消原来物理带库，毕竟相对于磁盘来说磁带还是有着他固有的优势；其实虚拟带库只是在客户数据量比较大，而备份窗口又比较小的情况下的一个折中的方案，用磁盘速度较快的特性，来满足客户相对比较苛刻备份的需求，然后在其他的时间再将虚拟带库的内容迁移到物理带库中去，以便作为永久的归档来使用。\r\n\r\n我的观点是物理带库是不能够取消的，虚拟带库只能是作为一个补充产品存在（至少暂时是这样）。毕竟从虚拟带库这个概念推出那一天开始就是把它定位在Nearline的产品，而不是online或者offline。\r\n\r\n我没做过TSM的东西，但是听orian说的好像和虚拟带库的原理相差不大，但是不知道这个磁盘缓冲能够设多大。 [/B]

\r\n\r\ntsm原则上可以设置无限的磁盘缓冲（操作系统支持的上限，虚拟带库也有操作系统，也有上限，所以是一样的），位置也没有要求。\r\n\r\ntsm实用一种file的设备，就如同一盘盘磁带，可以放到任何文件系统之上，当然需要做一些配置。\r\n\r\n只是现在这种磁盘缓冲对于lanfree支持不好（主要在低端windows客户端，不支持san 磁盘scsi resveration的情况下有问题），不如虚拟带库。\r\n\r\n我没有任何对于虚拟带库的“不良”看法，但有一点是绝对不敢苟同的就是：虚拟带库比磁带快。这种说法太模糊，通常是在大量的小文件的时候，虚拟带库比较快，而大文件（每个image达到几百M以上）的时候，只要配置了合适的设备，相近价格的情况下，磁带绝对比虚拟带库快。\r\n\r\n另外我也认为虚拟带库是个不错的产品，但如果只停留在“虚拟”磁带库有点大材小用，不过解决了两个备份中的问题：1。小文件备份速度；2。管理的复杂性。但实际上虚拟带库完全可以再走一步，例如做成一个虚拟的数据备份黑匣子，后端连接任何磁盘、带库，前端连接san和客户机，安装的时候自动分析系统资源，动态设置，就是把备份管理软件、备份策略设置更为简化、形象化，保存方式也多种多样，这样优点就突出了。有点类似ibm的retain 450/550之类，但它也不够好，比如不能支持任意磁盘，带库，不够“开放”。备份界面也还是没能够更人性化。更重要的是还是很贵。。。

作者: wangyuep 时间: 2006-06-08 09:39
其实虚拟磁带库我也只做飞康的产品，对于其他品牌的产品也不是很熟悉，所以我提到的虚拟磁带库基本上就是按照飞康的思路来说的。\r\n\r\n1.虚拟磁带库实际上只是一个VTL的硬件头+若干个磁盘阵列；所谓的VTL硬件头实际上就是一个安装了Linux操作系统的服务器+VTL软件，后面连接的磁盘阵列也可以是不同厂家，不同型号的产品。当然了，在VTL硬件头后面也可以直接连接物理带库，同时可以通过VTL软件来实现虚拟带库与物理带库之间的同步。而在这之中，飞康的产品仅仅是提供VTL软件而已。我们现在在市场可以看到很多的虚拟带库产品都是一整套的解决方案，实际上都是其他厂商的的一个Bundle产品，也就是说他们实际上是用飞康的VTL软件+他们自己的磁盘阵列，这样可以增加他们的利润，例如华为的VTL就是这样。\r\n\r\n2.就飞康的VTL来说它与备份软件是完全独立的两个产品，两者没有任何关系，也就是说，VTL软件不管你前端用的是什么备份软件；同时，备份软件可不识别VTL产品，从备份软件上来看，VTL与物理带库之间没有任何区别。其实我觉得这样也挺好的，如果将两者之间建立起联系的话对备份来说会觉得很混乱，容易造成错误。\r\n\r\n3.VTL还能够提供良好的远程容灾的功能。这个功能实际上就是靠两个VTL软件之间的功能来实现的。\r\n\r\n先说这么多吧，累，开始工作了

作者: prada_gu 时间: 2006-06-08 17:55
备份的话,采用硬件的肯定还是比采用软件虚拟的性能高很多,应至少能提高40%吧,TSM软件即便也能提供虚拟带库的功能, 但它的性能还是不如硬件的\r\n采用软件备份的话,理论值能到80MB/S\r\n物理虚拟带库,可以达到240MB/S的

作者: orian 时间: 2006-06-10 11:29
备份软件看怎么来配。如果做磁盘的lanfree (ibm是sanergy)，也是存储可能达到的极限性能啊，没有什么理论差别。当然，最终结果还是看到底怎么配得硬件、软件（无论是虚拟带库还是备份软件自身）、系统架构。\r\n\r\n单纯说那种技术好不太符合独立设计师、咨询专家的立场，通常背后有销售意图左右。设计师、咨询专家的最重要观点就是没有观点。\r\n\r\n例如，token ring过时了，但不一定最一个项目就不可以采用。例如客户有一台mainframe还要“利旧”，如果采用新的cip卡，可能一块卡就几十万出去了，而且不一定能装，那还不如攒点旧的token ring bridge，将就用了。当然这是个极端，现实中，看情况下菜。\r\n\r\n世人皆以善之为善，其不善也。

作者: prada_gu 时间: 2006-06-10 20:40

最初由 orian 发布\r\n[B]\r\n\r\n世人皆以善之为善，其不善也。 [/B]

\r\n\r\n精辟\r\n学习之 \r\n\r\n:right:

作者: cyr1974 时间: 2006-11-13 14:04
我认为没有哪种技术好或不好，具体取决于客户需求，只有最适合的就是最好的。

作者: piner 时间: 2006-11-14 08:36
只要适合就成，我们现在先备份到近线存储，再备份到磁带，也算是假虚拟\r\n

作者: cyr1974 时间: 2006-11-17 09:35
关键这些文件都是小文件，而且不定期使用，数量又非常大，这样的话对备份是个挑战。每天当然不可能全备，增量备份的机制就非常重要了，每天首先找到增量，然后再背出来，具体备到带库还是磁盘上我想就增量备份来说速度都不是问题，关键是确认增量的时间与以后从介质上恢复某个具体文件的时间

作者: 传真天下 时间: 2006-11-18 19:05
我们的做法是：\r\n\r\n\r\n采用HP的VSL 1002虚拟磁带库作近在线备份，吧VSL1002虚拟成了一个大的磁带库，可达到9.6个T以上，我们测试的备份速度和以太网一样快，然后选用了HP的LTO 2代技术的HP MSL2024磁带库，选用的是960的磁带机，每秒可到80M的速度，可以达到9.6T，如果压缩最大可到2倍的9.6T，我们是作的VOD流的备份，存储也是HP的，感觉用的不错。

作者: CHOSiN 时间: 2006-11-18 21:15

最初由 cyr1974 发布\r\n[B]关键这些文件都是小文件，而且不定期使用，数量又非常大，这样的话对备份是个挑战。每天当然不可能全备，增量备份的机制就非常重要了，每天首先找到增量，然后再背出来，具体备到带库还是磁盘上我想就增量备份来说速度都不是问题，关键是确认增量的时间与以后从介质上恢复某个具体文件的时间 [/B]

\r\n\r\n磁带向外读小文件非常之慢，特别是没有特定的使用规律，建议用磁盘或虚拟带库做中介。但无论怎样，小文件碰到磁带，就是个慢。\r\n\r\n大文件还好，尽管有频繁retrieve的时候性能也不太好，但由于文件大，导回来的时间和换带能贴补一下。\r\n\r\ntsm的hsm功能可以利用一下，能自动backup和restore，做几个磁盘池。sata的

作者: cobalt 时间: 2006-11-20 12:24
hsm还需要改进，目前功能还是太简单。

作者: insyde 时间: 2006-11-28 17:34
我们用磁盘阵列备份，数据量2、30T左右，备份和恢复即高效又可靠。

作者: wangyuep 时间: 2006-11-29 09:01

最初由 insyde 发布\r\n[B]我们用磁盘阵列备份，数据量2、30T左右，备份和恢复即高效又可靠。 [/B]

\r\n\r\n就是安全性差了一点。

作者: bowieco 时间: 2006-12-01 14:22
还是推荐采用磁带库，可以考虑多驱动器和扩展，虚拟带库绝对是骗人的东西，虚拟化存储是可以考虑的。磁带的生命周期是磁盘比不了的

作者: bei_zj 时间: 2006-12-08 10:12
做过小文件的备份，veritas备份IBM3583磁带，恢复时是个问题~`慢

作者: nj_zhaoxu 时间: 2007-01-31 12:52
采用分级备份方式吧\r\n\r\n在线的数据在磁盘阵列柜中无可厚非,raid 5/6.\r\n\r\n近线建议采取虚拟磁带库来做,可以采用备份软件加插件的方式也可以购买硬件虚拟带库,后者预算要求稍微高点\r\n\r\n离线的1-2个driver的LTO3的带库比较适合TB级的备份.\r\n\r\n具体实际的备份还要根据环境和数据块来选择

作者: njzq 时间: 2009-05-21 13:44
现看看以后说不准会用上

作者: humen001 时间: 2009-06-05 23:36
建议还是使用虚拟带库，这么大的数据量，而且是非结构化数据，不适合常规磁带备份方式

作者: andraw_lzp 时间: 2009-06-06 00:35
仔细学一学，以后会用得着

作者: pmt_dec 时间: 2010-12-28 13:54
{:4_437:}

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)