Chinaunix

标题: symantec SF在进行镜像复制的时候,是否要对原有数据进行格式转换 [打印本页]

作者: sofsys    时间: 2010-12-20 18:13
标题: symantec SF在进行镜像复制的时候,是否要对原有数据进行格式转换
如题

记得在NBU数据备份的时候,都要将数据转化成适应NBU格式的数据,这样才能够进行数据的备份与恢复,数据可用,那么SF是否也需要这样呢?
作者: mike79    时间: 2010-12-20 18:15
晕,怎么把镜像和复制放一起说了?一个是VxVM volume mirror,另一个是VVR,不一样的。
作者: boyyang    时间: 2010-12-20 18:17
vvr也要在vxvm的基础上r,r原有的卷不行的。
作者: sofsys    时间: 2010-12-20 18:19
呵呵,表达有误,谢谢赐教
作者: 无牙    时间: 2010-12-20 18:20
NBU备份不牵扯到各式转换。SF和NBU是两回事。
作者: sofsys    时间: 2010-12-20 18:20
那用不用将用户原有的数据格式进行转换一下,才能用呢?
作者: boyyang    时间: 2010-12-20 18:21
需要转换。
作者: sofsys    时间: 2010-12-20 18:23
换汤不换药啊,这样的话,用户原有的数据保证就存在风险啦!
作者: mike79    时间: 2010-12-20 18:28
SF For AIX上面有命令可以将LVM VG转为VxVM DG,不过我没用过,也不太看好这种功能。万一转不成丢数据了,你该找谁?
作者: sofsys    时间: 2010-12-20 18:30
对,这就是SF的一大弱点啊,希望能早点改进。

另SF 的CDP说的挺好的,到底他是不是真正能够不限制快照的那种CDP?
作者: sofsys    时间: 2010-12-20 18:31
还有,这种CDP或者镜像技术,是基于块级数据来解决传输与去重么?
作者: boyyang    时间: 2010-12-20 18:32
装上,就别想卸载了,卸了以后,原来的格式不会变回来的。
作者: sofsys    时间: 2010-12-20 18:34
呵呵,这就是霸气,IBM和EMC等MIRRO SNAPshot是不是也存在这个问题?兼容性差
作者: mike79    时间: 2010-12-20 18:37
镜像技术没有去重之说吧?VVR才有这方面的考虑,不过也是在复制断掉之后的重同步。
作者: boyyang    时间: 2010-12-20 18:44
对,这就是SF的一大弱点啊,希望能早点改进。

另SF 的CDP说的挺好的,到底他是不是真正能够不限制快照的 ...
sofsys 发表于 2010-12-20 18:30



    据说是filestor CDP,也就是基于文件级别的,具体能恢复到什么粒度就不知道了。问赛门销售吧,让赛门也来回答回答。或者诋毁一下,吸引一个塞们总级人物出来,嘿嘿。我很期望。
作者: 无牙    时间: 2010-12-20 18:48
赛门总级的应该不来这。

另外SF没有CDP。
作者: sofsys    时间: 2010-12-20 20:23
搞混了,应该是NBU的CDP,不好意思,那么版主肯定熟悉NBU7的CDP和去重技术了?
作者: 无牙    时间: 2010-12-20 23:11
NBU的CDP说实话不怎么样。CDP对系统的开销比较大,不是什么系统能适合用的。
其他厂商的CDP没用过,不知道是不是也这样?
作者: sofsys    时间: 2010-12-20 23:43
NBU的CDP说实话不怎么样。CDP对系统的开销比较大,不是什么系统能适合用的。
其他厂商的CDP没用过,不知道 ...
无牙 发表于 2010-12-20 23:11



    不过NBU7的PPT上说的很好,说基本上不占用主机资源,我见过的CDP,在数据初始化时占用大概20%的CPU以及10%强的内存,等运行起来时,基本上看不到占用资源的痕迹。
作者: ry715    时间: 2010-12-21 08:48
SF 到底要不要做格式转换,似乎也是看平台的吧,而且是不是真的装了就不能用,也得看相应的环境吧,这个可以请无牙版主来回答一下,我的影响中,windows是肯定要做相应转换的,但是AIX还有其他有的系统中似乎是可以在原有的文件系统上加一个“壳”,对原有数据并没有影响,而且并不取代原有的卷管理系统,可以卸载。版主在否,给个结论呗,你对SF应该比较了解了。
作者: mike79    时间: 2010-12-21 09:44
SF 到底要不要做格式转换,似乎也是看平台的吧,而且是不是真的装了就不能用,也得看相应的环境吧,这个可以 ...
ry715 发表于 2010-12-21 08:48

