通常，在执行虚拟机实例的磁盘快照之前，必须同步磁盘以确保所有缓冲区都已写入磁盘。 如果客户机操作系统是Linux，则可以使用像fsfreeze这样的工具来执行此操作。 如果客户机操作系统是基于Windows的，如何确保磁盘已经同步？ 编辑 ：当我问这个问题的时候，我想到了OpenStack，所以我对下面的OpenStack支持的pipe理程序的答案感兴趣： KVM Xen的 Hyper-V的
我读的所有东西都让我觉得lvm快照是被快照（ed）的逻辑卷的直接副本，但是如果快照一个90 g逻辑卷需要10秒钟的时间，这又是如何呢？ 如果我在/ var上有一个KVM qcow2磁盘映像，并且/ var / volgroup1 / lv_var上的/ var为90 GB。 我做了一个lvcreate -L 90G -n var_snapped -s / dev / volgroup1 / lv_var，这是否意味着我可以删除var上的qcow2图像，然后挂载var_snapped逻辑卷并将其复制到那里，我将精细？ 我不明白如何快速地发生1：1的副本。
我有我的数据库备份到EBS驱动器。 我目前的备份方法是 1）排队所有写（不重要如何） 2）杀死数据库进程 3）detach + umount ebs的音量 4）拍快照 5）快照完成后重新附加 我的问题是，快照实际上需要一段时间，我可以重新附加我的EBS，而我的EC2快照处于挂起状态，否则我的风险腐败/数据丢失？
VMWare KB和多个博客指出，长时间运行的快照对性能和完整性都不利。 他们有有效的分数。 当然，这不是在ESXi上，而是在NIX服务器上的Workstation \ VirtualBox，我确实看到很多博客都在使用LVM（甚至是ZFS）快照。 假设LVM，他们实际上将他们的VMDK存储在一个LVM卷上，并且获取他们想要的所有快照。 我没有看到这个解决scheme与简单地使用VMDK快照有什么不同，但是从性能或者完整性的angular度来看，VMWare并没有提到它。 很多博客都认为这是一个快照解决scheme。 这就是长期运行VMWare快照坏，如果他们不是真正的VMWare快照，而是在LVM \ ZFS卷上的VMDK？ 澄清 长时间运行的快照是一个连续运行很长时间的快照。 假设我设置了几个Windows虚拟机，在LVM级别快照它们，并运行它们几个星期或几个月（甚至可能在整个过程中）。 当我想要回滚时，只需回滚快照即可返回到以前的版本。 VMWare KB明确指出（对于本地VMWare快照） “使用单一快照的时间不能超过24-72小时，为了应用程序或虚拟机版本控制的目的，快照不应该长期保存。 众所周知，人们运行LVM \ ZFS快照大量时间，没有不良影响。
我有一个文件服务器，我只是安装lvm。 我有两个LVM分区/ dev / fileserverLVM / home / dev / fileserverLVM / backup 我想将快照存储在/ dev / fileserverLVM / backup中。 我读过的东西都是你创build一个新的逻辑分区。 这可以避免和快照直接写入/ dev / fileserverLVM /备份？ 还是我没有select？
快照备份与传统备份有何不同？ 我知道快照备份需要最less的时间，但我不明白他们如何做到这一点。 任何人都可以向我解释这个？
我的日志中有几个错误。 我的环境是： Server 2008 R2 （服务器核心堆栈上的虚拟机）。 AppAssure Replay 4作为备份解决scheme。 在傍晚备份通常情况下，快照创build正常。 在白天和其他时间，这是一个不同的故事：快照失败：许多作家进入失败状态，超时。 AppAssure's在某个时间点AppAssure's响应是重新启动代理服务。 这个问题解决了很短的时间，但是当我今天尝试的时候，这根本就不起作用 。 我已经尝试着去重新设定编写者 – 我以为他们是由VSS Service/Microsoft Shadow Copy Provider ，但显然不是。 我应该通过Microsoft Shadow Copy Provider运行Hyper-V Shadow Copy Provider吗？ 我的错误显然是： 无法为“C：…”采取VSS快照和传输数据导致卷的VSS快照出错：DoSnapShotSet的AsyncWait失败 – 提供程序否决了快照。 事件ID： 12289 ，VSS。 'Volume Shadow Copy Service error：unexpected DeviceIOControl（\？\ Volume {guid} hr = 9×80070057，参数不正确操作：自动select不同的卷。 事件ID：22，volsnap：为卷C上的卷影副本指定的卷影副本存储卷：无法添加。 当我尝试查看C：驱动器上的“Shadow Copies”选项卡时出现一般性错误。 运行“DiskShadow列表编写器状态”给我的状态代码7，具体是什么意思：“VSS_WS_FAILED_AT_PREPARE_BACKUP”。 我相信，显然所有这些错误都是相关的。 我所看到的大多数解决scheme都是停止VSS和相关服务，注销一些模块，然后重新注册它们以重新设置编写器（对于Server 2003）。 我不同意这个解决scheme，没有理由不需要重新启动盒子就不能解决这个问题。 […]
我想通过复制LVM快照来备份我的XEN虚拟机。 我试图装载一个包含XEN客户虚拟磁盘（ext4）的快照。 以下是我所遵循的所有步骤。 我无法安装快照，似乎没有分区表。 唯一存在的卷组是“VG_XenStorage-2be5fe38-c04b-3277-4ce0-438139457a4a” 我尝试备份的虚拟磁盘是：“/ dev / VG_XenStorage-2be5fe38-c04b-3277-4ce0-438139457a4a / VHD-8c8064d2-0101-46d4-b1e5-607ad4a92621” 我的快照LV的名称是“vmbackup”。 Xen主机上的mount命令的手册页不显示支持的ext4。 因此，我用ext3磁盘做了同样的testing，但是它给了我相同的结果。 [root@ ~]# vgdisplay — Volume group — VG Name VG_XenStorage-2be5fe38-c04b-3277-4ce0-438139457a4a System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 76 VG Access read/write VG Status resizable MAX LV 0 Cur LV 4 Open LV 3 Max PV 0 Cur PV […]
直到最近，我们一直在使用SAS磁盘上的RAID10将mongo备份归档到隐藏SECONDARY服务器上的LVM快照。 目前，从500Gb数据量的快照操作需要花费很长时间。 最终档案大约是100Gb，在30分钟内创build第一个35Gb之后，磁盘速度令人难以置信。 直到存档达到52 Gb的那一刻，它工作了6个多小时。 我知道在主卷上的活动I / O期间执行LVM快照可能会减慢磁盘操作速度，但无法成像，可能会使速度减慢数十倍！ 现在我正在考虑如何提高备份的速度 。 作为一个潜在的解决scheme，我看到了在备份服务器上停止mongodb并从“离线”服务器/卷运行LVM快照的方式。 然后再次启用它，并与主副本集重新同步。 但是，这种方式可能会导致一个问题，当php-mongo驱动程序没有正确反应副本集中的服务器列表更改。 而且我们需要在所有连接的客户端上重新启动php-fpm以解决这个问题，并使php迅速看到新的变化。 请您介绍一下如何在主动I / O负载下对数据500Gb +进行mongo备份的最佳方法。 先谢谢你！
我正在尝试使用WMI获取虚拟机快照的EnabledState。 那就是我尝试获取拍摄快照时虚拟机当前的EnabledState。 到目前为止，我知道如何列出机器的所有快照。 为此我使用： winrm e wmi/root/virtualization/* -filter:"select * from Msvm_VirtualSystemSettingData where SettingType = 5" 这提供了许多关于快照的信息，但是它并没有给我虚拟机的启用状态。 任何想法我怎么能得到的？