请讨论下，如何备份给vShpere当NFS存储的win2012系统

peter1025

windows server 2012的确不错，正给环境中测试使用，挂给vShpere当NFS存储。现在碰到一个备份的问题，不知正在使用win2012当NFS存储的大大是怎么处理的？目前想到的就是：
1、用VDR/VDP之类的对各个vm进行备份
2、用win2013自带的Backup功能进行备份
3、请大大教我，感谢了！
简单的话，是不是选择第2种方式就可以了？这样备份可靠么？

TiGi

本帖最后由 TiGi 于 1-22-2013 09:44 编辑
使用第二个方式的话，很可能会遇到“文件打开”问题。
vDR、vDP就不说了。
Dell的AppAssure、VBR也是个方法 —— 前面那个因为很难搞到号，估计只有买许可一途；后面那个有和谐法。类似的备份产品还有很多，就不复述了。
如果要做到备份虚拟机内的“颗粒”，那不妨可以考虑BE2012/r2或者BE2010r3/r4 —— 前面那个因为很难搞到号，估计只有买许可一途；后面那个有和谐法 —— BE2012r2和BE2010r4尚未发布(估计本月底或者下月发布测试，3-4月左右开始正式上市) —— 按照以前的管理，SYMC的rN，可以继续使用原有的序列号的。
——————
补充一下，目前的BE2010/2012尚且不支持Server 2012，新的rN将会支持 —— 也就是说暂时无法在Server 2012上装BE主模块和BE代理。

scegg

Windows backup无法对正在操作的文件备份。比如SqlServer的数据库。对于NFS猜测可能也有类似问题，你要测测才知道了。或者问问winxp2000

remember

winxp2000想必已经测试了，这个建议你直接请教他，和谐难保在最新server 2012不出问题，毕竟和谐最新版的备份软件太少。

winxp2000

方法多了去，windows的分布式的文件系统可以对自己的文件夹备份
另外，在windows 下多挂一个磁盘，做一个软镜像（直接就是raid 1)
这些是不用额外增加成本的
如果能够买备份软件..............这个很多办法（比如说DELL的appassure)
但是我想你和大部分的网友也留意到
做vmware的备份不能单纯的备份虚拟机文件，而且需要在操作系统层面做备份才有效的
比如，你的主机，windows的，你只是把硬盘备份出来了，但是在你不断备份的时候，里面的数据库或者软件却是有问题的（硬盘备份是相当于硬件级别的备份了），备份里面也是坏的
所以，目前的备份软件一般是装在虚拟机里面的（需要装一个agent）
而vmware自带的VDP VDR就不用这个agent，只是目前没多少个人用而已
综上所述，根据你们的预算去做这个备份
另外，上次我发了几个贴，其实我发现在windows 2012环境里面，还是建立iscsi给VMware用比较好
你决定用NFS？

seanlaser

内置备份工具在2008就已经是VSS备份了，不会有文件打开的问题。不过内置备份还是有和GuestOS内的VSS无法沟通的问题，因此不具有GuestOS内的应用数据一致性。
不过但凡是有这种需要的VM都应该用GuestOS内的带有Agent的备份方式，比较保险。
要么采用从内到外从应用到备份全MS的方案，这种情况下所有的直至应用的VSS都能被协调一致性，但这很多人是无法接受的……

seanlaser

DFS是一个文件共享/分发的解决方案，强烈不推荐作为备份来用。
软Raid以前需要动态卷，现在起码StorageSpace，这些都要额外折腾，而且很多人不喜欢。
备份软件还是需要的，而且要考虑应用感知的那种。当然如果你的服务器只是做做文件共享什么的，可以不考虑应用问题。
VMware再怎么样也只是备份VM，这个从一开始的设计就决定了其使用目的。再强调一次，VM层面的备份只是为了恢复VM（可以Host层面无agent），应用层面要另外考虑（GuestOS内的Agent）。都支持的方案，嗯……不是没有，就是很贵而已（因为事实上还是有Agent）。

dilidolo

1.大多数应用并不需要crash consistent，除了数据库类。
2.除非只有Windows的环境，不然不存在VSS协调一致性。
3.如果全Windows环境，并且备份软件支持（比如Netbackup），可以做到vmware snapshot vss aware，但是会牺牲其他一些功能。
所以，我不管背后的存储用的是什么，备份只有两种。
1.agent - database类
2a.除数据库类外的，vm snapshot后存储上snapshot + 备份，再删除vm snapshot。
2b。通过vstorage api备份。
2a或2b取决于架构大小和备份软件对存储的支持。

TiGi

本帖最后由 TiGi 于 1-22-2013 19:57 编辑
我的备份策略和你的差不多(括号内是使用的目的，供其它DXJM参考)：
我是采用BE2012(包括数据库选件、虚拟化选件等，以此实现颗粒度以及数据库一致性等)、vDP（整机备份及恢复、删重）、EQL SnapShot(存储的快照，很多时候是最简单、便捷的 —— 至少EQL是这样)、EQL Replication(作为灾备的一个手段)、影卷副本(这样对于文件服务器的普通用户而言，就可以完成个别文档的恢复)。

winxp2000

真强力，3重保险

TiGi

