blocks|key|2201155|text|请注意，快照不是备份的替代品！我只使用快照来创建短期故障恢复点，例如在服务器修补可能会损坏它的东西之前。但是我不会保存超过几天的快照，我绝不会定期地创建它们，仅仅是因为我以后可以而且可能需要它们。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2201156|请注意，大多数虚拟化感知备份软件也使用快照的自动化方式，使VM在备份之前保持一致的只读状态。但是，即使这样，一旦备份工作完成，快照也会再次被删除。|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|E|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|F|8|@]|9|@]|A|$]]]|D|$]]

Be aware that snapshots are not a replacement for backups!
I use snapshots only for creating short-term failback points, e.g. before a server is patched with something that might break it. But I won't keep snapshots for longer than several days, and by no means I would create them on a regular basis, just because I can and might need them later.

Please note that most virtualization aware backup software also use snapshots in an automated way to bring a VM to a consistent read-only state before backing it up. But even then the snapshot is deleted again as soon as the backup job has finished.

blocks|key|2201139|text|快照不是设计成常规检查点的，也不是备份解决方案。如果让它们太多(比如空间不足、存储速度慢，在一些情况下还会导致腐败)，您可能会有几个问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

Snapshots are not designed to make regular checkpoint and are not a backup solutions.
You can have several issues by keeping them too much (like out of space, storage slow-down, and in some few cases also corruptions)

blocks|key|2201022|text|通常，磁盘性能(以及VM存储的大小扩展)是快照的关注点，因为磁盘现在被划分为平面磁盘和快照磁盘(可能是多个快照磁盘)；当没有快照时，一个简单的磁盘操作可能会大大膨胀，可能需要处理基本和(多个)快照磁盘上的数据(这些磁盘与基本磁盘或其他磁盘不相邻；增加了许多额外的查找时间)，需要比在平面磁盘上更多的IO时间。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2201023|评估您的磁盘性能；如果它对您没有显着影响，那么快照就会消失。|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|E|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|F|8|@]|9|@]|A|$]]]|D|$]]

Generally, disk performance (and size expansion of the VM's storage) is the concern with snapshots, as disk is now split between the flat disk and the snapshot disk (potentially multiple snapshot disks); a simple disk operation when there is no snapshot can significantly balloon, potentially needing to work with data on both the base and (multiple) snapshot disks (which are not contiguous with the base or each other; adding much additional seek time), requiring a lot more IO time than on a flat disk.

Evaluate your disk performance; if it doesn't impact you significantly then snapshot away.

blocks|key|2201200|text|快照可用作执行维护活动时保持回滚点的机制，但不应用作备份VM的机制。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

Snapshots can be used as a mechanism to keep a rollback point when performing maintenance activities, but should not be used as a mechanism to backup the VM.

blocks|key|4494939|text|这是最佳做法得出的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4494940|http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1025279|offset|length|4494941|链中所支持的快照的最大支持量为32。但是，VMware建议您在链中只使用2-3个快照。|4494942|24-72小时内不要使用单个快照。不应为了应用程序或虚拟机版本控制的目的而长时间维护快照。这样可以防止快照越来越大，以至于在删除/提交快照到原始虚拟机磁盘时会引发问题。获取快照，对虚拟机进行更改，一旦验证了虚拟机的正确工作状态，就删除/提交快照。|4494943|尤其要努力在高事务虚拟机(如电子邮件和数据库服务器)上使用快照。这些快照可以非常迅速地增长，填补数据存储空间。一旦您验证了正在测试的进程的正确工作状态，就在这些虚拟机上提交快照。|4494944|链中过多的增量文件(由过多的快照引起)或较大的增量文件可能会导致虚拟机和主机性能下降。|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|2T|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|U|8|@]|9|@$D|V|E|W|1|X]]|A|$]]|$1|F|3|G|5|6|7|Y|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|Z|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|10|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|11|8|@]|9|@]|A|$]]]|N|$O|$5|P|Q|R|A|$S|C]]]]

This is from the best practices.

<a href="http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&amp;cmd=displayKC&amp;externalId=1025279" rel="nofollow noreferrer">http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&amp;cmd=displayKC&amp;externalId=1025279</a>