AIX中不取代LVM,也就是LVM VG和VxVM DG可以共存,当然是管辖不同的磁盘
另外也可以卸载
至于说对已有的JFS2加壳,这个大概不行吧。我记得是可以把LVM VG转为VxVM DG,是否能转回来不太确定。
作者: ry715    时间: 2010-12-21 09:49
这个事情我也不确定,所以需要由版主出来解释一下,别我说错了,又误导别人,然后又被XXX,那就不好了。
作者: netbackup    时间: 2010-12-26 19:31
SF For AIX上面有命令可以将LVM VG转为VxVM DG,不过我没用过,也不太看好这种功能。万一转不成丢数据了,你 ...
mike79 发表于 2010-12-20 18:28



SF提供的转换工具非常成熟,在转换前工具本身就提供有严格检测机制确定生产系统盘是否满足转换条件,工具在转换前会自动备份私有区的元数据信息。所谓的数据转换,需要理解的转换对象并不是你生产系统的真实数据,仅仅是对磁盘私有区的操作行为。
至少SF在中国的电信级业务系统的应用案例中,如BOSS/BI/CRM等实施案例中到目前为止还没有遇到过因为数据转换丢失数据的现象。  所有这些应用案例中数据库/应用或文件系统的数据量很多都是>10TB级的,也有高达100TB级的系统。无论是HP HP-UX、IBM AIX还是SUN Solaris平台,都有成功实施的案例。

所有的数据迁移工具都不是绝对的安全,不要把数据的安全寄托于某一种工具,即便你使用传统的dd或备份软件迁移数据,或其他迁移工具,都有存在相似的数据丢失风险,因此,最重要的是你是否有严格的预检测机制、是否有完整的数据保护方案,是否有完善的回退机制和方案。
作者: netbackup    时间: 2010-12-26 19:42
如题

记得在NBU数据备份的时候,都要将数据转化成适应NBU格式的数据,这样才能够进行数据的备份与恢复, ...
sofsys 发表于 2010-12-20 18:13


XD,你先搞清楚一个概念,备份软件是不涉及数据转换的。
作者: mike79    时间: 2010-12-26 19:57
SF提供的转换工具非常成熟,在转换前工具本身就提供有严格检测机制确定生产系统盘是否满足转换条件, ...
netbackup 发表于 2010-12-26 19:31

你自己也说了,数据转换是对磁盘头部的元数据区做操作,就是找到LP和PP的映射表,所以那些那些10T、100T的案例其实说服力不大。
我对这种转换功能不看好是因为异常情况,比如在转换过程中被kill了,或者系统掉电了,或者磁盘发生故障了等等。
用传统的备份恢复方法,至少原来数据都还在
作者: netbackup    时间: 2010-12-26 20:03
你自己也说了,数据转换是对磁盘头部的元数据区做操作,就是找到LP和PP的映射表,所以那些那些10T、100T的 ...
mike79 发表于 2010-12-26 19:57


XD,我前面已经说了,你仔细看看第三段话的意思。
作者: mike79    时间: 2010-12-26 20:07
XD,我前面已经说了,你仔细看看第三段话的意思。
netbackup 发表于 2010-12-26 20:03

这段话我看了,太空了,说了等于没说。
我觉得采用传统的备份恢复时间会更长,空间占用会更大,过程会更繁琐,但是数据更安全。或者你说说看,采用传统的备份恢复手段,怎样的情况下会发生类似的数据丢失?
作者: netbackup    时间: 2010-12-26 20:29
这段话我看了,太空了,说了等于没说。
我觉得采用传统的备份恢复时间会更长,空间占用会更大,过程会更 ...
mike79 发表于 2010-12-26 20:07


XD,既然你已经看了,我想你应该是理解那段话最后一部分信息的含义。任何事情都没有绝对的安全,我们需要做的就是尽可能的做好数据保护方案,系统回退方案,应急处理方案等等。相信你做项目实施的时候,你会做很多前期准备工作。
不要把所有的鸡蛋放在一个篮子里,也不要把所有的希望寄托于某一种工具。
作者: boyyang    时间: 2010-12-26 20:32
矫情
作者: 无牙    时间: 2010-12-27 08:13
矫情
boyyang 发表于 2010-12-26 20:32



   
作者: ry715    时间: 2010-12-27 08:48
为什么要把NBU的备份和SF的格式转换拿出来对比呀,这个难道不是关公战秦琼???




欢迎光临 Chinaunix (http://bbs.chinaunix.net/) Powered by Discuz! X3.2