我读了很多关于 aws ebs 的文章，很多人似乎鼓励人们冻结文件系统期间快照。但是，亚马逊的这份文档却持不同意见：
在完成期间，正在进行的快照不会受到对卷的持续读写的影响。
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html
为什么许多人在快照期间冻结文件系统，而 AWS 文档说快照不受 I/O 影响？
如果我的文件系统用于 ftp 怎么办？
如果我的文件系统用于数据库怎么办？
答案1
简短回答：这实际上取决于您在实例上运行的应用程序类型。
长答案：基本上，对正在运行的机器进行非静止快照类似于“拔掉电源插头” - 即突然、立即、意外的崩溃。
在启用 I/O 屏障的情况下运行时，现代日志文件系统无论发生什么崩溃都应该保持一致。这确实不是意味着内存中的数据不会丢失；相反，已提交的数据保证存储在持久存储器（即磁盘）上。
这实际上适用于任何正确记录日志的应用程序，尤其是符合 ACID 的数据库（非完整列表：MSSQL、InnoDB、PostgreSQL、Oracle、IBM DB2、ecc）。同样，这确实不是意味着突然断电（或恢复的、非静止的快照）不会导致任何数据丢失；相反，这意味着当（可能是隐式的）COMMIT 返回时，任何相关数据都在稳定的存储中。
使用这种日志应用程序，您不必严格地让文件系统处于静止状态。恢复快照后的第一次启动时，系统将回复其日志（文件系统和数据库），并达到一致状态。
然而，有很多应用程序确实不是正确记录他们的更新，以及要求相当于fsck返回一致状态。主要示例是 MySQL+MyISAM：这个（非常常见的）数据库引擎是不是符合 ACID 标准，因为它的写入速度非常快，这是通过批量处理不相关的 I/O 操作而实现的，而很少考虑常规 I/O 障碍。不正常关闭（即断电、系统或 mysql 崩溃、非静止快照）MyISAM 数据库在mysqlcheck/mysqlrepair执行操作之前可能无法运行。
各种指南都建议在快照之前使文件系统静止，原因正是如此：一些“未准备好的”应用程序（例如：MyISAM）可能会因突然关闭和随后的恢复而受到一定损坏，需要进行一致性检查。
底线：如果你使用启用了 I/O 屏障的日志文件系统（ext4 和 XFS 上的默认设置）和符合 ACID 标准的数据库，您可以安全地拍摄非静止快照。最坏的情况下，您可能会在挂载快照时看到一些非致命错误/警告，但日志回复将使系统处于一致状态。但是，如果使用 MyISAM，最好在拍摄快照之前冻结/静止文件系统。
答案2
如果在系统运行时拍摄 Amazon 快照，则它们本身并不安全。如果您在创建快照之前关闭系统，则它们是安全的。缓存在操作系统缓冲区或应用程序缓冲区（例如数据库）中的任何文件系统数据都不会成为快照的一部分。这可能会导致无法恢复的损坏。
Linux 和 Windows 都具有操作系统提供的冻结系统（通知应用程序将其数据刷新到磁盘）的机制。一旦完成，就会执行解冻，允许应用程序继续运行。在冻结和解冻之间，会拍摄快照。注意：大多数应用程序不支持冻结/解冻，有些应用程序的实现方式不正确。请仔细查看供应商文档。
另一个重要事项是检查应用程序存储数据的位置。按照最佳实践设计，数据库将其数据、日志等存储在不同的文件系统上。这意味着您可能在不同的时间为一个卷创建快照，而不是另一个卷创建快照（可能需要将其作为一组快照才能成功恢复应用程序及其数据）。
关键是要了解崩溃一致性快照与应用程序一致性快照之间的区别。
这是一篇有关 EBS 快照的文章，解释了这些差异。
[Michael 评论后的更新]
快照实现了写时复制 (COW)。一旦启动快照，就可以修改文件系统。如果文件系统写入磁盘块，COW 子系统会将原始块复制到其内部缓存，以便在快照期间可以修改文件系统。
在快照期间无需冻结文件系统。在创建快照期间，将创建/复制必要的卷数据结构，因此无需冻结。根据系统和缓存在内存中的数据量、操作系统和应用程序日志的大小等，冻结/快照/解冻周期可能只需几秒钟。
这是一篇介绍各种快照技术的文章，其中包括对写时复制的解释：