The maximum supported amount of snapshots in a chain is 32. However, VMware recommends that you use only 2-3 snapshots in a chain.

Use no single snapshot for more than 24-72 hours. Snapshots should not be maintained over long periods of time for application or Virtual Machine version control purposes.
This prevents snapshots from growing so large as to cause issues when deleting/committing them to the original virtual machine disks. Take the snapshot, make the changes to the virtual machine, and delete/commit the snapshot as soon as you have verified the proper working state of the virtual machine.

Be especially diligent with snapshot use on high-transaction virtual machines such as email and database servers. These snapshots can very quickly grow in size, filling datastore space. Commit snapshots on these virtual machines as soon as you have verified the proper working state of the process you are testing.

An excessive number of delta files in a chain (caused by an excessive number of snapshots) or large delta files may cause decreased virtual machine and host performance.

blocks|key|2201098|text|我喜欢VMWare快照！对于DEV和QA服务器来说，这是一个非常棒的特性。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2201099|在生产机器上，我从IT人员那里听到的最常见的问题是他们占用的磁盘空间。提前计划可以减轻这一点，但在生产环境中总是会有有限的限制。换句话说，您只能获取磁盘所能容纳的快照。|2201100|大多数情况下，我的客户只在需要完全备份客户操作系统环境时才会拍照。因此，例如，我们将在安装一个主要的应用程序更新之前拍摄一个快照。如果VM运行的是数据库服务器，我们可能不会快照，而只是备份内部使用的数据库。|2201101|就像上文中的Shane一样，我想说性能的影响并不那么重要，特别是如果服务器的CPU通常不是固定的，而且您可以安排在非高峰时间拍摄快照。YMMV|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|J|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|K|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|L|8|@]|9|@]|A|$]]]|H|$]]

I LOVE VMWare Snapshots! This is such an awesome feature for DEV and QA servers.

On a production machine, the most common problem I hear from IT staff is the disk space they take up. Planning ahead can mitigate this but there are always going to be finite limits in a production environment. In other words, you can only take as many snapshots as your disks will hold.

Most of the time, my customers take snapshots only when they need a full backup of the guest OS environment. So, for instance, we wil take a snapshot before installing a major application update. We probably will not take a snapshot if the VM is running a database server, and instead just back up the databases in use inside. 

Like Shane above, I'd say the performance hit is less important, especially if the server's CPU isn't usually pegged out and you can schedule the snapshots to be taken during off-peak times. YMMV.

blocks|key|4494777|text|我在这里没有提到的是VM震颤。如果您有一个非常繁忙的生产服务器，您的快照将增长很快。如果你在任何一段时间内都能打开气球，那么上面提到的气球有更大的可能发生。当您关闭该快照时，可能会出现服务中断的情况。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|4494778|当我不得不拍摄一台生产机器的快照时，通常是在开发人员在开发环境中对其进行测试之后，在服务器上更新一些软件时。快照将在非高峰时间完成，并且在成功升级后通常会在相同的维护窗口中关闭。|entityMap|0|LINK|mutability|MUTABLE|url|http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1013163^0|A|4|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@$A|N|B|O|1|P]]|C|$]]|$1|D|3|E|5|6|7|Q|8|@]|9|@]|C|$]]]|F|$G|$5|H|I|J|C|$K|L]]]]

Something I don't see mentioned here are <a href="http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&amp;cmd=displayKC&amp;externalId=1013163" rel="nofollow noreferrer">VM stuns</a>. If you have a very busy production server your snaps will grown quickly. If you have the snap open for any length of time the ballooning mentioned above has greater potential to occur. When you go to close that snapshot out there is potential for an interruption of services with the stun.

When I have to take a snapshot of a production machine it is generally when a developer is updating some software on the server, after its been tested in the development environment. The snap would be done in off peak hours and closed out generally in that same maintenance window after a successful upgrade.