本帖最后由 TiGi 于 1-22-2013 15:34 编辑
前面说了BE我是从7.3就开始用的(那时候为了防备千年虫)；vDP/vDR是"免费"的；EQL的复制/快照也是"免费"的。多给自己一条路，总归比发生问题了没有路走要好。
——————————————
真的发生问题，设备之类的也就是百多万的事情(即便发生问题，基本上IT也不会有啥责任)；软件许可是不会磨灭的；但是实际数据/业务数据的价值就说不准了(不值钱或者值几百、几千万、几亿都是别人说了算的)。

seanlaser

BE2012——Agent应用层面备份——文件、应用、系统恢复有保证
vDP——虚拟主机 VM层面备份——VM恢复有保证
EQL快照——存储层面——测试数据、快速数据恢复有保证
EQL 复制——容灾有保证
有层次的纵深式防护！这个结构还是很犀利的恶，当然仅适合有一定内部IT能力的组织

TiGi

本帖最后由 TiGi 于 1-22-2013 18:03 编辑
因为使用BE十多年了，整体还是比较熟悉的；而且BE还是比较容易安装和使用的。
EQL的复制、快照，其实非常简单 —— 买了EQL么就要用足他的一切特性。
vDP么，部署这关过了，随后也不难。
所以，这些对IT能力的要求并不高；而软件许可么，BE全新购买、包含各种组件/代理的话，也就是10万上下吧，持续SnS的费用也还可以；而EQL，属于算贵也不算贵的存储设备，且用足所有特性之后，就不会觉得贵。
——————————————————
今年还在考虑用AppAssure —— 对于某些应用VM执行持续性的保护 —— 据说价格不贵。
目前BE2012的问题在于备份的对象太多了，备份窗口太密集 —— 尽管我全部采用磁盘备份；
EQL的问题在于我不可能每几分钟做一次快照 —— 尽管EQL的规格、性能、负荷、存储空间都足够；
而EQL的复制，基本上只能每天复制一次 —— 更高的频度，就需要更大的链路带宽。
将某些VM迁移到两个单CPU的服务器上，许可费用也不贵，只要加一个vC基础版的许可就可以 —— 而vDP如果也位于这个集群内、备份另外一个双CPU的集群的话，可以解决鸡蛋位于篮子内的问题 —— 对于这个单CPU集群考虑用AppAssure。
————————————
两台单CPU的ESXi主机、两台双CPU的ESXi主机、一台双CPU的Hyper-V、一台单CPU的PC，最多更新一台备份服务器。外加3、4个存储。
每年换一台服务器、每一年半到两年换一个存储。......只要类似的产品依旧存在，整个架构、规划，估计可以混到我退休。哈哈。

remember

TiGi你是CIO吧？经验决定了很强势的备份容灾方案，没有天灾，打个不确切好比银行保险库的说；请教一下，异地容灾TiGi兄有何见解呢？对于对这块属于缺失非常大的部分，属于只在实验做过的简单层面

TiGi

本帖最后由 TiGi 于 1-22-2013 20:10 编辑
灾备，说难也不难。具体看你的要求的。
打个比方，假设你的备份数据复制到外置硬盘上，那准备2、3个或者10-20个硬盘，每天将备份过的硬盘带回家，将不需要保留的硬盘带回公司，这就可以实现灾备。这样的方案，一个硬盘底座200块、硬盘300-1000/个。
如果你不能忍受丢失一分一秒的数据丢失，那解决方案只能扔大钱进去。
——————————
买EQL之前，就考虑过快照、复制。然后么，一个个EQL买(目前买了三个)，启用的特性么一个个来(先快照、后复制)。
如果没有MD3000i的使用经验、没有对两个产品之间差异性的了解、没有使用EQL特性的计划/打算，那绝大部分人都会觉得EQL不值这个价格！但是像我这样，怎样用、怎样延伸扩展都计划好，那就会觉得花的钱还是有其意义的。
——————————
之所以采取多个措施，是因为2010年底的时候，在邮件服务器重装的时候，发生过问题：
我们一直使用Domino Notes。当初，邮件服务器重装(由03r2改为08r2；后来的实践表明这是一个非常正确的决策)，将所有邮件剪切走之后，我在ESXi里面建了一个Server08r2，然后重装Domino，为了确保系统准确有效，拷贝了几个邮件库进去，测试OK无误后，对原有的邮件服务器进行重装。重装一切都顺利，然后开始将迁移出去的邮件库搬回去。但是在拷贝邮件数据的时候，存放邮件数据的MD3000i的Lun，发生了不在首选控制器的错误，对于这样的错误，通常情况下，切换一下Lun的控制器即可，但是切换的时候，点击后切换后，Lun丢失了。.......捣腾了半天，Lun上的数据就是看不到。结果，大部分用户丢失了半个月的邮件数据。当然，这样的数据丢失，属于尚可忍受的范畴，还不算灾难。
这个事件的后续么.......九个月之后，看到了MD3000i的新固件，升级后，这个Lun又回来了。
这个事情之后，我一直遵守两个原则：
1、重要系统，不搞原拆原建 —— 大范围虚拟化可以很大程度地解决这个问题；
2、重要数据，没有两个以上的备份措施保障的话，不擅动 —— 因此快照、复制、备份全部上；
3、上系统、建系统之前，考虑这个系统的持久运行 —— 服务器虚拟化、存储虚拟化有助于这个需求。