blocks|key|2200968|text|可以在快照处理期间降低网络性能。但在我看来，一点点失败比失去数据要好一些。根据数据的重要性，我可能会在晚上做一次。除非你的数据非常重要，你必须每小时做一次等等。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2200969|只有您可以决定您可能丢失多少数据，如果您需要恢复。|2200970|如果你能和一张24小时前的快照生活在一起，那就坚持它吧。但是，如果您需要从还原开始至少一个小时的数据，请执行此操作。|2200971|我们每小时为主数据库服务器运行快照，因为这每小时都会发生变化。但是，我们的Exchange每12小时就会被快照一次。|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|J|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|K|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|L|8|@]|9|@]|A|$]]]|H|$]]

Network performance can be degrated during the snapshot process. But in my opinion a little bit of a perofrmance hit is better than losing data. Depending on how critical the data is I would maybe do one during the night. Unless your data is that critical that you must do Hourly etc. 

Only you can decied how much data you can lose should you need to restore. 

If you can live with a snapshot 24 hours old stick with it. But if you need your data no less than an hour old from a restore do that. 

We run snapshots hourly for our main database server as this changes hourly. But our Exchange Server is snapshotted every 12 hours.

blocks|key|4494796|text|中小型服务器，低I/O，那么是的，很好。如前所述，域控制器，无无！这也取决于你是否要求一个安静的快照。例如，对于活动的DB服务器，内存/磁盘I/O运行会导致中断(+a)超时(+b)+)。我以前见过甲骨文TNS被打断过。当然，事务已恢复，但仍不理想。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|4|5|6|7|C|8|@]|9|@]|A|$]]]|B|$]]

Small to medium servers with low I/O, then yes, fine. As mentioned above, domain controllers, no no NO! Also depends on whether you're asking for a quiesced snapshot. With an active DB server, for example, the memory/disk I/O run-down can a) timeout and b) cause interruption. I've seen Oracle TNS being interrupted before. Granted, the transaction recovered, but still not ideal.

blocks|key|4494866|text|你有三个选择。第一个也是最简单的一个是快照，然而，这并不是您的VM的正式备份。它适用于实验室环境，但不适合生产VM。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4494867|第二个选择是使用Vmware数据恢复(VDR)。这个工具对于中小型企业来说是很棒的。这比快照要好得多，但是它有一些限制，比如您可以同时备份8个VM。不错，但如果您有数百个VM，这是不合适的。|4494868|最专业的解决方案是使用VMWare的vStorage+API的解决方案。像(TSM)这样的解决方案，它扩展了VMWare的vStorage+API来为VM备份提供解决方案。外面还有其他人。当然，价格会随着使用而上涨，但这完全取决于你想做什么。我要么使用VDR，要么得到一些使用VDR+API进行备份和还原的解决方案提供程序。做你的研究并祝你好运:)|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|G|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|H|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|I|8|@]|9|@]|A|$]]]|F|$]]

You have three choices. First one and the easiest one is to take snapshots, however, this is not considered an official back of your VMs. It is good for lab environments but not production VMs.

Your second option is to use Vmware data recovery (VDR). This tool is great for small-to-medium sized business. This is a lot better than snapshots but it has some limitations, like you can backup 8 VMs simultaneously. Not bad but if you have hundreds of VMs, this is not suitable. 

The most professional solutions is the one who uses VMWare's vStorage API. Solutions like Tivoli storage manager (TSM), it extends VMWare's vStorage API to provide a solution to VM backups. There are others out there. The price goes up with the usage of course but it all depends on what you want to do. I would either use VDR or get some solution provider that uses vStorage API to do my backups and restores. Do your research and good luck :)

Is it a good idea to take snapshots of production servers at regular intervals. I am reading a lot of website that suggest that you should not take snapshots of production systems, stating that it can effect network and machine performance. Anybody have any insight on this?

See: <a href="http://communities.vmware.com/message/1047809" rel="nofollow noreferrer">http://communities.vmware.com/message/1047809</a>

VMWare Snapshots

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

定期拍摄生产服务器的快照是个好主意吗？我正在阅读许多网站，建议您不要拍摄生产系统的快照，它可以影响网络和机器的性能。有人对此有洞察力吗？请参阅：http://communities.vmware.com/message/1047809

问VMWare快照
EN

回答 10

Server Fault用户

Server Fault用户

Server Fault用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问VMWare快照EN

回答 10

Server Fault用户

Server Fault用户

Server Fault用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问VMWare快照
EN